[RADIATOR] Converting from using a plaintext users file, to using LDAP

[Hugh Irvine]

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 <eivind at 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
> eivind at aminor.no
> 
> 
> _______________________________________________
> radiator mailing list
> radiator at open.com.au
> http://www.open.com.au/mailman/listinfo/radiator


--

Hugh Irvine
hugh at 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.