If you run 'wbinfo -G 100' on a DC where Domain Users has a gidNumber attribute, the ID for Domain Users gets set to '100' root@dc3:~# getent group Domain\ Users SAMDOM\domain users:x:10000: root@dc3:~# wbinfo -G 100 S-1-5-21-1768301897-3342589593-1064908849-513 root@dc3:~# wbinfo -G 10000 S-1-5-21-1768301897-3342589593-1064908849-513 root@dc3:~# wbinfo --group-info="Domain Users" SAMDOM\domain users:x:100: root@dc3:~# getent group Domain\ Users SAMDOM\domain users:x:100: root@dc3:~# net cache flush root@dc3:~# getent group Domain\ Users SAMDOM\domain users:x:10000: As you can see, 'net cache flush' has to be run to fix this.
It now seems that it could be ANY user or group that has an xidNumber in idmap.ldb and a uidNumber or gidNumber in AD, has this problem. Stefan G. Weichinger has just posted this on the Samba mailing list: # wbinfo --group-info="domain admins" ARBEITSGRUPPE\domain admins:x:3000013: # net cache flush # wbinfo --group-info="domain admins" ARBEITSGRUPPE\domain admins:x:10512:
with 4.7.3 I can confirm that a stale entry in the idmap.ldb on a AD DC can poinson the gencache with a wrong mapping when idmap_ldb:use rfc2307 is enabled. That can be triggered by wbinfo -G xxx with xxx being the stale POSIX ID from the idmap.ldb file. Looking at the weird behaviour and problems that "idmap_ldb:use rfc2307" is causing on a AD DC, when people had idmap tdb before or if they decide to change uid/gidnumber attributes for example) we should consider to officially deprecate this parameter (or even remove this for AD DC setups). The fact that this parameter is not documented is actually kind of deprecating it already.
(In reply to Björn Jacke from comment #2) Can you explain further what 'deprecating' the parameter and ultimately removing it will do.