Problem: UCS School Replica Nodes Generate Continuous failed.ldif

Knowledge Base Community
, , , , ,
1

Problem

After upgrading a UCS School Primary Node to UCS 5.2, failed.ldif files may appear regularly on UCS School Replica Nodes.

Removing or replaying the failed LDIF files as described in the following article only resolves the issue temporarily:

New failed.ldif files continue to be generated on the replica systems.

A typical failed LDIF may contain entries similar to the following:

dn: uid=10test,cn=lehrer,cn=users,ou=selfmade,dc=example,dc=int
changetype: modify
add: description
description: Test12
-
replace: entryCSN
entryCSN: 20260603113321.786069Z#000000#000#000000
-
replace: modifyTimestamp
modifyTimestamp: 20260603113321Z
-
delete: krb5KDCFlags
-
delete: userPassword
-
delete: krb5Key
-
delete: krb5KeyVersionNumber
-
delete: pwhistory

The following errors can typically be found in /var/log/univention/listener.log on the affected Replica Node:

LISTENER    ( ERROR   ) : replication: Object class violation; dn="uid=lara.croft,cn=users,ou=selfmade,dc=example,dc=int": object class violation while adding
LISTENER    ( ERROR   ) :     additional info: object class 'krb5KDCEntry' requires attribute 'krb5KeyVersionNumber'

Investigation

The issue can be identified by the following symptoms:

  • One or more failed.ldif files are created repeatedly on Replica Nodes.
  • The same LDAP objects fail replication multiple times.
  • Listener logs report object class violations involving Kerberos-related attributes.
  • Affected objects are typically located within UCS School Organizational Units (OUs).

To verify the issue, inspect the listener log:

grep -A2 -B2 "object class violation" /var/log/univention/listener.log

You can also review the contents of the generated failed.ldif files:

cat /var/lib/univention-directory-replication/failed.ldif

Root Cause

The issue is caused by missing or incomplete UCS School LDAP ACL registrations after a major or minor UCS upgrade.
As a result, LDAP modifications affecting UCS School objects may be processed with insufficient permissions. This can lead to incomplete replication operations where mandatory Kerberos attributes are removed or cannot be updated correctly, resulting in LDAP object class violations on Replica Nodes.

A similar issue affecting UCS 5.0 environments is tracked in the following bug report:

Solution

Re-register the UCS School LDAP ACLs on the Primary Node.

Run the following commands on the UCS School Primary Node:

  • udm settings/ldapacl modify --dn "cn=65ucsschool,cn=ldapacl,cn=univention,$(ucr get ldap/base)" --set active=FALSE

  • univention-run-join-scripts --force --run-scripts 70ucs-school-ldap-acls-master.inst

The join script recreates and re-registers the UCS School LDAP ACL configuration on the Primary Node.

Verification

After re-registering the LDAP ACLs:

  1. Monitor /var/log/univention/listener.log on the Replica Nodes.
  2. Ensure that no new failed.ldif files are generated.
  3. Verify that LDAP modifications within UCS School OUs replicate successfully.
  4. Confirm that no further krb5KDCEntry object class violations appear in the listener logs.

Example command:

  • tail -f /var/log/univention/listener.log

Additional Information

If failed.ldif files already exist, process them according to the procedure described in the following article after the ACL issue has been resolved:

Resolving the ACL registration issue first is important, otherwise newly generated replication failures may continue to occur.