On Thu, 2022-07-21 at 10:54 -0400, ralph strebbing
wrote:> On Thu, Jul 21, 2022 at 10:22 AM Rowland Penny via samba
> <samba at lists.samba.org> wrote:
> > No, you can edit sam.ldb, provided you use the ldb tools or ldap
> > utils
> > etc. What isn't recommended is to modify the files under sam.ldb.d
> Yeah, the issue was the sam.ldb file didn't have any of the hashes we
> were looking for (if we were looking at the right info). This is
> where
> the conflicting information comes into play, because only from the
> domain specific ldb file in sam.ldb.d/ were we able to find the
> unicodePwd,
You have to do a few things to get it:
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
> which I can't even verify is being used anymore
Unless I missed something, yes it is still being used,
> , nor can I
> peg down how it's calculated in a way that we can just swap
> easily/safely without breaking things like our Azure sync.
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.
>
> > There is nothing stopping you creating users with a password and
> > then
> > changing it again once everything is set up, but there numerous
> > ways of
> > creating user homedirs etc as the user logs in for the first time.
> Right, well when we need to specifically create a user, this isn't a
> problem, and it's what we do. I was talking more about when we need
> to
> set up a new workstation for an existing user, we do a LOT of prep
> and
> customization for the users here, dealing with a lot of stupidity.
> Regardless it's the concept of being able to log in as that user to
> perform tasks, then revert the password so they don't have to reset
> it
> on next login.
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.
>
> > I think what is going on here is that you are thinking in NT4-style
> > domain setup and you should be thing in AD domain setup.
> Can you fill me in on the different lines of thought here? I was a
> bit
> too young to work with NT4 domains, so AD style (with Windows Server
> 2012 and above), or what I've done with this AD DC setup through
> Samba
> is the most I've worked with domain setups. I know NT4 was an older
> style of domain, and a lot less secure (Based on what I was reading,
> things like smbpasswd, pdbedit, etc. being tools to work-around
> accomplish what I'm trying to do), but I guess I don't really know
> the
> key differences in mentality, if you feel like giving a brief history
> lesson for me.
No such thing as a brief history :-)
I doubt very much if you have ever dealt with an NT4 domain, Microsoft
EOL'ed them in 2004. Samba produced something that emulated them (hence
NT4-style), this intially work with the Samba databases, but quickly
moved to using ldap. These are still with us, but they require SMBv1,
so you really shouldn't set up a new NT4-style domain.
There are numerous differences between an NT4-style domain (no GPO's
for instance) and AD domains. NT4-style domains only have one DC
(called a PDC), any others are BDC's (which can be promoted to a PDC if
the PDC falls over), all AD DC's are equal except for the FSMO roles
and these can be on any DC (they can even be shared out on multiple
DC's).
I could go on (and on) about this, I could write a book about this (but
I am not going to)
It is highly probably, that most (if not all) of the mods you make to a
computer for a user can be done with GPO's and/or configure programs.
Rowland