Thanks for the explanation, Quanah. Much appreciated!
-- Robert G. Werner Systems Admnistrator University of California Merced, Office of Information Techonology rwern...@ucmerced.edu<mailto:rwern...@ucmerced.edu> | it.ucmerced.edu<https://it.ucmerced.edu/> | 209.201.43<tel:209.201.4386>68 -------- Original message -------- From: Quanah Gibson-Mount <qua...@symas.com> Date: 6/5/18 5:34 PM (GMT-08:00) To: Robert Werner <rwern...@ucmerced.edu>, Dan White <dwh...@olp.net> Cc: cyrus-sasl@lists.andrew.cmu.edu Subject: Re: Problem using saslauthd against ldap server ... --On Tuesday, June 05, 2018 11:45 PM +0000 Robert Werner <rwern...@ucmerced.edu> 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>
