Thanks for the explanation, Quanah. Much appreciated!
--
Robert G. Werner
Systems Admnistrator
University of California Merced, Office of Information Techonology
-------- Original message --------
From: Quanah Gibson-Mount <quanah@xxxxxxxxx>
Date: 6/5/18 5:34 PM (GMT-08:00)
To: Robert Werner <rwerner2@xxxxxxxxxxxx>, Dan White <dwhite@xxxxxxx>
Cc: cyrus-sasl@xxxxxxxxxxxxxxxxxxxx
Subject: Re: Problem using saslauthd against ldap server ...
--On Tuesday, June 05, 2018 11:45 PM +0000 Robert Werner
<rwerner2@xxxxxxxxxxxx> wrote:
> We are using the "userPassword" attribute, and the password is
> encrypted. I"m not sure what the algo is. But the the thing is that
> with Auth Plain and Auth Login the password is being send in clear.
The userPassword attribute, by RFC, is base64 encoded (not encrypted). The
reason you see "userPassword:: <value>" from an ldapsearch result (vs
"userPassword: <value>") indicates that encoding is in place. You can
trivially decode the value. In addition, OpenLDAP by default stores a hash
of the password, not the password itself.
If you decode the value, you should get something like:
{SSHA}m80vEZ5rVevDAMoamCO1qKwIV/AEow8D
which indicates that the password hash is using SSHA.
The real issue, based on what you're describing, is that the password being
sent to the ldap server to validate against the hash has been truncated for
some reason.
You can confirm that basic authentication against your ldap server is
working via the "ldapwhoami" binary to rule out any issue on the LDAP
server side.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
<rwerner2@xxxxxxxxxxxx> wrote:
> We are using the "userPassword" attribute, and the password is
> encrypted. I"m not sure what the algo is. But the the thing is that
> with Auth Plain and Auth Login the password is being send in clear.
The userPassword attribute, by RFC, is base64 encoded (not encrypted). The
reason you see "userPassword:: <value>" from an ldapsearch result (vs
"userPassword: <value>") indicates that encoding is in place. You can
trivially decode the value. In addition, OpenLDAP by default stores a hash
of the password, not the password itself.
If you decode the value, you should get something like:
{SSHA}m80vEZ5rVevDAMoamCO1qKwIV/AEow8D
which indicates that the password hash is using SSHA.
The real issue, based on what you're describing, is that the password being
sent to the ldap server to validate against the hash has been truncated for
some reason.
You can confirm that basic authentication against your ldap server is
working via the "ldapwhoami" binary to rule out any issue on the LDAP
server side.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
