ADSync - Objekte löschen und zurückholen

Objekte werden absichtlich aber manchmal auch unabsichtlich gelöscht. Diese Seite beschreibt, was da im Hintergrund dann genau passiert, wenn Sie Office 365 samt DirSync im Boot haben.

Übersicht: Benutzer wird gelöscht und wieder "hergestellt"

Hierbei sind zwei Fälle zu unterscheiden. Sie können ein User direkt in der Cloud löschen und wiederherstellen oder sie löschen den Benutzer im lokalen Active Directory und der DirSync-Prozess übernimmt das Löschen.

Der "Regelfall" ist natürlich, dass Sie alle Benutzer über ihr lokales Active Directory verwalten und damit auch die Objekte in der Cloud verwaltet werde. Wenn Sie einen Benutzer On-Premises löschen, dann wird das Konto in der Cloud entsprechend "Gelöscht". In der Cloud landet es AD-im Papierkorb. Aber wie stellen Sie einen gelöschten Benutzer wieder her und was passiert dabei? Die folgende Tabelle soll dabei helfen.

Lesen Sie dazu vorher aber auch die Informationen der Seite ADSync Matching und Office 365 SourceAnchor und ADMT.

Gelöschtes Objekt Zwischenstand Wiederherstellung

Cloud-Only User in Office 365 wurde mit Remove-MSOLUser oder Admin Center gelöscht.

Der Benutzer wird in den Office 365 Papierkorb verschoben. On-Prem gibt es kein entsprechendes Objekt.

Sie können das Konto mit Restore-MSOLUser oder das Admin Center einfach wieder zurückholen.

ADSyncUser in der Cloud mit "Remove-MSOLUser gelöscht

Obwohl das Konto durch den DirSync angelegt wurde. können Sie es im Admin Center und mit "Remove-MSOLUser" löschen. Es wird in den Office 365 Papierkorb verlagert.

Der "normale DirSync" löscht keine User im On-PremAD (Ausnahme Azure Ad Premium). Insofern bleibt das On-Prem-Gegenstück unberührt.

Genauso wie ein CloudOnly-User können sie auch einen DirSync-User aus dem Office 365 Papierkorb mittels "Restore-MSOLUser" oder Admin Center wieder zurück holen.

Er behält dabei seine ImmutableID und wird weiter abgeglichen.

Wenn AADConnect noch vorhanden ist, dann kommt der gelöschte Benutzer beim nächsten Sync auch wieder zurück, AADConnect macht immer zuerst einen "Import und erkennt, dass der Benutzer "fehlt".

On-Prem User gelöscht und KEIN AD-Papierkorb aktiv

Das Benutzer-Objekt wird durch den DirSync in Office 365 nach "Deleted User" verschoben. Der Anwender kann sich nicht mehr anmelden aber das Postfach etc. bleibt noch 30 Tage vorhanden.

Ohne Papierkorb kann das Objekt mit der gleichen GUID nur hergestellt werden, wenn ein autoritatives Restore eines DC erfolgt. Alternativ kann ein neuer Benutzer angelegt werden und dann ein Match herbeigeführt werden.

On-Prem User gelöscht und AD-Papierkorb aktiv

Das Benutzer-Objekt wird durch den DirSync in Office 365 nach "Deleted User" verschoben. Der Anwender kann sich nicht mehr anmelden aber das Postfach etc. bleibt noch 30 Tage vorhanden.

Der AD-Papierkorb erlaubt sehr schnell und einfach die Wiederherstellung eines versehentlich gelöschten Objekts.

On-Prem User nicht mehr im DirSync Scope.

Das Objekt wird in Office 365 entfernt, da es nicht mehr im Scope ist. Es liegt 30 Tage in dem Office 365 Papierkorb.

Wenn Sie das Objekt wieder in den Scope bringen, wird es auch wieder aus dem Office 365-Papierkorb in die normale Benutzerliste verschoben.

