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

Rowland Penny rpenny at samba.org
Tue Jul 5 14:10:34 UTC 2022

On Tue, 2022-07-05 at 13:43 +0000, Heil, Stefan via samba wrote:
> > You shouldn't have to set 'pwdLastSet', it should be done for you
> > when
> > the password is changed, having said that, why are you doing it
> > this
> > way ? Wouldn't it be better to use samba-tool ?
> > 
> > Rowland
> Dear Rowland,
> Thanks for your reply. You are, of course, right that setting
> pwdLastSet should not be needed in normal circumstances, and that
> what we are doing with these imports is unusual, at best.
> The reason, in a nutshell: The import-script is part of a legacy
> codebase I inherited. Our environment is heterogenous (Active
> Directory with Windows Server + Exchange in the HQ, Samba Domains in
> the branch offices), but joining the Samba-DCs into the AD-domain was
> a no-go (due to the Exchange schema extensions), and "trust
> relationships" weren't yet supported by Samba back then. My
> predecessor then came up with the idea to "clone" our main Windows AD
> (incl. domain SID and everything...) and import most of the Windows
> LDAP tree into our Samba-DCs in the branch offices. We know that this
> is definitely not a "supported way" of working with Samba / AD, but
> the results are actually pretty good: centrally managed user accounts
> (in the HQ Windows-AD) but still having bi-directional user
> authentication (single-sign-on even!) between our Samba domains and
> our Windows AD domain (while the Windows-DCs and Samba-DCs actually
> never ever communicate directly with each other). 
> We will eventually move to trust relationships between Samba-DCs and
> the Windows-DCs since that has been supported in Samba for a while
> now, but we aren't quite there yet. This is the reason we still
> depend on these scripts, and the ability to import users (including
> their unicodePwd and pwdLastSet attributes, since users are centrally
> managed in the HQ Windows AD) for a little longer. Our migration plan
> is a two-step process: first migrate everything from Ubuntu-18.04 to
> Debian-11, and then, at a later point, move away from this crazy mess
> of script-based cloning / importing to a trust-based relationship
> (hopefully by the end of the year).
> So, long story short: the fact that newer versions of ldbmodify
> suddenly tripped over our LDIF files, just got us a bit worried,
> hence asking here if this is still supposed to work or not (and if
> so: possibly point out a bug in ldbmodify, in case the line ordering
> of our LDIF files is valid). We basically just wanted to know, if our
> way of importing these users (incl. unicodePwd, pwdLastSet) will
> continue to work for the time being or if these problems with
> ldbmodify imports are a sign that we might have to move to trust
> relationships immediately? 
> Thank you!
> Best,
> Stefan

You are good at understatements :-D
Yes, this isn't really a supported way of running Samba, but needs
must, etc

I have never tried to change a password in the way you have, but I
think I understand what is going on.
Samba progressively gets nearer and nearer to Windows AD, so I think
that early versions of Samba would allow your first ldif, but now you
are probably getting something like a collision, the password is
changed and this prompts 'pwdLastSet' to be set, just when the 'ldif'
tries to set it. Your new ldif sets the password (which sets
'pwdLastSet') and then resets 'pwdLastSet'.


More information about the samba mailing list