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