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>