samba - Oct 2024 - How to set `unicodePwd`? "it's not allowed to set the NT hash password directly"

On Mon, 28 Oct 2024 13:37:27 +0100
William David Edwards <wedwards at cyberfusion.nl> wrote:
> Rowland Penny via samba schreef op 2024-10-28 12:50:
> > On Mon, 28 Oct 2024 12:17:02 +0100
> > William David Edwards via samba <samba at lists.samba.org>
wrote:
> > 
> >> I think I might've found a solution while debugging.
> >> 
> >> To understand what I'm doing wrong with `unicodePwd`, I'm
trying to
> >> get the LDAP request that LAM does, and compare it to mine.
> >> 
> >> As I temporarily switched to an unencrypted connection to be able
> >> to dump the payload without a MTIM, Samba -rightfully- says:
> >> 
> >> "Password modification over LDAP must be over an encrypted
> >> connection"
> >> 
> >> To mitigate this, I set
> >> `fAllowPasswordOperationsOverNonSecureConnection` (`dSHeuristic`
> >> 13):
> >> 
> >> `root at addc-test:~# samba-tool forest directory_service
dsheuristics
> >> 0000000011001`
> >> 
> >> Note that I also set fUserPwdSupport to 1, which I don't
believe to
> >> be needed (as I'm using `unicodePwd`, not `userPassword`),
which
> >> means TRUE according to
> >>
https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/e5899be4-862e-496f-9a38-33950617d2c5:
> >> 
> >> "If this character is neither "0" nor
"2", then the fUserPwdSupport
> >> heuristic is TRUE. If this character is "2", then the
> >> fUserPwdSupport heuristic is FALSE. If this character is
"0", then
> >> the fUserPwdSupport heuristic is FALSE for AD DS and TRUE for AD
> >> LDS."
> >> 
> >> However, after enabling this heuristic, `userPassword` works. You
> >> previously adviced using it instead of `unicodePwd`. This
didn't
> >> work, and the attribute was stored plaintext. I now believe this
> >> was the case simply because `userPassword` wasn't enabled (I
didn't
> >> realise it requires a heuristic).
> >> 
> >> Which begs the question: why does samba-tool go through the
trouble
> >> of transforming the user-specified password into something
that's
> >> acceptable to `unicodePwd`?
> > 
> > Because the unicodePwd attribute is used to store the encoded AD
> > password.
> 
> According to 
>
https://microsoft.public.windows.server.active-directory.narkive.com/Vo4nv0wF/difference-between-userpassword-and-unicodepwd:
> 
> "unicodePwd is the "real password attribute" [...]
userPassword is
> "switchable". It can be turned into a regular attribute, or it
can be
> turned into a write-alias for unicodePwd. AD by default has it as a 
> regular attribute. ADAM by default has it as a unicodePwd alias. This
> is controlled by the 9th char of dsHeuristics. 0 is the default
> (different in AD w2k3 and ADAM). 1 means "userPassword is write-alias
> for unicodePwd", 2 means "userPassword is a regular
attribute". [...]
> When userPassword is a write-alias for unicodePwd, it is written as a
> regular value, no unicode, no double-quotes. However, passwords can
> never be read."
This is Samba and on Samba (unless something has changed and I missed
it), userPassword is not an alias for unicodePwd.
> 
> In other words: if `userPassword` is a write-alias for `unicodePwd`,
> a non-encrypted password can be passed, but it can't be read. So, how
> is it relevant that "the unicodePwd attribute is used to store the
> encoded AD password"?
> 
As far as I am aware, the only place that Samba looks for the password
is the 'unicodePwd' attribute, if anyone knows different, please supply
a link to Samba documentation that explains it.

Rowland

Rowland Penny via samba schreef op 2024-10-28 13:55:
> On Mon, 28 Oct 2024 13:37:27 +0100
> William David Edwards <wedwards at cyberfusion.nl> wrote:
> 
>> Rowland Penny via samba schreef op 2024-10-28 12:50:
>> > On Mon, 28 Oct 2024 12:17:02 +0100
>> > William David Edwards via samba <samba at lists.samba.org>
wrote:
>> >
>> >> I think I might've found a solution while debugging.
>> >>
>> >> To understand what I'm doing wrong with `unicodePwd`,
I'm trying to
>> >> get the LDAP request that LAM does, and compare it to mine.
>> >>
>> >> As I temporarily switched to an unencrypted connection to be
able
>> >> to dump the payload without a MTIM, Samba -rightfully- says:
>> >>
>> >> "Password modification over LDAP must be over an
encrypted
>> >> connection"
>> >>
>> >> To mitigate this, I set
>> >> `fAllowPasswordOperationsOverNonSecureConnection`
(`dSHeuristic`
>> >> 13):
>> >>
>> >> `root at addc-test:~# samba-tool forest directory_service
dsheuristics
>> >> 0000000011001`
>> >>
>> >> Note that I also set fUserPwdSupport to 1, which I don't
believe to
>> >> be needed (as I'm using `unicodePwd`, not `userPassword`),
which
>> >> means TRUE according to
>> >>
https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/e5899be4-862e-496f-9a38-33950617d2c5:
>> >>
>> >> "If this character is neither "0" nor
"2", then the fUserPwdSupport
>> >> heuristic is TRUE. If this character is "2", then
the
>> >> fUserPwdSupport heuristic is FALSE. If this character is
"0", then
>> >> the fUserPwdSupport heuristic is FALSE for AD DS and TRUE for
AD
>> >> LDS."
>> >>
>> >> However, after enabling this heuristic, `userPassword` works.
You
>> >> previously adviced using it instead of `unicodePwd`. This
didn't
>> >> work, and the attribute was stored plaintext. I now believe
this
>> >> was the case simply because `userPassword` wasn't enabled
(I didn't
>> >> realise it requires a heuristic).
>> >>
>> >> Which begs the question: why does samba-tool go through the
trouble
>> >> of transforming the user-specified password into something
that's
>> >> acceptable to `unicodePwd`?
>> >
>> > Because the unicodePwd attribute is used to store the encoded AD
>> > password.
>> 
>> According to
>>
https://microsoft.public.windows.server.active-directory.narkive.com/Vo4nv0wF/difference-between-userpassword-and-unicodepwd:
>> 
>> "unicodePwd is the "real password attribute" [...]
userPassword is
>> "switchable". It can be turned into a regular attribute, or
it can be
>> turned into a write-alias for unicodePwd. AD by default has it as a
>> regular attribute. ADAM by default has it as a unicodePwd alias. This
>> is controlled by the 9th char of dsHeuristics. 0 is the default
>> (different in AD w2k3 and ADAM). 1 means "userPassword is
write-alias
>> for unicodePwd", 2 means "userPassword is a regular
attribute". [...]
>> When userPassword is a write-alias for unicodePwd, it is written as a
>> regular value, no unicode, no double-quotes. However, passwords can
>> never be read."
> 
> This is Samba and on Samba (unless something has changed and I missed
> it), userPassword is not an alias for unicodePwd.
> 
>> 
>> In other words: if `userPassword` is a write-alias for `unicodePwd`,
>> a non-encrypted password can be passed, but it can't be read. So,
how
>> is it relevant that "the unicodePwd attribute is used to store the
>> encoded AD password"?
>> 
> 
> As far as I am aware, the only place that Samba looks for the password
> is the 'unicodePwd' attribute, if anyone knows different, please
supply
> a link to Samba documentation that explains it.
> 
As mentioned before, I'm able to log in with a password set using 
`userPassword` when `fUserPwdSupport` is enabled.
> Rowland
Met vriendelijke groeten,

William David Edwards