3.0.17 password ending in '\' problem, LDAP backend [bug?]
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
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.
--
On Παρ, Σεπ 07 2018 at 11:30:19 πμ, Olivier <Olivier.Nicole@cs.ait.ac.th> wrote: Dear Olivier, the heart of the problem I am describing refers to the inability of the LDAP module to retrieve a clear text password from the directory if this ends in '\'. Radclient refers to how I send the request and it seems in freeradius 3 there were changes to that as well. No shell is involved and I use vim on linux for the file editing. Regards, Kostas
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
-- Kostas Zorbadelos http://gr.linkedin.com/in/kzorba
On Sep 7, 2018, at 4:13 AM, Kostas Zorbadelos <kzorba@otenet.gr> wrote:
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.
We fixed all of the handling of the backslash character in v3. Before that, it was random and inconsistent. Now, the rules are the same as for shells. Which is what people are used to, and what makes sense.
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\
i.e. User-Password = "test123\" Which for shells, is an invalid quoted string. So, it's invalid here.
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
Exactly.
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.
Yes. That's the normal rule for double-quoted strings. Cleartext-Password is for the server. If you set it in radclient, it will be ignored.
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)
The server works, and will accept backslashes in passwords.
(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
Yes, the same rules for double quoted strings apply here.
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)
Please don't post module config to the list. We don't need it. See: http://wiki.freeadius.org/list-help
Is this a bug (looks like to me), feature, or am I missing something?
It's *fixing* a bug.
Could I do something with unlang, or in the ldap module config in this case?
Map the LDAP userPassword attribute to a binary attribute, e.g. Tmp-Octets-0. Then, copy that to Cleartext-Password: ldap if (control:Tmp-Octets-0) { update control { Cleartext-Password := &control:Tmp-Octets-0 } } Alan DeKok.
On Παρ, Σεπ 07 2018 at 02:39:30 μμ, Alan DeKok <aland@deployingradius.com> wrote: Hi Alan,
Yes. That's the normal rule for double-quoted strings.
understood everything about the backslash fixes.
Cleartext-Password is for the server. If you set it in radclient, it will be ignored.
Yes, silly from my part, I got confused.
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)
The server works, and will accept backslashes in passwords.
(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
Yes, the same rules for double quoted strings apply here.
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)
Please don't post module config to the list. We don't need it.
Sorry, I have missed this page.
Is this a bug (looks like to me), feature, or am I missing something?
It's *fixing* a bug.
:)
Could I do something with unlang, or in the ldap module config in this case?
Map the LDAP userPassword attribute to a binary attribute, e.g. Tmp-Octets-0. Then, copy that to Cleartext-Password:
ldap if (control:Tmp-Octets-0) { update control { Cleartext-Password := &control:Tmp-Octets-0 } }
A big thanks for your clarifications and solution proposal Alan. You are doing an excellent work for many years along with the other developers of the project and you provide invaluable help. I am sure your solution will work but in any case I need to test it and deploy it. Best regards, Kostas -- Kostas Zorbadelos http://gr.linkedin.com/in/kzorba
On Παρ, Σεπ 07 2018 at 02:39:30 μμ, Alan DeKok <aland@deployingradius.com> wrote: Hi again,
Is this a bug (looks like to me), feature, or am I missing something?
It's *fixing* a bug.
Could I do something with unlang, or in the ldap module config in this case?
Map the LDAP userPassword attribute to a binary attribute, e.g. Tmp-Octets-0. Then, copy that to Cleartext-Password:
ldap if (control:Tmp-Octets-0) { update control { Cleartext-Password := &control:Tmp-Octets-0 } }
quickly tried your proposed fix in production. Did not seem to work: (33318) Fri Sep 7 15:41:31 2018: Debug: Received Access-Request Id 249 from 79.128.178.33:52087 to 79.128.178.43:1812 length 140 (33318) Fri Sep 7 15:41:31 2018: Debug: User-Name = "kzorba1@otenet.gr" (33318) Fri Sep 7 15:41:31 2018: Debug: NAS-Port-Type = xDSL (33318) Fri Sep 7 15:41:31 2018: Debug: User-Password = "test123\\" (33318) Fri Sep 7 15:41:31 2018: Debug: NAS-Port-Id = "#DSLAM PORT DESCRIPTION HERE#" (33318) Fri Sep 7 15:41:31 2018: Debug: Calling-Station-Id = "BNG INTERFACE # DSLAM PORT DESCRIPTION" (33318) Fri Sep 7 15:41:31 2018: Debug: NAS-Port = 12234455 (33318) Fri Sep 7 15:41:31 2018: Debug: # Executing section authorize from file /opt/freeradius-auth-3.0.17/etc/raddb/sites-enabled/MYSERVER (33318) Fri Sep 7 15:41:31 2018: Debug: authorize { ... (33318) Fri Sep 7 15:41:31 2018: Debug: ldap_1: Processing user attributes (33318) Fri Sep 7 15:41:31 2018: Debug: [ldap_1] = updated ... (33318) Fri Sep 7 15:41:31 2018: Debug: if (control:Tmp-Octets-0) { (33318) Fri Sep 7 15:41:31 2018: Debug: if (control:Tmp-Octets-0) -> TRUE (33318) Fri Sep 7 15:41:31 2018: Debug: if (control:Tmp-Octets-0) { (33318) Fri Sep 7 15:41:31 2018: Debug: update control { (33318) Fri Sep 7 15:41:31 2018: Debug: } # update control = noop (33318) Fri Sep 7 15:41:31 2018: Debug: } # if (control:Tmp-Octets-0) = noop ... (33318) Fri Sep 7 15:41:31 2018: Debug: [pap] = updated (33318) Fri Sep 7 15:41:31 2018: Debug: } # authorize = updated (33318) Fri Sep 7 15:41:31 2018: Debug: Found Auth-Type = PAP (33318) Fri Sep 7 15:41:31 2018: Debug: # Executing group from file /opt/freeradius-auth-3.0.17/etc/raddb/sites-enabled/MYSERVER (33318) Fri Sep 7 15:41:31 2018: Debug: Auth-Type PAP { (33318) Fri Sep 7 15:41:31 2018: Debug: pap: Login attempt with password (33318) Fri Sep 7 15:41:31 2018: Debug: pap: Comparing with "known good" Cleartext-Password (33318) Fri Sep 7 15:41:31 2018: ERROR: pap: Cleartext password does not match "known good" password (33318) Fri Sep 7 15:41:31 2018: Debug: pap: Passwords don't match (33318) Fri Sep 7 15:41:31 2018: Debug: [pap] = reject (33318) Fri Sep 7 15:41:31 2018: Debug: } # Auth-Type PAP = reject (33318) Fri Sep 7 15:41:31 2018: Debug: Failed to authenticate the user (33318) Fri Sep 7 15:41:31 2018: Debug: Using Post-Auth-Type Reject (33318) Fri Sep 7 15:41:31 2018: Debug: # Executing group from file /opt/freeradius-auth-3.0.17/etc/raddb/sites-enabled/MYSERVER (33318) Fri Sep 7 15:41:31 2018: Debug: Post-Auth-Type REJECT { (33318) Fri Sep 7 15:41:31 2018: Debug: attr_filter.access_reject: EXPAND %{User-Name} (33318) Fri Sep 7 15:41:31 2018: Debug: attr_filter.access_reject: --> kzorba1@otenet.gr (33318) Fri Sep 7 15:41:31 2018: Debug: attr_filter.access_reject: Matched entry DEFAULT at line 11 (33318) Fri Sep 7 15:41:31 2018: Debug: [attr_filter.access_reject] = updated (33318) Fri Sep 7 15:41:31 2018: Debug: } # Post-Auth-Type REJECT = updated (33318) Fri Sep 7 15:41:31 2018: Debug: Delaying response for 1.000000 seconds (33318) Fri Sep 7 15:41:32 2018: Debug: Sending delayed response (33318) Fri Sep 7 15:41:32 2018: Debug: Sent Access-Reject Id 249 from 79.128.178.43:1812 to 79.128.178.33:52087 length 20 (33318) Fri Sep 7 15:41:36 2018: Debug: Cleaning up request packet ID 249 with timestamp +229 Could it be that radclient actually sends '\\' at the end of the password, as shown in the debug output? The ldap stored password contains only a single '\' in the end. PAP comparison therefore seems to fail. Is there a way to send a single '\' at the end of User-password to debug this? Am I again missing something? Regards, Kostas -- Kostas Zorbadelos http://gr.linkedin.com/in/kzorba
On Sep 7, 2018, at 9:02 AM, Kostas Zorbadelos <kzorba@otenet.gr> wrote:
quickly tried your proposed fix in production. Did not seem to work:
Hmm..
... (33318) Fri Sep 7 15:41:31 2018: Debug: pap: Login attempt with password (33318) Fri Sep 7 15:41:31 2018: Debug: pap: Comparing with "known good" Cleartext-Password (33318) Fri Sep 7 15:41:31 2018: ERROR: pap: Cleartext password does not match "known good" password (33318) Fri Sep 7 15:41:31 2018: Debug: pap: Passwords don't match
You'll have to look at the contents of Cleartext-Password to see what's going on here. Just log it to a file.
Could it be that radclient actually sends '\\' at the end of the password, as shown in the debug output?
No. That's just due to the rules for escaping the double-quoted string.
The ldap stored password contains only a single '\' in the end. PAP comparison therefore seems to fail. Is there a way to send a single '\' at the end of User-password to debug this? Am I again missing something?
The issue is that backslash is used inside strings to mean that something is being escaped. So it can't really be used all by itself. The only other solution then is to copy the User-Password to an octets attribute, and compare them manually: if (control:Tmp-Octets-0 && User-Password) { update request { Tmp-Octets-0 := &User-Password } if (&control:Tmp-Octets-0 == &request:Tmp-Octets-0) { accept } else { reject } } Alan DeKok.
On Παρ, Σεπ 07 2018 at 04:46:35 μμ, Alan DeKok <aland@deployingradius.com> wrote: Hi Alan and all, a quick update on this, to have it for future reference.
Map the LDAP userPassword attribute to a binary attribute, e.g. Tmp-Octets-0. Then, copy that to Cleartext-Password:
ldap if (control:Tmp-Octets-0) { update control { Cleartext-Password := &control:Tmp-Octets-0 } }
quickly tried your proposed fix in production. Did not seem to work:
Hmm..
The above solution did not work exactly as is. A minor patch was needed: if (control:Tmp-Octets-0) { update control { Cleartext-Password := "%{string:control:Tmp-Octets-0}" } } The binary attribute would need to be converted to string for the comparison in pap to work.
... (33318) Fri Sep 7 15:41:31 2018: Debug: pap: Login attempt with password (33318) Fri Sep 7 15:41:31 2018: Debug: pap: Comparing with "known good" Cleartext-Password (33318) Fri Sep 7 15:41:31 2018: ERROR: pap: Cleartext password does not match "known good" password (33318) Fri Sep 7 15:41:31 2018: Debug: pap: Passwords don't match
You'll have to look at the contents of Cleartext-Password to see what's going on here. Just log it to a file.
radiusd -X showed the exact value of Cleartext-Password. <academic interest> I wonder how I could log it to a file however. detail.log did not work. Should I use linelog? </academic interest>
Could it be that radclient actually sends '\\' at the end of the password, as shown in the debug output?
No. That's just due to the rules for escaping the double-quoted string.
Indeed I verified that in a pcap capture. The whole escaping in shell strings always confused me so I try to stay away from it :) Have you implemented the string escape rules of bash? For example I tried to send a password ending in '\\' through radclient. I had to input User-Password = "test123\\\\\\\\" in the attribute file!
The ldap stored password contains only a single '\' in the end. PAP comparison therefore seems to fail. Is there a way to send a single '\' at the end of User-password to debug this? Am I again missing something?
The issue is that backslash is used inside strings to mean that something is being escaped. So it can't really be used all by itself.
The only other solution then is to copy the User-Password to an octets attribute, and compare them manually:
if (control:Tmp-Octets-0 && User-Password) { update request { Tmp-Octets-0 := &User-Password }
if (&control:Tmp-Octets-0 == &request:Tmp-Octets-0) { accept } else { reject }
}
I did't need to resort to this. I think that was good, because I didn't like to idea to bypass the pap authentication module. Thanks again for the support. Best regards, Kostas -- Kostas Zorbadelos http://gr.linkedin.com/in/kzorba
On Δευ, Σεπ 10 2018 at 04:25:50 μμ, Kostas Zorbadelos <kzorba@otenet.gr> wrote:
The above solution did not work exactly as is. A minor patch was needed:
if (control:Tmp-Octets-0) { update control { Cleartext-Password := "%{string:control:Tmp-Octets-0}"
or should we use Cleartext-Password := "%{string:&control:Tmp-Octets-0}" What is the "correct" way in this reference? Both seem to work.
} }
The binary attribute would need to be converted to string for the comparison in pap to work.
-- Kostas Zorbadelos http://gr.linkedin.com/in/kzorba
On Sep 10, 2018, at 9:25 AM, Kostas Zorbadelos <kzorba@otenet.gr> wrote:
The above solution did not work exactly as is. A minor patch was needed:
if (control:Tmp-Octets-0) { update control { Cleartext-Password := "%{string:control:Tmp-Octets-0}" } }
That's fine. You could use "&" too, which is required in v4. But it's fine for v3.
<academic interest> I wonder how I could log it to a file however. detail.log did not work.
The detail module can log any attribute if you configure the module correctly. The detail.log file logs replies by default, not attributes in the control list.
Should I use linelog? </academic interest>
That works, too.
The whole escaping in shell strings always confused me so I try to stay away from it :) Have you implemented the string escape rules of bash?\
We've implemented the string escape rules for single and double-quotes
For example I tried to send a password ending in '\\' through radclient. I had to input
User-Password = "test123\\\\\\\\"
Hmm... that doesn't look right. It should be simpler than that. If you're piping the attribute through a shell, then those escaping rules apply *on top of* what FreeRADIUS does. But if you do radclient -f file, then the attributes in "file" shouldn't need 3 layers of escaping. Just one. Alan DeKok.
On Δευ, Σεπ 10 2018 at 11:34:34 πμ, Alan DeKok <aland@deployingradius.com> wrote:
The whole escaping in shell strings always confused me so I try to stay away from it :) Have you implemented the string escape rules of bash?\
We've implemented the string escape rules for single and double-quotes
OK. I will refer to bash documentation :)
For example I tried to send a password ending in '\\' through radclient. I had to input
User-Password = "test123\\\\\\\\"
Hmm... that doesn't look right. It should be simpler than that.
I think so too.
If you're piping the attribute through a shell, then those escaping rules apply *on top of* what FreeRADIUS does.
But if you do radclient -f file, then the attributes in "file" shouldn't need 3 layers of escaping. Just one.
I am talking about -f <file> in radclient. I made all tests and saw the constructed packets in wireshark. My guess is that you need escaping when reading the file, then again you use escaping when constructing the packet. Haven't gone through the code though. Another example is when I needed to send a literal '\t' (without it being translated to tab). I had to use the sequence User-Password = "test\\\\t1" in the radclient input file to send 'test\t1' in the constructed packet. Could it be that I am doing something wrong? Regards, Kostas -- Kostas Zorbadelos http://gr.linkedin.com/in/kzorba
On Sep 10, 2018, at 1:17 PM, Kostas Zorbadelos <kzorba@otenet.gr> wrote:
I am talking about -f <file> in radclient. I made all tests and saw the constructed packets in wireshark. My guess is that you need escaping when reading the file, then again you use escaping when constructing the packet. Haven't gone through the code though.
Another example is when I needed to send a literal '\t' (without it being translated to tab). I had to use the sequence
User-Password = "test\\\\t1"
in the radclient input file to send 'test\t1' in the constructed packet.
Could it be that I am doing something wrong?
No. It looks like the backslash fixes aren't quite done yet. Alan DeKok.
On Παρ, Σεπ 07 2018 at 02:39:30 μμ, Alan DeKok <aland@deployingradius.com> wrote: Hi Alan, before opening a github issue, I saw yours: https://github.com/FreeRADIUS/freeradius-server/issues/2299
We fixed all of the handling of the backslash character in v3. Before that, it was random and inconsistent.
Now, the rules are the same as for shells. Which is what people are used to, and what makes sense.
Have you documented somewhere what is your intended policy with strings? Does it affect all strings (as in xlat expanded in configuration *and* string radius attribute values)? I can see that string attributes get escaped in the debug output as well, so I guess you un-escape/escape strings in both input and output, correct? Regards, Kostas -- Kostas Zorbadelos http://gr.linkedin.com/in/kzorba
On Sep 11, 2018, at 9:00 AM, Kostas Zorbadelos <kzorba@otenet.gr> wrote:
Have you documented somewhere what is your intended policy with strings?
The normal rules apply for double-quoted strings. There's no need to re-document rules which have been documented elsewhere for 30+ years.
Does it affect all strings (as in xlat expanded in configuration *and* string radius attribute values)?
The rules for double quoted strings apply to all double quoted strings...
I can see that string attributes get escaped in the debug output as well, so I guess you un-escape/escape strings in both input and output, correct?
Yes, when printing double quoted strings, you print the contents, including any escaped characters. The idea is that printing and parsing are the exact opposites. So parse(print(string)) == string, and print(parse("foo")) == "foo" Alan DeKok.
participants (3)
-
Alan DeKok -
Kostas Zorbadelos -
Olivier