LDAP und AD nicht konsistent zueinander

UCS - Univention Corporate Server
,
#1

UCS 4.1-4 errata 408
Hallo,
unser UCS ist DC der Windows Domäne. Es werden mir von Nagios regelmäßig Warnungen wie folgt angezeigt:

S4CONNECTOR WARNING: Found 6 reject(s)! Please check output of univention-s4connector-list-rejected.

Fünf der rejects habe ich mittels des Artikels How to deal with s4-connector rejects entfernt, da sie für mich nicht nachvollziehbar waren.

# univention-s4connector-list-rejected
UCS rejected
S4 rejected
    1:    S4 DN: CN=dc,CN=Computers,DC=domain,DC=intern
         UCS DN: cn=dc,cn=computers,dc=domain,dc=de
	last synced USN: 12199260

Dieser letzte reject irritiert mich aber. Im Computers-Container des LDAP sind zwei Computer-Objekte enthalten, die im AD in einer anderen OU abgelegt sind. Das Verschieben von Computer-Objekten aus dem Computers-Container in einen passenden OU-Container mache ich immer, um Gruppenrichtlinien darauf anwenden zu können. Diese Aktion führe ich entweder mit der AD-Verwaltung auf meinem Win7 AdminPC oder einem Win2008R2 Server durch.
Neben diesen beiden nicht synchronen Computer-Objekten gibt es eine handvoll weiterer, die im LDAP im Vergleich zum AD in unterschiedlichen Ordnern abgelegt sind.

Wie kann ich LDAP und AD wieder synchronisieren?

Gruß,
Peter

#2

I would advise against deleting rejects because you do not know what these mean. All these reject will appear again if the object that caused it is touched again. So always solve the reason for the reject.

that, I do not get. “domain.de” and “domain.intern” are not different folders, it are different DNS domains.

The objects that are different in the LDAP and the AD should be seen as rejects - from that point on, you should be able to determine why these objects are rejected. Ultimatly, the reject list and the “/var/log/univention/connector-s4.log” should tell you what to do to sync LDAP and AD.

#3 
S4 DN: CN=dc,CN=Computers,DC=domain1,DC=intern
UCS DN: cn=dc,cn=computers,dc=domain2,dc=de

Uups, here I made a mistake. It is domain1.intern and domain2.de.

I can’t memorize exactly which five rejects I have removed. Two of those rejects were refered to a test server which doesn’t exist anymore and which I removed from LDAP and/or S4/AD finally. The others I don’t know.

However the last reject remains although I did a resync for this item of LDAP and S4. Before resyncing I raise the debug level of s4-connector to 4.

ucr set connector/debug/level=4
invoke-rc.d univention-s4-connector restart

And this is the appropiate extract from /var/log/univention/connector-s4.log :

