Hi,

Thank you!! I was fooled when I checked the content with vi. Sorry for the disturbance, I hope it will help others.

Yours sincerely,

Antoine

On 13/12/2019 04:29, Howard Chu wrote:

Antoine Tran wrote:

...

On 12/12/2019 14:02, Howard Chu wrote:

...

antoine.tran@thales-services.fr wrote:

...

Full_Name: Antoine TRAN Version: openldap-servers-2.4.44-21.el7_6.x86_64 OS: CentOS Linux release 7.7.1908 (Core) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.190.88.94)

I use slappasswd to generate SSHA password. The issue is it behavior is different whether I submit the password - in stdin or in command-line '-s' - and from a secret file '-T'. Command: slappasswd -h {SSHA} => write 'd' twice as password slappasswd -h {SSHA} -s d

provides working SSHA.

But: echo d >/run/secrets/rootpw slappasswd -h {SSHA} -T /run/secrets/rootpw provides a valid SSHA, but that does not match the password.

My multiple test are done by replacing rootpw in /etc/openldap/slapd.conf, regenerating with: systemctl stop slapd sed -i -e "s,rootpw .*$,rootpw ${ROOTPW_HASH},g" /etc/openldap/slapd.conf slapcat -n 0 -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d systemctl start slapd ldapsearch -D "${ROOTDN}" -w "${ROOTPW}"

The content of the secret file can be "d" or "d\n", it does not make a difference. Also, if I change the schema from SSHA to just a fixed salt, the '-T' seems to work as expected: (a) slappasswd -c 123 => write d twice (b) slappasswd -c 123 -s 123 (c) slappasswd -c 123 -T /run/secrets/rootpw

(a), (b) and (c) gives the exact same hash. But I cannot put a fixed salt and use SSHA, slappasswd prevents me from that, with an error schema already provided.

Unable to reproduce, SSHA works fine here.

Obviously you can't use a fixed salt with SSHA, that's the point of its salt is to be random and different every time.

I wanted to override the salt as a test, to check if we have the same output with a file and in command-line. But I found another way to test.

...

When using a password in a file you must ensure the trailing '\n' is omitted. This is already documented in the manpage.

I did read and checked this point. I have written that I did not have a newline. But here is a simple and reproducible test, that took me some long time. In a Linux machine with internet, just copy paste this:

 docker run --name slappasswd --rm -ti centos:7 bash

 yum install openldap-servers -y

 cat <<EOF >/makeSecret.py
 import os
 import sys
 import hashlib
 from base64 import urlsafe_b64encode as encode
 from base64 import urlsafe_b64decode as decode

 def makeSecret(password):
     salt = os.urandom(4)
     h = hashlib.sha1(password)
     h.update(salt)
     return "{SSHA}" + encode(h.digest() + salt)

 if __name__ == '__main__':
     print(makeSecret(sys.argv[1]))
 EOF

 cat <<EOF >/checkPassword.py
 import os
 import sys
 import hashlib
 from base64 import urlsafe_b64encode as encode
 from base64 import urlsafe_b64decode as decode

 def checkPassword(challenge_password, password):
     challenge_bytes = decode(challenge_password[6:])
     digest = challenge_bytes[:20]
     salt = challenge_bytes[20:]
     hr = hashlib.sha1(password)
     hr.update(salt)
     return digest == hr.digest()

 if __name__ == '__main__':
     print(checkPassword(sys.argv[1], sys.argv[2]))
 EOF

 python /checkPassword.py $(python /makeSecret.py d) d

 python /checkPassword.py $(slappasswd -s d) d

 mkdir -p /run/secrets/
 echo d>/run/secrets/rootpw
 python /checkPassword.py $(slappasswd -T /run/secrets/rootpw) d
 echo Begin-$(cat /run/secrets/rootpw)-End
 # => shows no newline:
 #Begin-d-End

It will show you that all hash works except the part with slappasswd -T, and I checked the newline.

I've run your steps. Your test is still invalid. Learn how to use the echo command.

#### [root@507ab0515ed6 /]# od -xc /run/secrets/rootpw 0000000 0a64 d \n 0000002 [root@507ab0515ed6 /]# echo -n d > /run/secrets/rootpw [root@507ab0515ed6 /]# python /checkPassword.py $(slappasswd -T /run/secrets/rootpw) d Warning: Password file /run/secrets/rootpw is publicly readable/writeable True [root@507ab0515ed6 /]# ####

Closing this ITS.

...

...

...

I saw the same issue in another openldap mail: https://www.openldap.org/lists/openldap-software/200805/msg00060.html but no answer.