I have a Enterasys HiPath controller that Im trying to pass an attribute to throw the user into the correct policy upon authentication. I talked with their support and they say to set the Filter-Id attribute to the name of the policy set on the controller. I did, but it doenst seem to pass. In the debug for radius I get this: [peap] Got tunneled reply RADIUS code 2 Filter-Id = "Faculty" EAP-Message = 0x03080004 Message-Authenticator = 0x00000000000000000000000000000000 User-Name = "ktest" and it goes on to: Cleaning up request 18 ID 109 with timestamp +12 User-Name = "ktest" NAS-IP-Address = 127.0.4.1 NAS-Port = 222 Framed-MTU = 1400 Called-Station-Id = "00:1f:45:7f:83:fa" Calling-Station-Id = "00:24:d6:a6:ce:ce" NAS-Port-Type = Wireless-802.11 NAS-Identifier = "TEST" Siemens-AP-Serial = "0500010143052305" Siemens-AP-Name = "AP09" Siemens-VNS-Name = "TEST" Siemens-BSSID = "TEST" Siemens-BSS-MAC = "00:1f:45:7f:83:fa" Siemens-Policy = "Students" Siemens-Topology = "TopoStudents" Siemens-Ingress-Rate = "Unlimited" Siemens-Egress-Rate = "Unlimited" I use LDAP (via eDirectory) on the backend and authentication is working fine. It pulls the correct value for the Filter-Id attribute, but it doesnt seem to take effect. The Siemens-xxx attributes are coming from the controller and you can see based on the Siemens-Policy = "Students" attribute that the student policy is still applying - not the Faculty policy as is defined in the Filter-Id attribute. I have also tried to set the Siemens-Policy attribute on the user but that did not work either. Am I missing something in the config to have this value sent back to the NAS? FreeRadius 2.1.8
Rob, You need to ensure that the value of Filter-Id maps exactly to the value of the policy that you're trying to apply. So you need to have a policy defined on the controller named "Faculty", not "faculty" or "facultY", but "Faculty". For instance, if I have a policy named "NewmanN" and I pass a Filter-Id="NewmanN" then I get: Client session MAC [00:22:6B:9A:2B:77] on AP [IRV-AP3620] with SSID [SMFC] from VNS [SMFC] with username [test.user11] with mu session timer [52549] has been successfully authenticated. Policy [NewmanN] is applied. The desired policy is applied. If I pass a Filter-Id="Newmann" then I get: Client session MAC [00:22:6B:9A:2B:77] on AP [IRV-AP3620] with SSID [SMFC] from VNS [SMFC] with username [test.user11] with mu session timer [52201] has been successfully authenticated. Policy [SMFC Auth] is applied. The default policy for that VNS is applied because there was no policy matching "Newmann". -- View this message in context: http://freeradius.1045715.n5.nabble.com/Attribute-not-passing-to-NAS-tp32894... Sent from the FreeRadius - User mailing list archive at Nabble.com.
Hi Mikal- Thanks for responding. I have it set up just like that...the policy on the controller is named Faculty. I even took LDAP out of it to make sure that the attribute was passing correctly. I have a user defined in the /etc/raddb/users ktest Cleartext-Password := "password" Filter-Id = "Faculty" When I authenticate with this user I get: Client session MAC [00:24:D6:A6:CE:CE] on AP [JRG-1FL-AP09] with SSID [TEST] from VNS [TEST] with username [ktest] has been successfully authenticated. Policy [Students] is applied. I get the same msg for an ldap user that has the Filter-Id set to Faculty as well. For comparison, on the controller my vns settings include: VNS Name: TEST WLAN Service: TESTWLAN Non-Auth policy: NonAuth Auth Policy: Students (support told me this doesnt matter what its set to...the Filter-Id will override this) Restrict policy set unchecked Enable checked I have another policy named Faculty that is assigned the AuthFaculty topology (which sets the tagged vlan). How does this compare to your setup? Do I need the restrict policy set option checked and config'd? -Rob On Thu, Dec 2, 2010 at 11:38 AM, mikal <mpm@atceast.com> wrote:
Rob,
You need to ensure that the value of Filter-Id maps exactly to the value of the policy that you're trying to apply. So you need to have a policy defined on the controller named "Faculty", not "faculty" or "facultY", but "Faculty".
For instance, if I have a policy named "NewmanN" and I pass a Filter-Id="NewmanN" then I get:
Client session MAC [00:22:6B:9A:2B:77] on AP [IRV-AP3620] with SSID [SMFC] from VNS [SMFC] with username [test.user11] with mu session timer [52549] has been successfully authenticated. Policy [NewmanN] is applied.
The desired policy is applied.
If I pass a Filter-Id="Newmann" then I get:
Client session MAC [00:22:6B:9A:2B:77] on AP [IRV-AP3620] with SSID [SMFC] from VNS [SMFC] with username [test.user11] with mu session timer [52201] has been successfully authenticated. Policy [SMFC Auth] is applied.
The default policy for that VNS is applied because there was no policy matching "Newmann".
-- View this message in context: http://freeradius.1045715.n5.nabble.com/Attribute-not-passing-to-NAS-tp32894... Sent from the FreeRadius - User mailing list archive at Nabble.com. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Rob, You shouldn't need to check the "restrict policy" option. My setup is actually using a Captive Portal for the users to enter credentials. So I start them off with a non-auth policy that uses a "Routed" topology and then once authenticated uses a "Bridge at AP" topology. So the controller is serving up the CP page, and then I'm using freeradius with a MySQL backend. Did you capture a trace from the controller interface just to ensure that the attribute/value pair is appearing at the controller interface correctly? Wireless Controller->Utilities->Wireless Controller TCP Dump Management. So my VNS setup looks like: VNS Name: SMFC WLAN Service: SMFC Non-Auth policy: SMFC NonAuth Auth Policy: SMFC Auth (support is correct, this will be overwritten if the radius-accept contains a Filter-Id value that matches a configured policy) Restrict policy set unchecked Enable checked Under VNS Configuration->Policies I have a policy: named Policy Name:NewmanN. I throw a row in my MySQL radreply table to use a Filter-Id value of NewmanN for a particular user (test.user11 in this case) and I'm off and running. If I set the Filter-Id value in my MySQL row to Newmann, or newmanN, etc. then I get the default policy applied to test.user11. The same behavior that you're seeing. "ktest Cleartext-Password := "password" Filter-Id = "Faculty" When I authenticate with this user I get: Client session MAC [00:24:D6:A6:CE:CE] on AP [JRG-1FL-AP09] with SSID [TEST] from VNS [TEST] with username [ktest] has been successfully authenticated. Policy [Students] is applied. I get the same msg for an ldap user that has the Filter-Id set to Faculty as well. For comparison, on the controller my vns settings include: VNS Name: TEST WLAN Service: TESTWLAN Non-Auth policy: NonAuth Auth Policy: Students (support told me this doesnt matter what its set to...the Filter-Id will override this) Restrict policy set unchecked Enable checked I have another policy named Faculty that is assigned the AuthFaculty topology (which sets the tagged vlan). How does this compare to your setup? Do I need the restrict policy set option checked and config'd?" -- View this message in context: http://freeradius.1045715.n5.nabble.com/Attribute-not-passing-to-NAS-tp32894... Sent from the FreeRadius - User mailing list archive at Nabble.com.
Mikal- Yes, I have done a packet trace. The Filter-Id attribute is sent on the 2nd packet of the authentication attempt, during the first access-challenge. After that, Filter-Id isnt mentioned again until after the Access-Accept packet on the Accounting-Request. However, on the Accounting-Request packet its shown as Students, not Faculty. The whole authentication process is 20 packets, excluding the accounting packets. The only thing I noticed that may be out of the ordinary is that there are 10 access-request packets, with 9 of them being duplicates to the first request. The Filter-Id attribute is only sent on the first challenge response. Im not sure if this is normal or not as I dont have anything to compare to. Do you see something similar with your configuration? On Thu, Dec 2, 2010 at 1:01 PM, mikal <mpm@atceast.com> wrote:
Rob,
You shouldn't need to check the "restrict policy" option. My setup is actually using a Captive Portal for the users to enter credentials. So I start them off with a non-auth policy that uses a "Routed" topology and then once authenticated uses a "Bridge at AP" topology.
So the controller is serving up the CP page, and then I'm using freeradius with a MySQL backend.
Did you capture a trace from the controller interface just to ensure that the attribute/value pair is appearing at the controller interface correctly? Wireless Controller->Utilities->Wireless Controller TCP Dump Management.
So my VNS setup looks like:
VNS Name: SMFC WLAN Service: SMFC Non-Auth policy: SMFC NonAuth Auth Policy: SMFC Auth (support is correct, this will be overwritten if the radius-accept contains a Filter-Id value that matches a configured policy) Restrict policy set unchecked Enable checked
Under VNS Configuration->Policies I have a policy: named Policy Name:NewmanN.
I throw a row in my MySQL radreply table to use a Filter-Id value of NewmanN for a particular user (test.user11 in this case) and I'm off and running. If I set the Filter-Id value in my MySQL row to Newmann, or newmanN, etc. then I get the default policy applied to test.user11. The same behavior that you're seeing.
"ktest Cleartext-Password := "password" Filter-Id = "Faculty"
When I authenticate with this user I get:
Client session MAC [00:24:D6:A6:CE:CE] on AP [JRG-1FL-AP09] with SSID [TEST] from VNS [TEST] with username [ktest] has been successfully authenticated. Policy [Students] is applied.
I get the same msg for an ldap user that has the Filter-Id set to Faculty as well.
For comparison, on the controller my vns settings include: VNS Name: TEST WLAN Service: TESTWLAN Non-Auth policy: NonAuth Auth Policy: Students (support told me this doesnt matter what its set to...the Filter-Id will override this) Restrict policy set unchecked Enable checked
I have another policy named Faculty that is assigned the AuthFaculty topology (which sets the tagged vlan).
How does this compare to your setup? Do I need the restrict policy set option checked and config'd?"
-- View this message in context: http://freeradius.1045715.n5.nabble.com/Attribute-not-passing-to-NAS-tp32894... Sent from the FreeRadius - User mailing list archive at Nabble.com. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
"Yes, I have done a packet trace. The Filter-Id attribute is sent on the 2nd packet of the authentication attempt, during the first access-challenge. After that, Filter-Id isnt mentioned again until after the Access-Accept packet on the Accounting-Request. However, on the Accounting-Request packet its shown as Students, not Faculty. The whole authentication process is 20 packets, excluding the accounting packets. The only thing I noticed that may be out of the ordinary is that there are 10 access-request packets, with 9 of them being duplicates to the first request. The Filter-Id attribute is only sent on the first challenge response. Im not sure if this is normal or not as I dont have anything to compare to. Do you see something similar with your configuration?" Nope, one Access-Request, one Access-Accept. I just turned off accounting to keep it as clean and simple as possible, so just a request and an accept. Sounds like this may be the heart of the issue, it sounds as though you would be fine if you just had 1 Request/Accept since that first Accept contains the Filter-Id. It seems as though that is being lost/overwritten when the second, etc. Accept is received. -- View this message in context: http://freeradius.1045715.n5.nabble.com/Attribute-not-passing-to-NAS-tp32894... Sent from the FreeRadius - User mailing list archive at Nabble.com.
Also, check your radius server configuration on the controller. Check the timeout and retry settings (might even try changing the retry value to 1). I'm set to retries = 3, timeout = 5 for this server. -- View this message in context: http://freeradius.1045715.n5.nabble.com/Attribute-not-passing-to-NAS-tp32894... Sent from the FreeRadius - User mailing list archive at Nabble.com.
participants (2)
-
mikal -
Rob Yamry