Hello
I realized that userPassword in my openldap directory cannot be validated when hashed in SSHA-512 ldapsearch binds fails (err 49) , shibboleth SSO binding against ldap userPassword also fails I tried to check the cleartext password against the userPassword field with ApacheDirectoryStudio , here it works . I changed the password (reseeting the same cleartext one) using SSHA-256 (again in ApacheDirectoryStudio interface) , then ldapsearch bind works !
Is there a problem with SSHA-512 hashed userPassword ? Maybe something one the client or server side must be set to use SSHA-512 ?
Thanks for your advices .
--On Thursday, July 16, 2020 11:08 PM +0200 Jehan PROCACCIA jehan.procaccia@imtbs-tsp.eu wrote:
Is there a problem with SSHA-512 hashed userPassword ? Maybe something one the client or server side must be set to use SSHA-512 ?
Three things:
a) For ldap binds to work with SSHA512, the pw-sha2 module must be loaded in slapd
b) Passwords should be changed via an LDAP v3 password modify option. This requires the 2.0.0-M15 (or later) release of Apache Directory Studio, and doing so is obtuse with the way it's currently implemented (See also https://issues.apache.org/jira/browse/DIRSTUDIO-648)
c) No client should care how userPassword is stored. If it does, then the client is implemented incorrectly.
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
thank you for you response indeed a) answer did solve the pb by loading pw-sha2 :
dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: pw-sha2
I also read on tutos to set olcPasswordHash: {SSHA}
dn: olcDatabase={-1}frontend,cn=config add: olcPasswordHash olcPasswordHash: {SSHA}
Although I applied both of these config, I don't think the latter solve my initial pb , I guess 1st one was sufficient . that second (olcPasswordHash: {SSHA}) is only necessary to force SSHA hash when user change their password ?
Thanks .
----- Mail original ----- De: "Quanah Gibson-Mount" quanah@symas.com À: "jehan procaccia" jehan.procaccia@imtbs-tsp.eu, "openldap-technical" openldap-technical@openldap.org Envoyé: Jeudi 16 Juillet 2020 23:01:04 Objet: Re: invalid credentials when userPassword hash in SSHA-512
--On Thursday, July 16, 2020 11:08 PM +0200 Jehan PROCACCIA jehan.procaccia@imtbs-tsp.eu wrote:
Is there a problem with SSHA-512 hashed userPassword ? Maybe something one the client or server side must be set to use SSHA-512 ?
Three things:
a) For ldap binds to work with SSHA512, the pw-sha2 module must be loaded in slapd
b) Passwords should be changed via an LDAP v3 password modify option. This requires the 2.0.0-M15 (or later) release of Apache Directory Studio, and doing so is obtuse with the way it's currently implemented (See also https://issues.apache.org/jira/browse/DIRSTUDIO-648)
c) No client should care how userPassword is stored. If it does, then the client is implemented incorrectly.
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
--O
dn: olcDatabase={-1}frontend,cn=config add: olcPasswordHash olcPasswordHash: {SSHA}
Although I applied both of these config, I don't think the latter solve my initial pb , I guess 1st one was sufficient . that second (olcPasswordHash: {SSHA}) is only necessary to force SSHA hash when user change their password ?
{SSHA} is the default, and is not {SSHA512}
If you want it to force SSHA512 for any new password changes done via an LDAP v3 password modify operation, you must set it to {SSHA512} instead of {SSHA}.
I would note that starting with OpenLDAP 2.4.50, ARGON2 password hashes are supported the argon2 password module, and they are considered more secure than SSHA512.
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
openldap-technical@openldap.org
-
Jehan PROCACCIA -
Quanah Gibson-Mount