using {CRYPT} for rootpw, using SHA512?

[Brian Reichert]

I've been messing with trying to get SHA512 password hash formats in
openldap 2.4.39 under a 64-bit CentOS 6 distribution, using the LTB RPMs.

I have read the FAQ at http://www.openldap.org/faq/data/cache/1467.html

- The first entry describes a third-party module; I have been
using that for years on a 32-bit CentOS 5 platform, using the
vendor-provided openldap-2.3.43 RPMs.

My efforts to build that module for 2.4.39 seemed to build clean,
but effort to bind as a user with a {SHA512} hashed password cause
slapd to segfault.

I didn't try very hard to track that down, as there seem to be
better supported techniques.

- The third entry describes a slapo-pw-sha2 overlay, but no LTB RPM
provides the overlay. I tried exactly once to build this overlay,
but that failed due to a configure failure. I blame me; I'll
revisit this when I have the time.

However, I had some luck with the second entry, using {CRYPT}.

Following these instructions, I was able to create users, successfully
bind, and even use ldappasswd to change the passwords:

http://www.openldap.org/lists/openldap-technical/201305/msg00002.html

But, when I generated a hashed password using suggestions like this:

http://serverfault.com/questions/330069/how-to-create-an-sha-512-hashed-password-for-shadow

# python -c 'import crypt; print crypt.crypt("test", "$6$random_salt")'
$6$random_salt$BnOQxEG8Gk2rzFYwoWXjr59zLVYzwshvca5oV0PtU8fAfT4a571evgca.E0hLnYNCdfq//zw9YyQN33QtztI10

and tried to embed this rootpw in my config file;

rootpw {CRYPT}$6$random_salt$BnOQxEG8Gk2rzFYwoWXjr59zLVYzwshvca5oV0PtU8fAfT4a571evgca.E0hLnYNCdfq//zw9YyQN33QtztI10

I would get bind errors.

Have I misunderstood how to use {CRYPT} for storing root's password?

[Quanah Gibson-Mount]

--On Thursday, August 14, 2014 5:05 PM -0400 Brian Reichert

Post by Brian Reichert
I've been messing with trying to get SHA512 password hash formats in
openldap 2.4.39 under a 64-bit CentOS 6 distribution, using the LTB RPMs.

SHA512 works fine for me with 2.4.39.

--Quanah


--

Quanah Gibson-Mount
Server Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration

[Quanah Gibson-Mount]

--On Thursday, August 14, 2014 2:45 PM -0700 Quanah Gibson-Mount

Post by Quanah Gibson-Mount
--On Thursday, August 14, 2014 5:05 PM -0400 Brian Reichert

Post by Brian Reichert
I've been messing with trying to get SHA512 password hash formats in
openldap 2.4.39 under a 64-bit CentOS 6 distribution, using the LTB RPMs.

SHA512 works fine for me with 2.4.39.

More specifically, I build openldap myself, and I do:

