1) Interessant: Es liegen mehr als 8 Minuten zwischen creation timestamp im UDS LDAP und im Master Samba4 (jeweils Uhrzeit auf dem Master).
Das deutet ggf. auf hohe Last hin?

root@s4master:~# univention-ldapsearch -xLLL cn=s4slave +
dn: cn=s4slave,cn=dc,cn=computers,dc=ucs,dc=local
structuralObjectClass: person
entryUUID: 34c94736-e166-1032-8b9b-11c70b1270c4
creatorsName: uid=Administrator,cn=users,dc=ucs,dc=local
createTimestamp: 20131114104939Z
entryCSN: 20131114121051.411845Z#000000#000#000000
modifiersName: cn=admin,dc=ucs,dc=local
modifyTimestamp: 20131114121051Z
entryDN: cn=s4slave,cn=dc,cn=computers,dc=ucs,dc=local
subschemaSubentry: cn=Subschema
hasSubordinates: FALSE


# Timestamps des s4slave Objekts im s4master sam.ldb, das von s4master stammt:
dn: CN=s4slave,OU=Domain Controllers,DC=ucs,DC=local
whenCreated: 20131114105808.0Z          ## exakt zu diesem Zeitpunkt kam das Objekt per S4-Connector aus dem LDAP auf dem Master Samba4 an.


2) Das Timing der Join-Prozesse von DC Backup und DC Slave ist aber auch recht eng:
Das Rechnerkonto des DC Backup selbst wurde erst 11:48 (local time) angelegt, aber dann schon 11:51 vom S4 Connector nach Samba4 repliziert:

root@s4master:~# univention-ldapsearch -xLLL cn=s4-backup +
dn: cn=s4-backup,cn=dc,cn=computers,dc=ucs,dc=local
structuralObjectClass: person
entryUUID: 043a470a-e166-1032-8b93-11c70b1270c4
creatorsName: uid=Administrator,cn=users,dc=ucs,dc=local
createTimestamp: 20131114104818Z
entryCSN: 20131114105958.465062Z#000000#000#000000
modifiersName: cn=admin,dc=ucs,dc=local
modifyTimestamp: 20131114105958Z
entryDN: cn=s4-backup,cn=dc,cn=computers,dc=ucs,dc=local
subschemaSubentry: cn=Subschema
hasSubordinates: FALSE

# Timestamps des s4-backup Objekts im s4master sam.ldb, das von s4master stammt:
dn: CN=S4-BACKUP,OU=Domain Controllers,DC=ucs,DC=local
whenCreated: 20131114105100.0Z
uSNCreated: 3818
whenChanged: 20131114105132.0Z
uSNChanged: 3910