Quest Migration Manager for AD QMM – verwaiste Objekte in ADAM Directory

Während einer Directoy Synchronisation mit dem Quest Migration Manager for AD QMM können verwaiste Objekten in der der ADAM Datenbank entstehen.

Ich hatte in der Vergangenheit schon des Öfteren über das Handling des Quest Migration Manager for AD QMM-AD berichtet. Nachdem in einem aktuell laufenden Projekt die Directory Synchronization DSA abgeschlossen ist und die DSA-Agenten gestoppt sind, möchte ich nun die verwaisten Objekte im ADAM Directory bereinigen.

Hintergrund:

Jedes Synchronisierte Objektpaar wird in dem QMM ADAM Directory als MAP-Object angelegt. Sollte ein Objekt in der Zieldomäne gelöscht und erneut migriert worden sein, so existieren für das Quell-Objekt zwei Objektpaare in dem QMM ADAM Directory. Dies ist für den Betrieb der Synchronisation nicht weiter schlimm. Sobald Ressourcen mit dem Quest Resource Updating Manager RUM umgezogen werden, wird es unschön. Der RUM erzeugt aus den Daten im ADAM Directory eine Datei VMOVER.INI, welche SID-Paare [Quell-SID <> Ziel-SID] enthält. Die VMOVER.EXE sucht beim reACLing Prozess nach der Quell SID und trägt die in der VMOVER.INI vorhandene Ziel-SID ein. Wenn hier mehrere Einträge für eine Quell-SID vorhanden sind, so werden alle Ziel-SIDs eingetragen. In unserem Beispiel existiert eine der beiden SIDs nicht mehr in der Ziel-Domäne, was zu einem verwaisten Eintrag in der ACL der Ressource führt (z.B. NTFS ACL).

Lösung:

Um verwaiste Einträge in ACLs zu vermeiden stellt der Quest Support ein Script zur Verfügung, welches verwaiste Einträge aus dem QMM ADAM Directory entfernen kann.

Download Link

Anwendung:

Wie findet man Objekte im ADAM Directory?

Auf dem ADAM Server findet man unter [Start – Programme – ADAM] einen Eintrag [ADAM ADSI Edit]. Wichtig ist hier der DN (Distinguished Name). Dies ist der Projektname, welcher in der QMM Konsole angegeben wird. Beispiel: cn=QMMAD.

Die Objekte werden im ADAM Directory in einer flachen Struktur angelegt, sodass eine manuelle Suche fast unmöglich ist. Hier hilft eine LDAP Query mit ADSI-Edit. Für die Speicherung der Informationen aus Quell und Zielobjekt in einem MAP-Object hat sich Quest neue Attribute ausgedacht. Der SamAccountName wird zum Beispiel in zwei Attributen gespeichert:

Quell-Domain: aelita-Amm-SourceSamAccountName
Ziel-Domain:    aelita-Amm-TargetSamAccountName

Eine LDAP Query für einen Account könnte so aussehen:

Name:                         beliebiger Name
Root of Search:           CN=QMMAD
Query String:              (aelita-Amm-TargetSamAccountName=”Name des Objekts”)

Objekte als gelöscht markieren:

Das Skript des Quest Support RemoveQMMMapInvalidEnrtries.vbs sucht die Einträge im ADAM Directory in der Ziel-Domäne. Sollte das Objekt nicht mehr existieren, so wird das Attribute aelita-Amm-Deleted auf den Wert TRUE gesetzt. Die LDAP Query kann wie folgt angepasst werden:

Suche nach existierenden Objekten: (aelita-Amm-Deleted nicht gesetzt / Not set)

(&(aelita-amm-targetsamaccountname=“Name“)(!aelita-Amm-Deleted=*))

 Suche nach gelöschten Objekten: (aelita-Amm-Deleted=TRUE)

(&(aelita-amm-targetsamaccountname=“Name“)(aelita-Amm-Deleted=TRUE))

Quest Support hat ein kurzes Video veröffentlicht, welches die ADSI Verbindung zum ADAM Directory erläutert:

Link zum Video