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

Kostas Zorbadelos kzorba at otenet.gr
Fri Sep 7 10:13:42 CEST 2018


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.

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.

-- 
Kostas Zorbadelos	http://gr.linkedin.com/in/kzorba		


More information about the Freeradius-Users mailing list