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

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.

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

14.05.2023 22:21, Rowland Penny via samba wrote:
...> 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.
This part is relatively easy to fix by ensuring the uid is the same in ad and
in local /etc/passwd. That's what I always had, and this works one way or
another.

It was the different sid bug which I mentioned, and that one is fixed now.

So everything works.

/mjt