[Samba] New (4.18 provisioned) domain is missing id lookups from idmap.ldb

Tue Sep 5 09:00:11 UTC 2023

On Tue, 5 Sep 2023 10:37:14 +0200
Kees van Vloten via samba <samba at lists.samba.org> wrote:

> 
> Op 05-09-2023 om 10:00 schreef Rowland Penny via samba:
> > On Tue, 5 Sep 2023 09:37:02 +0200
> > Kees van Vloten via samba <samba at lists.samba.org> wrote:
> >
> >> Op 04-09-2023 om 23:04 schreef Rowland Penny via samba:
> >>> On Mon, 4 Sep 2023 22:50:56 +0200
> >>> Kees van Vloten via samba <samba at lists.samba.org> wrote:
> >>>
> >>>> On 04-09-2023 22:26, Rowland Penny via samba wrote:
> >>>>> On Mon, 4 Sep 2023 22:09:35 +0200
> >>>>> Kees van Vloten via samba <samba at lists.samba.org> wrote:
> >>>>>
> >>>>>> Hi Team,
> >>>>>>
> >>>>>>
> >>>>>> I am setting up a new AD-domain, the first DC is just
> >>>>>> operational and some users and groups are created.
> >>>>>>
> >>>>>> This run on Debian 11, Samba 4.18.6 and it is set up with the
> >>>>>> same (but evolved) Ansible code I used for my other domains
> >>>>>> (all of them on different networks and independent of each
> >>>>>> other). The older domains were initially set up with Samba
> >>>>>> 4.14 and another with 4.15 and upgraded many times since, the
> >>>>>> new setup with 4.18.6. In all places gets installed from the
> >>>>>> same debian packages.
> >>>>>>
> >>>>>> Due to the repeatable Ansible setup the /etc/samba/smb.conf is
> >>>>>> exactly the same (apart from the domain name etc.) on the
> >>>>>> existing domains and the new domain. And all domains were
> >>>>>> provisioned with '--use-rfc2307'.
> >>>>>>
> >>>>>> 'samba-tool processes | wc -l' is equal between old and new: 24
> >>>>>> lines. And ps aux | grep winbindd also shows an equal number of
> >>>>>> winbind processes.
> >>>>>>
> >>>>>> '/etc/nsswitch.conf' is also equal and includes winbind for
> >>>>>> passwd and group.
> >>>>>>
> >>>>>>
> >>>>>> Now the mystery starts: there is a difference in id (uid/gid)
> >>>>>> lookups on a DC between the older domains and the new domain.
> >>>>>>
> >>>>>> It looks like the new domain is not querying
> >>>>>> /var/lib/samba/private/idmap.ldb (but is does exist there),
> >>>>>> whereas the older once are.
> >>>>>>
> >>>>>> As an example I tried: getent passwd '<DOMAIN-NAME>\domain
> >>>>>> admins'
> >>>>>>
> >>>>>> On the old domain(s) this results (as expected) in:
> >>>>>>
> >>>>>> OLDDOM\domain admins:*:3000004:3000004::/home/domain
> >>>>>> admins:/bin/bash
> >>>>>>
> >>>>>> But on the new domain the lookup has no result.
> >>>>>>
> >>>>>> The winbind logging is equally different, on the old domain
> >>>>>> (success):
> >>>>>>
> >>>>>> [2023/09/04 20:55:56.243929,  3]
> >>>>>> ../../source3/winbindd/winbindd_misc.c:355(winbindd_interface_version)
> >>>>>>       winbindd_interface_version: [nss_winbind (2502996)]:
> >>>>>> request interface version (version = 32)
> >>>>>> [2023/09/04 20:55:56.243999,  3]
> >>>>>> ../../source3/winbindd/winbindd.c:497(process_request_send)
> >>>>>>       process_request_send: [nss_winbind (2502996)] Handling
> >>>>>> async request: GETPWNAM
> >>>>>> [2023/09/04 20:55:56.244007,  3]
> >>>>>> ../../source3/winbindd/winbindd_getpwnam.c:59(winbindd_getpwnam_send)
> >>>>>>       [nss_winbind (2502996)] Winbind external command GETPWNAM
> >>>>>> start. Query username 'OLDDOM\domain admins'.
> >>>>>> [2023/09/04 20:55:56.244312,  3]
> >>>>>> ../../source3/winbindd/winbindd_getpwnam.c:149(winbindd_getpwnam_recv)
> >>>>>>       Winbind external command GETPWNAM end.
> >>>>>>       (name:passwd:uid:gid:gecos:dir:shell)
> >>>>>>       OLDDOM\domain admins:*:3000004:3000004::/home/domain
> >>>>>> admins:/bin/bash [2023/09/04 20:55:56.244322,  3]
> >>>>>> ../../source3/winbindd/winbindd.c:564(process_request_done)
> >>>>>>       process_request_done: [nss_winbind(2502996):GETPWNAM]:
> >>>>>> NT_STATUS_OK [2023/09/04 20:55:57.091601,  3]
> >>>>>> ../../source3/winbindd/winbindd_misc.c:355(winbindd_interface_version)
> >>>>>>       winbindd_interface_version: [nss_winbind (2502997)]:
> >>>>>> request interface version (version = 32)
> >>>>>> [2023/09/04 20:55:57.091800,  3]
> >>>>>> ../../source3/winbindd/winbindd.c:497(process_request_send)
> >>>>>>       process_request_send: [nss_winbind (2502997)] Handling
> >>>>>> async request: GETGROUPS
> >>>>>> [2023/09/04 20:55:57.091817,  3]
> >>>>>> ../../source3/winbindd/winbindd_getgroups.c:63(winbindd_getgroups_send)
> >>>>>>       [nss_winbind (2502997)] Winbind external command
> >>>>>> GETGROUPS start. Searching groups for username 'root'.
> >>>>>> [2023/09/04 20:55:57.093936,  3]
> >>>>>> ../../source3/winbindd/winbindd_util.c:1736(lookup_usergroups_cached)
> >>>>>>       : lookup_usergroups_cached
> >>>>>> [2023/09/04 20:55:57.106212,  3]
> >>>>>> ../../source3/winbindd/winbindd_getgroups.c:267(winbindd_getgroups_recv)
> >>>>>>       Winbind external command GETGROUPS end.
> >>>>>>       Received 2 entries.
> >>>>>> [2023/09/04 20:55:57.106337,  3]
> >>>>>> ../../source3/winbindd/winbindd_getgroups.c:272(winbindd_getgroups_recv)
> >>>>>>       0: GID 10000
> >>>>>> [2023/09/04 20:55:57.106344,  3]
> >>>>>> ../../source3/winbindd/winbindd_getgroups.c:272(winbindd_getgroups_recv)
> >>>>>>       1: GID 10019
> >>>>>> [2023/09/04 20:55:57.106350,  3]
> >>>>>> ../../source3/winbindd/winbindd.c:564(process_request_done)
> >>>>>>       process_request_done: [nss_winbind(2502997):GETGROUPS]:
> >>>>>> NT_STATUS_OK
> >>>>>>
> >>>>>> On the new domain (no result):
> >>>>>>
> >>>>>> [2023/09/04 20:54:18.579629,  3]
> >>>>>> ../../source3/winbindd/winbindd_misc.c:355(winbindd_interface_version)
> >>>>>>       winbindd_interface_version: [nss_winbind (43590)]:
> >>>>>> request interface version (version = 32)
> >>>>>> [2023/09/04 20:54:18.579686,  3]
> >>>>>> ../../source3/winbindd/winbindd.c:497(process_request_send)
> >>>>>>       process_request_send: [nss_winbind (43590)] Handling
> >>>>>> async request: GETPWNAM
> >>>>>> [2023/09/04 20:54:18.579701,  3]
> >>>>>> ../../source3/winbindd/winbindd_getpwnam.c:59(winbindd_getpwnam_send)
> >>>>>>       [nss_winbind (43590)] Winbind external command GETPWNAM
> >>>>>> start. Query username 'NEWDOM\domain admins'.
> >>>>>> [2023/09/04 20:54:18.582975,  1]
> >>>>>> ../../source3/winbindd/wb_queryuser.c:128(wb_queryuser_got_uid)
> >>>>>>       XID type is 2, should be ID_TYPE_UID or ID_TYPE_BOTH.
> >>>>>> [2023/09/04 20:54:18.582990,  1]
> >>>>>> ../../source3/winbindd/winbindd_getpwnam.c:142(winbindd_getpwnam_recv)
> >>>>>>       Could not convert sid
> >>>>>> S-1-5-21-435088123-233829246-2133031062-512:
> >>>>>> NT_STATUS_NO_SUCH_USER [2023/09/04 20:54:18.582995,  3]
> >>>>>> ../../source3/winbindd/winbindd.c:564(process_request_done)
> >>>>>>       process_request_done: [nss_winbind(43590):GETPWNAM]:
> >>>>>> NT_STATUS_NO_SUCH_USER
> >>>>>>
> >>>>>> Another indication that /var/lib/samba/private/idmap.ldb is not
> >>>>>> used comes from the group lookup of domain admins:
> >>>>>>
> >>>>>> getent group '<DOMAIN-NAME>\domain admins'
> >>>>>>
> >>>>>> Old domain: OLDDOM\domain admins:x:3000004: (3000004 is the
> >>>>>> xidNumber in idmap.ldb)
> >>>>>>
> >>>>>> New domain: NEWDOM\domain admins:x:10001: (10001 is the
> >>>>>> gidNumber in the ldap record of the group)
> >>>>>>
> >>>>>>
> >>>>>> Would could cause this different behaviour (on these 2 very
> >>>>>> similar environments)?
> >>>>> You giving Domain Admins a gidNumber attribute, which by the way
> >>>>> has just broken sysvol.
> >> This is required to be able to use 'domain admins' on Linux
> >> member-server when idmap = ad. Normally the idmap.ldb xidNumber has
> >> priority over gidNumber when the GID lookup is done on a DC.
> > The problem is that Domain Admins has to own things in Sysvol and
> > it is a group, a group cannot normally own things on Unix, so
> > Domain Admins is mapped to 'ID_TYPE_BOTH' in idmap.ldb
> > If you give Domain Admins a gidNumber, you break this mapping and
> > the group cannot own things in sysvol, this breaks sysvol.
> >
> > You have two options, create a new group to use instead of Domain
> > Admins, or remove 'idmap_ldb:use rfc2307 = yes' from the DCs
> 
> It has worked properly with gidNumber and xidNumber for last 15
> months on my existing domains. Sysvol on those domains is not broken,
> it works fine with Windows 10 (which is very critical on access
> permissions).

