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

Kostas Zorbadelos kzorba at otenet.gr
Fri Sep 7 15:02:26 CEST 2018


On Παρ, Σεπ 07 2018 at 02:39:30 μμ, Alan DeKok <aland at 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 at 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 at 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		



More information about the Freeradius-Users mailing list