samba - Feb 2022 - Corruption of winbind cache after converting NT4 to AD domain

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.

...
>> 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?

I think this is where my misunderstanding comes from.

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.
>>    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"
(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).  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.

> 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.  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!

/mjt

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

On 2/12/22 02:56, Michael Tokarev via samba wrote:
> 
> 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.
> 

Yes, I prefer doing things locally, too.  So much easier; 
self-contained; not dependent on any other machine.  That's why I was 
initially resistant to binding my linux machines to the domain, 
particularly since they NFS mount the shares.

But you should really pay attention to what Roland keeps telling you: 
while you *can* do things this way, it's not optimal and cumbersome to 
maintain. It's an administration/design question, not a technical one.

A good compromise is to have some local accounts which are not in the 
domain so that you can still log in to the machine if, say, your DC is 
down and you don't have redundant DC's.

That said, we're talking about linux here, and there is no 
one-size-fits-all or universal solution to every problem. You have to 
decide, based on the topology of your network and your 
authentication/authorization needs what the best architecture is. It's 
not about "can I do this?" it's more "should I do
this?".  That's the
beauty of linux; you get to decide how things are done, not Microsoft. 
That's why linux runs on several billion more devices than Windows does.