It appears to work okay, but the wrong groups are owning things in
sysvol.

> 
> But yeah, it is not worth the discussion since the issue I am 
> experiencing is not something with sysvol.
> 
> >
> >> On this new domain it looks like winbindd is not doing an attempt
> >> to lookup the xidNumber, as you can see in the logs above.
> >>
> > It does look that way, but why ????
> 
> Hey, that is exactly the question I was asking because I can't figure
> it out myself :-)
> 
> It is even more strange since I have those older domains which are 
> configured exactly the same (I tried to find differences but so far I 
> have not found any), on which it does work. The only obvious
> difference is that they were upgraded several times and the new
> domain is not.
> 
> I also ran the id lookup with winbind at loglevel 10 (on both old and 
> new domain), although it produces a lot more output, there is still
> no (clear) clue why it does not go into the xidNumber lookup code.
> 
> Later today I will try to run the same code with older versions of
> Samba and I will create a bug if I can find a version with which it
> does work properly.
> 

I went the other way, I had a DC in a VM, running 4.17.10 on Debian 12

adminuser at testdc1:~$ getent group 'domain admins'
TEST\domain admins:x:3000004:

So, I upgraded to Samba from backports and tried again

adminuser at testdc1:~$ getent group 'domain admins'
TEST\domain admins:x:3000004:
adminuser at testdc1:~$ sudo net cache flush
adminuser at testdc1:~$ getent group 'domain admins'
TEST\domain admins:x:3000004:
adminuser at testdc1:~$ sudo samba -V
Version 4.18.6-Debian

Rather than adding a gidNumber attribute to Domain Admins, I added one
to Domain Users

adminuser at testdc1:~$ getent group 'domain users'
TEST\domain users:x:100:
adminuser at testdc1:~$ sudo net cache flush
adminuser at testdc1:~$ getent group 'domain users'
TEST\domain users:x:10000:

As you can see, it initially used the ID '100' from idmap.ldb because
this is what was in the cache, after clearing the cache, it used the
gidNumber from AD.

I the turned off 'idmap_ldb:use rfc2307 = yes' in smb.conf and
restarted Samba

adminuser at testdc1:~$ getent group 'domain users'
TEST\domain users:x:10000:
adminuser at testdc1:~$ sudo net cache flush
adminuser at testdc1:~$ getent group 'domain users'
TEST\domain users:x:100:

Back to '100' after clearing the cache.

Sorry, but I cannot recreate your problem, everything works as it has
done for the last 10 years.

Rowland