current ID-Mapping code produces inconsistent results under various circumstances: 1. The rid and autorid modules (or more generally any module that is purely algorithmic and create mappings in both directions), return different results depending on whether the cache is filled or not filled with corresponding entries. The reason is that the cache (and backends like TDB) do care about the type of a mapping. The sid_to_unixid code asks for the type of a sid before going into the id mapping code. But if for instance a number is given to the uid-to-sid call with a rid backend, that is mapped to a sid, no matter what the type of the resulting sid would be (or if it even existed). If the sid happens to be a group sid, the cache is primed with a sid2uid mapping for this sid, and a following sid2gid call for that sid (or a gid2sid for that gid) fails. After a "net cache flush", the sid2gid and gid2sid calls would succeed. 2. There are singular and plural calls into id mapping (sid_to_uid,sid_to_gid, sids_to_unix_ids). The singular calls call singular backend functions on the winbindd parent-child-pipe. The plural call calls a plural variant. These behave slightly differently. For example, they hand different sets of sids to the passdb idmap backend. E.g. the builtin\\administrators group will get different sids when resolved via singluar or plural.
The patch for this bug is to 1. only use one code path into id mapping (the sids2xids one) 2. to fix what sids are handed to the passdb backend 3. to teach the rid and autorid modules to return mappings of type BOTH and teach the sids2xids code to interpret the more generous types correctly. Michael
Created attachment 8258 [details] Patches for v4-0-test
Comment on attachment 8258 [details] Patches for v4-0-test ACK
==> Karolin for 4.0
Pushed to autobuild-v4-0-test.
Pushed to v4-0-test. Closing out bug report. Thanks!