Hi, I've set up a Cisco WLC carrying several SSIDs authenticating against freeradius using EAP-PEAP. I would like to make it so that specific users can only connect to some SSIDs. Requests contain the attribute "Airespace-Wlan-Id" which contains the numeric index of the SSID the request is associated to. I have therefore set up my users file like this: test1 Auth-Type == EAP, Airespace-Wlan-Id == 2, NAS-IP-Address == 192.168.225.110, Cleartext-Password := "test1" This, however, doesn't seem to work as freeradius seems to drop the Airespace-Wlan-Id attribute while processing the request. As can be seen in the debug trace (debug_fail.txt), the user is being matched at first ([files] users: Matched entry test1 at line 173) but isn't found later on. When I remove that one check from the users file leaving test1 Auth-Type == EAP, NAS-IP-Address == 192.168.225.110, Cleartext-Password := "test1" the request is being accepted (see debug_ok.txt). The reject is clearly coming from freeradius being unable to match the request against the users file therefore being unable to get to the cleartext password, but only when I'm checking the Airespace-Wlan-Id attribute. However, as can be seen, the attribute is present in the request and the user is matched at first, even for the failed attempt. This is freeradius 2.1.8 on Ubuntu 10.04, I'm not using inner-tunnel for EAP. I'm clearly missing something here, could somebody point me in the right direction? Thanks and regards, Bodo Bodo Bellut bodo@bellut.net | USE PGP! +-----------+ Stangefolstr. 17 Fax/Mobile: just ask | (key via server |\ O---m /| 44141 Dortmund Fon: +49-700-77-BELLUT | or on request) |/---------\| PGP: 768/FA18A639 AE 5A 47 40 5A A0 D6 15 8E 54 44 AA 8D DD 6E BD+-----------+
freerad wrote:
This, however, doesn't seem to work as freeradius seems to drop the Airespace-Wlan-Id attribute while processing the request. As can be seen in the debug trace (debug_fail.txt), the user is being matched at first ([files] users: Matched entry test1 at line 173) but isn't found later on.
Copy your outer attributes into the inner tunnel. Unless you do that all you get is a few attributes mapped from the PEAP session into a fake RADIUS request. If you uncomment "copy_request_to_tunnel = yes" in the eap-peap submodule config section, FreeRADIUS will also add the attributes from the outer request to this fake request. If you need to also send attributes back from the inner authentication, also activate use_tunneled_reply but be warned that this will drop information outside of the cryptographic tunnel, so ensure your communication channel between FreeRADIUS and the NAS is secured against eavesdropping, and watch your WLC logs for problems that might occur when the username changes in some software revs. You can avoid doing this by only setting outer reply attributes in post-auth. Note that by running both your outer and inner tunnels through the same users file, you are matching the outer username in the users file unless you filter on "FreeRadius-Proxied-To == 127.0.0.1" or whatnot. Even Windows clients allow you to change the outer user ID (in fact it is *encouraged* to use "anonymous" or such in the outer request), and that outer username is not checked against a password, so you want to be really careful here only to make decisions based on the inner tunnel username. When you use copy_request_to_tunnel, it will use the PEAP username, and will not overwrite the User-Name attribute with the one from the outer request. Another way attributes can disappear is if you are filtering them with one of the attrs.* files, so if it still does not work after trying that, make sure the Airespace-Wlan-Id is allowed in those files.
Hi, Brian Julin wrote:
freerad wrote:
This, however, doesn't seem to work as freeradius seems to drop the Airespace-Wlan-Id attribute while processing the request. As can be seen in the debug trace (debug_fail.txt), the user is being matched at first ([files] users: Matched entry test1 at line 173) but isn't found later on.
Copy your outer attributes into the inner tunnel. Unless you do that all you get is a few attributes mapped from the PEAP session into a fake RADIUS request. If you uncomment "copy_request_to_tunnel = yes" in the eap-peap submodule config section, FreeRADIUS will also add the attributes from the outer request to this fake request. If you need to also send attributes back from
That did it. I was mistaken as to what copy_request_to_tunnel did, thinking it was only relevant when using the inner-tunnel virtual server.
Note that by running both your outer and inner tunnels through the same users file, you are matching the outer username in the users file unless you filter on "FreeRadius-Proxied-To == 127.0.0.1" or whatnot. Even Windows clients allow you to change the outer user ID (in fact it is *encouraged* to use "anonymous" or such in the outer request), and that outer username is not checked against a password, so you want to be really careful here only to make decisions based on the inner tunnel username. When you use copy_request_to_tunnel, it will use the PEAP username, and will not overwrite the User-Name attribute with the one from the outer request.
So what you're saying is, an attacker could use an outer ID to have freeradius supply different/additional attributes in its reply? As I'm using reply attributes to place users into VLANs I can see where this could lead to security issues. I guess I should look into the inner-tunnel virtual server again and disable the users module on the default server. regards, Bodo -- Bodo Bellut bodo@bellut.net | USE PGP! +-----------+ Stangefolstr. 17 Fax/Mobile: just ask | (key via server |\ O---m /| 44141 Dortmund Fon: +49-700-77-BELLUT | or on request) |/---------\| PGP: 768/FA18A639 AE 5A 47 40 5A A0 D6 15 8E 54 44 AA 8D DD 6E BD+-----------+
freerad wrote: So what you're saying is, an attacker could use an outer ID to have freeradius supply different/additional attributes in its reply?
Yes. And that non-attackers would do this too if they were following best practices, because they would be setting their outer usernames to something anonymous. In fact there used to be WIndows WLAN card drivers that put strange values in the outer username with no way to configure it.
I guess I should look into the inner-tunnel virtual server again and disable the users module on the default server.
Probably; it's possible to do it all in the same virtual server, but it involves a lot of manual configuration and the reasons to do it that way have been diminishing as FreeRADIUS development progressed. Once you build the mental model of the NAS<->FR conversation being the outer RADIUS wrapper and the client<->FR conversation being the inner tunnel, emulated into a RADIUS-like request, EAP inner methods make much more sense.
freerad@spambin.de wrote:
That did it. I was mistaken as to what copy_request_to_tunnel did, thinking it was only relevant when using the inner-tunnel virtual server.
copy_request_to_tunnel is about copying attributes to the inner tunnel part of the PEAP authentication method. It has nothing to do with the inner-tunnel virtual server.
So what you're saying is, an attacker could use an outer ID to have freeradius supply different/additional attributes in its reply?
If you've configured your policies that way.
As I'm using reply attributes to place users into VLANs I can see where this could lead to security issues. I guess I should look into the inner-tunnel virtual server again and disable the users module on the default server.
The default configuration includes the inner-tunnel virtual server for a reason. We STRONGLY suggest you use it. Alan DeKok.
freerad@spambin.de wrote:
I've set up a Cisco WLC carrying several SSIDs authenticating against freeradius using EAP-PEAP. I would like to make it so that specific users can only connect to some SSIDs. Requests contain the attribute "Airespace-Wlan-Id" which contains the numeric index of the SSID the request is associated to.
I have therefore set up my users file like this:
test1 Auth-Type == EAP, Airespace-Wlan-Id == 2, NAS-IP-Address == 192.168.225.110, Cleartext-Password := "test1"
Which is wrong. The "Auth-Type == EAP" comparison is useless. Delete it. The NAS-IP-Address is also causing a problem. The FAQ says to create a name and a password like this: test1 Cleartext-Password := "test1" Do that, and it will work. Then, gradually change the configuration, testing it each time. The "man" page describes this process.
This, however, doesn't seem to work as freeradius seems to drop the Airespace-Wlan-Id attribute while processing the request.
No.
As can be seen in the debug trace (debug_fail.txt), the user is being matched at first ([files] users: Matched entry test1 at line 173) but isn't found later on.
Yes, because you didn't set "copy_request_to_tunnel = yes" in the eap module. This is documented.
When I remove that one check from the users file leaving
test1 Auth-Type == EAP, NAS-IP-Address == 192.168.225.110, Cleartext-Password := "test1"
the request is being accepted (see debug_ok.txt).
The reject is clearly coming from freeradius being unable to match the request against the users file therefore being unable to get to the cleartext password, but only when I'm checking the Airespace-Wlan-Id attribute. However, as can be seen, the attribute is present in the request and the user is matched at first, even for the failed attempt.
This is freeradius 2.1.8 on Ubuntu 10.04, I'm not using inner-tunnel for EAP.
I'm clearly missing something here, could somebody point me in the right direction?
Ensure that you understand the configuration you're using. Ensure that you start off with the simplest possible configuration that works, and then gradually make it more complex. Alan DeKok.
participants (3)
-
Alan DeKok -
Brian Julin -
freerad＠spambin.de