samba - Aug 2024 - a way to migrate pasword from Samba 4.0 AD DC to new AD DC?

Dne 2024.08.14 10:16, Rowland Penny via samba wrote:
> On Wed, 14 Aug 2024 05:56:22 +0200
> Franta Hanzl?k via samba <samba at lists.samba.org> wrote:
> 
>> Please, is there any way to migrate passwords from old Samba 4.0 Ad DC
>> to new (Samba 4.20) one?
> 
> Yes, add another DC, but you will probably have to do it in stages,
> Samba 4.0.x went EOL 9 years ago. I think you would have to upgrade to
> 4.5.x then 4.20.x
The new AD domain name will be different than it is on the old 4.0 DC,
so I'd rather start with a clean install.
I'm not an AD guru and I'm afraid of problems ;)
>> On ldbsearch export on old AD only related item I see is
'unicodePwd'
>> attribute, and it is maybe possible write to new system using
>> ldbmodify
>>  - but it is right and simplest solution?
> 
> No it isn't right and it isn't simple. The password you get back if
you
> ask for the contents of the unicodePwd isn't the password, it is the
> 64bit encoding of the password, which doesn't seem to be reversible.
> You also cannot just write a password to the unicodePwd attribute, it
> has to be encoded in a precise way and written over SSL.
I meant using ldbmodify to write directly the base64 string obtained from
the old DC, directly on the AD DC machine. This would work without TLS and
even without Samba running, and it should be possible to write just about
anything, any value, to the attribute. Or am I mistaken?
>> And one more question - why don't I get any result from the command
>> (on 4.20 AD DC, provisioned with --plaintext-secrets):
>> 
>> # samba-tool user getpassword testusr
>> --attributes=unicodePwd,virtualClearTextUTF16,virtualClearTextUTF8
>> on: CN=testusr,OU=users,DC=ad,DC=my,DC=home unicodePwd::
>> CkODmLSx+ZaJO/qHDQibNw== Got password OK
>> 
>> Why are the virtualClearTextUTF16 and virtualClearTextUTF8 values ??
>> missing and how do I make them exist?
>> Does using the 'samba-tool user syncpasswords' command have
anything
>> to do with this?
> 
> Have you actually set them ?
Do I have to set them myself?
By what?
There is no option here for Samba to do this itself?
Isn't it initiated by the 'samba-tool user syncpasswords' command?
> Why do you need plaintext passwords ?
Some authentication mechanisms require a cleartext password on the server 
side.

-- 
Thanks, Franta Hanzlik

On 14-08-2024 12:24, Franta Hanzlik via samba wrote:
> Dne 2024.08.14 10:16, Rowland Penny via samba wrote:
>> On Wed, 14 Aug 2024 05:56:22 +0200
>> Franta Hanzl?k via samba <samba at lists.samba.org> wrote:
>>
>>> Please, is there any way to migrate passwords from old Samba 4.0 Ad
DC
>>> to new (Samba 4.20) one?
>>
>> Yes, add another DC, but you will probably have to do it in stages,
>> Samba 4.0.x went EOL 9 years ago. I think you would have to upgrade to
>> 4.5.x then 4.20.x
>
> The new AD domain name will be different than it is on the old 4.0 DC,
> so I'd rather start with a clean install.
> I'm not an AD guru and I'm afraid of problems ;)
While you are afraid of problems, it sounds like this approach is much 
more complex and error-prone than Rowland's? suggestion.

Samba-DC is written with a long backward compatibility on the network in 
mind. Adding a 4.5 DC and from thereon a recent version DC is the usual 
and preferred upgrade path.

