Escaped backslash in User-Name when sending Access-Accept
Hi, I'm having some issues authenticating iOS clients (with FreeRADIUS v2.1.10 installed on a Ubuntu server) with EAP-TLS when the username contains a domain name in the form of Domain\Username (the account is in Active Directory). I think the issue is caused by the fact that the final Access-Accept reply has the backslash after the domain name escaped, so that the output looks like this: Sending Access-Accept of id 171 to 172.27.28.84 port 32769 User-Name = "ocg\\cmctrf3" instead of containing the original, un-escaped domain\username: Sending Access-Accept of id 171 to 172.27.28.84 port 32769 User-Name = "ocg\cmctrf3" Mine is just a theory, but I cannot verify it until I figure out how to have the un-escaped ocg\cmctrf3 string being sent in the output instead of the current escaped one. So my question is "how do I cause the User-Name to be send un-escaped? Do I make a change in the clients.con file...? The eap.conf file...? If so, under which section and where..? Sorry for what may look like a dumb question, but I could not find this mentioned anywhere else. As a side-note, if I omit the domain name in the iOS device and just login with the username "cmctrf3" for example, the iPhones/iPads are able to login without problems. The issue only occurs when the domain name appears before escaped. All other devices (Windows and Mac desktops) seem to be able to get past that escaped sequence without problems. Below is a blurb showing the debug output. I do see the un-escaped ocg\cmctrf3 being logged, but the escaped one at the end is what is porbably biting me. Thanks, Roberto Franceschetti # Executing section authorize from file /etc/freeradius/clients.conf +- entering group authorize {...} ++[preprocess] returns ok [suffix] No '@' in User-Name = "ocg\cmctrf3", skipping NULL due to config. ++[suffix] returns noop [ntdomain] Looking up realm "ocgov" for User-Name = "ocg\cmctrf3" [ntdomain] No such realm "ocgov" ++[ntdomain] returns noop ++[mschap] returns noop [eap] EAP packet type response id 10 length 43 [eap] Continuing tunnel setup. ++[eap] returns ok Found Auth-Type = EAP # Executing group from file /etc/freeradius/clients.conf +- entering group authenticate {...} [eap] Request found, released from the list [eap] EAP/peap [eap] processing type peap [peap] processing EAP-TLS [peap] eaptls_verify returned 7 [peap] Done initial handshake [peap] eaptls_process returned 7 [peap] EAPTLS_OK [peap] Session established. Decoding tunneled attributes. [peap] Peap state send tlv success [peap] Received EAP-TLV response. [peap] Success [eap] Freeing handler ++[eap] returns ok Login OK: [ocg\\cmctrf3] (from client 172.27.28.84 port 29 cli f0-cb-a1-2b-61-4d) # Executing section post-auth from file /etc/freeradius/clients.conf +- entering group post-auth {...} ++[exec] returns noop } # server lwap-clients Sending Access-Accept of id 171 to 172.27.28.84 port 32769 MS-MPPE-Recv-Key = 0x15c9ba070e3579e43c54314c24e7e09f4753c779e4e013b4bbd080a2cab4bbb2 MS-MPPE-Send-Key = 0x4f27c90c8fdf27be122e70c2c4d82bebd65797dafebe2ebb4ca91bedfd244cb5 EAP-Message = 0x030a0004 Message-Authenticator = 0x00000000000000000000000000000000 User-Name = "ocg\\cmctrf3" PLEASE NOTE: Florida has a very broad public records law (F. S. 119). All e-mails to and from County Officials are kept as a public record. Your e-mail communications, including your e-mail address may be disclosed to the public and media at any time.
Roberto Franceschetti wrote:
Mine is just a theory, but I cannot verify it until I figure out how to have the un-escaped ocg\cmctrf3 string being sent in the output instead of the current escaped one.
It probably is not escaped. Some logs and debug outputs escape before outputting to syslog or the screen, but some do not, so it is hard to be sure what you are seeing without taking an actual packet dump and looking at the actual bytes sent. The only time you should ever have to deal with problems with unescaping in the User-Name attribute is when you edit it by hand, for example, if you take an inner tunnel copy of the user-name and then place it by hand in the outer reply (which you should only do if you can trust your NAS and the network between it to keep that secret.) If you do such a thing, it is very hard to get an unescaped edited string back into an attribute, because any attribute you define will be escaped when you try to glue it back together with an xlat. You can, however, do so using %{1}, %{2}, %{3} etc from a regexp match. # The following will take the User-Name from the request and put it into the reply, # without adding any escaping. if (User-Name =~ /(.*)/) { update reply { User-Name = "%{1}" } }
Roberto Franceschetti wrote:
I'm having some issues authenticating iOS clients (with FreeRADIUS v2.1.10 installed on a Ubuntu server) with EAP-TLS when the username contains a domain name in the form of Domain\Username (the account is in Active Directory).
I think the issue is caused by the fact that the final Access-Accept reply has the backslash after the domain name escaped, so that the output looks like this:
Sending Access-Accept of id 171 to 172.27.28.84 port 32769 User-Name = "ocg\\cmctrf3"
instead of containing the original, un-escaped domain\username:
Sending Access-Accept of id 171 to 172.27.28.84 port 32769 User-Name = "ocg\cmctrf3"
No. The escaping is done when the string is *printed*. It sends just one '\' in the Access-Accept. Use wireshark to check.
Mine is just a theory, but I cannot verify it until I figure out how to have the un-escaped ocg\cmctrf3 string being sent in the output instead of the current escaped one. So my question is "how do I cause the User-Name to be send un-escaped? Do I make a change in the clients.con file...? The eap.conf file...? If so, under which section and where..? Sorry for what may look like a dumb question, but I could not find this mentioned anywhere else.
You don't "unescape" anything. The server sends the correct User-Name. It Does the Right Thing.
As a side-note, if I omit the domain name in the iOS device and just login with the username "cmctrf3" for example, the iPhones/iPads are able to login without problems. The issue only occurs when the domain name appears before escaped. All other devices (Windows and Mac desktops) seem to be able to get past that escaped sequence without problems.
So the issue is the domain name. NOT the escaping. You THINK it's the escaping, but you're not really sure.
Below is a blurb showing the debug output. I do see the un-escaped ocg\cmctrf3 being logged,
No. That's a debug message, which isn't logging, and doesn't affect anything.
Login OK: [ocg\\cmctrf3] (from client 172.27.28.84 port 29 cli f0-cb-a1-2b-61-4d) # Executing section post-auth from file /etc/freeradius/clients.conf +- entering group post-auth {...} ++[exec] returns noop } # server lwap-clients Sending Access-Accept of id 171 to 172.27.28.84 port 32769 MS-MPPE-Recv-Key = 0x15c9ba070e3579e43c54314c24e7e09f4753c779e4e013b4bbd080a2cab4bbb2 MS-MPPE-Send-Key = 0x4f27c90c8fdf27be122e70c2c4d82bebd65797dafebe2ebb4ca91bedfd244cb5 EAP-Message = 0x030a0004 Message-Authenticator = 0x00000000000000000000000000000000 User-Name = "ocg\\cmctrf3"
Well... if the server is sending Access-Accept and the user doesn't get online... nothing is going wrong with FreeRADIUS. Alan DeKok.
participants (3)
-
Alan DeKok -
Brian Julin -
Roberto Franceschetti