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