Can I convert the ldif's userPassword:: "salted hash, aka SSHA" to "hash type$salt$hash" format of shadow passwords?
Or do I need to force those users with SSHA hashed passwords to change their password?
Most of the users passwords are in crypt format. I found a perl one liner to base64 decode those passwords hashes. (1)
I'm attempting to create shadow passwd files with an old Debian 6.0.10 (squeeze) LDAP installation and Debian's slapd package (2.4.23-7.3+deb6u2 squeeze-lts patched oldoldstable) includes a perl script ldiftopasswd, which I thought came from upstream, but it's not included in the most recent source of openldap. If my reading of the perl is correct, it was meant for earlier iterations of shadow passwords that did not include hash format or salt. I'm not having any success using the script this far.
1. http://www.perlmonks.org/bare/?node_id=963814 alias ldapdecode="perl -MMIME::Base64 -n -00 -e 's/\n //g;s/(?<=:: )(\S+)/decode_base64($1)/eg;print'" and just do ldapsearch | ldapdecode
Thanks, Chuck
On Wednesday, 4 November 2015 17:45:28 CET, Chuck Peters wrote:
Can I convert the ldif's userPassword:: "salted hash, aka SSHA" to "hash type$salt$hash" format of shadow passwords?
Or do I need to force those users with SSHA hashed passwords to change their password?
You will not be able to decode SSHA hashed passwords to clear text, and for this reason to rehash them again.
matthias
On Wed, Nov 04, 2015 at 04:45:28PM +0000, Chuck Peters wrote:
Can I convert the ldif's userPassword:: "salted hash, aka SSHA" to "hash type$salt$hash" format of shadow passwords?
Not usefully: there is no support for single-round SSHA1 in most Unix-like crypt(3) libraries.
Or do I need to force those users with SSHA hashed passwords to change their password?
Yes
Most of the users passwords are in crypt format. I found a perl one liner to base64 decode those passwords hashes. (1)
By 'crypt format' do you mean the old Unix 13-char DES-based hash, or one of the newer ones? At present you should really only be using the newer multi-round hashes, with this order of preference:
$2y$ or $2a$ Bcrypt $6$ Multi-round SHA512 $5$ Multi-round SHA256 $1$ Multi-round MD5
I'm attempting to create shadow passwd files with an old Debian 6.0.10 (squeeze) LDAP installation and Debian's slapd package (2.4.23-7.3+deb6u2 squeeze-lts patched oldoldstable) includes a perl script ldiftopasswd, which I thought came from upstream, but it's not included in the most recent source of openldap. If my reading of the perl is correct, it was meant for earlier iterations of shadow passwords that did not include hash format or salt. I'm not having any success using the script this far.
alias ldapdecode="perl -MMIME::Base64 -n -00 -e 's/\n //g;s/(?<=:: )(\S+)/decode_base64($1)/eg;print'" and just do ldapsearch | ldapdecode
That script simply converts the Base64 encoded fields of an LDIF file into their native (binary) format.
Beware of old distros as they may not support all of the hash formats.
Why do you need a passwd/shadow file in the first place? Surely it is much better to set your systems up to validate logins against LDAP directly. That way the only thing that needs to care about hash formats is the LDAP server process.
Andrew
On Thu, Nov 5, 2015 at 9:45 AM, Andrew Findlay andrew.findlay@skills-1st.co.uk wrote:
On Wed, Nov 04, 2015 at 04:45:28PM +0000, Chuck Peters wrote:
Most of the users passwords are in crypt format. I found a perl one liner to base64 decode those passwords hashes. (1)
By 'crypt format' do you mean the old Unix 13-char DES-based hash, or one of the newer ones? At present you should really only be using the newer multi-round hashes, with this order of preference:
It's the old Unix hash. If it were up to me, we would be requiring all users change their password and update the hash to SHA512.
Beware of old distros as they may not support all of the hash formats.
I modified a passwd shell script which outputs a file with the SHA512 hash, so it is supported to some degree, but may not work for LDAP.
Why do you need a passwd/shadow file in the first place? Surely it is much better to set your systems up to validate logins against LDAP directly. That way the only thing that needs to care about hash formats is the LDAP server process.
Resources is the short answer. It's only one system currently and kind of a mess. Originally their were two systems, but system crashes and lack of resources... It's a small non-profit where we do not want most of our users sharing LDAP info. We need to upgrade the old Debian OS and we are migrating to a VPS. Feb is technically when Debian LTS support ends, and it is two OS upgrades behind.
Volunteers are working on the migration, and the only one with real LDAP experience is volunteering primarily in an advisory capacity. I have been running Linux mail systems since 96, but I have very little experience with LDAP. The non-profit board of directors wants migration done ahead of other priorities, so I want to take my time to learn LDAP and avoid potential problems caused by our legacy mess and inexperienced people attempting to migrate and upgrade LDAP. Once we migrate, we can put the old system behind a firewall and take our time migrating/upgrading LDAP.
I noticed your site http://www.skills-1st.co.uk/ has some good resources. It would be great if we had someone with your skills and experience volunteering!
One question I haven't completely figured out is how we have 16 users with the SSHA hashes because 10 of them have never accessed the shell where the passwd script results in the SSHA hash. The two other options for changing passwords are through the web using poppassd within webmail, and some old custom php code, and they both produce crypt hashes. If a user has the SSHA format, they can't login to the old php interface. Password changes within webmail work, but the user sees "ERROR:255". And this issue seems minor compared to others we have...
Thanks, Chuck
--On Thursday, November 05, 2015 1:19 PM -0500 Chuck Peters cplists@axs.org wrote:
I modified a passwd shell script which outputs a file with the SHA512 hash, so it is supported to some degree, but may not work for LDAP.
I'm using SSHA512 with my passwords in OpenLDAP, works just fine. You'll want the contrib pw-sha2 module.
--Quanah
--
Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap-technical@openldap.org
-
Andrew Findlay -
Chuck Peters -
Matthias Apitz -
Quanah Gibson-Mount