Re: [RADIATOR] Converting from using a plaintext users file, to using LDAP
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
Re: [RADIATOR] Converting from using a plaintext users file, to using LDAP
Hugh Irvine wrote: 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. My plan is to avoid the entire AuthBy FILE, if I can, so whoever is provisioning these users won't have to also edit a file, adding the users to the groups in LDAP should be sufficient. And if we need to make new levels of user access / giving special attributes to some, we'll add a new group and do a small change in radiusd.cfg I'll add the attributes with AddToReply, in the specific AuthBy block, and won't need to use an AuthBy FILE then? Regards Eivind Olsen ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Converting from using a plaintext users file, to using LDAP
Hello Elvind - Yes your approach will also work - I misunderstood your original question and thought you wanted to retain the AuthBy FILE component. The AuthBy FILE part would only be to hold the group reply attributes, which as you say can also be done with AddToReply in the simple case. regards Hugh On 25 Sep 2013, at 10:11, Eivind Olsen eiv...@aminor.no wrote: Hugh Irvine wrote: 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. My plan is to avoid the entire AuthBy FILE, if I can, so whoever is provisioning these users won't have to also edit a file, adding the users to the groups in LDAP should be sufficient. And if we need to make new levels of user access / giving special attributes to some, we'll add a new group and do a small change in radiusd.cfg I'll add the attributes with AddToReply, in the specific AuthBy block, and won't need to use an AuthBy FILE then? Regards Eivind Olsen -- 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
[RADIATOR] Converting from using a plaintext users file, to using LDAP
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
