Hello Elvind - Yes this is fairly simple to do with multiple AuthBy clauses - in this case with a trailing AuthBy FILE to set the required reply attributes.
Depending on how many groups you need, it may be preferable to have a group attribute in each user record rather than use memberOf. In either case you would do something like this: …… AuthByPolicy ContinueWhileAccept <AuthBy GROUP> # check users and determine group AuthByPolicy ContinueUntilAccept <AuthBy LDAP2> ….. </AuthBy> <AuthBy LDAP2> ….. </AuthBy> ….. </AuthBy> <AuthBy FILE> # apply per-group reply attributes ….. </AuthBy> ….. hope that helps regards Hugh On 24 Sep 2013, at 23:00, Eivind Olsen <eiv...@aminor.no> wrote: > Hello. > > I've very recently been given the task of migrating an existing Radiator > installation from having its users in a plaintext file (AuthBy FILE), to > authenticating against LDAP. > > This sounds straight forward enough, I'm somewhat familiar with AuthBy LDAP2. > > Now, what gets me a bit confused is this: the current users textfile has > entries with various attributes. Often it's the same attribute for many > users, but not always. For example, some have Timetra-Cmd attribute > listing read-only commands. > > Oh, and if possible, I'd prefer to _not_ store these directly in the LDAP > (if I can avoid extending the LDAP schema and avoid having to mess up the > user provisioning tool, I'd prefer that). What I'd like to accomplish > somehow is mapping the various userlevels to group-membership in LDAP. If > someone are a member of for example the group "timetra-full-admin" they'll > get a Timetra-Cmd set to one thing ,and if they're a member of > "timetra-read-only" they'll have it set to something else. Makes sense? > If I have to store the attribute values directly in LDAP, there's also a > high chance that whoever is provisioning users might make a typo of some > sorts. In other words: I don't want to "extract attribute X from LDAP, and > returns its exact value". Oh, and if I can avoid using Perl hooks, that > would also be a good thing for me :) > > One way I've thought might work is having multiple AuthBy LDAP2-blocks > chained together, with different searchfilters and replying with specific > attributes, similar to this pseudo-code: > > Auth-block1: if memberOf=timetra-full-admins" reply with attr > Timetra-Cmd="abcd", otherwise continue to next block > Auth-block2: if memberOf=timetra-read-only" reply with attr > Timetra-Cmd="efgh", otherwise continue to next block > ... > no more blocks? Reject user. > > Part of me thinks there's bound to be a better way than this, though. Can > anyone lend me a clue? :) > > Regards > Eivind Olsen > eiv...@aminor.no > > > _______________________________________________ > radiator mailing list > radiator@open.com.au > http://www.open.com.au/mailman/listinfo/radiator -- Hugh Irvine h...@open.com.au Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. _______________________________________________ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator