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
