Univention Bugzilla – Bug 49321
lookup of SIDs for Posix GIDs does not work for BUILTIN groups on memberserver
Last modified: 2021-07-15 19:23:12 CEST
Created attachment 9981 [details] debug.log Similar to Bug #49310, but the other way around: On a UCS Memberserver the lookup of SIDs for Posix GIDs does not work for BUILTIN groups: root@member13:~# wbinfo --gid-to-sid 5053 failed to call wbcGidToSid: WBC_ERR_DOMAIN_NOT_FOUND Could not convert gid 5053 to sid It should work though. The account is present in OpenLDAP. root@member13:~# univention-ldapsearch -LLL sambasid=S-1-5-32-546 gidnumber dn: cn=Guests,cn=Builtin,dc=ar41i1,dc=qa gidNumber: 5053 After some debugging in the same way as for Bug #49310#c1 we think we found out how this happens: The attached debug.log shows in log.winbindd that it receives a wbint_UnixIDs2Sids for 5053, probably by wbinfo. winbindd somehow quickly finds the group name for that and runs a "lookupname ar41i1+Guests" against the winbindd child process for that domain (processed in log.wb-AR41I1), which in turn runs a lsa_LookupNames4 for that name against the AD DC. This system call is answered by the AD DC with SID_NAME_UNKNOWN / NT_STATUS_NONE_MAPPED. After that it simply gives up and returns the result. After some experimentation with the idmap config of the UCS memberserver we found out more: On memberservers we currently configure idmap for two domains: The '*'-Domain (aka "alloc"-Domain) and the "$windows_domain". Both have a range. If you ask winbind to resolve 5053, it seems to somehow check the ranges. There are two ways to make winbind obtain a result in this case, which helped to understand what's going on, but both are not real solutions: a) Add "idmap config BUILTIN" to smb.conf, with a range that convers the GID in question. Unfortunately, this range collides with the one configured for the main "$windows_domain". To make this work in a test setup, the idmap config lines for BUILTIN need to be put before the conflicting ones for "$windows_domain". b) Manually add a mapping object below cn=idmap,cn=univention and adjust the range for the idmap config '*' to conver the GID in question. Obviously this also collides with the main "$winbind_domain". And you have the gidNumber assigned to two objects (of different objectClass, so that would probably even be ok -- while confusing). My current idea for solving this situation would be to go the way of solution a): Add a "idmap config BUILTIN" line to the smb.conf, but with a dummy range. To make this work, we would need to adjust winbind to not filter idmap config lookups by range. That way it would consider the BUILTIN entry and ask the AD DC for BUILTIN+Guests too - and obtain a result.
A quote for this by Michael Adam, author of the current winbind idmap code: * "As someone else has already said: builtin are different. These are machine-local anyways." In other words: Samba doesn't care for a domain wide mapping for these accounts. Further more, the usual examples on wiki.samba.org even say: * The '*' domain is for what is known as the 'Well Known SIDs' That would be solution b) explained above. Documentation about current idmap status: * Rewrite #6: https://www.samba.org/~obnox/presentations/sambaXP-2009/sambaxp-2009-talk-obnox-slides-presentation.pdf * Rewrite #7: https://www.samba.org/~obnox/presentations/sambaXP-2011/sambaxp-2011-talk-idmap-presentation.pdf
FYI: Affected accounts are listed in librpc/idl/security.idl : ===================================================================== /* SECURITY_BUILTIN_DOMAIN_RID */ const string NAME_BUILTIN = "BUILTIN"; const string SID_BUILTIN = "S-1-5-32"; const string SID_BUILTIN_ADMINISTRATORS = "S-1-5-32-544"; const string SID_BUILTIN_USERS = "S-1-5-32-545"; const string SID_BUILTIN_GUESTS = "S-1-5-32-546"; const string SID_BUILTIN_POWER_USERS = "S-1-5-32-547"; const string SID_BUILTIN_ACCOUNT_OPERATORS = "S-1-5-32-548"; const string SID_BUILTIN_SERVER_OPERATORS = "S-1-5-32-549"; const string SID_BUILTIN_PRINT_OPERATORS = "S-1-5-32-550"; const string SID_BUILTIN_BACKUP_OPERATORS = "S-1-5-32-551"; const string SID_BUILTIN_REPLICATOR = "S-1-5-32-552"; const string SID_BUILTIN_RAS_SERVERS = "S-1-5-32-553"; const string SID_BUILTIN_PREW2K = "S-1-5-32-554"; const string SID_BUILTIN_REMOTE_DESKTOP_USERS = "S-1-5-32-555"; const string SID_BUILTIN_NETWORK_CONF_OPERATORS = "S-1-5-32-556"; const string SID_BUILTIN_INCOMING_FOREST_TRUST = "S-1-5-32-557"; const string SID_BUILTIN_PERFMON_USERS = "S-1-5-32-558"; const string SID_BUILTIN_PERFLOG_USERS = "S-1-5-32-559"; const string SID_BUILTIN_AUTH_ACCESS = "S-1-5-32-560"; const string SID_BUILTIN_TS_LICENSE_SERVERS = "S-1-5-32-561"; const string SID_BUILTIN_DISTRIBUTED_COM_USERS = "S-1-5-32-562"; const string SID_BUILTIN_CRYPTO_OPERATORS = "S-1-5-32-569"; const string SID_BUILTIN_EVENT_LOG_READERS = "S-1-5-32-573"; const string SID_BUILTIN_CERT_SERV_DCOM_ACCESS = "S-1-5-32-574"; =====================================================================