[RADIATOR] AuthBy LSA and BaseDN

Heikki Vatiainen hvn at open.com.au
Thu Sep 13 14:37:54 CDT 2012


On 09/13/2012 10:24 PM, Craig Simons wrote:
> Gaah! You're right. In my mind I was referencing examples of querying AD
> via LDAP, which would obviously not apply in this case.

I thought I'd check this before you do too much work :)

> 1)  I would imagine it would only be an authby group where you'd query
> the user in AD and ContinueWhileAccept into an LDAP lookup that would
> look for the user in the tree. It would seem that each authentication
> event would require a lookup to 2 different servers, which in a busy
> production environment, I'm not sure it's worth the latency and
> complication. 

It might not be that bad. When thinking of e.g., PEAP and EAP-MSCHAP-V2,
you would get one LDAP look for each full PEAP authentication. There are
multiple messages for inner EAP-MSCHAP-V2, but you would only need to do
LDAP lookup when inner LSA return accept. This could be handled with
ContinueWhileAccept.

Based on what you wrote about option 2, I gather what would be
sufficient is LDAP lookup to check the user exists. The BaseDN would be
set to excludes projects and such. This would be easy to do with
NoCheckPassword option.

> 2) Our AD environment, like many others, delegates permissions to
> multiple administrators who all have different areas of responsibility.
> In ours, administrators can create local accounts in their OUs for their
> own projects, etc. However, all of our students/staff/etc live in a more
> tightly controlled OU that is administered centrally. We'd like to
> contain Radius look ups to this container, but it would appear that we'd
> need to add everyone into a default group. I have no idea what the
> implications are for this, so I'm not sure if it's a non-starter or not.

So the user would have to be under the tightly controlled OU which would
be the BaseDN in AuthBy LDAP2. However, if there's already a group for
centrally administered users, maybe that could be used for LSA Group check.

> I'll have to go back and think about this some more.

Please let us know how this gets solved.

Thanks,
Heikki



-- 
Heikki Vatiainen <hvn 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.


More information about the radiator mailing list