A customer "lost" the memberOf attributes in samba after update to UCS 5. A closer investigation showed that the attributes are still there but the group "Pre-Windows 2000 Compatible Access" that have right access to the attribute was empty. In most test environments the foreign Security Principal S-1-5-11 (Authenticated Users) is attached there, but I also found a test environment that looked like the one of the customer. It does not matter why that happen, the pain is very high and as we change the default acl:search=no to yes (UCR var samba/acl_search) with the update to UCS 5 this take effect with the update. I think it would be a good idea to extend the pre checks to verify the group "Pre-Windows 2000 Compatible Access" is not empty and if so throw a message that must be confirmed. Alternative or additional a test in diagnose module (with fix me) would be nice. The windows standard is/was the foreign Security Principal "Authenticated Users" in the group "Pre-Windows 2000 Compatible Access" BUT the work around against printing nightmare was removing this! Alternative to "Authenticated Users" the foreign Security Principal "ENTERPRISE_DOMAIN_CONTROLLERS" (S-1-5-9) should fix the visibility of memberOf for at least univention-s4search and within the most impacts.
We had the same issue in a customer environment after running: /usr/share/univention-ldap-overlay-memberof/univention-update-memberof The problem is that the S4 Connector overwrites the group membership and removes the SID S-1-5-11 and the result is that memberOf doesn't work in Samba 4. The result was a failure to log in the applications. Workaround: ucr set connector/s4/mapping/group/ignorelist="$(ucr get connector/s4/mapping/group/ignorelist),Pre-Windows 2000 Compatible Access" service univention-s4-connector restart Steps to reproduce: root@primary10:~# samba-tool group listmembers "Pre-Windows 2000 Compatible Access" S-1-5-11 root@primary10:~# univention-ldapsearch cn="Pre-Windows 2000 Compatible Access" -LLL uniqueMember dn: cn=Pre-Windows 2000 Compatible Access,cn=Builtin,dc=deadlock10,dc=intranet root@primary10:~# univention-s4search cn=stefan memberOf # record 1 dn: CN=stefan,CN=Users,DC=deadlock10,DC=intranet memberOf: CN=gp1,CN=Groups,DC=deadlock10,DC=intranet # Referral ref: ldaps://deadlock10.intranet/CN=Configuration,DC=deadlock10,DC=intranet # Referral ref: ldaps://deadlock10.intranet/DC=DomainDnsZones,DC=deadlock10,DC=intranet # Referral ref: ldaps://deadlock10.intranet/DC=ForestDnsZones,DC=deadlock10,DC=intranet # returned 4 records # 1 entries # 3 referrals root@primary10:~# udm groups/group modify --dn "cn=Pre-Windows 2000 Compatible Access,cn=Builtin,dc=deadlock10,dc=intranet" --append users="uid=Administrator,cn=users,dc=deadlock10,dc=intranet" Object modified: cn=Pre-Windows 2000 Compatible Access,cn=Builtin,dc=deadlock10,dc=intranet root@primary10:~# univention-ldapsearch cn="Pre-Windows 2000 Compatible Access" -LLL uniqueMember dn: cn=Pre-Windows 2000 Compatible Access,cn=Builtin,dc=deadlock10,dc=intranet uniqueMember: uid=Administrator,cn=users,dc=deadlock10,dc=intranet root@primary10:~# samba-tool group listmembers "Pre-Windows 2000 Compatible Access" Administrator root@primary10:~# univention-s4search cn=stefan memberOf # record 1 dn: CN=stefan,CN=Users,DC=deadlock10,DC=intranet # Referral ref: ldaps://deadlock10.intranet/CN=Configuration,DC=deadlock10,DC=intranet # Referral ref: ldaps://deadlock10.intranet/DC=DomainDnsZones,DC=deadlock10,DC=intranet # Referral ref: ldaps://deadlock10.intranet/DC=ForestDnsZones,DC=deadlock10,DC=intranet # returned 4 records # 1 entries # 3 referrals root@primary10:~# samba-tool group addmembers "Pre-Windows 2000 Compatible Access" --member-dn="CN=S-1-5-11,CN=ForeignSecurityPrincipals,$(ucr get samba4/ldap/base)" Added members to group Pre-Windows 2000 Compatible Access root@primary10:~# samba-tool group listmembers "Pre-Windows 2000 Compatible Access" Administrator S-1-5-11 root@primary10:~# univention-s4search cn=stefan memberOf # record 1 dn: CN=stefan,CN=Users,DC=deadlock10,DC=intranet memberOf: CN=gp1,CN=Groups,DC=deadlock10,DC=intranet # Referral ref: ldaps://deadlock10.intranet/CN=Configuration,DC=deadlock10,DC=intranet # Referral ref: ldaps://deadlock10.intranet/DC=DomainDnsZones,DC=deadlock10,DC=intranet # Referral ref: ldaps://deadlock10.intranet/DC=ForestDnsZones,DC=deadlock10,DC=intranet # returned 4 records # 1 entries # 3 referrals root@primary10:~# https://help.univention.com/t/problem-no-memberof-attributes-in-samba-after-update-to-ucs-5/18673
This happens again in a big school environment, where all school servers were affected!
adjusted the help article: https://help.univention.com/t/problem-some-attributes-in-samba-like-memberof-are-missing/18673
In this case, the customer needs to trigger all groups in openldap to get them to itslearning. And the s4-connector removed the one member in the group in samba4, because the groupmembership is inconsistent, even in a fresh installed environment
The following groups are affected as well: univention-s4search ... dn: CN=Windows Authorization Access Group,CN=Builtin,DC=iso,DC=intranet member: CN=S-1-5-9,CN=ForeignSecurityPrincipals,DC=iso,DC=intranet dn: CN=IIS_IUSRS,CN=Builtin,DC=iso,DC=intranet member: CN=S-1-5-17,CN=ForeignSecurityPrincipals,DC=iso,DC=intranet Those objects don't have a uniqueMember on the LDAP side. --- Side note: The following group is missing the member attribute on the S4 side: dn: cn=Authenticated Users,cn=Builtin,dc=iso,dc=intranet uniqueMember: cn=Windows Hosts,cn=groups,dc=iso,dc=intranet uniqueMember: cn=DC Slave Hosts,cn=groups,dc=iso,dc=intranet
To me this reads like a two stage play: First stage: * Group memberships seem to differ between OpenLDAP and Samba/AD (already on fresh installation). That's what I get from Comment 4. Second stage: * During an update the S4-Connector may recognize that he wants to sync all things from OpenLDAP to Samba/AD. That's what I get from the help article.
And then there's the third stage that this particular bug is about: When this affects the group "Pre-Windows 2000 Compatible Access" and memberships get revoked there, then those accounts that lost membership will notice it because membership in this particular group controls visibility of the AD attribute "member". (That's what I learned from Julia IIRC).
(In reply to Arvid Requate from comment #7) > And then there's the third stage that this particular bug is about: > > When this affects the group "Pre-Windows 2000 Compatible Access" and > memberships > get revoked there, then those accounts that lost membership will notice it > because membership in this particular group controls visibility of the AD > attribute "member". > (That's what I learned from Julia IIRC). Correct, and this is why the bug is so important. We have not tested a reprovisioning of samba4 but if all the groups are synced during this reprovisioning, those customers are affected by this issue.
Yes, I observed the same behavior here on my production system and my testsystem.
Happened again, but not only the memberof attribut was missing, but lots more (uidNumber), which caused no share access on non ucs servers, because the idmapping for winbind was failing. This was happened after package updates, not the major UCS 5.2 upgrade.
Okay, cause for the last appearance was the setting of the new univentionObjectIdentifier attribute, which triggered the synchronization of the group, with it non existing members in openLdap. This is set with ucs 5.2.2
It really seems to be related to the introduction of univentionObjectIdentifier. After I updated my system to UCS 5.2-2, the S4 connector is not able to read the memberOf attribute, although it is present in the sam.ldb. This bug is very critical and will affect all samba and ucs@school instances. The subsequent error could be that the logon to Windows clients fails. UCS: 5.2-2 errata148 Installed: samba4=4.21 5.0/keycloak=25.0.6-ucs4 5.0/ox-connector=2.3.3 Upgradable: keycloak root@ucs5primary:~# root@ucs5primary:~# univention-ldapsearch uid=test.user memberOf # extended LDIF # # LDAPv3 # base <dc=miro,dc=intranet> (default) with scope subtree # filter: uid=test.user # requesting: memberOf # # test.user, users, miro.intranet dn: uid=test.user,cn=users,dc=miro,dc=intranet memberOf: cn=Account Operators,cn=Builtin,dc=miro,dc=intranet memberOf: cn=Admin-restricted,cn=groups,dc=miro,dc=intranet memberOf: cn=Administrators,cn=Builtin,dc=miro,dc=intranet memberOf: cn=Domain Guests,cn=groups,dc=miro,dc=intranet memberOf: cn=Domain Users,cn=groups,dc=miro,dc=intranet memberOf: cn=Enterprise Admins,cn=groups,dc=miro,dc=intranet memberOf: cn=Guests,cn=Builtin,dc=miro,dc=intranet # search result search: 3 result: 0 Success # numResponses: 2 # numEntries: 1 root@ucs5primary:~# univention-s4search cn=test.user | grep memberOf root@ucs5primary:~# ldbsearch -H /var/lib/samba/private/sam.ldb cn=test.user | grep -Ei 'DN|memberOf' dn: CN=test.user,CN=Users,DC=miro,DC=intranet uidNumber: 2037 gidNumber: 5001 memberOf: CN=Domain Guests,CN=Groups,DC=miro,DC=intranet memberOf: CN=Enterprise Admins,CN=Groups,DC=miro,DC=intranet memberOf: CN=Administrators,CN=Builtin,DC=miro,DC=intranet memberOf: CN=Guests,CN=Builtin,DC=miro,DC=intranet memberOf: CN=Account Operators,CN=Builtin,DC=miro,DC=intranet memberOf: CN=Admin-restricted,CN=Groups,DC=miro,DC=intranet distinguishedName: CN=test.user,CN=Users,DC=miro,DC=intranet ref: ldap://miro.intranet/DC=DomainDnsZones,DC=miro,DC=intranet ref: ldap://miro.intranet/DC=ForestDnsZones,DC=miro,DC=intranet root@ucs5primary:~# univention-app info UCS 5.2-1 root@ucs5primary:~/univention-support# ls -lah /usr/share/univention-ldap/univention-update-univention-object-identifier ls: Zugriff auf '/usr/share/univention-ldap/univention-update-univention-object-identifier' nicht möglich: Datei oder Verzeichnis nicht gefunden UCS 5.2-2 root@ucs5primary:~/univention-support# ls -lah /usr/share/univention-ldap/univention-update-univention-object-identifier -rwxr-xr-x 1 root root 3,1K 2. Jul 15:20 /usr/share/univention-ldap/univention-update-univention-object-identifier
Just want to add another data point: I've updated two 5.0-10 instances to 5.2-2 over the last couple of days. The issue happened on both of them. Just UCS without UCS@school, only base apps (DHCP, Samba 4, Keycloak). Applying the fix from the support DB article (re-adding S-1-5-11 to group "Pre-Windows 2000 Compatible Access") helped in both cases.
79c95688fb3 feat(updater): Ensure "Pre-Windows 2000 Compatible Access", "Windows Authorization Access Group" and "IIS_IUSRS" are added to connector/s4/mapping/group/ignorelist fb88807ab1f feat(s4-connector): Add "Pre-Windows 2000 Compatible Access", "Windows Authorization Access Group" and "IIS_IUSRS" to connector/s4/mapping/group/ignorelist. ef6c837200d fix(updater): Move check directly to postup.sh 2ba2eed8795 feat(diagnostic): Diagnostic module for memberOf in Samba/AD ad51aeb2703 fix(diagnostic): Mitigate missing button spacing 1cfe4ce2a56 fix(updater,doc): document proper signature key for UCS 5.2 Package: univention-s4-connector Version: 16.2.2 Branch: 5.2-0 Scope: errata5.2-2 Successful build Package: univention-management-console-module-diagnostic Version: 8.2.3 Branch: 5.2-0 Scope: errata5.2-2
As discussed: I'd rather not remove those groups from the diagnostic check, because the check serves a purpose (to assign static Posix IDs for these groups across the UCS domain). I've added them to the joinscript of univention-samba4 where we already pre-create a couple of those special AD accounts (or groups). That should fix new installations. Update scenarios should not require this, so I didn't additionally put that into the postinst. 5e49261464e | fix(samba4): Create "Pre-Windows 2000 Compatible Access", "Windows Authorization Access Group" and "IIS_IUSRS" in UDM via joinscript Package: univention-samba4 Version: 11.2.1 Branch: 5.2-0 Scope: errata5.2-2
<https://errata.software-univention.de/#/?erratum=5.2x151> <https://errata.software-univention.de/#/?erratum=5.2x152> <https://errata.software-univention.de/#/?erratum=5.2x153>