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

12.02.2022 12:30, Rowland Penny via samba wrote:
> On Sat, 2022-02-12 at 11:56 +0300, Michael Tokarev wrote:
>> Please note: I'm not arguing here, my intention is the
understanding.
+++

Rowland, I really apprecate your explanations. And the only my intention
is to understand.  But I still can not... :(

I see what you suggest, what you recommend to do/use.  But why it is
incorrect to have local user AND the AD user (maybe after fixing the bug
in winbind from $subj which you say is not a bug)?

You're saying "stop thinking the old way". But it raises the same
question: why, what's wrong with the "old way" (besides the
$subj)?
Why I can't have everything locally without relying on any external
networking services unless I actually come over network (from windows
machine)?

The corruption definitely can be fixed, this is not a question here
anymore. The argument that local user and AD user have different SIDs
is not valid either, we can make them the same.

But the main - conceptual - question is why we can't have local user
with "AD extensions", so to say, or "AD user" with
"local extensions",
declaring them the SAME user? What's wrong with this *conceptually*?

Again, I'm not asking about personal preferences, but about the concept.

Maybe if this conceptual question is answered, everything else will
become much simpler...

Thanks,

/mjt

12.02.2022 15:04, Michael Tokarev via samba wrote:
..
> Again, I'm not asking about personal preferences, but about the
concept.
Just to give an example - what I'm talking about.

Many IP networking concepts come from BSD IP stack. There was a concept of
ethernet segment. With a few, as it seemed, conceptual properties. It must
have a network address, it must have a broadcast address, and regular IP
addresses.  For example, 192.168.1.0/24 - network address is 192.168.1.0,
broadcast is 192.168.1.255, and other numbers in-between are regular.

But for many decades, network address is not used, and broadcast, while
used, is used by certain services only (eg netbios which is going away
too).

And actually, neither network nor broadcast addresses are *required* for
communication between regular hosts, - there's nothing neither in
Ethernet nor IP which relies on them.

But some people still think there's no "ethernet segment" without
network
and broadcast addresses, it just does not exist. And this is mostly b/c
some software still uses BSD-derived implementation which requires these
(the _implementation_, not actual way it works). Some software or hardware
(eg cisco) requires these addresses. That's probably why some people
think that not having network/broadcast is an error which should be fixed
first before any other debugging is done - nope, it should not, linux
works just fine without these, and other implementation will do too
if they just stop verifying that these addresses are set and refusing
to do if they're not.

On linux I can have a /32 address (actually many of them) on an interface
and as many /32 routes on the same interface as I want, - essentially making
an ethernet interface to act like point-to-point interface (with ARP working
behind the scenes as it is used on ethernet). And it is not an error on the
linux part that cisco does not allow such configuration or that some people
who configure cisco does not know how to configure that on a cisco router.

What I'm saying is: network and broadcast addresses are optional, it is not
part of "ethernet segment" *concept*, IP over ethernet works just fine
w/o
them.

The same applies to our discussion about AD users and local users. So far
I don't see why conceptually they should be entirely separate instead of
complimenting each other. I'm not talking about currently implemented
scenario in winbind (which seem to rely on them being separate without
verifying if this is the case, and behaving inconsistently/buggy if they're
not).

Thanks,

/mjt

On Sat, 2022-02-12 at 15:04 +0300, Michael Tokarev
wrote:
> 12.02.2022 12:30, Rowland Penny via samba wrote:
> > On Sat, 2022-02-12 at 11:56 +0300, Michael Tokarev wrote:
> > > Please note: I'm not arguing here, my intention is the
> > > understanding.
> +++
> 
> Rowland, I really apprecate your explanations. And the only my
> intention
> is to understand.  But I still can not... :(
> 
> I see what you suggest, what you recommend to do/use.  But why it is
> incorrect to have local user AND the AD user (maybe after fixing the
> bug
> in winbind from $subj which you say is not a bug)?
There is no bug, it is the way it is supposed to work.

If you have a local user 'fred' (in /etc/passwd), this will not be the
same user as a user called 'fred' in AD. Samba can obtain the users
data from AD, but it may not be saved as the AD user and this can lead
to all sorts of problems. Now if you only have 'fred' in AD none of
these problems will occur because 'fred' will be the same user
everywhere.
> 
> You're saying "stop thinking the old way". But it raises the
same
> question: why, what's wrong with the "old way" (besides the
$subj)?
> Why I can't have everything locally without relying on any external
> networking services unless I actually come over network (from windows
> machine)?
Because that isn't the way AD works.
Okay, a bit of history :-)
First there was DOS, which was a single user system, then Windows came
along, but wasn't really useful until Windows for workgroups. Now
workgroups were interesting because these allowed users to read/write
data to other computers and use printers etc on other computers (I am
simplifying things here), but workgroups didn't scale well, you had to
create the same users & groups on all workgroup machines, this soon got
tedious.
So Microsoft came up with NT4 domains, followed by Samba. On Windows
the SID identifies the users & groups, but means nothing to Unix, this
is where Samba comes in, initially in an NT4-style domain, Samba
required a local user to map domain users to, later versions using ldap
did away with this requirement.
However NT4-style domains had their problems, security being one of
them, so Microsoft came up with AD, which used DNS, ldap and kerberos.
Samba had to keep up with Microsoft, so it gained code to allow it to
join an AD domain and work began to make Samba operate as an AD DC.

Right from the start, an AD joined computer did not require local
users, winbind maps AD users to a local Unix users. For instance, the
'rid' idmap backend will take an AD users RID and calculate the users
Unix ID from that.
  
> 
> The corruption definitely can be fixed, this is not a question here
> anymore. The argument that local user and AD user have different SIDs
> is not valid either, we can make them the same.
Yes it can be fixed, by setting things up correctly. You are not the
first person to try and bend AD and it has always ended in tears.
> 
> But the main - conceptual - question is why we can't have local user
> with "AD extensions", so to say, or "AD user" with
"local
> extensions",
> declaring them the SAME user? What's wrong with this *conceptually*?
Because you do not need to do it, yes, you can use an unjoined
'standalone server' in an AD domain, but this would mean creating
exactly the same users & groups on the standalone server that exist in
AD, also the passwords would have to be the same and kept in sync. Once
you join a computer to an AD domain, you must use the users & groups
from AD.
> 
> Again, I'm not asking about personal preferences, but about the
> concept.
> 
> Maybe if this conceptual question is answered, everything else will
> become much simpler...
It is simple, join all machines to the domain and use the users and
groups from AD

Rowland