Der Fokus dieser Tabelle liegt auch Benutzern, da damit auch Daten und Lizenzen verbunden sind. Auch Gruppen werden mit AADConnect synchronisiert und können gelöscht werden. Hier ist das Matching aber etwas einfacher. Siehe dazu auch ADSync - Gruppen matchen und ADSync und Gruppen

Die verschiedenen Fälle habe ich im Detail dokumentiert:

Office 365 ist sehr dynamisch und einige der hier beschriebenen Verhaltensweisen waren früher noch nicht möglich. Ich kann nicht dafür garantieren, dass diese auch morgen noch genauso funktionieren. Microsoft entwickelt den DirSync kontinuierlich weiter.

Löschen im lokalen AD mit ADSync

Der normale Weg ist es, ein Objekt im Active Directory zu löschen. Beim nächsten ADSync-Lauf erkennt dies der Prozess und entfernt das Konto beim Import erst aus dem Connector Space.

In den Details ist zu sehen, dass das Objekt in Verbindung mit dem AD-Papierkorb gar nicht mehr nach "Deleted Objects" verschoben wird, sondern in der OU bleibt

Wenn es keinen eingehenden Link in einem anderen Connector gibt, wird das Objekt auch aus dem Metaverse entfernt.

Beim nächsten Export wird das Objekt dann auch im Azure AD entfernt. Sobald ich das Objekt wieder aus dem Papierkorb zurückhole, wird es beim nächsten Sync wieder erkannt und neu angelegt. Da mitterlweile der Sourceanchor (Siehe SourceAnchor Details) normalerweise aus der ObjectGUID abgeleitet wird, wird quasi das gleiche Objekt wieder hergestellt.

Das gilt aber nur für Benutzer. Für Gruppen gibt es diese Funktion nicht, denn der AzureAD-Papierkorb gilt nur für "Microsoft Gruppen".

ADSync legt die Gruppe in der Cloud mit einer neuen ObjectID an. Es ist eine neue Gruppe und wie wird nicht aus einem "AzureAD Papierkorb" geholt.

Out of Scope-verschieben

Wenn ADSync nicht alle OUs überwacht und ich ein Objekt aus einer überwachten OU in eine nicht überwachte OU verschiebe, dann erkennt auch ein DeltaSync, dass sich an dem Objekt etwas geändert at und es nicht mehr da ist.

Allerdings zeigt der Distinguishedname dann nicht mehr das "0ADEL"-Prefix sondern einfach nur den alten DN. Ein Klick auf das Element liefert aber keine Informationen mehr.

Auch hier kann ich das Element wieder in die OU zurückschieben, so dass es wieder als "Neu" erscheint und angelegt wird

Das hindert ADSync aber nicht, der Gruppe in der Cloud eine neue ObjectID zuzuweisen, Es ist eine neue Gruppe und wie wird nicht aus einem "AzureAD Papierkorb" geholt.

Sonderfall: Move-ADObject

Mit dem Commandlet Move-ADObject lassen sich nicht nur Objekte innerhalb einer Domain verlagern sondern auch in andere Domänen verschieben. Sie bekommen dann eine neue ObjectID. Entsprechend sollte ADSync den Verlust des Objekts in der Quelle erkennen aber auch das neue Objekt im Ziel wiederfinden. Verschoben habe ich mit:

