[Samba] New (4.18 provisioned) domain is missing id lookups from idmap.ldb
Kees van Vloten
keesvanvloten at gmail.com
Tue Sep 5 09:10:23 UTC 2023
Op 05-09-2023 om 11:00 schreef Rowland Penny via samba:
> 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
Thanks for checking.
It looks like there is no simple answer but it must be something in my
new environment. I will do some more debugging later today.
Is it possible to what is in the cache?
You flush it with 'net flush cache' but it could be useful for debugging
to check its content.
>
>
>
>
>
More information about the samba
mailing list