Product: Nubus for UCS Component: UDM Summary: Make migration and execution of /usr/share/univention-ldap/univention-update-univention-object-identifier controllable via UCR variable. ### Description With the introduction of the univentionObjectIdentifier, a critical issue has arisen where the Samba 4 connector is unable to read the memberOf attribute, despite its presence in sam.ldb. This affects all Samba and UCS@school instances and can lead to severe problems, including failed logons for Windows clients. See Bug #53882 This bug appears to be directly related to the univentionObjectIdentifier and the execution of the script /usr/share/univention-ldap/univention-update-univention-object-identifier. Currently, there's no apparent mechanism to control the execution or migration process associated with this new identifier. To mitigate potential issues and provide administrators with greater control, it's crucial to introduce a Univention Config Registry (UCR) variable to manage the migration and execution of this script. ### Steps to Reproduce 1. Update a UCS system to UCS 5.2-2. 2. Ensure Samba 4 is installed and configured (e.g., samba4=4.21). 3. Attempt to retrieve the memberOf attribute for a user via univention-s4search. ### Expected Results The memberOf attribute should be correctly replicated and readable by the Samba 4 connector, as demonstrated by univention-s4search. ### Actual Results After updating to UCS 5.2-2, the memberOf and several attributes are not readable by the Samba 4 connector (univention-s4search cn=test.user | grep memberOf returns no output), even though it is present in `sam.ldb` (ldbsearch -H /var/lib/samba/private/sam.ldb cn=test.user | grep -Ei 'DN|memberOf' shows the attribute). This indicates a synchronization issue between OpenLDAP and Samba's sam.ldb following the univentionObjectIdentifier introduction. ### Technical Details & Logs Affected System Information: UCS Version: 5.2-2 errata148 Installed Components: samba4=4.21, keycloak=25.0.6-ucs4, ox-connector=2.3.3 Upgradable Components: keycloak Command Output: 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 No output 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 ### Proposed Solution Introduce a Univention Config Registry (UCR) variable that allows administrators to: 1. Control the execution of /usr/share/univention-ldap/univention-update-univention-object-identifier. This could include options to enable/disable its automatic execution or trigger it manually. 2. Manage the migration process related to univentionObjectIdentifier, potentially allowing for pausing, resuming, or verifying the migration status. This UCR variable would provide a critical control point for administrators, especially in complex environments like UCS@school, to prevent and resolve issues related to the univentionObjectIdentifier introduction.
An UCR variable to make the creation of the univentionObjectIdentifier attribute more controllable would be extremely helpful. When migrating the Primary DC from UCS 5.0 to 5.2, I already have 2 hours of maintenance downtime. Forcefully adding an attribute to every single of our 750.000 LDAP objects at the end of the process would potentially add many many hours of LDAP replication to Backup and Replica Hosts to that downtime, making, for instance, real-time password changes impossible. I would much rather have a way to add the attribute manually at a time of my choice.
Would you prefer a migration with a high replication load, but at a time of your choosing (during a maintenance window)? Or a migration that uses throttling, allowing the migration to run for days (outside maintenance windows) but with a low load?
(In reply to Daniel Tröder from comment #2) > Would you prefer a migration with a high replication load, but at a time of > your choosing (during a maintenance window)? > Or a migration that uses throttling, allowing the migration to run for days > (outside maintenance windows) but with a low load? I'd just need a way to choose the timing of the migration, the replication load is not the big problem, if I can let it run over the weekend. I've meanwhile realized that the migration is triggered by the PostUp script for UCS 5.2-2 calling the join script 20-univention-ldap-config-master.inst, which in turn runs /usr/share/univention-ldap/univention-update-univention-object-identifier. So I might just hook into the process with a custom PostUp script, which renames the update script or removes the execution bit, and then run the script manually later.