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

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.

12.02.2022 15:45, Patrick Goetz wrote:
> 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.
No, Patrick, you got me wrong.  I'm not saying here to continue list AD
users in /etc/passwd - this is your step 1 above.  I'm not about local
accounts, not about keeping local account. I was commenting about just
the last step - chown/chgrp (and fixing ACLs the same way).

When you use idmap_backend = ad, you can have the uid/gid for the user
listed in the AD as uidNumber and gidNumber attributes (and set them to
any value you choose).

This way, you assign these numbers manually (it is not samba who's doing
this), and all your linux machines who're configured with the same
idmap_backend will have the same uid/gid for them automatically, to the
values you set. If you choose to keep files belonging to your former
linux users, you can assign your AD users the same uid/gid they had on
linux, and you don't need to change ownership as in the step 3 above.

It is just a small comment. And ofc. you can prefer other idmap backends
which maps RIDs to uids differently.

Thanks!

/mjt

On Sat, 2022-02-12 at 06:45 -0600, Patrick Goetz via samba
wrote:
> 
> 
> 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.
It is actually winbind that does this, but only when nsswitch asks it
to.

Rowland