Update:

Finally got around to playing with this again. Looks like i'm not experiencing the issue any more... which is odd... since it's all scripted... (╯°□°)╯︵ ┻━┻

At least a takeaway from all this is that ill now be using argon2 ┬─┬ノ( º _ ºノ)

Thank you always for the awesome support!!!

Best, Dave

On Mon, Dec 6, 2021 at 2:58 PM Dave Macias davama@gmail.com wrote:

Thank you Quanah for the input. I will say that i always turn off line wrap “ldif-wrap=no” when i export. Dont like how it looks with the wrap. So each attribute is one line on import.

I still have yet to try what Michael suggested about scping the mdb files over.

I’ll report on that hopefully this week.

Thank you, Dave On Dec 6, 2021, 12:46 PM -0500, Quanah Gibson-Mount quanah@symas.com, wrote:

--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