Re: FreeRADIUS, 802.1x, and multiple user stores
I believe you shed light onto the AD situation, but one item of note is that my campus' primary user store is OpenLDAP and is what is used by our production FreeRADIUS services. What I need to do is so our primary AD forest's domain controllers can be used. An Active Directory domain authenticated host/workstation would need to use AD for the user store and anything else would go against OpenLDAP. But we also have the issue where there are separate AD forests in our campus environment. I will do some testing in my development environment to leverage ntlm_auth against our main campus AD store. -j
Date: Wed, 01 Aug 2012 10:19:25 -0700 From: Alan DeKok <aland@deployingradius.com> To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: Re: FreeRADIUS, 802.1x, and multiple user stores Message-ID: <5019651D.8060004@deployingradius.com> Content-Type: text/plain; charset=ISO-8859-1
Jonathan L Ocab wrote:
My next step is getting 802.1x working such that FreeRADIUS can authenticate users to different Active Directory user stores based on the domain provided.
That's not really how Active Directory works. The various domains should all be accessible from one local AD server. Then, you authenticate to that AD server, using the domain. The AD server figures out how to authenticate the user.
This is a fundamental limitation in AD. As a result, it's a fundamental limitation in Samba, which is AD compatible. As a result, it's a fundamental limitation in FreeRADIUS, which uses Samba for AD authentication.
What would be the best way to implement FreeRADIUS such that authorization/authentication requests are confirmed against different Active Directory domains based on the domain information provided with the username?
Use the "--domain" parameter to ntlm_auth.
Should I light up a new FreeRADIUS instance to correspond to each AD domain (or OpenLDAP) and proxy from the primary FreeRADIUS server handling 802.1x requests?
That shouldn't be necessary.
Or should I handle it at the site configuration level and load a different 'ldap' module based on the domain provided with the username?
No.
Alan DeKok.
Jonathan L Ocab wrote:
I believe you shed light onto the AD situation, but one item of note is that my campus' primary user store is OpenLDAP and is what is used by our production FreeRADIUS services.
Authenticating *only* to OpenLDAP is easy, and it works.
What I need to do is so our primary AD forest's domain controllers can be used. An Active Directory domain authenticated host/workstation would need to use AD for the user store and anything else would go against OpenLDAP.
I don't know what that means. You're using AD to store user information, and LDAP for "everything else". What is "everything else"? Why would it matter to RADIUS?
But we also have the issue where there are separate AD forests in our campus environment.
If they're completely separate, your best bet is to run one VM per AD forest. Have the VM run FreeRADIUS + Samba. Configure a central FreeRADIUS proxy to send packets to the appropriate VM.
I will do some testing in my development environment to leverage ntlm_auth against our main campus AD store.
That's the best way. If it works for ntlm_auth, FreeRADIUS can just leverage that. Alan DeKok.
participants (2)
-
Alan DeKok -
Jonathan L Ocab