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

12.02.2022 01:01, Patrick Goetz via samba wrote:
[]
> I just moved from NT4 to Samba AD too.? My original plan was to leave the
linux machines standalone, but the more I worked with the system the more
> obvious it became that this was a bad idea for various reasons; e.g. the
access permissions on filesystems shared to Windows machines aren't the same
> if you don't mind the linux workstation to the domain.
"The more obvious it become". This is my "gut feeling" for
now, - just
because else it doesn't actually work due to the $subj. But I'm not
sure yet if it is just wrong assumption in winbind a bug due to this
wrong assumption, or it is actually _required_ to have no unix users
with the same name/uid as in AD. So far I tend to see it more like
a bug than actual architectural requirement.  Maybe difficult to
fix bug but still a bug.
> So, what I'm currently doing on the linux machines:
> 
>  ?1. Remove local linux accounts which match AD accounts.
> 
>  ?2. Bind the linux machine to the domain
> 
>  ?3. Reset the permissions on the /home/USER directories on the linux
machines to match the UID assigned by Samba. If you're using security
groups,
> these work, too, and you can assign permissions on linux with these, too.
FWIW, this step isn't actually necessary if you assign uidNumber &
gidNumber
for your users/groups to be the same as on your standalone server(s)
(assuming all servers shared the same uids).

/mjt

On Sat, 2022-02-12 at 10:36 +0300, Michael Tokarev via samba
wrote:
> 12.02.2022 01:01, Patrick Goetz via samba wrote:
> []
> > I just moved from NT4 to Samba AD too.  My original plan was to
> > leave the linux machines standalone, but the more I worked with the
> > system the more 
> > obvious it became that this was a bad idea for various reasons;
> > e.g. the access permissions on filesystems shared to Windows
> > machines aren't the same 
> > if you don't mind the linux workstation to the domain.
> 
> "The more obvious it become". This is my "gut feeling"
for now, -
> just
> because else it doesn't actually work due to the $subj. But I'm not
> sure yet if it is just wrong assumption in winbind a bug due to this
> wrong assumption, or it is actually _required_ to have no unix users
> with the same name/uid as in AD. So far I tend to see it more like
> a bug than actual architectural requirement.  Maybe difficult to
> fix bug but still a bug.
It is not a bug, you just do not have users in /etc/passwd and AD, you
just have them in AD.
> 
> > So, what I'm currently doing on the linux machines:
> > 
> >   1. Remove local linux accounts which match AD accounts.
I would go further, any users with an ID > 1000 that are not in AD
should be moved to AD.

Rowland

On 2/12/22 01:36, Michael Tokarev wrote:
>> So, what I'm currently doing on the linux machines:
>>
>> ??1. Remove local linux accounts which match AD accounts.
>>
>> ??2. Bind the linux machine to the domain
>>
>> ??3. Reset the permissions on the /home/USER directories on the linux 
>> machines to match the UID assigned by Samba. If you're using
security
>> groups, these work, too, and you can assign permissions on linux with 
>> these, too.
> 
> FWIW, this step isn't actually necessary if you assign uidNumber & 
> gidNumber
> for your users/groups to be the same as on your standalone server(s)
> (assuming all servers shared the same uids).
> 

Yes, this was my original plan, and that will work with *linux* 
workstations (see following response to your next message).

But then every time you add a new user you have to also add this user to 
/etc/passwd with the right UID, and also remember to delete them when 
they're deleted from the domain.  The question to ask yourself is "what
is gained by doing it this way?"  I couldn't think of anything;
that's
when I realized that it's simpler to just let the domain manage user 
accounts affiliated with the domain.

It's also worth noting what complications might arise when using local 
accounts.  I haven't tested this (because I abandoned the idea of using 
local uid-synchronized accounts), but in some contexts I make heavy use 
of AD security groups to fine tune file system access.  So, for example, 
I might have security groups that look like this:

    -- structural-biology
       -- rolands-group
       -- jeremeys-group

    -- rolands-group
       - roland
       - mjt
       - ...

    -- jeremys-group
       - jeremy
       - pgoetz
       - ...

Being able to nest security groups is one of the most useful features of 
AD authentication.

So suppose you have local linux users mjt and pgoetz and a share with 
permissions like this:

   drwxr-x---   5 jeremy structural-biology       4096 Jan  5 08:32 data


Are *local* users mtj and pgoetz going to be able to access this 
directory?  I *think* nsswitch will do the right thing here and look for 
the group in AD when it can't find it locally, but this is the sort of 
complication that might come up.