The RADIUS client has mangled the State attribute
Alan DeKok
aland at deployingradius.com
Wed Apr 29 18:52:08 CEST 2020
On Apr 29, 2020, at 12:40 PM, Kyle Keilson <kkeilson at 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 at 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.
More information about the Freeradius-Users
mailing list