2.6 slapadd bug? - SHA512 userPassword hash get 2 characters appended to the end at import
Hello,
Playing with 2.6 on rhel8
When imported my data.ldif I noticed i no longer could bind and my credentials would fail. Thought it was simply my account and tried with other test accounts and failed too.
When i compare the userPassword attributes from the source to my 2.6 environment, i see there are two extra characters at the end.
So original looks like: (and whats in data.ldif file)
userPassword:: e2Nblablasuperdupper512hashthatendshere
vs the one in 2.6
userPassword:: e2Nblablasuperdupper512hashthatendshereXX
This happens on all the userPassword attributes that are SHA512. The XX characters seem random, no pattern to it. In other words each userPassword attribute has its own XX characters.
Interesting, i dont see this issue with accounts that still have SHA1 hash. They are identical.
I dont recall if i saw this on 2.5 but I’ll update on that.
Thank you, Dave
I forgot to mention that the source of the sha512 data.ldif is from a v2.4 environment. If that has any relevance.
So i slapcat the 2.4 data, massage it for all the new overlays we want to use, and slapadd it to my v2.6 environment.
Hope that info is useful. On Dec 4, 2021, 2:58 AM -0500, Dave Macias davama@gmail.com, wrote:
Hello,
Playing with 2.6 on rhel8
When imported my data.ldif I noticed i no longer could bind and my credentials would fail. Thought it was simply my account and tried with other test accounts and failed too.
When i compare the userPassword attributes from the source to my 2.6 environment, i see there are two extra characters at the end.
So original looks like: (and whats in data.ldif file)
userPassword:: e2Nblablasuperdupper512hashthatendshere
vs the one in 2.6
userPassword:: e2Nblablasuperdupper512hashthatendshereXX
This happens on all the userPassword attributes that are SHA512. The XX characters seem random, no pattern to it. In other words each userPassword attribute has its own XX characters.
Interesting, i dont see this issue with accounts that still have SHA1 hash. They are identical.
I dont recall if i saw this on 2.5 but I’ll update on that.
Thank you, Dave
On 12/4/21 14:17, Dave Macias wrote:
I forgot to mention that the source of the sha512 data.ldif is from a v2.4 environment. If that has any relevance.
So i slapcat the 2.4 data, massage it for all the new overlays we want to use, and slapadd it to my v2.6 environment.
2.6 should be capable of dumping 2.4 databases. Might also be worth a try.
Ciao, Michael.
P.S.: After the migration you might want to consider using {ARGON2} scheme because slapd-pw-sha2 is only contrib code while slappw-argon2 is a core module. And {SHA512} scheme is also *very* weak because it does only one round of SHA-512 computation.
2.6 should be capable of dumping 2.4 databases. Might also be worth a try.
P.S.: After the migration you might want to consider using {ARGON2} scheme because slapd-pw-sha2 is only contrib code while slappw-argon2 is a core module. And {SHA512} scheme is also *very* weak because it does only one round of SHA-512 computation.
Will definitely consider moving to argon2, but would probably come post 2.4>2.6 migration.
What you mean by 2.6 should be capable of dumping 2.4 dbs? As in slapcat my 2.6 and import to 2.4? If so, i can definitely try but would be a basic tree with one user for this potential “bug” issue im encountering.
Oh! That would be much easier! Will report back. Thank you On Dec 4, 2021, 8:43 AM -0500, Michael Ströder michael@stroeder.com, wrote:
On 12/4/21 14:36, Dave Macias wrote:
What you mean by 2.6 should be capable of dumping 2.4 dbs?
If you have 2.4 .mdb files 2.6 should be capable of exporting the database to LDIF. It might be worth to check whether 2.6 adds the XX chars too.
Ciao, Michael.
--On Saturday, December 4, 2021 2:58 AM -0500 Dave Macias davama@gmail.com wrote:
Hello,
Playing with 2.6 on rhel8
When imported my data.ldif I noticed i no longer could bind and my credentials would fail. Thought it was simply my account and tried with other test accounts and failed too.
When i compare the userPassword attributes from the source to my 2.6 environment, i see there are two extra characters at the end.
So original looks like: (and whats in data.ldif file)
userPassword:: e2Nblablasuperdupper512hashthatendshere
vs the one in 2.6
userPassword:: e2Nblablasuperdupper512hashthatendshereXX
This happens on all the userPassword attributes that are SHA512. The XX characters seem random, no pattern to it. In other words each userPassword attribute has its own XX characters.
I've generally seen issues like this when a script that munges data fails to correctly delete multi-line attribute values and the leftover bits get tacked onto the previous attribute. One way around this is to turn off LDIF line wraps on export.
--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
-
Dave Macias -
Michael Ströder -
Quanah Gibson-Mount