Kostas Zorbadelos <kzorba@otenet.gr> writes:
Greetings to all,
just finished a project upgrading a big authentication infrastructure from freeradius 2.2.X to 3.0.17. I face a problem with very few users whose passwords end in '\'. They used to work in freeradius 2.
Debugging output (stripping the sensitive information):
kzorba@system(0)[10:19 AM]~/radius->cat test_kzorba1.txt User-Name = kzorba1@otenet.gr NAS-Port-Type = xDSL User-Password = test123\ NAS-Port-Id ="#DSLAM PORT DESCRIPTION HERE#" Calling-Station-Id = "BNG INTERFACE # DSLAM PORT DESCRIPTION" NAS-Port = 12234455
using freeradius 3.0.17 radclient:
kzorba@system(0)[10:26 AM]~/radius->/opt/freeradius3-auth/bin/radclient -f test_kzorba1.txt -x localhost:1812 auth XXXXX (0) Error parsing "test_kzorba1.txt": Invalid escape at end of string radclient: Failed parsing input files ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
With radclient 3.0.17 I needed to add an extra \ at the end of the User-Password to send the request. No Cleartext-Password is set.
It looks like a problem of escaping character in whatever shell, text editor, operating system you are using. On Unix, a line ending with a \ traditionnaly means that the line is continuing on the next line. Even it could be that when copying from one system to the other, you have added invisible character at the end of each line (your text editor consider that it should not display any CRTL-M at the end of the line, but if it is there, it messes up with LDAP, it happened to me earlier this week). Good luck, Olivier
kzorba@system(0)[10:49 AM]~/radius->/opt/freeradius3-auth/bin/radclient -f test_kzorba1.txt -x localhost:1812 auth XXXXX Sent Access-Request Id 141 from 0.0.0.0:44902 to 79.128.178.43:1812 length 140 User-Name = "kzorba1@otenet.gr" NAS-Port-Type = xDSL User-Password = "test123\\" NAS-Port-Id = "#DSLAM PORT DESCRIPTION HERE#" Calling-Station-Id = "BNG INTERFACE # DSLAM PORT DESCRIPTION" NAS-Port = 12234455
Using freeradius 2.2.10 radclient:
kzorba@system(0)[10:22 AM]~/radius->/opt/freeradius2-auth/bin/radclient -f test_kzorba1.txt -x localhost:1812 auth XXXXX Sending Access-Request of id 184 to 79.128.178.43 port 1812 User-Name = "kzorba1@otenet.gr" NAS-Port-Type = xDSL User-Password = "test123\\" NAS-Port-Id = "#DSLAM PORT DESCRIPTION HERE#" Calling-Station-Id = "BNG INTERFACE # DSLAM PORT DESCRIPTION" NAS-Port = 12234455
Independent of which radclient is used, the server has the same behavior demonstrated in the following debug (using radmin in production, excellent feature by the way)
(13592044) Fri Sep 7 10:22:40 2018: Debug: Received Access-Request Id 184 from XXXXXXXX:59592 to XXXXXXXXX:1812 length 140 (13592044) Fri Sep 7 10:22:40 2018: Debug: User-Name = "kzorba1@otenet.gr" (13592044) Fri Sep 7 10:22:40 2018: Debug: NAS-Port-Type = xDSL (13592044) Fri Sep 7 10:22:40 2018: Debug: User-Password = "test123\\" (13592044) Fri Sep 7 10:22:40 2018: Debug: NAS-Port-Id = "#DSLAM PORT DESCRIPTION HERE#" (13592044) Fri Sep 7 10:22:40 2018: Debug: Calling-Station-Id = "BNG INTERFACE # DSLAM PORT DESCRIPTION" (13592044) Fri Sep 7 10:22:40 2018: Debug: NAS-Port = 12234455 (13592044) Fri Sep 7 10:22:40 2018: Debug: # Executing section authorize from file /opt/freeradius-auth-3.0.17/etc/raddb/sites-enabled/MYSERVER (13592044) Fri Sep 7 10:22:40 2018: Debug: authorize { (13592044) Fri Sep 7 10:22:40 2018: Debug: [preprocess] = ok (13592044) Fri Sep 7 10:22:40 2018: Debug: [chap] = noop (13592044) Fri Sep 7 10:22:40 2018: Debug: [mschap] = noop (13592044) Fri Sep 7 10:22:40 2018: Debug: suffix: Checking for suffix after "@" (13592044) Fri Sep 7 10:22:40 2018: Debug: suffix: Looking up realm "otenet.gr" for User-Name = "kzorba1@otenet.gr" (13592044) Fri Sep 7 10:22:40 2018: Debug: suffix: Found realm "otenet.gr" (13592044) Fri Sep 7 10:22:40 2018: Debug: suffix: Adding Stripped-User-Name = "kzorba1" (13592044) Fri Sep 7 10:22:40 2018: Debug: suffix: Adding Realm = "otenet.gr" (13592044) Fri Sep 7 10:22:40 2018: Debug: suffix: Authentication realm is LOCAL (13592044) Fri Sep 7 10:22:40 2018: Debug: [suffix] = ok ... (13592044) Fri Sep 7 10:22:40 2018: Debug: ldap_1: ... (13592044) Fri Sep 7 10:22:40 2018: Debug: ldap_1: Performing search in ..., scope "sub" (13592044) Fri Sep 7 10:22:40 2018: Debug: ldap_1: Waiting for search result... (13592044) Fri Sep 7 10:22:40 2018: Debug: ldap_1: User object found at DN ... (13592044) Fri Sep 7 10:22:40 2018: Debug: ldap_1: Processing user attributes (13592044) Fri Sep 7 10:22:40 2018: WARNING: ldap_1: Failed parsing value "test123\\" for attribute Cleartext-Password: Invalid escape at end of string ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (13592044) Fri Sep 7 10:22:40 2018: Debug: ldap_1: No attributes updated ... (13592044) Fri Sep 7 10:22:40 2018: WARNING: pap: No "known good" password found for the user. Not setting Auth-Type (13592044) Fri Sep 7 10:22:40 2018: WARNING: pap: Authentication will fail unless a "known good" password is available (13592044) Fri Sep 7 10:22:40 2018: Debug: [pap] = noop (13592044) Fri Sep 7 10:22:40 2018: Debug: } # authorize = updated (13592044) Fri Sep 7 10:22:40 2018: ERROR: No Auth-Type found: rejecting the user via Post-Auth-Type = Reject ... (13592044) Fri Sep 7 10:22:45 2018: Debug: Cleaning up request packet ID 184 with timestamp +173038
In the ldap entry of the user, the password is stored with a (single) ending '\'.
Here is the relevant config of the ldap module in my case (again sensitive information stripped)
ldap ldap_1 { server = "MYSERVER"
identity = "LDAP BIND DN" password = PASSWD base_dn = "MY BASE DN" sasl { } # # Mapping of LDAP directory attributes to RADIUS dictionary attributes. # update { ... control:Cleartext-Password := 'myTextPwd' reply:Framed-IP-Address = 'Framed-IP-Address' ... } user { base_dn = "${..base_dn}" filter = "MY SEARCH FILTER" sasl { } # scope = 'sub' }
group { }
profile { }
client { }
accounting { }
post-auth { }
options { chase_referrals = yes rebind = yes res_timeout = 10 srv_timelimit = 4 net_timeout = 2 idle = 60 probes = 3 interval = 3 #ldap_debug = 0x0028 }
tls { }
pool { start = ${thread[pool].start_servers} min = ${thread[pool].min_spare_servers} max = ${thread[pool].max_servers} spare = ${thread[pool].max_spare_servers} uses = 0 retry_delay = 5 lifetime = 0 idle_timeout = 60 } }
Is this a bug (looks like to me), feature, or am I missing something? I also saw a relevant policy to sanitize the password in the request, commented out:
filter_password { if (&User-Password && \ (&User-Password != "%{string:User-Password}")) { update request { &Tmp-String-0 := "%{string:User-Password}" &User-Password := "%{string:Tmp-String-0}" } } }
However the request doesn't have anything to do with it, this seems like an ldap module issue.
Could I do something with unlang, or in the ldap module config in this case?
Regards, Kostas
PS: If '\' is not at the end of the password, everything is OK.
--