Move-ADObject `
   -Identity "CN=Movegroup,OU=movetest,DC=carius,DC=de" `
   -TargetPath "OU=movetest,DC=sub,DC=carius,DC=de" `
   -TargetServer subdc.sub.carius.de

Beide Domains sind durch ADSync verwaltet und beide OUs im Scope. Allerdings war ich dann schon überrascht, dass ADSync beim "Delta Import" nichts erkannt hat. Auch im Metaverse war noch die alte OU enthalten. Erst ein Full-Import hat diese Veränderung aufgezeigt. Ein Objekt, welches mit Move-ADObject in eine andere Domäne verschoben wird, die von AD-Sync nicht überwacht wird, wird nicht als "Delete" erkannt. Das originale Objekt landet auch nicht AD-Papierkorb oder als "Deleted Object in einer OU. Move-ADObjects scheint das Quellobject bei einer Migration in eine andere Domäne komplett zu zerstören.

Wenn Sie diesen Fall haben, dann sollten Sie nach dem Move immer ein "Full-Sync" machen.

Löschen eines Benutzer im Admin Portal

Wenn Sie das Office 365 Admin-Portal nutzen, dann können Sie dort sehr wohl Benutzer löschen. Aber die GUI erlaubt ihnen nur solche Objekte zu löschen, die nicht synchronisiert sind. Der "Löschen"-Punkt ist bei meinem per ADSync verwalteten Benutzer nicht aktiv.

Insbesondere das DirSync-Konto selbst ist besonders geschützt:

Löschen eines AD-Sync Users in der Cloud per Admin Center

Interessant ist aber, dass im neuen Admin Center aktuell (Mai 2016) auch synchronisierte Objekte im Active Directory einen aktiven "Löschen" Button haben, der sogar zum nächsten Schritt führt:

Bei einer Kontrolle im Januar 2018 hat Microsoft den Fehler schon korrigiert.

Der reguläre Weg so ein Objekt zu löschen erfolgt über den Verzeichnisabgleich AADConnect. Sie müssten das Objekt im lokale Active Directory so verändern, dass es von AADConnect nicht mehr "gesehen" wird. Der einfachste Griff ist sicher das Löschen das lokalen Kontos. Wenn Sie AADConnect mit einer Filterung von Objekten nach OU, Gruppe oder LDAP-Feld eingerichtet haben, können Sie so ein Objekt wieder aus dem Scope nehmen. AADConnect löscht dann das Objekt in der Cloud.

Sie können natürlich den "DirSync" im Tenant abschalten und dann nach einer Wartezeit die Objekte in der Cloud löschen. Aber ich möchte nicht gleich den gesamten AADConnect für einige Tage außer Kraft setzen. Das ist schon ein Risiko und beim Einsatz der Funktion Office 365 Password Sync auch störend, da Anwender während der Zeit zwar das lokale Kennwort ändern können aber in der Cloud dies nicht nachgezogen wird. Zudem ist das Löschen der Benutzer in der Cloud samt ihrer Daten gar nicht das, was sie eigentlich haben sollten.

Ähnliches passiert, wenn Sie bei einem bei einem per DirSync verwalteten Benutzer die Gruppenmitgliedschaften ändern wollen.

Alle Gruppen die über DirSync verwaltet werden, sind "ReadOnly". Sie können den synchronisierten Office 365 User aber natürlich in eine Office 365 Gruppe addieren und entfernen.

Löschen eines ADSync Users in der Cloud per PowerShell

Offiziell können Sie z.B. Benutzern nicht über die Weboberfläche löschen. Allerdings ist dies nur die halbe Wahrheit. Über die Office 365 PowerShell können Sie einen Benutzer mit "Remove-MSOLUser" auch Löschen, wenn er über den DirSync angelegt wurde. Ich habe das mit einem Konto einmal getestet"

Das Konto war danach wirklich in der Cloud "weg" und unter "Gelöschte Objekte" zu finden

Ich hätte das Konto von dort wieder "herstellen" können, aber dann wird es ein "In Cloud" Konto. Interessanter fand ich aber zu sehen, was der DirSync dazu sagt. er hat im gleichen DirSync-Lauf beim Export aus Office 365 den "Delete" erkannt und beim Import das Konto umgehen wieder angelegt.

Für ein "Aufräumen" von überzähligen Objekten im AzureAD muss der DirSync gar nicht abgeschaltet werden. Das so gelöschte Objekt wird in den Azure AD Papierkorb verschoben. Wenn das lokale AD-Objekt aber noch vorhanden ist, dann wird das Konto beim nächsten "Sync" aber wieder aus dem "DeletedUser"-Container restauriert und es kann weiter gehen

# AADConnect
Start-ADSyncCycle -PolicyType initial

Der Benutzer verschwindet dann auch wieder aus "Deleted Objects" und wird wieder als ganz normaler Anwender angezeigt.

Wiederverbinden ohne AD-Papierkorb

Wenn alle "Löschvorgänge" geplant waren, funktioniert der DirSync wunderbar und korrigiert auch Fehler des Administrators in der Cloud. Was aber passiert, wenn das Löschen On-Premises gar nicht gewünscht war und wieder rückgängig gemacht werden soll? Der aus dem AD gelöschte Benutzer ist ja im Bereich "Gelöschte Objekte" in Office 365 vorhanden. Ich wollte auf jeden Fall verhindern, dass eine erneute Bereitstellung im lokalen AD mit dem DirSync ein neues zweites Objekt anlegt und die Mails des gelöschten Benutzers verschwinden. Zudem sollte die Adresse nicht allzu lange "unerreichbar" sein. Entsprechend veränderten sich die Felder.

Ohne den AD-Papierkorb habe ich folgenden Prozess mir überlegt.

Schritt Befehl Beschreibung


ADSyncCycle anhalten 

 

Set-ADSyncScheduler `
   -SyncCycleEnabled:$false

