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

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

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 Sun, 2023-05-14 at 19:29 +0300, 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.
I think some effort should be put into understanding that ordering. ?If
@reboot is to be expected to work, then the users should be supplied
before cron starts. ?

This isn't something Samba controls, this is a packaging choice.?

I realise it won't be easy, but that would be the correct way forward
on this issue.
> 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.
This might be related to the Nov 2021 security fixes. ?

However I would warn that multiple definition of users is not something
we test, so I would be very cautious, and generally suggest moving to a
'single source of truth', as any manual /etc/passwd entries would need
to be maintained manually.?

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