Broken UID/GID allocation in IDMAP TDB

[norbert.hanke]

This is on a TrueNAS CORE system on the latest version TrueNAS-13.0-U3.1 . It has a 3 year history of updates.
The problem is not specific to version 13.0-U3.1 : it has been there before.

The system has been joined to a Samba AD domain ever since, and rfc2307 name mapping works.
But there seems to be an issue with TDB UID and GID allocation for users and groups that have no UID and GID set in AD.

/var/log/samba4/log.winbindd-idmap has entries like
[2023/01/05 23:22:41.675762, 1] ../../source3/winbindd/idmap_tdb_common.c:66(idmap_tdb_common_allocate_id_action) Fatal Error: GID range full!! (max: 7999) [2023/01/05 23:22:41.675819, 1] ../../source3/winbindd/idmap_tdb_common.c:149(idmap_tdb_common_allocate_id) Error allocating a new GID

I increased the upper limit for the TDB UID range to 8200, with the result that just error message changes:
[2023/01/05 23:24:48.359581, 1] ../../source3/winbindd/idmap_tdb_common.c:66(idmap_tdb_common_allocate_id_action) Fatal Error: GID range full!! (max: 8200) [2023/01/05 23:24:48.359796, 1] ../../source3/winbindd/idmap_tdb_common.c:149(idmap_tdb_common_allocate_id) Error allocating a new GID

In log.smbd I see entries for computer accounts, and for users that have no UID set in AD like
[2023/01/03 20:24:05.571166, 0] ../../source3/auth/auth_util.c:1928(check_account) check_account: Failed to convert SID S-1-5-21-744319914-1299377278-1878550687-9604 to a UID (dom_user[MYDOMAIN\e7470-1$]) [2023/01/05 09:50:53.465695, 0] ../../source3/auth/auth_util.c:1928(check_account) check_account: Failed to convert SID S-1-5-21-744319914-1299377278-1878550687-500 to a UID (dom_user[MYDOMAIN\administrator])

If I set a UID attribute in AD for such accounts the error goes away. Having UIDs on computer accounts is not typical, but at least it helps.

In the fileystem I can see numeric GIDs that are no more known to winbind, like
# getfacl /mnt/data/userdata # file: /mnt/data/userdata # owner: root # group: MYDOMAIN\fileadmins group@:rwxpDdaARWcCo-:fd-----:allow group:MYDOMAIN\domain users:r-x---a-R-c---:-------:allow group:3008:rwxpDdaARWcCo-:fdi----:allow group:3007:rwxpDdaARWcCo-:fd-----:allow group:MYDOMAIN\folder redirection users:r--p--a-R-c---:-------:allow everyone@:r-x---a-R-c---:-------:allow

winbind knows a few builtin users but far from all that I would expect:
# gid=3000 ; while [ $gid -le 3010 ] ; do getent group $gid ; gid=$(($gid+1)) ; done BUILTIN\administrators:x:3000 BUILTIN\users:x:3001 BUILTIN\guests:x:3002

Is there a way to reset ID allocation to start from scratch? Or manually edit the ID database to fix it?

I tried this but it does not work:
# ldbedit -H /var/db/system/samba4/winbindd_idmap.tdb Can't find include file registry Can't load /usr/local/etc/smb4.conf - run testparm to debug it no matching records - cannot edit

maybe this is useful information?

Code:

# tdbtool /var/db/system/samba4/winbindd_idmap.tdb dump

key 13 bytes
DN=@BASEINFO
data 43 bytes
[000] 67 19 01 26 01 00 00 00  40 42 41 53 45 49 4E 46  g..&... @BASEINF
[010] 4F 00 73 65 71 75 65 6E  63 65 4E 75 6D 62 65 72  O.sequen ceNumber
[020] 00 01 00 00 00 01 00 00  00 31 00                 ....... .1

key 9 bytes
USER HWM
data 4 bytes
[000] 81 4A 5D 05                                       .J].

key 10 bytes
GROUP HWM
data 4 bytes
[000] 81 4A 5D 05                                       .J].

key 14 bytes
IDMAP_VERSION
data 4 bytes
[000] 02 00 00 00                                       ...

This is my samba configuration:

Code:

# testparm -s
Load smb config files from /usr/local/etc/smb4.conf
Loaded services file OK.
Weak crypto is allowed

Server role: ROLE_DOMAIN_MEMBER

# Global parameters
[global]
        ads dns update = No
        aio max threads = 2
        allow trusted domains = No
        bind interfaces only = Yes
        client ldap sasl wrapping = seal
        disable spoolss = Yes
        dns proxy = No
        domain master = No
        enable web service discovery = Yes
        kerberos method = secrets and keytab
        kernel change notify = No
        load printers = No
        local master = No
        logging = syslog@2 file
        map to guest = Bad User
        max log size = 51200
        nsupdate command = /usr/local/bin/samba-nsupdate -g
        preferred master = No
        realm = AD.MYDOMAIN.TLD
        registry shares = Yes
        security = ADS
        server multi channel support = No
        server role = member server
        server string = FreeNAS Server
        template shell = /bin/sh
        unix extensions = No
        winbind cache time = 7200
        winbind enum groups = Yes
        winbind enum users = Yes
        winbind max domain connections = 10
        winbind nss info = rfc2307
        workgroup = MYDOMAIN
        idmap config *: range = 3000-8200
        idmap config mydomain: unix_primary_group = Yes
        idmap config mydomain: unix_nss_info = Yes
        idmap config mydomain: schema_mode = rfc2307
        idmap config mydomain: range = 10000-999999
        idmap config mydomain: backend = ad
        rpc_server:mdssvc = disabled
        rpc_daemon:mdssd = disabled
        idmap config * : backend = tdb
        directory name cache size = 0
        dos filemode = Yes

This looks ok:
# midclt call activedirectory.domain_info | jq { "LDAP server": "10.88.1.9", "LDAP server name": "dc2.ad.mydomain.tld", "Realm": "AD.MYDOMAIN.TLD", "Bind Path": "dc=AD,dc=MYDOMAIN,dc=TLD", "LDAP port": 389, "Server time": 1672961806, "KDC server": "10.88.1.9", "Server time offset": 0, "Last machine account password change": 1592159970 }

 

[anodos]

We keep snapshots of the dataset where the idmap.tdb file is located. There is an issue with idmap.tdb handling in U3.1 that is being fixed in U4, but relying on that for your AD configuration is bad practice. It's non-deterministic and somewhat defeats the purpose of having SSO in a business environment (It's basically guaranteed that these IDs won't match on any two servers in the environment).

If you're reliant on those entries being absolutely consistent, I recommend populating the uid/gid values in your domain appropriately.