3.0.17 password ending in '\' problem, LDAP backend [bug?]

Olivier Olivier.Nicole at cs.ait.ac.th
Fri Sep 7 10:30:19 CEST 2018


Kostas Zorbadelos <kzorba at 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 at system(0)[10:19 AM]~/radius->cat test_kzorba1.txt 
> User-Name = kzorba1 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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.

-- 


More information about the Freeradius-Users mailing list