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. 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. -- Kostas Zorbadelos http://gr.linkedin.com/in/kzorba