Re: The RADIUS client has mangled the State attribute
I've reviewed the debug output and it appears to point to the attr_filter.post_proxy filter. I should mention that the defaults for the attr_filter are in use and have not been changed. Here is the output when the server is processing packets: (0) Received Access-Request Id 150 from 192.168.1.5:61168 to 192.168.1.4:1812 length 381 (0) User-Name = "testuser@ringlingtest.com" (0) Service-Type = Framed-User (0) Cisco-AVPair = "service-type=Framed" (0) Framed-MTU = 1485 (0) EAP-Message = 0x02010018014b4b45494c534f4e4064657061756c2e656475 (0) Message-Authenticator = 0x168a719ee6ceaba1d478fa2f469bf647 (0) Cisco-AVPair = "audit-session-id=B5BF26D800000D54C6C4F544" (0) Cisco-AVPair = "method=dot1x" (0) Cisco-AVPair = "client-iif-id=855639101" (0) Cisco-AVPair = "vlan-id=5" (0) NAS-IP-Address = 192.168.1.5 (0) NAS-Port-Id = "capwap_9000013c" (0) NAS-Port-Type = Wireless-802.11 (0) NAS-Port = 6018 (0) Called-Station-Id = "07-4c-d9-2e-12-c0:eduroam" (0) Calling-Station-Id = "e0-32-7e-72-b4-9a" (0) Airespace-Wlan-Id = 4 (0) Cisco-AVPair = "cisco-wlan-ssid=eduroam" (0) NAS-Identifier = "test-controller" (0) # Executing section authorize from file /etc/raddb/sites-enabled/default (0) authorize { (0) policy split_username_nai { (0) if (&User-Name && (&User-Name =~ /^([^@]*)(@([-[:alnum:]]+\.[-[:alnum:].]+))?$/)) { (0) if (&User-Name && (&User-Name =~ /^([^@]*)(@([-[:alnum:]]+\.[-[:alnum:].]+))?$/)) -> TRUE (0) if (&User-Name && (&User-Name =~ /^([^@]*)(@([-[:alnum:]]+\.[-[:alnum:].]+))?$/)) { (0) update request { (0) EXPAND %{1} (0) --> testuser (0) &Stripped-User-Name := testuser (0) } # update request = noop (0) if ("%{3}" != '') { (0) EXPAND %{3} (0) --> ringlingtest.com (0) if ("%{3}" != '') -> TRUE (0) if ("%{3}" != '') { (0) update request { (0) EXPAND %{3} (0) --> ringlingtest.com (0) &Stripped-User-Domain = ringlingtest.com (0) } # update request = noop (0) } # if ("%{3}" != '') = noop (0) [updated] = updated (0) } # if (&User-Name && (&User-Name =~ /^([^@]*)(@([-[:alnum:]]+\.[-[:alnum:].]+))?$/)) = updated (0) ... skipping else: Preceding "if" was taken (0) } # policy split_username_nai = updated (0) if (noop || !&Stripped-User-Domain) { (0) if (noop || !&Stripped-User-Domain) -> FALSE (0) if (&Stripped-User-Domain != "ringling.edu") { (0) if (&Stripped-User-Domain != "ringling.edu") -> TRUE (0) if (&Stripped-User-Domain != "ringling.edu") { (0) update { (0) control:Load-Balance-Key := &Calling-Station-ID -> 'e0-32-7e-72-b4-9a' (0) control:Proxy-To-Realm := 'DEFAULT' (0) request:Operator-Name := "1ringling.edu" (0) } # update = noop (0) return (0) } # if (&Stripped-User-Domain != "ringling.edu") = noop (0) } # authorize = updated (0) Starting proxy to home server 163.253.30.2 port 1812 (0) # Executing section pre-proxy from file /etc/raddb/sites-enabled/default (0) pre-proxy { (0) attr_filter.pre-proxy: EXPAND %{Realm} (0) attr_filter.pre-proxy: --> DEFAULT (0) attr_filter.pre-proxy: Matched entry DEFAULT at line 50 (0) [attr_filter.pre-proxy] = updated (0) } # pre-proxy = updated (0) Proxying request to home server 163.253.30.2 port 1812 timeout 30.000000 (0) Sent Access-Request Id 59 from 0.0.0.0:42392 to 163.253.30.2:1812 length 160 (0) User-Name = "testuser" (0) EAP-Message = 0x02010018014b4b45494c534f4e4064657061756c2e656475 (0) Message-Authenticator = 0x168a719ee6ceaba1d478fa2f469bf647 (0) NAS-IP-Address = 192.168.1.4 (0) Called-Station-Id = "08-4f-f9-2e-13-c0:eduroam" (0) Calling-Station-Id = "e0-32-7e-72-b4-9a" (0) NAS-Identifier = "test-controller" (0) Operator-Name := "1ringling.edu" (0) Proxy-State = 0x313530 Waking up in 0.3 seconds. (0) Marking home server 163.253.30.2 port 1812 alive (0) Clearing existing &reply: attributes (0) Received Access-Reject Id 59 from 163.253.30.2:1812 to 199.27.242.193:42392 length 89 (0) Message-Authenticator = 0xde3171110d3a45e469ec27c03d000dad (0) EAP-Message = 0x04010004 (0) Reply-Message = "Empty Realm Forwarded by ringling.edu." (0) Proxy-State = 0x313530 (0) # Executing section post-proxy from file /etc/raddb/sites-enabled/default (0) post-proxy { (0) attr_filter.post-proxy: EXPAND %{Realm} (0) attr_filter.post-proxy: --> DEFAULT (0) attr_filter.post-proxy: Matched entry DEFAULT at line 102 (0) [attr_filter.post-proxy] = updated (0) eap: No pre-existing handler found (0) [eap] = noop (0) } # post-proxy = updated (0) Login incorrect (Home Server says so): [testuser@ringlingtest.com] (from client test-controller port 6018 cli e0-32-7e-72-b4-9a) (0) Using Post-Auth-Type Reject (0) # Executing group from file /etc/raddb/sites-enabled/default (0) Post-Auth-Type REJECT { (0) attr_filter.access_reject: EXPAND %{User-Name} (0) attr_filter.access_reject: --> testuser@ringlingtest.com (0) attr_filter.access_reject: Matched entry DEFAULT at line 11 (0) [attr_filter.access_reject] = updated (0) [eap] = noop (0) policy remove_reply_message_if_eap { (0) if (&reply:EAP-Message && &reply:Reply-Message) { (0) if (&reply:EAP-Message && &reply:Reply-Message) -> TRUE (0) if (&reply:EAP-Message && &reply:Reply-Message) { (0) update reply { (0) &Reply-Message !* ANY (0) } # update reply = noop (0) } # if (&reply:EAP-Message && &reply:Reply-Message) = noop (0) ... skipping else: Preceding "if" was taken (0) } # policy remove_reply_message_if_eap = noop (0) } # Post-Auth-Type REJECT = updated (0) Login incorrect: [testuser@ringlingtest.com] (from client amplify-controller port 6018 cli e0-32-7e-72-b4-9a) (0) Sent Access-Reject Id 150 from 199.27.242.193:1812 to 192.168.1.5:61168 length 0 (0) Message-Authenticator = 0xde3171110d3a45e469ec27c03d000dad (0) EAP-Message = 0x04010004 (0) Finished request Waking up in 4.9 seconds. Kyle Keilson Manager, macOS Technology and Help Desk Institutional Technology Ringling College of Art and Design 2700 N Tamiami Trail Sarasota, FL 34234 Office: 941.359.7633 Web: www.ringling.edu <http://www.ringling.edu/> On 4/29/20, 12:26 PM, "Freeradius-Users on behalf of Alan DeKok" <freeradius-users-bounces+kkeilson=ringling.edu@lists.freeradius.org on behalf of aland@deployingradius.com> wrote: On Apr 29, 2020, at 12:21 PM, Kyle Keilson <kkeilson@ringling.edu> wrote: > > I’ve installed CentOS 8 with FreeRadius 3.0.17 and encountering an issue with eap proxied requests. When a client is proxied to another server, the EAP response is: > > eap: The RADIUS client has mangled the State attribute, OR you are forcing EAP in the wrong situation > > I’ve also noticed that the username from the EAP request is filtering out the suffix before proxying to another server. Any thoughts on why this is occurring? Because you configured it to do this. That isn't the default configuration. In order to see *why* this is happening, read the debug output. > Below is the output from radiusd -X command: That isn't helpful. See the docs: https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwiki.freeradius.org%2Flist-help&data=02%7C01%7Ckkeilson%40ringling.edu%7Cf78bbacff341470c5e1208d7ec5a0c55%7C4a0ab0eb147e46e6a02569574c2f3fed%7C0%7C0%7C637237743824020748&sdata=PAgvoTT5ZkWpKoN4PbZ1ob1S%2BJDmKjBaRjmCXb7nZi0%3D&reserved=0 We need to see the debug when the server is processing packets. Nothing else will help. Alan DeKok. - List info/subscribe/unsubscribe? See https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freeradius.org%2Flist%2Fusers.html&data=02%7C01%7Ckkeilson%40ringling.edu%7Cf78bbacff341470c5e1208d7ec5a0c55%7C4a0ab0eb147e46e6a02569574c2f3fed%7C0%7C0%7C637237743824020748&sdata=ssp0Rbefu3GVNdkm5EehPQPge1McdA0HZqAH%2BKjV8qQ%3D&reserved=0
On Apr 29, 2020, at 12:40 PM, Kyle Keilson <kkeilson@ringling.edu> wrote:
I've reviewed the debug output and it appears to point to the attr_filter.post_proxy filter. I should mention that the defaults for the attr_filter are in use and have not been changed.
The attr_filter.post_proxy filter is run *after* the reply from the home server has come back to the proxy. So no, it's not mangling the user name.
Here is the output when the server is processing packets:
(0) Received Access-Request Id 150 from 192.168.1.5:61168 to 192.168.1.4:1812 length 381 (0) User-Name = "testuser@ringlingtest.com"
That's the good name.
... (0) # Executing section authorize from file /etc/raddb/sites-enabled/default (0) authorize { (0) policy split_username_nai {
And... there we are. You edited the default configuration to add this policy.
(0) if (&User-Name && (&User-Name =~ /^([^@]*)(@([-[:alnum:]]+\.[-[:alnum:].]+))?$/)) { (0) if (&User-Name && (&User-Name =~ /^([^@]*)(@([-[:alnum:]]+\.[-[:alnum:].]+))?$/)) -> TRUE (0) if (&User-Name && (&User-Name =~ /^([^@]*)(@([-[:alnum:]]+\.[-[:alnum:].]+))?$/)) { (0) update request { (0) EXPAND %{1} (0) --> testuser (0) &Stripped-User-Name := testuser
This split name then becomes the User-Name used for proxying.
... (0) } # authorize = updated
You've deleted most everything else in the "authorize" section, and replaced it with your custom rules. So... your custom rules are creating the issue. The default configuration doesn't do this.
(0) Starting proxy to home server 163.253.30.2 port 1812 (0) # Executing section pre-proxy from file /etc/raddb/sites-enabled/default (0) pre-proxy { (0) attr_filter.pre-proxy: EXPAND %{Realm} (0) attr_filter.pre-proxy: --> DEFAULT (0) attr_filter.pre-proxy: Matched entry DEFAULT at line 50 (0) [attr_filter.pre-proxy] = updated (0) } # pre-proxy = updated
That's the pre-proxy filter, not the post-proxy one. They're different, and that matters.
(0) Proxying request to home server 163.253.30.2 port 1812 timeout 30.000000 (0) Sent Access-Request Id 59 from 0.0.0.0:42392 to 163.253.30.2:1812 length 160 (0) User-Name = "testuser"
This is the Stripped-User-Name from above.
(0) Received Access-Reject Id 59 from 163.253.30.2:1812 to 199.27.242.193:42392 length 89 (0) Message-Authenticator = 0xde3171110d3a45e469ec27c03d000dad (0) EAP-Message = 0x04010004 (0) Reply-Message = "Empty Realm Forwarded by ringling.edu."
And your custom home server has rejected the packet. Note that there is no message such as this in the debug output you posted:
eap: The RADIUS client has mangled the State attribute, OR you are forcing EAP in the wrong situation
Perhaps that message is coming from the home server? If so, it will also produce *other* messages complaining that something has mangled the User-Name. The answer is to not mangle the User-Name. If you need to look at the realm, you can just use a regular expression to parse the realm. *Don't* create a Stripped-User-Name attribute. Especially if you don't use it. Alan DeKok.
I realized that the issue was not related to the original error. In setting up the proxy home servers, I eliminated "nostrip" from the "realm DEFAULT" stanza, and added it directly to the home_server pool. After making this change, it seems that requests are now going through. Thanks you for your help. Regards, Kyle Keilson Manager, macOS Technology and Help Desk Institutional Technology Ringling College of Art and Design 2700 N Tamiami Trail Sarasota, FL 34234 Office: 941.359.7633 Web: www.ringling.edu <http://www.ringling.edu/> On 4/29/20, 12:52 PM, "Freeradius-Users on behalf of Alan DeKok" <freeradius-users-bounces+kkeilson=ringling.edu@lists.freeradius.org on behalf of aland@deployingradius.com> wrote: On Apr 29, 2020, at 12:40 PM, Kyle Keilson <kkeilson@ringling.edu> wrote: > > I've reviewed the debug output and it appears to point to the attr_filter.post_proxy filter. I should mention that the defaults for the attr_filter are in use and have not been changed. The attr_filter.post_proxy filter is run *after* the reply from the home server has come back to the proxy. So no, it's not mangling the user name. > Here is the output when the server is processing packets: > > (0) Received Access-Request Id 150 from 192.168.1.5:61168 to 192.168.1.4:1812 length 381 > (0) User-Name = "testuser@ringlingtest.com" That's the good name. > ... > (0) # Executing section authorize from file /etc/raddb/sites-enabled/default > (0) authorize { > (0) policy split_username_nai { And... there we are. You edited the default configuration to add this policy. > (0) if (&User-Name && (&User-Name =~ /^([^@]*)(@([-[:alnum:]]+\.[-[:alnum:].]+))?$/)) { > (0) if (&User-Name && (&User-Name =~ /^([^@]*)(@([-[:alnum:]]+\.[-[:alnum:].]+))?$/)) -> TRUE > (0) if (&User-Name && (&User-Name =~ /^([^@]*)(@([-[:alnum:]]+\.[-[:alnum:].]+))?$/)) { > (0) update request { > (0) EXPAND %{1} > (0) --> testuser > (0) &Stripped-User-Name := testuser This split name then becomes the User-Name used for proxying. > ... > (0) } # authorize = updated You've deleted most everything else in the "authorize" section, and replaced it with your custom rules. So... your custom rules are creating the issue. The default configuration doesn't do this. > (0) Starting proxy to home server 163.253.30.2 port 1812 > (0) # Executing section pre-proxy from file /etc/raddb/sites-enabled/default > (0) pre-proxy { > (0) attr_filter.pre-proxy: EXPAND %{Realm} > (0) attr_filter.pre-proxy: --> DEFAULT > (0) attr_filter.pre-proxy: Matched entry DEFAULT at line 50 > (0) [attr_filter.pre-proxy] = updated > (0) } # pre-proxy = updated That's the pre-proxy filter, not the post-proxy one. They're different, and that matters. > (0) Proxying request to home server 163.253.30.2 port 1812 timeout 30.000000 > (0) Sent Access-Request Id 59 from 0.0.0.0:42392 to 163.253.30.2:1812 length 160 > (0) User-Name = "testuser" This is the Stripped-User-Name from above. > (0) Received Access-Reject Id 59 from 163.253.30.2:1812 to 199.27.242.193:42392 length 89 > (0) Message-Authenticator = 0xde3171110d3a45e469ec27c03d000dad > (0) EAP-Message = 0x04010004 > (0) Reply-Message = "Empty Realm Forwarded by ringling.edu." And your custom home server has rejected the packet. Note that there is no message such as this in the debug output you posted: >> eap: The RADIUS client has mangled the State attribute, OR you are forcing EAP in the wrong situation Perhaps that message is coming from the home server? If so, it will also produce *other* messages complaining that something has mangled the User-Name. The answer is to not mangle the User-Name. If you need to look at the realm, you can just use a regular expression to parse the realm. *Don't* create a Stripped-User-Name attribute. Especially if you don't use it. Alan DeKok. - List info/subscribe/unsubscribe? See https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freeradius.org%2Flist%2Fusers.html&data=02%7C01%7Ckkeilson%40ringling.edu%7C15d6ea223fe148355b8a08d7ec5db6bb%7C4a0ab0eb147e46e6a02569574c2f3fed%7C0%7C0%7C637237759556135647&sdata=P8YmCsVWGhYbD4g3Hnt1RBmRWdYc5Jhi41APWnTf9r8%3D&reserved=0
participants (2)
-
Alan DeKok -
Kyle Keilson