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