[Samba] Corruption of winbind cache after converting NT4 to AD domain

[Rowland Penny]

On Sat, 2022-02-12 at 11:56 +0300, Michael Tokarev wrote:
> Please note: I'm not arguing here, my intention is the understanding.
> 
> 12.02.2022 11:17, Rowland Penny via samba wrote:
> ...
> > This is one of the reasons that I keep saying that if you have run
> > an
> > NT4-style domain, then you should forget a lot of what you know, it
> > is
> > no longer relevant.
> 
> Even without NT4-style domain we'll face the same prob. Eg, we had
> just
> linux machines, and added a bunch of windows workstations and had to
> configure AD with samba. Should we convert all linux users to AD
> to continue using linux?  This sounds counter-productive and
> confusing.

OK, on a normal Linux computer, users & groups with ID's < 1000 are
system users & groups and shouldn't be in AD. Normal Linux users &
groups start at 1000 and you need a few users outside AD (just in case
something goes wrong and you cannot connect to AD) and as Microsoft SFU
started ID's at 10000, that is probably a good place to start AD user &
groups. This just leaves the Well Known SIDs, you can put these either
high above the DOMAIN range you set in smb.conf or between your local
Unix users & groups and AD users & groups, I prefer the latter.

> 
> ...
> > > Roughly
> > > speaking, we have local linux users with their passwords and ssh
> > > keys,
> > > and their windows passwords are stored within AD.
> > 
> > This is where you are going wrong, you do not local Unix users, you
> > make AD users into Unix users.
> > 
> > >   The uid numbers are
> > > the same, the names are the same.
> > 
> > But the SIDs will be different.
> 
> Why? Because of some bug in winbind we're discussing?

There is NO bug.

> 
> I think this is where my misunderstanding comes from.

Definitely

> 
> Linux does not have notion of SID, it uses uid. And the uid will
> be the same for sure.  I guess we definitely can make samba always
> return the "windows SID" in this case when the user is in both the
> AD and locally, and only return "unix SID" (whatever it is) when
> this user does not exist in AD.  I think this will solve everything
> and make whole set of issues to go away, and it will be one user
> again as in days of NT4-style domains.

Stop right there, this will not work and even if it did, you do not
need it.
I have said this before, but I will say it again but louder:

STOP THINKING IN THE OLD WAYS.

Just have users and groups in AD and make them into Linux users with
winbind.

> 
> > >    And I don't understand that it is
> > > bad and especially WHY it is bad. Besides bad (to my view: buggy)
> > > behavor of winbind (it should either give meaningful error
> > > message
> > > or should work, but not error out randomly with a very difficult
> > > to
> > > debug issues).
> > > 
> > > It is not mixed users, - I view it is the same single user whos
> > > windows-related attributes are stored in the AD. That's it.
> > 
> > No, it is two users with the same name, one in /etc/passwd, one in
> > AD.
> 
> So make winbind to return "unix SID" only when there's no "windows
> SID"

No, winbind will return the Unix ID.

> (or "AD SID") for this user, and these two users will become one
> again.
> I think it's best of all worlds, no?
> 
> > > > > So there are two parts of the question:
> > > > > 
> > > > > First, how such setup should be done? We really used to linux
> > > > > auth
> > > > > and linux
> > > > > work, it's somewhat unnatural to rely on the AD when dealing
> > > > > with
> > > > > local linux
> > > > > accounts.  But at the same time, these account should have
> > > > > access
> > > > > from windows
> > > > > to their files.  And most important, _why_ this setup should
> > > > > be
> > > > > done?
> > 
> > Lets go back to my username:
> > 
> > rowland at devstation:~$ getent passwd rowland
> > rowland:*:10000:10000:Rowland Penny:/home/rowland:/bin/bash
> > rowland at devstation:~$ grep -c 'rowland' /etc/passwd
> > 0
> 
> I do have many users like this on my second test server where I've
> added
> only a few users from our list for testing.  It works for sure (with
> the only difference of added TLS\\ prefix in my case).

