samba - Jul 2022 - ldbmodify sometimes fails when changing attribute "unicodePwd" depending on line order in LDIF file

> 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

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

Rowland