Solange ADSync weiter läuft, sollten Sie nicht in der Cloud an Objekten etwas "rumschrauben". Der DirSync-Prozess ist hier sehr einehmend und wenn in seinem Tenant z.B. ein Objekt auftaucht, was dort nicht hingehört, dann wird dieses umgehend auch wieder gelöscht.


Cloud User restaurieren 

 

Restores <upn_des_Users>

Das durch den DirSync gelöschte Benutzerobjekt liegt im Papierkorb und ist dort erst mal nicht weiter bearbeitbar. Es muss also zuerst wieder zum Leben erweckt werden. Das ist im Fall eines gelöschten Objekts besonders wichtig, damit z.B.: eingehende Mails weiterhin funktionieren. Länger als 30 Tage darf dies aber nicht dauern, sonst ist das Postfach leer.


ImmutableID leeren 

 

set-MsolUser `
   -UserPrincipalName <upn_des_Users> `
   -ImmutableId "$null"

Das wiederhergestellte Objekt hat noch alle vorherigen Properties. Damit es mit einem neuen AD-Objekt "gematched" werden kann, muss die ImmutableID erst einmal geleert werden. Die Angabe von "$null" funktionierte bei mir nicht. Erst ein Leerstring hat das Feld leer gemacht oder sie geben "$null" mit Anführungszeichen an.


AD-Objekt bereitstellen 

On-Prem AD