You can remove the 'TLS\\' by adding 'winbind use default domain = yes'
to your smb.conf and restarting Samba.

>   But in order to
> do what you suggest, I have to add networking ways to logins locally
> too
> (eg pam_winbind), but we already have prefectly working /etc/passwd &
> /etc/shadow which does not depend on the network and which does not
> depend on trusting the AD to not use uidNumber=0 somewhere for
> example.

But if you use local users, they will be unknown to AD and you should
map Administrator to root.

> 
> 
> > As you can see, I have a Unix ID (and the second '10000' is Domain
> > Users), but I am NOT in /etc/passwd. This means that Unix knows who
> > I
> > am.
> > The 'passwd' line in /etc/nsswitch.conf is this:
> > passwd:         compat winbind
> > 
> > Which means that /etc/passwd is checked first, then AD, can you see
> > why
> > you cannot have users in /etc/passwd and AD ?
> 
> No, I don't see why.

Because ALL your local users will be used before the AD ones.

>   It's the same here too (except I use files not compat,
> but in this context it doesn't matter). And honestly I don't see why
> I can't
> have the same username in both, at least not from this config and
> this
> ordering rules.
> 
> If we have the same username/uid in /etc/passwd and in AD.
> 
> When we need username to uid conversion, we first look at
> /etc/passwd, find
> it and return it. Done.  Ditto for uid-to-username.
> 
> When we need to convert something to SID, we should not use
> /etc/nsswitch.conf
> in the first place, - it knows nothing about SIDs, and no unix tool
> look them up
> too. So ask AD, return SID from there, or create the fake "unix SID"
> if not.
> If that's not enough, make it configurable in smb.conf.
> 
> Why I can't have the same user (and for me it is the same user) both
> locally
> and in the AD?
> 
> > > > I can assure that 'rowland' isn't in /etc/passwd
> > > 
> > > The main question is why. And my inside is fighting with this
> > > idea too:
> > > why should we move our lovely local users to some remote location
> > > and
> > > make our main server dependant from some other machine(s) while
> > > it already
> > > self-contained?  We do have local accounts on all linux servers
> > > (sharing
> > > the same uids), - this may be difficult to administer (it's not
> > > with a
> > > bit of getting used to), but it is 100% reliable.
> > 
> > Because it gives you one place to administrate everything, as I
> > keep
> > saying, forget most things you know.
> 
> The "one place" has its own good and bad sides. When something can be
> done
> locally I prefer it to be done locally. It's okay for me to have uid-
> >name
> mapping over the network, but I tend to configure auth for users
> locally
> (we don't have many servers) and don't understand why just giving
> some of
> my users access to their files from windows machine forces me to
> REMOVE
> these users from the system and move everything to network. Very
> confusing.
> 
> > > > I do not recommend using 'netbios aliases' use a dns 'CNAME'
> > > > instead.
> > > 
> > > Hm.
> > > It's actually interesting.
> > > 
> > > I didn't plan to mention this but we faced an issue here too.
> > > 
> > > When I added a CNAME for a host, it didn't work, - neither from
> > > windows
> > > nor from smbclient, when logging in the server returned "wrong
> > > password"
> > > when connecting to //cname/foo -U foo, but worked fine when using
> > > //mainname/foo -U foo.  And it didn't work until I added the
> > > above
> > > netbios aliases line and re-joined this server to the domain
> > > (net ads leave | join). Only after that clients were able to
> > > connect.
> > > It took me lots of time to figure it out.  In the AD some AltName
> > > attributes appeared after the rejoin (I don't remember exactly).
> > 
> > AD lives on dns and netbios is going away.
> 
> This doesn't explain why it still requires netbios :)
> 
> And yes, DNS CNAME alone definitely works from windows machines and
> from
> linux machines too, - I tried with smbclient and it too failed to
> login.
> I'll investigate this further later.
> 
> Thank you!

STOP THINKING IN THE OLD WAY.

Rowland

> 
> /mjt