(cd openldap-$(LDAP_VERSION)/contrib/slapd-modules/passwd/sha2; \

LD_RUN_PATH=$(LDAP_LIB_DIR):$(OPENSSL_LIB_DIR):$(CYRUS_LIB_DIR):$(LIBTOOL_LIB_DIR)
$(MAKE) prefix=$(ZIMBRA_HOME)/openldap-$(LDAP_VERSION)
libexecdir=$(ZIMBRA_HOME)/openldap-$(LDAP_VERSION)/sbin
LIBS="-L$(LDAP_LIB_DIR) -lldap_r -llber" install STRIP=""; \


to build the module and then load the module:

olcModuleLoad: {7}pw-sha2.la

Then set the password hash in the frontend DB:

{-1}frontend DB:

olcPasswordHash: {SSHA512}

--Quanah

--

Quanah Gibson-Mount
Server Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration

[Brian Reichert]

Post by Quanah Gibson-Mount
--On Thursday, August 14, 2014 2:45 PM -0700 Quanah Gibson-Mount

Post by Quanah Gibson-Mount
SHA512 works fine for me with 2.4.39.

I concede, it should be straightforward.

Post by Quanah Gibson-Mount
More specifically, I build openldap myself,

That was my first speedbump, oddly enough.

This is a CentOS 6.5 box. I removed CentOS's openldap-servers and
openldap-clients RPMs. The core openldap RPM is still in place,
as CentOS has somee dependancies.

I installed openldap-ltb-2.4.39-2.el6.x86_64.rpm and
berkeleydb-ltb-4.6.21.NC-4.el6.patch4.x86_64.rpm from the LTB repo.
Successfully spun up slapd, using the shiny new mdb backend I
referred to in another thread.

Then:

# lwp-download ftp://ftp.openldap.org/pub/OpenLDAP/openldap-release/openldap-2.4.39.tgz
# tar -zxf openldap-2.4.39.tgz
# cd openldap-2.4.39
# ./configure
...
checking db.h usability... no
checking db.h presence... no
checking for db.h... no
configure: error: BDB/HDB: BerkeleyDB not available
# rpm -q db4 berkeleydb-ltb
db4-4.7.25-18.el6_4.x86_64
berkeleydb-ltb-4.6.21.NC-4.el6.patch4.x86_64

I suppose I can start playing the 'configure' whack-a-mole game that
I've been playing for decades, to try to work past the mismatch in
expectations. But, I'm really busy right now. :)
I'll happily give this a go, once I'm past other issues. Then, if
successful, figure out to package it up as an RPM, as in my
environment, it's part of our deployment process...

Post by Quanah Gibson-Mount
--Quanah
--
Quanah Gibson-Mount
Server Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration

[Howard Chu]

Post by Brian Reichert

Post by Quanah Gibson-Mount
--On Thursday, August 14, 2014 2:45 PM -0700 Quanah Gibson-Mount

Post by Quanah Gibson-Mount
SHA512 works fine for me with 2.4.39.

I concede, it should be straightforward.

Post by Quanah Gibson-Mount
More specifically, I build openldap myself,

That was my first speedbump, oddly enough.
This is a CentOS 6.5 box. I removed CentOS's openldap-servers and
openldap-clients RPMs. The core openldap RPM is still in place,
as CentOS has somee dependancies.
I installed openldap-ltb-2.4.39-2.el6.x86_64.rpm and
berkeleydb-ltb-4.6.21.NC-4.el6.patch4.x86_64.rpm from the LTB repo.
Successfully spun up slapd, using the shiny new mdb backend I
referred to in another thread.
# lwp-download ftp://ftp.openldap.org/pub/OpenLDAP/openldap-release/openldap-2.4.39.tgz
# tar -zxf openldap-2.4.39.tgz
# cd openldap-2.4.39
# ./configure
...
checking db.h usability... no
checking db.h presence... no
checking for db.h... no
configure: error: BDB/HDB: BerkeleyDB not available
# rpm -q db4 berkeleydb-ltb
db4-4.7.25-18.el6_4.x86_64
berkeleydb-ltb-4.6.21.NC-4.el6.patch4.x86_64

Most likely you only installed the library, but you need the -devel package.

You could, of course, also configure --disable-bdb --disable-hdb and ignore
it, since you're using mdb.

[Brian Reichert]

How do you encode your random salt?

In the example I gave, my salt was the actual string 'random_salt',
right from the example in the URL. Comments on the thread to that
example make it clear you should actually use a random salt, and
I've found pleny of examples that purport to generate one. By eye,
'random_salt' matches the regex you suggest.

But, I obviously could be quite wrong with such assertions.

SHA-512 password hash as used in
glibc crypt() implementation requires the salt be a random string
containing up to 16 characters drawn from the set [a-zA-Z0-9./]. I'm
using something like this to generate the salt (and hope for the

I'll give this a shot, and report back; thanks for the feedback!

Works quite well with our LDAP boxes.
Best regards,
??? Miroslaw Baran

[Miroslaw Baran]

Post by Brian Reichert

How do you encode your random salt?

In the example I gave, my salt was the actual string 'random_salt',
right from the example in the URL. Comments on the thread to that
example make it clear you should actually use a random salt, and
I've found pleny of examples that purport to generate one. By eye,
'random_salt' matches the regex you suggest.

Ah: underscore. Underscore doesn't, I'm afraid. [Yep; tested in a sandbox.]

-- m.

[Brian Reichert]

Post by Miroslaw Baran
Ah: underscore. Underscore doesn't, I'm afraid. [Yep; tested in a sandbox.]

Curses! You've caught me out! :)

Post by Miroslaw Baran
-- m.

[Brian Reichert]

Works quite well with our LDAP boxes.

So, what I see:

This code yeilds results like:

{CRYPT}JHGa.sqLNfcew

Which, by eye, looks like output from this:

# /usr/local/openldap/sbin/slappasswd -h '{CRYPT}' -s TestPass -c "$6$%.12s"
{CRYPT}$g6KO.N/Fj3GQ

Which do allow my rootdn to bind.

But, what confuses me is that the use of the password overlay as per

http://www.openldap.org/lists/openldap-technical/201305/msg00002.html

Yeilds this sort of results in an ldapsearch:

{CRYPT}$6$RKd7QOs4qcMu$0rxaR7Sjcl1Gm1sRU13H3lvha7.FbBXiNYK2hDix6rXekruzuNN7pW/1/9755KmD9NLqYcTFDbxubAvxyX.wg.

So - everything works, but I'm confused visually about the different
formats; the latter, from what I've read, contains info about the hash
format and the salt, but the data I record for rootpw does not.

Why are they different?

Best regards,
??? Miroslaw Baran

[Michael Ströder]

Post by Brian Reichert
slappasswd -h '{CRYPT}' -s TestPass -c "$6$%.12s"

Don't use double quotes with literally dollar signs in there (shell variable!).

Use this:

$ slappasswd -h '{CRYPT}' -s 'TestPass' -c '$6$%.12s'
{CRYPT}$6$mf/KdGXjco8f$Q5Jd034r2gCUaHqAGu03MWqUN8jRvKFtfEgVjnMj/Hjof3k1cELHMJkcvU3kfq0YsdlTTDLFVeqI53F1ZgXGk.

Ciao, Michael.

[Michael Ströder]

Post by Brian Reichert
Which do allow my rootdn to bind.

I'd argue that you don't need rootpw in configuration though. ;-)

Ciao, Michael.

[Ulrich Windl]

Post by Brian Reichert

Works quite well with our LDAP boxes.

[...]

Post by Brian Reichert
{CRYPT}JHGa.sqLNfcew

[...]

Post by Brian Reichert
{CRYPT}$6$RKd7QOs4qcMu$0rxaR7Sjcl1Gm1sRU13H3lvha7.FbBXiNYK2hDix6rXekruzuNN7pW/1/9755KmD9NLqYcTFDbxubAvxyX.wg.

[...]

Only the first example given is actually crypt() in the strict sense; the second example given is an glibc extension to crypt (SHA-512 (since glibc 2.7))

So if that is going to work cross-plattform, you must have a recent version of glibc everywhere, I guess. Details in "crypt(3)"...

Regards,
Ulrich

[Mirosław Baran]

Post by Ulrich Windl
Only the first example given is actually crypt() in the strict sense;
the second example given is an glibc extension to crypt (SHA-512
(since glibc 2.7))
So if that is going to work cross-plattform, you must have a recent
version of glibc everywhere, I guess. Details in "crypt(3)"...

Well, as long as the only place the password is checked/hashed happens
to be
the LDAP server (running on reasonably recent glibc), it should work
fine even
for non-glibc-based clients.

Best regards,
– Miroslaw Baran

[Miroslaw Baran]

Post by Brian Reichert
# python -c 'import crypt; print crypt.crypt("test", "$6$random_salt")'
$6$random_salt$BnOQxEG8Gk2rzFYwoWXjr59zLVYzwshvca5oV0PtU8fAfT4a571evgca.E0hLnYNCdfq//zw9YyQN33QtztI10
and tried to embed this rootpw in my config file;
rootpw {CRYPT}$6$random_salt$BnOQxEG8Gk2rzFYwoWXjr59zLVYzwshvca5oV0PtU8fAfT4a571evgca.E0hLnYNCdfq//zw9YyQN33QtztI10
I would get bind errors.

How do you encode your random salt? SHA-512 password hash as used in
glibc crypt() implementation requires the salt be a random string
containing up to 16 characters drawn from the set [a-zA-Z0-9./]. I'm
using something like this to generate the salt (and hope for the
best):

# python code
import random
import string
from passlib.hash import sha512_crypt # on Linux systems it just uses
crypt.crypt())

def randomized_string(size=16, chars=string.letters + string.digits +
string.punctuation):
# string.printable produces more than we can eat, unfortunately
return ''.join(random.choice(chars) for x in range(size))

def make_pass(passwd=None):
# generate password using crypt()'s SHA-512 method, randomized salt and
# randomized number of rounds.
if passwd is None:
passwd = randomized_string(32)
salt = randomized_string(16, ( './' + string.letters + string.digits))
iterations = random.randint(40000, 80000)
return '{CRYPT}' + sha512_crypt.encrypt(passwd, salt=salt,
rounds=iterations)

Works quite well with our LDAP boxes.

Best regards,
– Miroslaw Baran