Im lokalen On-Prem-AD habe ich dann ein AD-Objekt wieder neu angelegt (oder aus der Papierkorb wieder hergestellt). Wichtig ist, dass das Feld "Mail" dieses Objekts genau mit dem Feld "Mail" des Office 365-Objekts übereinstimmt, da der DirSync damit ein Matching macht (Siehe auch


DirSync reaktivieren

 

Set-ADSyncScheduler `
   -SyncCycleEnabled:$true
Start-ADSyncCycle `
   -PolicyType Delta

Nun sollte das Feld bereitet sein, dass der DirSync das neu im On-Prem-AD angelegte Konto in die Cloud replizieren kann. Dank der Mailadresse

Ich habe mit zu jedem Schritt mit "GET-MSOLUser" die Eigenschaften des Benutzers anzeigen lassen. Folgende Felder haben sich geändert:

Feld Ausgangsobjekt Durch DirSync gelöscht Nach
Recover-MSOLUser		 Nach
Set-MSOILUser
-immutableID ""		 Nach DirSync Match 

ExtensionData

System.Runtime.Serialization.Extension.DataObject

AlternateEmailAddresses

{}

{}

{}

{}

{}

AlternateMobilePhones

{}

{}

{}

{}

{}

AlternativeSecurityIds

{}

{}

{}

{}

{}

BlockCredential

False

False

False

False

False

City

CloudExchangeRecipientDisplayType

1073741824

1073741824

1073741824

1073741824

1073741824

Country

Department

DirSyncProvisioningErrors

{}

{}

{}

{}

{}

DisplayName

User6

User6

User6

User6

User6

Errors

Fax

FirstName

User6

User6

User6

User6

User6

ImmutableId

OgXZ+PUtOkOrY2Ea8NS16g==

OgXZ+PUtOkOrY2Ea8NS16g==

OgXZ+PUtOkOrY2Ea8NS16g==

 

eWhqldRfMkW8kQv337THoA== 

IndirectLicenseErrors

{}

{}

{}

{}

{}

IsBlackberryUser

False

False

False

False

False

IsLicensed

True

True

True

True

True

LastDirSyncTime

23.05.2016 09:34:00

$null

$null

$null

23.05.2016 10:50:19

LastName

LastPasswordChangeTimestamp

23.05.2016 09:29:24

23.05.2016 09:29:24

23.05.2016 09:29:24

23.05.2016 09:29:24

23.05.2016 09:29:24

LicenseReconciliationNeeded

False

False

False

False

False

Licenses

{carius:ENTERPRISEPACK}

LiveId

1003BFFD9078E2A6

1003BFFD9078E2A6

1003BFFD9078E2A6

1003BFFD9078E2A6

1003BFFD9078E2A6

MSExchRecipientTypeDetails

MobilePhone

ObjectId

34a7a955-d50f-4cfd-a7a9-2a5b076976e2

Office

OverallProvisioningStatus

Success

PendingInput

PendingInput

Success

Success

PasswordNeverExpires

True

True

True

True

True

PasswordResetNotRequiredDuringActivate

True

True

True

True

True

PhoneNumber

PortalSettings

PostalCode

PreferredLanguage

ProxyAddresses

{smtp:User6@carius.onmicrosoft.com, SMTP:User6@carius.de}

ServiceInformation

{}

{}

{}

{}

{}

SignInName

User6@carius.de

User6@carius.de

User6@carius.de

User6@carius.de

User6@carius.de

SoftDeletionTimestamp

$null

23.05.2016 10:34:05

$null

State

StreetAddress

StrongAuthenticationMethods

{}

{}

{}

{}

{}

StrongAuthenticationPhoneAppDetails

{}

{}

{}

{}

{}

StrongAuthenticationProofupTime

StrongAuthenticationRequirements

{}

{}

{}

{}

{}

StrongAuthenticationUserDetails

StrongPasswordRequired

True

True

True

True

True

StsRefreshTokensValidFrom

29.04.2015 00:38:12

23.05.2016 09:29:24

23.05.2016 09:29:24

23.05.2016 09:29:24

23.05.2016 09:29:24

Title

UsageLocation

DE

DE

DE

DE

DE

UserLandingPageIdentifierForO365Shell

UserPrincipalName

User6@carius.de

User6@carius.de

User6@carius.de

User6@carius.de

User6@carius.de

UserThemeIdentifierForO365Shell

UserType

Member

Member

Member

Member

Member

ValidationStatus

Healthy

Healthy

Healthy

Healthy

Healthy

WhenCreated

29.04.2015 00:38:12

29.04.2015 00:38:12

29.04.2015 00:38:12

29.04.2015 00:38:12

29.04.2015 00:38:12

 

Achtung
Ich habe nach dem "Recover" ein paar Minuten gewartet und mit erstaunen zu erkennen, dass DirSync das gerade wiederhergestellte Objekte einfach wieder entfernt hat. Der DirSync "kümmert" sich also um jedes Objekt, welches in der Cloud mit einer "ImmutableID" versehen ist. Insofern wäre dieser Weg nur gangbar, wenn es mir gelingt die ImmutableID an dem gelöschten Objekte zu entfernen.

Interessant ist dabei, dass das Office 365 Objekt fast komplett erhalten bleibt. Sowohl die Mailadressen aber auch die Mitgliedschaften in Office 365-Gruppen bleiben erhalten. Auch die Office 365 Lizenz und sogar administrative Berechtigungen sind nach der Wiederherstellung wieder vorhanden. Einzig die Mitgliedschaft in über DirSync verwaltete AD-Gruppen ist natürlich nicht mehr gegeben. Durch das Löschen des Objekts im lokalen On-Prem-AD ist das Benutzerobjekt dort auch aus den AD-Gruppen entfernt worden und der DirSync wurden die Gruppenmitgliedschaften natürlich auch in der Cloud aktualisiert. Durch die Neuanlage bzw. Wiederherstellung des Benutzers On-Premises und die Aufnahme in die Gruppen werden die Mitgliedschaften aber ebenfalls auch wieder in der Cloud aktualisiert. Insofern ist der Benutzer zumindest in der Cloud wieder komplett hergestellt.

Etwas anders sieht das natürlich On-Premises aus, wenn der Benutzer nicht über den Papierkorb wieder hergestellt, sondern neu angelegt wurde. Mit einer neuen SID und neuer ObjectGUID etc. ist er natürlich nicht mehr das gleiche Objekt. Auch könnten ihm On-Prem einige LDAP-Einstellungen fehlen, die auch in der Cloud Auswirkungen haben. Diese Beschreibung gilt daher nur für den vereinfachten Fall und z.B. nicht, wenn Sie Exchange oder Skype for Business im Hybrid Mode betreiben. Hier sind sicher noch einige weitere Einstellungen zu tätigen.

Wiederverbinden mit AD-Papierkorb

Seit Windows 2008R2 gibt es ja den AD-Papierkorb, ob den Objekte doch etwas einfacher wieder zurück geholt werden können. Zwar kann ein Administrator auch vorher versuchen, Objekte auf dem "Deleted Objects"-Container zurück zu holen. Aber dabei gehen doch einige Informationen des Benutzers verloren. Mittlerweile sollten aber alle Windows 2003 DCs und älter wirklich Geschichte sein und es kein Problem sein, den Forest auf dem Windows 2008R2-Mode zu betreiben und damit von den Vorteilen des AD-Papierkorbs zu profitieren.

  • AD User On-Prem anlegen
    Ich habe lokal einen Benutzer angelegt, eine Mailadresse verpasst und in ein paar Gruppen aufgenommen
  • DirSync abwarten
    Der Verzeichnisabgleich hat den Benutzer in Office 365 angelegt
  • AD User gelöscht
    Dann haben ich den Benutzer im On-Prem-AD wieder gelöscht
  • DirSync löscht Cloud User
    Wie zu erwarten wurde das Konto in der Cloud ebenfalls in den Papierkorb der Cloud verschoben
  • "Undelete" On-Prem
    Nun habe ich vom lokalen AD-Papierkorb gebraucht gemacht und das Konto wieder hergestellt. Dank dem AD-Papierkorb kam nicht nur die Mailadresse mit, sondern auch die Gruppenmitgliedschaften wurden komplett wieder hergestellt
  • DirSync aktualisierte das Cloud-Objekt
    Natürlich war ich nun gespannt, ob der DirSync ein neues Objekt anlegt oder das bestehende "gelöschte" Objekt wieder rettet. Der nächste DirSync hat tatsächlich das Konto aus dem Office 365 Papierkorb wieder direkt hergestellt.

Hier hat Microsoft mit dem ADSync eine sehr elegante Möglichkeit geschaffen, ein irrtümlich im lokalen Forest gelöschtes Objekt schnell wieder bereit zu stellen.

Wiederverbinden mit "Tombstone"

Leider kann man den AD-Papierkorb nicht mehr rückgängig machen. Denn erst danach ist mir aufgefallen, dass man auch ohne AD Papierkorb verschiedene AD-Objekte eines lokalen Windows 2003 Active  Directory wieder "entlöschen" kann. Wenn Benutzer gelöscht werden, dann verschwinden sie ja nicht sofort komplett aus der Datenbank, sondern werden "als gelöscht" markiert aber 60-120 Tage noch mitgeführt, damit alle Domain Controller diesen "Löschbefehl" auch lernen können. Erst nach Ablauf dieser "Tombstone"-Zeit löscht dann jeder DC für sich das Objekt.

Mit Tools wie ADRestore (Sysinternals) oder Lazarus oder auch LDP können Administratoren solche Konten aus dem "Deleted Object"- Container wieder herausholen. Der große Vorteil gegenüber einer Neuanlage ist, dass die ObjectGUID als auch die SID erhalten bleibt. Speziell die ObjectGUID ist ja im Hinblick auf die ImmutableID wichtig.

Ich könnte mir durchaus vorstellen, dass auch ein Undelete eines Objects über diesen Weg dazu führt, dass der DirSync das Objekt ebenfalls wieder aus dem Office 365 Papierkorb zurück holt. Allerdings werden Sie dann natürlich Gruppenmitgliedschaften und nicht gesicherte AD-Felder natürlich noch nacharbeiten müssen.

Remove-ADSyncCSObject

Achtung:
Sie sollten genau wissen, was Sie mit diesem Befehl anstellen.

Aber es gibt Fälle, in denen ADSync etwas aus dem Tritt kommt. Das passiert z.B. bei Änderungen an Synchronisierungs-Regel, die dann Objekte "disconnected" vom Metaverse oder ConnectorSpace hinterlassen und als Sync-Fehler hartnäckig ihre Statistik stören. Häufig ist es ein "sync-generic-failure", der sich auch nicht alleine irgendwann löst. In einem Fall hatte, warum auch immer, ADSync noch den ActiveSync-Container als "placeholder" in den Connector Space repliziert.

Der Benutzers selbst hat noch einen Connector aber das darunterliegende Objekte nicht mehr. "(Connector = false)". Das ist lange nicht aufgefallen, bis der Benutzer nun auch noch entfernt werden sollte.

Der Fehler enthält z.B. den String "ApplyDeleteToCS". ADSync versucht also das Objekte im ConnectorSpace zu löschen was aber nicht möglich ist, solange es noch das darunterliegende Objekte vorhanden ist. Ein Blick in den Connector-Space des Benutzers zeigt aber anscheinend einen Altlast bei den Synchronisierungsregeln.

Die Ursache konnte aber nicht mehr ermittelt werden. Die Holzhammer-Methode wäre nun ein Neuaufbau von ADSync mit einem HardMatch der Objekte. In dem Beispiel sind wir das Risiko eingegangen, direkt den ConnectorSpace zu bearbeiten. Per PowerShell kann ich als Administrator dort Objekte auslesen und löschen.

Get-ADSyncCSObject -DistinguishedName "CN=user1,OU=Abteilung,DC=msxfaq,DC=de" -ConnectorName msxfaq.de

Remove-ADSyncCSObject -DistinguishedName "CN=user1,OU=Abteilung,DC=msxfaq,DC=de" -ConnectorName msxfaq.de

So haben wir dann im ConnectorSpace die Objekte gelöscht, welche früher durch eine SyncRegel sowieso schon gelöscht sein sollten. Danach war der Fehler nicht mehr vorhanden.

Um aber ganz sicher zu sein, wurde dann ein "Full-Import " mit allen Connectoren ausgeführt, um ggfls. zu viel gelöschte Einträge zu erkennen. In dem Fall hat ADSync aber auch keine Objekte mehr angelegt:

Warnung
Auch wenn der Umgang mit "Remove-ADSyncCSObject" sehr einfach ist, so ist es doch ein tiefer Eingriff, der normalerweise nicht erforderlich sein sollte. Hier waren wohl eigene ADSync-Regeln der Vergangenheit die Ursache.

Weitere Links

Einen per DirSync in der Cloud angelegten Benutzer können Sie nicht einfach löschen.