[Samba] SID history secondary group set bloat

Weiser, Michael michael.weiser at atos.net
Thu Jun 10 07:07:57 UTC 2021


Hello Rowland,

> This 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.

Ah, that would be nice because it would match my use-case. So I'd just need to find out what I'm doing wrong.

> I fell your problems all stem from the way you were running Samba.

I have eliminated every trace of sssd from the system. I've put only winbind in /etc/nsswitch.conf. The winbind daemon is running. I've made autorid the default backend. I've cleared all caches again. nscd is not running.

The SID history SIDs are still mapped. What's still wrong with the way I run samba from your point of view?

root at debian:~# dpkg -l | grep sss
root at debian:~# cat /etc/sssd/sssd.conf
cat: /etc/sssd/sssd.conf: No such file or directory
root at debian:~# ps xaw | grep sssd
   2109 pts/1    S+     0:00 grep sssd

root at debian:~# grep ^passwd\\\|^group /etc/nsswitch.conf
passwd:         files winbind systemd
group:          files winbind systemd

root at debian:~# cat /etc/samba/smb.conf
[global]
        workgroup = EXAMPLE
        realm = EXAMPLE.ORG
        security = ads

        kerberos method = secrets and keytab

        debug level = 6

        idmap config * : range = 200000-1999999999
        idmap config * : backend = autorid

[test]
        path = /srv/test
        read only = no

root at debian:~# systemctl stop winbind
root at debian:~# systemctl stop smbd
root at debian:~# find /var/lib/samba /run/samba /var/cache/samba -type f | grep -v secrets.tdb | xargs rm -f
root at debian:~# grep ^secret /etc/passwd /etc/group
root at debian:~# systemctl start winbind
root at debian:~# systemctl start smbd

root at debian:~# ps xaw | grep nscd
   2134 pts/1    S+     0:00 grep nscd
root at debian:~# ps xaw | grep winbind
   2083 ?        Ss     0:00 /usr/sbin/winbindd --foreground --no-process-group
   2085 ?        S      0:00 winbindd: domain child [EXAMPLE]
   2097 ?        S      0:00 winbindd: domain child [DEBIAN]
   2098 ?        S      0:00 winbindd: idmap child
   2099 ?        S      0:00 winbindd: domain child [BUILTIN]
   2127 pts/1    S+     0:00 grep winbind

root at debian:~# 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),200001(BUILTIN\users)

root at debian:~# kinit secretuser
Password for secretuser at EXAMPLE.ORG:
root at debian:~# smbclient -k //debian/test -c exit
root at debian:~#

log.smbd:
[2021/06/10 09:00:34.466368,  4] ../../source3/smbd/sec_ctx.c:319(set_sec_ctx_internal)
  setting sec ctx (301142, 300513) - sec_ctx_stack_ndx = 0
[2021/06/10 09:00:34.466377,  5] ../../libcli/security/security_token.c:56(security_token_debug)
  Security token SIDs (22):
    SID[  0]: S-1-5-21-4131831116-1822871472-1861548575-1142
    SID[  1]: S-1-5-21-4131831116-1822871472-1861548575-513
    SID[  2]: S-1-5-21-4131831116-1822871472-1861548575-1132
    SID[  3]: S-1-5-21-4131831116-1822871472-1861548575-1141       <--- actual group SID
    SID[  4]: S-1-5-21-2623811102-3361044346-30300840-72198         <--- group SID history
    SID[  5]: S-1-5-21-1623811102-3361044346-30300840-72199         <--- group SID history
    SID[  6]: S-1-18-1
    SID[  7]: S-1-1-0
    SID[  8]: S-1-5-2

    SID[  9]: S-1-5-11
    SID[ 10]: S-1-5-32-545
    SID[ 11]: S-1-22-1-301142
    SID[ 12]: S-1-22-2-300513
    SID[ 13]: S-1-22-2-301142
    SID[ 14]: S-1-22-2-301132
    SID[ 15]: S-1-22-2-301141
    SID[ 16]: S-1-22-2-572198
    SID[ 17]: S-1-22-2-472199
    SID[ 18]: S-1-22-2-299999
    SID[ 19]: S-1-22-2-299990
    SID[ 20]: S-1-22-2-299982
    SID[ 21]: S-1-22-2-200001
   Privileges (0x               0):
   Rights (0x               0):
[2021/06/10 09:00:34.466423,  5] ../../source3/auth/token_util.c:873(debug_unix_user_token)
  UNIX token of user 301142
  Primary group is 300513 and contains 10 supplementary groups
  Group[  0]: 301142
  Group[  1]: 300513
  Group[  2]: 301132
  Group[  3]: 301141   <--- gid from actual group SID
  Group[  4]: 572198   <--- gid from group SID history
  Group[  5]: 472199   <--- gid from group SID history
  Group[  6]: 299999
  Group[  7]: 299990
  Group[  8]: 299982
  Group[  9]: 200001

Thanks,
Michael

________________________________________
From: samba <samba-bounces at lists.samba.org> on behalf of Rowland penny via samba <samba at lists.samba.org>
Sent: 10 June 2021 08:43
To: samba at lists.samba.org
Subject: Re: [Samba] SID history secondary group set bloat

Caution! External email. Do not open attachments or click links, unless this email comes from a known sender and you know the content is safe.

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,
> Michael


This 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



--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba




More information about the samba mailing list