in message "Re: How to make ldap evaluate clear text password vs DES stored password", Dan White dwhite@cafedemocracy.org wrote:
On 09/20/18?08:43?+0900, yokoyamy@jacic.or.jp wrote:
LDAP’s userPassowrd stored in the RDB has been already DES hashed by original app. On the other hand, input password from ldapseach command line is CREARTEXT.
If the hashed/encrypted password is supported by your local crypt(3) library, you can prepend the userPassword value with {CRYPT} as specified in slapd-config(5) and section 14.4.2 of the Admin Guide.
Else, if you have a pam module which supports authentication of your hash, take a look at Pass-Through authentication (section 14.5).
On 09/20/18 23:27 +0900, yokoyamy@jacic.or.jp wrote:
My CentOS can make cleartext into DES .
hete is a part of my previous slapd.conf
olcPasswordHash: {CRYPT} olcSizeLimit: 5000 olcPasswordCryptSaltFormat: "_%s"
unfortunately,it didn't work for my issue.
i think my slapd uses DES when i try to store new userPasword.
slapd will not really be concerned about the format of your hash, as long as your underlyding crypt(3) supports it. slapd will pass the cleartext password received from the client to crypt. You will need to consult your cyrpt(3) manpage for what is supported, and for what format it expects to receive ($id$rounds=yyy$salt$encrypts).
i think unless i fetch userPasdword from RDB through slapd, i will not be able to find SALT in userPassword.
If your RDB has a pam authentication module, then that may be a more appropriate route. In that case you would not need to make any of your RDB password hashes directly available to slapd. slapd would pass the cleartext password, from the client, down to the pam module by way of pass-through authentication and saslauthd.
Also, you should be taking appropriate security measures to protect the cleartext password over the wire (ldaps/STARTTLS).