Hi slow,> > root at debian:/var/cache/samba# id EXAMPLE\\secretuser > > uid=301142(EXAMPLE\secretuser) gid=300513(EXAMPLE\domain users) groups=300513(EXAMPLE\domain users),301142(EXAMPLE\secretuser),472199(EXAMPLE\secret),572198(EXAMPLE\secret),301141(EXAMPLE\secret),301132(EXAMPLE\cae)> from skimming over your mail, this look pretty much as expected I would say.Thinking about it, I can see how autorid's behaviour would make sense for the actual SID history use-case, i.e. keeping the SID history SID to gid mapping stable during a migration.> What did you expect? What is not working?My question remains if there's a way to prevent SID history SIDs from being mapped once they're no longer needed on a particular samba server, to prevent unnecessary bloating of the secondary group list, i.e. if there's a way to tell autorid (or nss) to recognize that 472199(EXAMPLE\secret), 572198(EXAMPLE\secret) and 301141(EXAMPLE\secret) are all the same group and only add gid 301141 to the UNIX token. Thanks, Michael ________________________________________ From: Ralph Boehme <slow at samba.org> Sent: 09 June 2021 16:56:59 To: Weiser, Michael Cc: Laubender, Guido; samba at lists.samba.org Subject: Re: [Samba] SID history secondary group set bloat Am 09.06.21 um 16:42 schrieb Weiser, Michael:>> Have you tried net cache flush and restarted winbind so the >> winbind cache gets flushed too? > > Yes, I've gone full rm -f on all but secrets.tdb and the IDs totally > differ from the previous test case as well. No nscd running either. > autorid really seems to be doing the mapping itself because it can't > tell that the SIDs really are sIDHistory.from skimming over your mail, this look pretty much as expected I would say. What did you expect? What is not working? Cheers! -slow -- Ralph Boehme, Samba Team https://samba.org/ Samba Developer, SerNet GmbH https://sernet.de/en/samba/ GPG-Fingerprint FAE2C6088A24252051C559E4AA1E9B7126399E46
On 10/06/2021 07:27, Weiser, Michael via samba wrote:> Hi slow, > >>> root at debian:/var/cache/samba# id EXAMPLE\\secretuser >>> uid=301142(EXAMPLE\secretuser) gid=300513(EXAMPLE\domain users) groups=300513(EXAMPLE\domain users),301142(EXAMPLE\secretuser),472199(EXAMPLE\secret),572198(EXAMPLE\secret),301141(EXAMPLE\secret),301132(EXAMPLE\cae) >> from skimming over your mail, this look pretty much as expected I would say. > Thinking about it, I can see how autorid's behaviour would make sense for the actual SID history use-case, i.e. keeping the SID history SID to gid mapping stable during a migration. > >> What did you expect? What is not working? > My question remains if there's a way to prevent SID history SIDs from being mapped once they're no longer needed on a particular samba server, to prevent unnecessary bloating of the secondary group list, i.e. if there's a way to tell autorid (or nss) to recognize that 472199(EXAMPLE\secret), 572198(EXAMPLE\secret) and 301141(EXAMPLE\secret) are all the same group and only add gid 301141 to the UNIX token. > > Thanks, > MichaelThis shouldn't happen and has never happened for myself. Both the 'rid' and 'autorid' backends calculate the Unix ID from the objects RID in AD. This means that there should only be one Unix ID for each user and group, the calculation should always produce the same number. I fell your problems all stem from the way you were running Samba. Rowland
Am 10.06.21 um 08:27 schrieb Weiser, Michael:> My question remains if there's a way to prevent SID history SIDs from > being mapped once they're no longer needed on a particular samba > server, to prevent unnecessary bloating of the secondary group list, > i.e. if there's a way to tell autorid (or nss) to recognize that > 472199(EXAMPLE\secret), 572198(EXAMPLE\secret) and > 301141(EXAMPLE\secret) are all the same group and only add gid 301141 > to the UNIX token.ah, now I get it. :) No, that's not supported, but it might be possible to add such a feature with some development effort. Cheers! -slow -- Ralph Boehme, Samba Team https://samba.org/ Samba Developer, SerNet GmbH https://sernet.de/en/samba/ GPG-Fingerprint FAE2C6088A24252051C559E4AA1E9B7126399E46 -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: <http://lists.samba.org/pipermail/samba/attachments/20210610/6fa1b0ad/OpenPGP_signature.sig>