[Samba] ldbmodify sometimes fails when changing attribute "unicodePwd" depending on line order in LDIF file

[Heil, Stefan]

On Wed, 2022-07-06 at 09:07 +1200, Andrew Bartlett wrote:


Dear Andrew,

Thank you so much for your detailed reply - this really helped!

> So what has happened is that since Samba 4.13 we have become much
> more
> strict in the handling of password updates, as we work to avoid
> database corruption, even when users like yourself set passwords
> 'directly' in the DB with the internal controls.
> 
> By very strictly restricting the values, we try not to have more
> security issues in this code (we have been bitten in the past).

That makes sense.

> This is not valid LDIF for thie operation.  This LDIF becomes:
> 
> dn:CN=username,OU=group,DC=domain,DC=example,DC=com
> changetype: modify
> replace: unicodePwd
> unicodePwd: <no value>
> replace: pwdLastSet
> pwdLastSet: <no value>
> add: unicodePwd
> unicodepwd::B4ek4PI4I1IExnPVfZz+Ag==
> add: pwdLastSet
> pwdLastSet:132868855091315424

Thanks for the clarification, we weren't aware of this. Now it all
makes much more sense.

> 
> > 
> > 2. We played around a bit with other attributes, but it seems this
> > problem only happens when "unicodePwd" attribute changes are
> > included,
> > AND if the lines for "replace: unicodePwd" and "unicodePwd:
> > xxxxxxxxxxxxxxxxxxxxxx==" are NOT consecutive.
> 
> Correct.

Thank you for confirming our assessment!

> 
> > 
> > 
> > Since the error message is a bit counter-intuitive - the problem is
> > not
> > with the content / complexity / length of the actual unicodePwd -
> > we
> > thought it makes sense to ask on the mailing list if this is
> > intended
> > behaviour or a bug?
> 
> Intended, just not intended that users would see it.  Patches to add
> a
> better error message are welcome.

I would love to help, but unfortunately I don't think my coding skills
are good enough... But as you said, users who run a typical Samba
installation probably won't ever hit this issue, at least my Google
search before posting to the mailing list produced zero meaningful
results.
> 

> > Either way, this import script and the underlying business process
> > are
> > important to us, so we just want to make sure that this won't
> > become
> > a
> > problem again in the future, and of course we'd be interested to
> > understand better what is going on here.
> > 
> > Thanks for any help / insights / leads!
> 
> Just specify the attributes exactly once and things should be fine.

This is very reassuring!


> However I have concerns.  The bypass method you use was set up for
> migrations from Samba3 into an empty domain.
> 
> If your domain is already in operation there may be a password
> history
> (ntPwdHistory, lmPwdHistory) and Kerberos passwords
> (supplementalCrednetials).  If these are not reset, you could end up
> with both synced and unsynced passwords available.

Thank you for mentioning this. I checked, and none of these attributes
are set for any of our users. I also spoke to my predecessor, who wrote
most of the original code of the import scripts, and we both think that
we should be safe, since we block any other method of setting or
changing passwords, and exclusively use our script-based method. Do you
agree with us here or is there something we overlook / fail to
understand properly? 


Thanks again & best regards,
Stefan

> 
> Andrew Bartlett
> 
> --
> Andrew Bartlett (he/him)       https://samba.org/~abartlet/
> Samba Team Member (since 2001) https://samba.org
> Samba Team Lead, Catalyst IT   https://catalyst.net.nz/services/samba
> 
> Samba Development and Support, Catalyst IT - Expert Open Source
> Solutions
>