Problem
When attempting to delete computer objects through the UCS → AD synchronization, the deletion fails and results in S4 connector rejects.
The UCS S4 connector logs show errors similar to the following:
sync UCS > AD: [windowscomputer] [ delete] 'cn=computer04,ou=arbeitsplatz-rechner,ou=rechner,DC=domain,DC=de'
delete subobject:
'CN=2022-11-09T06:58:38\+01:00{789ED6D9-GG12-1234-A00X-FJB84JDNMVU4},CN=computer04,OU=Arbeitsplatz-Rechner,OU=Rechner,DC=domain,DC=de'
sync failed, saved as rejected
ldap.NOT_ALLOWED_ON_NONLEAF: {'desc': 'Operation not allowed on non-leaf', 'info': 'subtree_delete: Unable to delete a non-leaf node (it has 1 children)!'}
The connector cannot remove the computer object from Active Directory because it still contains child objects. This results in synchronization failures and rejected objects in /var/lib/univention-connector/s4/.
Root Cause
The deletion of computer objects fails because the affected AD computer accounts contain BitLocker recovery information as child objects.
When BitLocker recovery data is stored in Active Directory, it is created as a sub-object of the computer account (e.g., CN=<timestamp>{GUID},CN=<computer>,OU=...).
This configuration is enforced by a Group Policy Object (GPO) under:
Computer Configuration > Policies > Windows Components > BitLocker Drive Encryption
→ Store BitLocker recovery information in Active Directory Domain Services
As a result, each computer object may have one or more BitLocker-related sub-objects (e.g., of objectClass msFVE-RecoveryInformation or msFVE-RecoveryPassword).
The LDAP error NOT_ALLOWED_ON_NONLEAF indicates that the system is trying to delete a container object that still has children — in this case, the BitLocker recovery entries.
If this policy remains active, the connector cannot delete computer objects until their BitLocker sub-objects are manually removed or the policy is adjusted.
Solution
-
Identify the BitLocker Recovery Objects
Run the following command on the UCS system to inspect the sub-objects:
ldbsearch -H /var/lib/samba/private/sam.ldb --cross-ncs \ -b "CN=2022-11-09T06:58:38\+01:00{789ED6D9-GG12-1234-A00X-FJB84JDNMVU4},CN=computer04,OU=Arbeitsplatz-Rechner,OU=Rechner,DC=domain,DC=de"You will see entries containing object classes such as:
msFVE-RecoveryPasswordmsFVE-RecoveryInformation
-
Remove the BitLocker Recovery Objects
You can delete the sub-object manually using:
ldbdel -H /var/lib/samba/private/sam.ldb \ "CN=2022-11-09T06:58:38\+01:00{789ED6D9-GG12-1234-A00X-FJB84JDNMVU4},CN=computer04,OU=Arbeitsplatz-Rechner,OU=Rechner,DC=domain,DC=de"Tip: When searching with
ldbsearch, remove the backslash (\) before the “+” character in the CN.
When using the full DN (Distinguished Name) in commands likeldbdel, the backslash must remain. -
Automated Cleanup (Recommended)
UCS provides a helper script that simplifies the removal process:
/usr/share/univention-samba4/scripts/purge_s4_computer.py --computername <ComputerNameWithout$>Replace
<ComputerNameWithout$>with the actual computer name (without the trailing$). -
Optional: Disable the GPO (Prevent Future Occurrences)
To prevent new BitLocker sub-objects from being created, disable or adjust the GPO:
Computer Configuration > Policies > Windows Components > BitLocker Drive Encryption → Store BitLocker recovery information in Active Directory Domain Services