- Kees.
>
>>> On ldbsearch export on old AD only related item I see is
'unicodePwd'
>>> attribute, and it is maybe possible write to new system using
>>> ldbmodify
>>> ?- but it is right and simplest solution?
>>
>> No it isn't right and it isn't simple. The password you get
back if you
>> ask for the contents of the unicodePwd isn't the password, it is
the
>> 64bit encoding of the password, which doesn't seem to be
reversible.
>> You also cannot just write a password to the unicodePwd attribute, it
>> has to be encoded in a precise way and written over SSL.
>
> I meant using ldbmodify to write directly the base64 string obtained from
> the old DC, directly on the AD DC machine. This would work without TLS 
> and
> even without Samba running, and it should be possible to write just about
> anything, any value, to the attribute. Or am I mistaken?
>
>>> And one more question - why don't I get any result from the
command
>>> (on 4.20 AD DC, provisioned with --plaintext-secrets):
>>>
>>> # samba-tool user getpassword testusr
>>> --attributes=unicodePwd,virtualClearTextUTF16,virtualClearTextUTF8
>>> on: CN=testusr,OU=users,DC=ad,DC=my,DC=home unicodePwd::
>>> CkODmLSx+ZaJO/qHDQibNw== Got password OK
>>>
>>> Why are the virtualClearTextUTF16 and virtualClearTextUTF8 values
??
>>> missing and how do I make them exist?
>>> Does using the 'samba-tool user syncpasswords' command have
anything
>>> to do with this?
>>
>> Have you actually set them ?
>
> Do I have to set them myself?
> By what?
> There is no option here for Samba to do this itself?
> Isn't it initiated by the 'samba-tool user syncpasswords'
command?
>
>> Why do you need plaintext passwords ?
>
> Some authentication mechanisms require a cleartext password on the 
> server side.
>

On Wed, 14 Aug 2024 12:24:12 +0200
Franta Hanzlik via samba <samba at lists.samba.org> wrote:
> Dne 2024.08.14 10:16, Rowland Penny via samba wrote:
> > On Wed, 14 Aug 2024 05:56:22 +0200
> > Franta Hanzl?k via samba <samba at lists.samba.org> wrote:
> > 
> >> Please, is there any way to migrate passwords from old Samba 4.0
> >> Ad DC to new (Samba 4.20) one?
> > 
> > Yes, add another DC, but you will probably have to do it in stages,
> > Samba 4.0.x went EOL 9 years ago. I think you would have to upgrade
> > to 4.5.x then 4.20.x
> 
> The new AD domain name will be different than it is on the old 4.0 DC,
> so I'd rather start with a clean install.
> I'm not an AD guru and I'm afraid of problems ;)
Then I suggest you start totally fresh and add your users & groups from
a CSV file or similar, give your users a temporary password and make
them change them at first login. You are going to have to make the
clients leave the 'old' domain and then join the 'new' domain,
whatever
you do.
> 
> >> On ldbsearch export on old AD only related item I see is
> >> 'unicodePwd' attribute, and it is maybe possible write to
new
> >> system using ldbmodify
> >>  - but it is right and simplest solution?
> > 
> > No it isn't right and it isn't simple. The password you get
back if
> > you ask for the contents of the unicodePwd isn't the password, it
> > is the 64bit encoding of the password, which doesn't seem to be
> > reversible. You also cannot just write a password to the unicodePwd
> > attribute, it has to be encoded in a precise way and written over
> > SSL.
> 
> I meant using ldbmodify to write directly the base64 string obtained
> from the old DC, directly on the AD DC machine. This would work
> without TLS and even without Samba running, and it should be possible
> to write just about anything, any value, to the attribute. Or am I
> mistaken?
You need to hash the password (which also means you need to known it)
before writing it to AD, you need to know exactly how to do this.

 
> 
> >> And one more question - why don't I get any result from the
command
> >> (on 4.20 AD DC, provisioned with --plaintext-secrets):
> >> 
> >> # samba-tool user getpassword testusr
> >> --attributes=unicodePwd,virtualClearTextUTF16,virtualClearTextUTF8
> >> on: CN=testusr,OU=users,DC=ad,DC=my,DC=home unicodePwd::
> >> CkODmLSx+ZaJO/qHDQibNw== Got password OK
> >> 
> >> Why are the virtualClearTextUTF16 and virtualClearTextUTF8 values
> >> ?? missing and how do I make them exist?
> >> Does using the 'samba-tool user syncpasswords' command
have
> >> anything to do with this?
> > 
> > Have you actually set them ?
> 
> Do I have to set them myself?
> By what?
> There is no option here for Samba to do this itself?
> Isn't it initiated by the 'samba-tool user syncpasswords'
command?
I have never used that command, but from my understanding, it is used
to sync AD passwords to an external ldap server e.g. Openldap
> 
> > Why do you need plaintext passwords ?
> 
> Some authentication mechanisms require a cleartext password on the
> server side.
What mechanism ?
Could it use kerberos instead, or authenticate via ldap from AD ?

Rowland