On Thu, 2022-07-21 at 13:05 -0400, ralph strebbing
wrote:> On Thu, Jul 21, 2022 at 11:54 AM Rowland Penny via samba
> <samba at lists.samba.org> wrote:
> > You have carry out the search on a DC.
> > You need to search in the path to sam.ldb
> > You need to explicitly ask for it.
> >
> > An example search would be:
> > ldbsearch -H /var/lib/samba/private/sam.ldb -P -b
> > 'cn=Users,dc=samdom,dc=example,dc=com' -s sub
> > '(&(objectcategory=person)(samaccountname=rowland))'
unicodePwd
> So this is what returned from our test user:
> # ldbsearch -H /var/lib/samba/private/sam.ldb -P -b
> 'dc=samdom,dc=com'
> -s sub '(&(objectcategory=person)(samaccountname=pwtest))'
unicodePwd
> > fgrep unicodePwd
> unicodePwd:: effDoqwcYECEahP6c/W8lA=>
> > You calculate the unicodePwd like this:
> >
> > echo -n "\"$PASSWORD\"" | iconv -f UTF-8 -t
UTF-16LE | base64 -w 0
> >
> > Note: The duplicate ' " ' are required, they are, believe
it or
> > not,
> > part of the password.
> When we ran the plaintest password (noted below) through the formula,
> we're met with a different value.
> # echo -n "\"JuniorMint10@\"" | iconv -f UTF-8 -t
UTF-16LE | base64
> -w 0
> IgBKAHUAbgBpAG8AcgBNAGkAbgB0ADEAMABAACIA
>
> > Depending on what your country allows, you could obtain the users
> > password,run it backwards through the formula above and then log
> > in.
> > If you do this, I would then set the user to have to change their
> > password at next logon.
> Now, we've done this with another test password, that returned a
> similar value to the above, and used
> # ldbedit -P -b 'dc=samdom,dc=com' -s sub
> '(&(objectcategory=person)(samaccountname=pwtest))' unicodePwd
> To modify the sam.ldb file, when we input the value WE calculated, it
> accepts it, and transforms it into a similar has that is returned
> when
> we run the ldbsearch command. This is fine, and accomplished half of
> our goal. The other half however, is trying to swap the old hash
> (effDoqwcYECEahP6c/W8lA==) in this case, BACK into the sam.ldb via
> ldbedit, in which case an error is returned stating we can't put NT
> Hash's directly into the sam.ldb. So is there a way to go about just
> swapping the hashes directly without the conversion taking place,
> allowing us to place the old password back on the user's object?
>
> Regards,
> Ralph
Sorry Ralph, it did work the last time I tried, but this was a long
time ago and it looks like something has changed.
Rowland