samba - May 2023 - samba users at boot, the same local and samba user bug has gone

On 14-05-2023 21:21, Rowland Penny via samba wrote:
>
>
> On 14/05/2023 17:29, Michael Tokarev via samba wrote:
>> Hi!
>>
>> We faced another issue with not having samba (ad-dc) users in local 
>> /etc/password:
>> this way, we can't easily have services run as users this way,
since
>> winbindd is
>> started later than most services are (and it requires working 
>> network). Also,
>> user-defined cron @reboot jobs aren't being run, for the same
reason:
>> cron is
>> stared before winbindd on most systems. This is quite difficult to 
>> change too,
>> since ordering is historic and other dependencies exists in-between.
>>
>> Thankfully, the bug which existed in samba 4.16 where, in presence of 
>> the same
>> username in ad and in /etc/passwd, winbindd/smbd sometimes treated it 
>> as one and
>> sometimes as two different users with different SIDs, apparently has 
>> been fixed
>> in 4.17. So far, samba always treats this user as one single entity 
>> here, with
>> 4.17 and 4.18, - unlike sporaric/unstable behavior we've seen in
4.16.
>>
>> FWIW. And thank you for the bugfixing.
>>
>> /mjt
>>
>
> Michael, you cannot have AD users in /etc/passwd because if a user is 
> in /etc/passwd it isn't the same user as the user by the same name in 
> AD. Local users do not have a SID, only AD or Samba users have a SID.
> Okay, that's not entirely true, Samba will create SID's
'S-1-2-*' for
> local users, but they are not true Windows SID's.
>
> If you create a local user on a domain joined machine and then create 
> a domain user (on a DC) with the same name and then use getent on the 
> joined machine, you will get this output:
> adminuser at lmde5:~$ getent passwd unixuser
> unixuser:x:1001:1001:,,,:/home/unixuser:/bin/bash
> adminuser at lmde5:~$ getent passwd SAMDOM\\unixuser
> SAMDOM\unixuser:*:13105:10513::/home/unixuser:/bin/bash
>
> You have to use the username in the form 'DOMAIN\\username' to get
the
> domain users output, otherwise you will always get the output for the 
> local user.
>
> As you can see, though they have the same username, they have 
> different Unix ID's and are different users. You could use the
'ad'
> idmap backend and set the Unix ID as the users uidNumber, but they 
> would still be different users.
The uid + gid are the unique identifier of a user in Linux, the name is 
only relevant for the translation of number (uid) to name.

I.e. a local-user == domain-user when uid + gid are identical.

My nsswitch.conf prefers local-users over domain-users:

passwd:???????? files systemd winbind
group:????????? files systemd winbind
shadow:???????? files
gshadow:??????? files

But when I do "id <user>" on a user that exists locally and in
the
domain I get the list of groups of both local + domain concatenated as 
one long list.

Would it be viewed as two separate users that would not happen.

- Kees.
>
> If you are running local services on the computer, you should be using 
> local users, not users stored in AD.
>
> Not sure what has changed for yourself, but I wouldn't rely on it, if 
> it changed once, it could, just as easily, change again.
>
> Rowland
>

On 14/05/2023 20:32, Kees van Vloten via samba wrote:
> The uid + gid are the unique identifier of a user in Linux, the name is 
> only relevant for the translation of number (uid) to name.
> 
> I.e. a local-user == domain-user when uid + gid are identical.
> 
> My nsswitch.conf prefers local-users over domain-users:
> 
> passwd:???????? files systemd winbind
> group:????????? files systemd winbind
> shadow:???????? files
> gshadow:??????? files
> 
> But when I do "id <user>" on a user that exists locally and
in the
> domain I get the list of groups of both local + domain concatenated as 
> one long list.
> 
> Would it be viewed as two separate users that would not happen.
> 
> - Kees.
> 
OK, I should have posted that as well:

adminuser at lmde5:~$ id unixuser
uid=1001(unixuser) gid=1001(unixuser) 
groups=1001(unixuser),13105(unixuser),10513(domain 
users),3001(BUILTIN\users)

adminuser at lmde5:~$ id SAMDOM\\unixuser
uid=13105(unixuser) gid=10513(domain users) groups=10513(domain 
users),13105(unixuser),3001(BUILTIN\users)

Still think they are the same user ?

Rowland

On Sun, 2023-05-14 at 21:32 +0200, Kees van Vloten via samba
wrote:
> The uid + gid are the unique identifier of a user in Linux, the name is 
> only relevant for the translation of number (uid) to name.
> 
> I.e. a local-user == domain-user when uid + gid are identical.
> 
> My nsswitch.conf prefers local-users over domain-users:
> 
> passwd:???????? files systemd winbind
> group:????????? files systemd winbind
> shadow:???????? files
> gshadow:??????? files
> 
> But when I do "id <user>" on a user that exists locally and
in the
> domain I get the list of groups of both local + domain concatenated as 
> one long list.
> 
> Would it be viewed as two separate users that would not happen.
> 
> - Kees.
While correct in a sense, Samba does not always go via nss, it has
optimisations (rich data paths) direct to winbindd, and the check of
the nsswitch understanding of the user is mainly a nod to historical
behaviour, to try and ensure that we only provide service to users that
the administrator can see via nsswitch. ?

For that reason, Samba is much more sensitive to names than you might
expect.  While we generally do idmap based lookups (more so since the
Nov 2021 security patches), this comment gives some context. ?I wrote:

commit 0a546be05295a7e4a552f9f4f0c74aeb2e9a0d6e
Author: Andrew Bartlett <abartlet at samba.org>
Date:   Fri Nov 12 16:10:31 2021 +1300


    CVE-2020-25717: s3:auth: Fallback to a SID/UID based mapping if the
named based lookup fails
    
    Before the CVE-2020-25717 fixes we had a fallback from
    getpwnam('DOMAIN\user') to getpwnam('user') which was very
dangerous and
    unpredictable.
    
    Now we do the fallback based on sid_to_uid() followed by
    getpwuid() on the returned uid.
    

My point is we do a name-based lookup first, and what 'fixed' this is
that we fallback to an ID based lookup second.  But to say that the
combination of Samba and Linux is insensitive to names is incorrect
(even as we reduce that sensitivity). 

I hope this provides some background here. 

Andrew Bartlett

-- 
Andrew Bartlett (he/him)        https://samba.org/~abartlet/
Samba Team Member (since 2001)  https://samba.org
Samba Developer, Catalyst IT    https://catalyst.net.nz/services/samba