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-pass...
# 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?
--On Thursday, August 14, 2014 5:05 PM -0400 Brian Reichert reichert@numachi.com wrote:
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
--On Thursday, August 14, 2014 2:45 PM -0700 Quanah Gibson-Mount quanah@zimbra.com wrote:
--On Thursday, August 14, 2014 5:05 PM -0400 Brian Reichert reichert@numachi.com wrote:
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
On Thu, Aug 14, 2014 at 01:48:20PM -0700, Quanah Gibson-Mount wrote:
--On Thursday, August 14, 2014 2:45 PM -0700 Quanah Gibson-Mount quanah@zimbra.com wrote:
SHA512 works fine for me with 2.4.39.
I concede, it should be straightforward.
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. :)
and I do:
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...
--Quanah
--
Quanah Gibson-Mount Server Architect Zimbra, Inc.
Zimbra :: the leader in open source messaging and collaboration
Brian Reichert wrote:
On Thu, Aug 14, 2014 at 01:48:20PM -0700, Quanah Gibson-Mount wrote:
--On Thursday, August 14, 2014 2:45 PM -0700 Quanah Gibson-Mount quanah@zimbra.com wrote:
SHA512 works fine for me with 2.4.39.
I concede, it should be straightforward.
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
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.
On 14 August 2014 21:05, Brian Reichert reichert@numachi.com wrote:
# 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
On Fri, Aug 15, 2014 at 12:49:03PM +0100, Miroslaw Baran wrote:
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 best):
I'll give this a shot, and report back; thanks for the feedback!
Works quite well with our LDAP boxes.
Best regards, ??? Miroslaw Baran
On Fri 15 Aug 2014 09:40:39 Brian Reichert wrote:
On Fri, Aug 15, 2014 at 12:49:03PM +0100, Miroslaw Baran wrote:
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.
On Fri, Aug 15, 2014 at 03:13:06PM +0100, Miroslaw Baran wrote:
Ah: underscore. Underscore doesn't, I'm afraid. [Yep; tested in a sandbox.]
Curses! You've caught me out! :)
-- m.
On Fri, Aug 15, 2014 at 12:49:03PM +0100, Miroslaw Baran wrote:
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
Brian Reichert wrote:
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.
Brian Reichert reichert@numachi.com schrieb am 15.08.2014 um 16:38 in
Nachricht 20140815143811.GN30182@numachi.com:
On Fri, Aug 15, 2014 at 12:49:03PM +0100, Miroslaw Baran wrote:
Works quite well with our LDAP boxes.
[...]
{CRYPT}JHGa.sqLNfcew
[...]
{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
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
openldap-technical@openldap.org
-
Brian Reichert -
Howard Chu -
Michael Ströder -
Miroslaw Baran -
Miroslaw Baran -
Mirosław Baran
-
Quanah Gibson-Mount -
Ulrich Windl