Getting a string 'as is' with no escapes from LDAP
Hello all, I think a new thread is better for this discussion. In a previous thread (http://lists.freeradius.org/pipermail/freeradius-users/2018-September/092606...) I raised the issue of failing to get a string as is from an LDAP backend. The string represents the clear text password and I would like to take it 'as is' with no escaping of any kind. I got the explanation about the shell rules that are now implemented in freeradius 3 for strings, so as to get a single uniform approach to freeradius 3 and fix the inconsistencies of string handling in freeradius 2. We got to the solution of mapping the LDAP attribute as a binary attribute, say Tmp-Octets-0 and then use the following policy: 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. Now, we found a problem for strings beginning with '0x' :) Example 1 (passwd '0xtest123') -------------------------------- kzorba@devradius(0)[09:34 AM]~/radius->/opt/freeradius/bin/radclient -f test_kzorba1.txt -x 79.128.176.142:1812 auth testing123 Sending Access-Request of id 178 to 79.128.176.142 port 1812 User-Name = "kzorba1@otenet.gr" NAS-Port-Type = xDSL User-Password = "0xtest123" NAS-Port-Id = "#DSLAM PORT DESCRIPTION HERE#" Calling-Station-Id = "BNG INTERFACE # DSLAM PORT DESCRIPTION" NAS-Port = 12234455 rad_recv: Access-Reject packet from host 79.128.176.142 port 1812, id=178, length=20 (0) Received Access-Request Id 99 from 79.128.176.142:50436 to 79.128.176.142:1812 length 140 (0) User-Name = "kzorba1@otenet.gr" (0) NAS-Port-Type = xDSL (0) User-Password = "0xtest123" (0) NAS-Port-Id = "#DSLAM PORT DESCRIPTION HERE#" (0) Calling-Station-Id = "BNG INTERFACE # DSLAM PORT DESCRIPTION" (0) NAS-Port = 12234455 (0) # Executing section authorize from file /opt/freeradius-3.0.17/etc/raddb/sites-enabled/cisco-bng (0) authorize { (0) [preprocess] = ok (0) [chap] = noop (0) [mschap] = noop ... rlm_ldap (ldap_1): Reserved connection (0) ... (0) ldap_1: Performing search in "..." with filter "...", scope "sub" (0) ldap_1: Waiting for search result... (0) ldap_1: User object found at DN "..." (0) ldap_1: Processing user attributes ... (0) ldap_1: WARNING: Failed parsing value "0xtest123" for attribute Tmp-Octets-0: Length of Hex String is not even, got 7 bytes ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (0) ldap_1: No attributes updated (0) ldap_1: reply:Framed-IP-Address = 62.103.131.9 rlm_ldap (ldap_1): Released connection (0) (0) [ldap_1] = updated ... (0) pap: WARNING: No "known good" password found for the user. Not setting Auth-Type (0) pap: WARNING: Authentication will fail unless a "known good" password is available (0) [pap] = noop (0) } # authorize = updated (0) ERROR: No Auth-Type found: rejecting the user via Post-Auth-Type = Reject (0) Failed to authenticate the user (0) Using Post-Auth-Type Reject (0) # Executing group from file /opt/freeradius-3.0.17/etc/raddb/sites-enabled/cisco-bng (0) Post-Auth-Type REJECT { (0) attr_filter.access_reject: EXPAND %{User-Name} (0) attr_filter.access_reject: --> kzorba1@otenet.gr (0) attr_filter.access_reject: Matched entry DEFAULT at line 11 (0) [attr_filter.access_reject] = updated (0) } # Post-Auth-Type REJECT = updated (0) Login incorrect (No Auth-Type found: rejecting the user via Post-Auth-Type = Reject): [kzorba1@otenet.gr] (from client myself port 12234455 cli BNG INTERFACE # DSLAM PORT DESC RIPTION) (0) Delaying response for 1.000000 seconds Waking up in 0.3 seconds. Example 2 (passwd '0xtest1234') -------------------------------- kzorba@devradius(0)[09:39 AM]~/radius->/opt/freeradius/bin/radclient -f test_kzorba1.txt -x 79.128.176.142:1812 auth testing123 Sending Access-Request of id 85 to 79.128.176.142 port 1812 User-Name = "kzorba1@otenet.gr" NAS-Port-Type = xDSL User-Password = "0xtest1234" NAS-Port-Id = "#DSLAM PORT DESCRIPTION HERE#" Calling-Station-Id = "BNG INTERFACE # DSLAM PORT DESCRIPTION" NAS-Port = 12234455 rad_recv: Access-Reject packet from host 79.128.176.142 port 1812, id=85, length=20 (0) Received Access-Request Id 85 from 79.128.176.142:38359 to 79.128.176.142:1812 length 140 (0) User-Name = "kzorba1@otenet.gr" (0) NAS-Port-Type = xDSL (0) User-Password = "0xtest1234" (0) NAS-Port-Id = "#DSLAM PORT DESCRIPTION HERE#" (0) Calling-Station-Id = "BNG INTERFACE # DSLAM PORT DESCRIPTION" (0) NAS-Port = 12234455 (0) # Executing section authorize from file /opt/freeradius-3.0.17/etc/raddb/sites-enabled/cisco-bng (0) authorize { ... (0) ldap_1: WARNING: Failed parsing value "0xtest1234" for attribute Tmp-Octets-0: Invalid hex data (0) ldap_1: No attributes updated ... Is there a way to overcome this? Generally speaking a solution is needed to get a string 'as is' out of an LDAP backend (most probably this will affect other backends too) without escaping/unescaping of any kind. Regards, Kostas -- Kostas Zorbadelos http://gr.linkedin.com/in/kzorba
Quick update, I found a workaround in my case. I map the ldap attribute to a binary attribute and in case for any reason this fails, I use Auth-Type ldap as last resort. My policy now looks like this: authorize { ... # set Cleartext-Password from LDAP in a way that avoids # freeradius string escaping rules if (&control:Tmp-Octets-0) { update control { Cleartext-Password := "%{string:&control:Tmp-Octets-0}" } } else { update { control:Auth-Type := ldap_1 } } ... } authenticate { ... ldap_1 } This seems to work. In any case, I consider it an issue that we cannot retrieve a string 'as is' out of an LDAP backend (and perhaps other backends too). Any thoughts/input highly welcome. Regards, Kostas On Τετ, Σεπ 12 2018 at 09:42:38 πμ, Kostas Zorbadelos <kzorba@otenet.gr> wrote:
Hello all,
I think a new thread is better for this discussion. In a previous thread (http://lists.freeradius.org/pipermail/freeradius-users/2018-September/092606...) I raised the issue of failing to get a string as is from an LDAP backend. The string represents the clear text password and I would like to take it 'as is' with no escaping of any kind.
I got the explanation about the shell rules that are now implemented in freeradius 3 for strings, so as to get a single uniform approach to freeradius 3 and fix the inconsistencies of string handling in freeradius 2.
We got to the solution of mapping the LDAP attribute as a binary attribute, say Tmp-Octets-0 and then use the following policy:
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.
Now, we found a problem for strings beginning with '0x' :)
Example 1 (passwd '0xtest123') -------------------------------- kzorba@devradius(0)[09:34 AM]~/radius->/opt/freeradius/bin/radclient -f test_kzorba1.txt -x 79.128.176.142:1812 auth testing123 Sending Access-Request of id 178 to 79.128.176.142 port 1812 User-Name = "kzorba1@otenet.gr" NAS-Port-Type = xDSL User-Password = "0xtest123" NAS-Port-Id = "#DSLAM PORT DESCRIPTION HERE#" Calling-Station-Id = "BNG INTERFACE # DSLAM PORT DESCRIPTION" NAS-Port = 12234455 rad_recv: Access-Reject packet from host 79.128.176.142 port 1812, id=178, length=20
(0) Received Access-Request Id 99 from 79.128.176.142:50436 to 79.128.176.142:1812 length 140 (0) User-Name = "kzorba1@otenet.gr" (0) NAS-Port-Type = xDSL (0) User-Password = "0xtest123" (0) NAS-Port-Id = "#DSLAM PORT DESCRIPTION HERE#" (0) Calling-Station-Id = "BNG INTERFACE # DSLAM PORT DESCRIPTION" (0) NAS-Port = 12234455 (0) # Executing section authorize from file /opt/freeradius-3.0.17/etc/raddb/sites-enabled/cisco-bng (0) authorize { (0) [preprocess] = ok (0) [chap] = noop (0) [mschap] = noop ... rlm_ldap (ldap_1): Reserved connection (0) ... (0) ldap_1: Performing search in "..." with filter "...", scope "sub" (0) ldap_1: Waiting for search result... (0) ldap_1: User object found at DN "..." (0) ldap_1: Processing user attributes ... (0) ldap_1: WARNING: Failed parsing value "0xtest123" for attribute Tmp-Octets-0: Length of Hex String is not even, got 7 bytes ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (0) ldap_1: No attributes updated (0) ldap_1: reply:Framed-IP-Address = 62.103.131.9 rlm_ldap (ldap_1): Released connection (0) (0) [ldap_1] = updated ... (0) pap: WARNING: No "known good" password found for the user. Not setting Auth-Type (0) pap: WARNING: Authentication will fail unless a "known good" password is available (0) [pap] = noop (0) } # authorize = updated (0) ERROR: No Auth-Type found: rejecting the user via Post-Auth-Type = Reject (0) Failed to authenticate the user (0) Using Post-Auth-Type Reject (0) # Executing group from file /opt/freeradius-3.0.17/etc/raddb/sites-enabled/cisco-bng (0) Post-Auth-Type REJECT { (0) attr_filter.access_reject: EXPAND %{User-Name} (0) attr_filter.access_reject: --> kzorba1@otenet.gr (0) attr_filter.access_reject: Matched entry DEFAULT at line 11 (0) [attr_filter.access_reject] = updated (0) } # Post-Auth-Type REJECT = updated (0) Login incorrect (No Auth-Type found: rejecting the user via Post-Auth-Type = Reject): [kzorba1@otenet.gr] (from client myself port 12234455 cli BNG INTERFACE # DSLAM PORT DESC RIPTION) (0) Delaying response for 1.000000 seconds Waking up in 0.3 seconds.
Example 2 (passwd '0xtest1234') -------------------------------- kzorba@devradius(0)[09:39 AM]~/radius->/opt/freeradius/bin/radclient -f test_kzorba1.txt -x 79.128.176.142:1812 auth testing123 Sending Access-Request of id 85 to 79.128.176.142 port 1812 User-Name = "kzorba1@otenet.gr" NAS-Port-Type = xDSL User-Password = "0xtest1234" NAS-Port-Id = "#DSLAM PORT DESCRIPTION HERE#" Calling-Station-Id = "BNG INTERFACE # DSLAM PORT DESCRIPTION" NAS-Port = 12234455 rad_recv: Access-Reject packet from host 79.128.176.142 port 1812, id=85, length=20
(0) Received Access-Request Id 85 from 79.128.176.142:38359 to 79.128.176.142:1812 length 140 (0) User-Name = "kzorba1@otenet.gr" (0) NAS-Port-Type = xDSL (0) User-Password = "0xtest1234" (0) NAS-Port-Id = "#DSLAM PORT DESCRIPTION HERE#" (0) Calling-Station-Id = "BNG INTERFACE # DSLAM PORT DESCRIPTION" (0) NAS-Port = 12234455 (0) # Executing section authorize from file /opt/freeradius-3.0.17/etc/raddb/sites-enabled/cisco-bng (0) authorize { ... (0) ldap_1: WARNING: Failed parsing value "0xtest1234" for attribute Tmp-Octets-0: Invalid hex data (0) ldap_1: No attributes updated ...
Is there a way to overcome this? Generally speaking a solution is needed to get a string 'as is' out of an LDAP backend (most probably this will affect other backends too) without escaping/unescaping of any kind.
Regards, Kostas
-- Kostas Zorbadelos http://gr.linkedin.com/in/kzorba
Seemed like a good idea to open an issue for it (#2302): https://github.com/FreeRADIUS/freeradius-server/issues/2302 Regards, Kostas On Τετ, Σεπ 12 2018 at 11:27:17 πμ, Kostas Zorbadelos <kzorba@otenet.gr> wrote:
Quick update, I found a workaround in my case.
I map the ldap attribute to a binary attribute and in case for any reason this fails, I use Auth-Type ldap as last resort.
My policy now looks like this:
authorize { ...
# set Cleartext-Password from LDAP in a way that avoids # freeradius string escaping rules if (&control:Tmp-Octets-0) { update control { Cleartext-Password := "%{string:&control:Tmp-Octets-0}" } } else { update { control:Auth-Type := ldap_1 } } ... }
authenticate { ... ldap_1 }
This seems to work. In any case, I consider it an issue that we cannot retrieve a string 'as is' out of an LDAP backend (and perhaps other backends too).
Any thoughts/input highly welcome.
Regards, Kostas
On Τετ, Σεπ 12 2018 at 09:42:38 πμ, Kostas Zorbadelos <kzorba@otenet.gr> wrote:
Hello all,
I think a new thread is better for this discussion. In a previous thread (http://lists.freeradius.org/pipermail/freeradius-users/2018-September/092606...) I raised the issue of failing to get a string as is from an LDAP backend. The string represents the clear text password and I would like to take it 'as is' with no escaping of any kind.
I got the explanation about the shell rules that are now implemented in freeradius 3 for strings, so as to get a single uniform approach to freeradius 3 and fix the inconsistencies of string handling in freeradius 2.
We got to the solution of mapping the LDAP attribute as a binary attribute, say Tmp-Octets-0 and then use the following policy:
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.
Now, we found a problem for strings beginning with '0x' :)
Example 1 (passwd '0xtest123') -------------------------------- kzorba@devradius(0)[09:34 AM]~/radius->/opt/freeradius/bin/radclient -f test_kzorba1.txt -x 79.128.176.142:1812 auth testing123 Sending Access-Request of id 178 to 79.128.176.142 port 1812 User-Name = "kzorba1@otenet.gr" NAS-Port-Type = xDSL User-Password = "0xtest123" NAS-Port-Id = "#DSLAM PORT DESCRIPTION HERE#" Calling-Station-Id = "BNG INTERFACE # DSLAM PORT DESCRIPTION" NAS-Port = 12234455 rad_recv: Access-Reject packet from host 79.128.176.142 port 1812, id=178, length=20
(0) Received Access-Request Id 99 from 79.128.176.142:50436 to 79.128.176.142:1812 length 140 (0) User-Name = "kzorba1@otenet.gr" (0) NAS-Port-Type = xDSL (0) User-Password = "0xtest123" (0) NAS-Port-Id = "#DSLAM PORT DESCRIPTION HERE#" (0) Calling-Station-Id = "BNG INTERFACE # DSLAM PORT DESCRIPTION" (0) NAS-Port = 12234455 (0) # Executing section authorize from file /opt/freeradius-3.0.17/etc/raddb/sites-enabled/cisco-bng (0) authorize { (0) [preprocess] = ok (0) [chap] = noop (0) [mschap] = noop ... rlm_ldap (ldap_1): Reserved connection (0) ... (0) ldap_1: Performing search in "..." with filter "...", scope "sub" (0) ldap_1: Waiting for search result... (0) ldap_1: User object found at DN "..." (0) ldap_1: Processing user attributes ... (0) ldap_1: WARNING: Failed parsing value "0xtest123" for attribute Tmp-Octets-0: Length of Hex String is not even, got 7 bytes ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (0) ldap_1: No attributes updated (0) ldap_1: reply:Framed-IP-Address = 62.103.131.9 rlm_ldap (ldap_1): Released connection (0) (0) [ldap_1] = updated ... (0) pap: WARNING: No "known good" password found for the user. Not setting Auth-Type (0) pap: WARNING: Authentication will fail unless a "known good" password is available (0) [pap] = noop (0) } # authorize = updated (0) ERROR: No Auth-Type found: rejecting the user via Post-Auth-Type = Reject (0) Failed to authenticate the user (0) Using Post-Auth-Type Reject (0) # Executing group from file /opt/freeradius-3.0.17/etc/raddb/sites-enabled/cisco-bng (0) Post-Auth-Type REJECT { (0) attr_filter.access_reject: EXPAND %{User-Name} (0) attr_filter.access_reject: --> kzorba1@otenet.gr (0) attr_filter.access_reject: Matched entry DEFAULT at line 11 (0) [attr_filter.access_reject] = updated (0) } # Post-Auth-Type REJECT = updated (0) Login incorrect (No Auth-Type found: rejecting the user via Post-Auth-Type = Reject): [kzorba1@otenet.gr] (from client myself port 12234455 cli BNG INTERFACE # DSLAM PORT DESC RIPTION) (0) Delaying response for 1.000000 seconds Waking up in 0.3 seconds.
Example 2 (passwd '0xtest1234') -------------------------------- kzorba@devradius(0)[09:39 AM]~/radius->/opt/freeradius/bin/radclient -f test_kzorba1.txt -x 79.128.176.142:1812 auth testing123 Sending Access-Request of id 85 to 79.128.176.142 port 1812 User-Name = "kzorba1@otenet.gr" NAS-Port-Type = xDSL User-Password = "0xtest1234" NAS-Port-Id = "#DSLAM PORT DESCRIPTION HERE#" Calling-Station-Id = "BNG INTERFACE # DSLAM PORT DESCRIPTION" NAS-Port = 12234455 rad_recv: Access-Reject packet from host 79.128.176.142 port 1812, id=85, length=20
(0) Received Access-Request Id 85 from 79.128.176.142:38359 to 79.128.176.142:1812 length 140 (0) User-Name = "kzorba1@otenet.gr" (0) NAS-Port-Type = xDSL (0) User-Password = "0xtest1234" (0) NAS-Port-Id = "#DSLAM PORT DESCRIPTION HERE#" (0) Calling-Station-Id = "BNG INTERFACE # DSLAM PORT DESCRIPTION" (0) NAS-Port = 12234455 (0) # Executing section authorize from file /opt/freeradius-3.0.17/etc/raddb/sites-enabled/cisco-bng (0) authorize { ... (0) ldap_1: WARNING: Failed parsing value "0xtest1234" for attribute Tmp-Octets-0: Invalid hex data (0) ldap_1: No attributes updated ...
Is there a way to overcome this? Generally speaking a solution is needed to get a string 'as is' out of an LDAP backend (most probably this will affect other backends too) without escaping/unescaping of any kind.
Regards, Kostas
-- Kostas Zorbadelos http://gr.linkedin.com/in/kzorba
On Sep 12, 2018, at 2:42 AM, Kostas Zorbadelos <kzorba@otenet.gr> wrote:
I think a new thread is better for this discussion. In a previous thread (http://lists.freeradius.org/pipermail/freeradius-users/2018-September/092606...) I raised the issue of failing to get a string as is from an LDAP backend. The string represents the clear text password and I would like to take it 'as is' with no escaping of any kind.
I got the explanation about the shell rules that are now implemented in freeradius 3 for strings, so as to get a single uniform approach to freeradius 3 and fix the inconsistencies of string handling in freeradius 2.
Yes. Plus, we have no idea what's in the back-end database. Are the strings "raw" and should be used as-is? Or do the strings contain escaped characters? It's impossible to know in advance. People want to use both types of data. We try to have the server make the best choice, but it's just a guess.
Now, we found a problem for strings beginning with '0x' :)
Yes. Some people want to be able to assign binary data to strings, too. So that syntax is supported. The question again is when and where it should be supported...
Is there a way to overcome this?
Come up with a solution that makes sense, works, and is simple for people to use.
Generally speaking a solution is needed to get a string 'as is' out of an LDAP backend (most probably this will affect other backends too) without escaping/unescaping of any kind.
There's a lot more than that involved, unfortunately. Alan DeKok.
On Πεμ, Σεπ 13 2018 at 10:09:58 πμ, Alan DeKok <aland@deployingradius.com> wrote:
On Sep 12, 2018, at 2:42 AM, Kostas Zorbadelos <kzorba@otenet.gr> wrote:
I think a new thread is better for this discussion. In a previous thread (http://lists.freeradius.org/pipermail/freeradius-users/2018-September/092606...) I raised the issue of failing to get a string as is from an LDAP backend. The string represents the clear text password and I would like to take it 'as is' with no escaping of any kind.
I got the explanation about the shell rules that are now implemented in freeradius 3 for strings, so as to get a single uniform approach to freeradius 3 and fix the inconsistencies of string handling in freeradius 2.
Yes.
Plus, we have no idea what's in the back-end database. Are the strings "raw" and should be used as-is? Or do the strings contain escaped characters?
You are correct, it could be both.
It's impossible to know in advance. People want to use both types of data. We try to have the server make the best choice, but it's just a guess.
Now, we found a problem for strings beginning with '0x' :)
Yes. Some people want to be able to assign binary data to strings, too. So that syntax is supported.
The question again is when and where it should be supported...
Is there a way to overcome this?
Come up with a solution that makes sense, works, and is simple for people to use.
I can only make a rough first proposal. In case of strings stored in a backend DB (LDAP, RDBMS) that get mapped to radius attributes it would be nice to let the admin declare the expected behavior. For example we could use something in the attribute definition in the dictionary to declare that values out of parsing of such an attribute should be obtained in raw form.
Generally speaking a solution is needed to get a string 'as is' out of an LDAP backend (most probably this will affect other backends too) without escaping/unescaping of any kind.
There's a lot more than that involved, unfortunately.
I can only guess the complexity. You fully grasp the code. Should we move the discussion to the github issue? Do you think this is a valid feature to have and work towards a solution? Regards, Kostas PS: I am curious, doesn't anyone else store clear text passwords with funny characters in backend DBs? As I said this used to work in freeradius 2 ldap module. -- Kostas Zorbadelos http://gr.linkedin.com/in/kzorba
participants (2)
-
Alan DeKok -
Kostas Zorbadelos