20.04.2017 12:25:52,888 LDAP        (INFO   ): _ignore_object: Do not ignore cn=dc,cn=computers,dc=domain2,dc=de
20.04.2017 12:25:52,889 LDAP        (INFO   ): __sync_file_from_ucs: object was added: cn=dc,cn=computers,dc=domain2,dc=de
20.04.2017 12:25:52,889 LDAP        (INFO   ): _ignore_object: Do not ignore cn=dc,cn=computers,dc=domain2,dc=de
20.04.2017 12:25:52,889 LDAP        (INFO   ): _object_mapping: map with key container and type ucs
20.04.2017 12:25:52,889 LDAP        (INFO   ): _dn_type ucs
20.04.2017 12:25:52,890 LDAP        (INFO   ): _ignore_object: Do not ignore cn=dc,cn=computers,DC=domain1,DC=intern
20.04.2017 12:25:52,890 LDAP        (INFO   ): __sync_file_from_ucs: finished mapping
20.04.2017 12:25:52,890 LDAP        (INFO   ): sync_from_ucs: sync object: cn=dc,cn=computers,DC=domain1,DC=intern
20.04.2017 12:25:52,890 LDAP        (PROCESS): sync from ucs: [     container] [       add] cn=dc,cn=computers,DC=domain1,DC=intern
20.04.2017 12:25:52,891 LDAP        (INFO   ): get_object: got object: CN=dc,CN=Computers,DC=domain1,DC=intern
20.04.2017 12:25:52,891 LDAP        (INFO   ): encode_s4_object: attrib objectGUID ignored during encoding
20.04.2017 12:25:52,891 LDAP        (INFO   ): LockingDB: Execute SQL command: 'SELECT id FROM S4_LOCK WHERE guid=?;', '('bf126e89-4246-4a60-9116-99829d75382b',)'
20.04.2017 12:25:52,891 LDAP        (INFO   ): LockingDB: Return SQL result: '[]'
20.04.2017 12:25:52,891 LDAP        (INFO   ): sync_from_ucs: modify object: cn=dc,cn=computers,DC=domain1,DC=intern
20.04.2017 12:25:52,892 LDAP        (INFO   ): sync_from_ucs: old_object: {}
20.04.2017 12:25:52,892 LDAP        (INFO   ): sync_from_ucs: new_object: {u'hasSubordinates': [u'TRUE'], u'entryCSN': [u'20160205160542.342852Z#000000#000#000000'], u'cn': [u'dc'],u'objectClass': [u'top', u'organizationalRole', u'univentionObject', u'univentionPolicyReference'], u'univentionObjectType': [u'container/cn'], u'entryUUID':[u'f0bbbe7e-8cdd-1033-87ce-d9d16f9f6032'], u'modifyTimestamp': [u'20160205160542Z'], u'modifiersName': [u'cn=admin,dc=domain2,dc=de'], u'createTimestamp': [u'20140620154734Z'],u'entryDN': [u'cn=dc,cn=computers,dc=domain2,dc=de'], u'subschemaSubentry': [u'cn=Subschema'], u'structuralObjectClass': [u'organizationalRole'], u'creatorsName': [u'']}
20.04.2017 12:25:52,892 LDAP        (INFO   ): sync_from_ucs: The following attribute has been changed: hasSubordinates
20.04.2017 12:25:52,892 LDAP        (INFO   ): sync_from_ucs: The following attribute has been changed: entryCSN
20.04.2017 12:25:52,892 LDAP        (INFO   ): sync_from_ucs: The following attribute has been changed: cn
20.04.2017 12:25:52,892 LDAP        (INFO   ): sync_from_ucs: Found a corresponding mapping defintion: cn
20.04.2017 12:25:52,892 LDAP        (INFO   ): sync_from_ucs: old_values: set([])
20.04.2017 12:25:52,892 LDAP        (INFO   ): sync_from_ucs: new_values: set([u'dc'])
20.04.2017 12:25:52,892 LDAP        (INFO   ): sync_from_ucs: The current S4 values: set([u'dc'])
20.04.2017 12:25:52,893 LDAP        (INFO   ): sync_from_ucs: The following attribute has been changed: objectClass
20.04.2017 12:25:52,893 LDAP        (INFO   ): sync_from_ucs: The following attribute has been changed: univentionObjectType
20.04.2017 12:25:52,893 LDAP        (INFO   ): sync_from_ucs: The following attribute has been changed: entryUUID
20.04.2017 12:25:52,893 LDAP        (INFO   ): sync_from_ucs: The following attribute has been changed: modifyTimestamp
20.04.2017 12:25:52,893 LDAP        (INFO   ): sync_from_ucs: The following attribute has been changed: modifiersName
20.04.2017 12:25:52,893 LDAP        (INFO   ): sync_from_ucs: The following attribute has been changed: createTimestamp
20.04.2017 12:25:52,893 LDAP        (INFO   ): sync_from_ucs: The following attribute has been changed: entryDN
20.04.2017 12:25:52,893 LDAP        (INFO   ): sync_from_ucs: The following attribute has been changed: subschemaSubentry
20.04.2017 12:25:52,893 LDAP        (INFO   ): sync_from_ucs: The following attribute has been changed: structuralObjectClass
20.04.2017 12:25:52,894 LDAP        (INFO   ): sync_from_ucs: The following attribute has been changed: creatorsName
20.04.2017 12:25:52,894 LDAP        (ALL    ): nothing to modify: cn=dc,cn=computers,DC=domain1,DC=intern
20.04.2017 12:25:52,894 LDAP        (INFO   ): sync_from_ucs: unlock UCS entryUUID: f0bbbe7e-8cdd-1033-87ce-d9d16f9f6032
20.04.2017 12:25:52,894 LDAP        (INFO   ): LockingDB: Execute SQL command: 'DELETE FROM UCS_LOCK WHERE uuid = ?;', '('f0bbbe7e-8cdd-1033-87ce-d9d16f9f6032',)'

I can’t see why this item still is rejected. Does anybody can help?

When resolving this issue, it might be that remaining differences of only few “computer” items in LDAP vs S4/AD are resolved as well. Although it might be that the rejects and the differences in LDAP vs AD aren’t connected.

#4

I do not see an error or reject (Traceback) in your exerpt of the S4 Connector Log - It could be helpful to read the complete log. Though again:

S4 DN: CN=dc,CN=Computers,DC=domain1,DC=intern
UCS DN: cn=dc,cn=computers,dc=domain2,dc=de

are not different folders, these are different bases/domains (ldap/base and S4/base).

#5

Yes, I know that they are different. But this is the way our UCS is configured from the beginning.

Mastodon