Authenticate to AD but only allow certain group
All, I've got authentication working nicely with MSCHAP, but now I'd like to only allow users that are members of a certain AD group. I would prefer to have this happen only when requests come from a specific client (wireless access point). In this case the idea is to have users only be able to get wireless access when they're in a specific AD group. How can I do this in freeradius? Thanks, Brian
Brian C. Huffman wrote:
I would prefer to have this happen only when requests come from a specific client (wireless access point). In this case the idea is to have users only be able to get wireless access when they're in a specific AD group.
How can I do this in freeradius?
If they're using wireless, and they're NOT in the group, reject. Use the source IP for wireless access. Use LDAP-Group for the group checks. if ((Packet-Src-IP == 1.2.3.4) && !(LDAP-Group == "allowed-for-wireless)) { reject } Alan DeKok.
Which file and section should this go in? Thanks, Brian On 02/03/2014 04:18 PM, Alan DeKok wrote:
Brian C. Huffman wrote:
I would prefer to have this happen only when requests come from a specific client (wireless access point). In this case the idea is to have users only be able to get wireless access when they're in a specific AD group.
How can I do this in freeradius? If they're using wireless, and they're NOT in the group, reject.
Use the source IP for wireless access. Use LDAP-Group for the group checks.
if ((Packet-Src-IP == 1.2.3.4) && !(LDAP-Group == "allowed-for-wireless)) { reject }
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Mon, Feb 3, 2014 at 3:33 PM, Brian C. Huffman <bhuffman@etinternational.com> wrote:
Which file and section should this go in?
I use FR from the Debian packages, so I am not exactly sure where your installed configs are. Here is where I would put it: /etc/freeradius/sites-available/default in the post-auth section: post-auth { if ((Packet-Src-IP == 1.2.3.4) && !(LDAP-Group == "allowed-for-wireless)) { reject } . . . . } -mz
On 02/03/2014 04:47 PM, Matt Zagrabelny wrote:
On Mon, Feb 3, 2014 at 3:33 PM, Brian C. Huffman <bhuffman@etinternational.com> wrote:
Which file and section should this go in? I use FR from the Debian packages, so I am not exactly sure where your installed configs are. Here is where I would put it:
/etc/freeradius/sites-available/default
in the post-auth section:
post-auth { if ((Packet-Src-IP == 1.2.3.4) && !(LDAP-Group == "allowed-for-wireless)) { reject }
. That works, but I still need to instantiate the ldap module. If I do it in post-auth, I get this error: /etc/raddb/sites-enabled/default[490]: "LDAP" modules aren't allowed in 'post-auth' sections -- they have no such method.
But I don't want to use ldap for authentication since I'm using mschap. Where should I do the initial call for ldap? Thanks, Brian
On Tue, Feb 04, 2014 at 03:30:34PM -0500, Brian C. Huffman wrote:
On 02/03/2014 04:47 PM, Matt Zagrabelny wrote:
On Mon, Feb 3, 2014 at 3:33 PM, Brian C. Huffman <bhuffman@etinternational.com> wrote:
Which file and section should this go in? I use FR from the Debian packages, so I am not exactly sure where your installed configs are. Here is where I would put it:
/etc/freeradius/sites-available/default
in the post-auth section:
post-auth { if ((Packet-Src-IP == 1.2.3.4) && !(LDAP-Group == "allowed-for-wireless)) { reject }
. That works, but I still need to instantiate the ldap module. If I do it in post-auth, I get this error: /etc/raddb/sites-enabled/default[490]: "LDAP" modules aren't allowed in 'post-auth' sections -- they have no such method.
But I don't want to use ldap for authentication since I'm using mschap. Where should I do the initial call for ldap?
If you're purely using the LDAP-Group functionality, you should be able to list "ldap" in the instantiate section of radiusd.conf. You mention you're doing wireless - you probably want the LDAP-Group check to be in the inner-tunnel post-auth section where the real user is known, not the default post-auth section. Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
On 02/04/2014 05:01 PM, Matthew Newton wrote:
You mention you're doing wireless - you probably want the LDAP-Group check to be in the inner-tunnel post-auth section where the real user is known, not the default post-auth section. Matthew
Matt, I'm not sure I follow. I tried to find a good explanation of the inner tunnel. I read the section on virtual servers, but wasn't quite sure how that applied. I'm using MSCHAP / Samba winbind to do the authentication to a Wireless AP. And I was looking to also verify that the user is a member of an AD group ("Wireless Allowed") before providing an authentication success. Can you explain why you suggested to use the inner tunnel? I'd just removed that from my sites-enabled and everything seemed to be working. Thanks, Brian
Hi,
I'm not sure I follow. I tried to find a good explanation of the inner tunnel. I read the section on virtual servers, but wasn't quite sure how that applied.
<snip>
Can you explain why you suggested to use the inner tunnel? I'd just removed that from my sites-enabled and everything seemed to be working.
the outer ID is pretty much like the outside of an envelope for mail - you get an identity..and a realm (if proxying) - but its really just to get the message to the right server.. the inner-tunnel is where the InnerID is dealt with - this is the REAL ID of the user/client which is revealed during the EAP protected phase.. and thus it cannot be spoofed as it has to be right (user/pass) to actually pass the authentication that occurs in EAP. as an example..I can have outerID - important_person@siteA.org innerID - student1@siteA.org I get authenticated as student1 ...if you base decisions in post-auth of the outer wrapper (default by default) then you're believing that I am important_person and will give me the wrong rights. alan
On 02/07/2014 04:42 PM, A.L.M.Buxey@lboro.ac.uk wrote:
the outer ID is pretty much like the outside of an envelope for mail - you get an identity..and a realm (if proxying) - but its really just to get the message to the right server..
the inner-tunnel is where the InnerID is dealt with - this is the REAL ID of the user/client which is revealed during the EAP protected phase.. and thus it cannot be spoofed as it has to be right (user/pass) to actually pass the authentication that occurs in EAP.
as an example..I can have
outerID - important_person@siteA.org innerID - student1@siteA.org
I get authenticated as student1 ...if you base decisions in post-auth of the outer wrapper (default by default) then you're believing that I am important_person and will give me the wrong rights.
alan
Alan, Are there always two levels of EAP in WPA (or WPA2) Enterprise? Where do the "outerID" credentials come from? Is that the wireless station (laptop, phone, etc.) or the access point? Thanks, Brian
Brian C. Huffman wrote:
Are there always two levels of EAP in WPA (or WPA2) Enterprise?
For TTLS and PEAP, yes. They set up a TLS tunnel between the supplicant and the server. They then send additional data inside of the tunnel.
Where do the "outerID" credentials come from? Is that the wireless station (laptop, phone, etc.) or the access point?
It's always the supplicant (laptop, phone, etc.) Alan DeKok.
All, So I finally got time to get back to this and it works! Now the only question is whether or not I'm allowing anything that I shouldn't. I'm using the freeradius rpm that came from the centos repo (CentOS 6). It seems like there are quite a few options that are enabled by default. I'm attaching the critical files (sites-enabled/default, sites-enabled/inner-tunnel, eap.conf). Is there anything I should disable to improve security? Thanks! Brian On 05/14/2014 02:24 PM, Alan DeKok wrote:
Brian C. Huffman wrote:
Are there always two levels of EAP in WPA (or WPA2) Enterprise? For TTLS and PEAP, yes. They set up a TLS tunnel between the supplicant and the server. They then send additional data inside of the tunnel.
Where do the "outerID" credentials come from? Is that the wireless station (laptop, phone, etc.) or the access point? It's always the supplicant (laptop, phone, etc.)
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Brian C. Huffman wrote:
It seems like there are quite a few options that are enabled by default. I'm attaching the critical files (sites-enabled/default, sites-enabled/inner-tunnel, eap.conf).
Don't do that. We know what's in the files. We don't need to see them again.
Is there anything I should disable to improve security?
The server is secure by default. A vague goal of "improve security" is meaningless and pointless. If you want to disable particular authentication methods, then go do that. Read the "default" virtual server, and remove the authentication methods you don't use. Alan DeKok.
Does mschap need to be enabled in both outter and inner tunnel? Thanks, Brian On 10/29/2014 03:28 PM, Alan DeKok wrote:
Brian C. Huffman wrote:
It seems like there are quite a few options that are enabled by default. I'm attaching the critical files (sites-enabled/default, sites-enabled/inner-tunnel, eap.conf). Don't do that. We know what's in the files. We don't need to see them again.
Is there anything I should disable to improve security? The server is secure by default. A vague goal of "improve security" is meaningless and pointless.
If you want to disable particular authentication methods, then go do that. Read the "default" virtual server, and remove the authentication methods you don't use.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
I don't think so. This is only for wireless WPA Enterprise. -b On 10/29/2014 03:54 PM, Alan DeKok wrote:
Brian C. Huffman wrote:
Does mschap need to be enabled in both outter and inner tunnel? Do you want to do MS-CHAP by itself, without PEAP?
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi, I'm having an issue with sql module, i want to continue in the authorize section even if the sql module fails, but is not working. I have this in the authorize section: sql if (fail) { ok } When i try radtest i see that the sql module fails (when my mysql is down) but the if condition is not respected and entire authorize section fails: rlm_sql_mysql: Starting connect to MySQL server rlm_sql_mysql: Couldn't connect to MySQL server radius@mariadb.local:radius rlm_sql_mysql: MySQL error: Lost connection to server at 'handshake: reading initial communication packet', system error: 11 rlm_sql_mysql: Socket destructor called, closing socket rlm_sql (sql): Opening connection failed (0) (0) [sql] = fail (0) } # authorize = fail Anyone has any idea what might be wrong? Best regards.
On Aug 16, 2025, at 8:17 AM, Ricardo Esteves <maverick.pt@gmail.com> wrote:
I'm having an issue with sql module, i want to continue in the authorize section even if the sql module fails, but is not working.
I have this in the authorize section:
sql if (fail) { ok }
When i try radtest i see that the sql module fails (when my mysql is down) but the if condition is not respected and entire authorize section fails:
The "fail" result causes the "authorize" section to the stopped. That's by design.
Anyone has any idea what might be wrong?
Nothing is wrong. If you want to override the fail, you have two options: # if SQL fails, then run "ok" redundant { sql ok } or sql { fail = 2 # over-rides the "stop on fail" } if (fail) { ok } Alan DeKok.
participants (7)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan Buxey
-
Alan DeKok -
Brian C. Huffman -
Matt Zagrabelny -
Matthew Newton -
Ricardo Esteves