[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: How to make ldap evaluate clear text password vs DES stored password
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).