Fehlerbehebung: Benutzer wurde von eADM nicht in Active Directory angelegt

Dieser Artikel beschreibt die häufigsten Gründe, warum eADM beim Erstellen eines Benutzerkontos in Active Directory (AD) fehlschlägt, und enthält Schritte zur Ermittlung und Behebung der jeweiligen Ursachen. Er richtet sich an eADM-Administratoren und IT-Partner, die lokale AD-Integrationen verwalten.

So lesen Sie das eADM-AD-Exportprotokoll

Der lokale eADM-Client erstellt für jeden Exportvorgang ein detailliertes Protokoll. Dieses Protokoll ist das wichtigste Diagnosetool, wenn ein Benutzerkonto nicht in AD angelegt wurde.

Die Protokolldateien können über „Synchronisierung“ → „Status“ → „Mehr“ → „eADM-Client-Protokoll herunterladen“ heruntergeladen werden. Alternativ befinden sie sich in der Regel unter C:\eADM\ oder einen bei der Installation konfigurierten Unterordner. Jeder Eintrag folgt diesem Muster:

DD.MM.YYYY HH:MM:SS - [action or result message]

Bei einem erfolgreichen „Create“-Vorgang wird jedes festgelegte Attribut protokolliert, gefolgt von einer Zeile ohne Fehlermeldung. Bei einem fehlgeschlagenen „Create“-Vorgang wird die Attributfolge protokolliert, anschließend wird der Vorgang mit einem Fehlercode und einer Fehlermeldung beendet. Beispiel für eine fehlgeschlagene Erstellung aus einem bekannten Supportfall:

23.07.2025 14:20:41 - Creating with LDAP://DC-SERVER/cn=Ola Nordmann,OU=eAdm,OU=Brukere,...\n23.07.2025 14:20:41 - Setting samAccountName to value 1001on\n23.07.2025 14:20:41 - Checking if upn is unique in domain ola.nordmann@eksempel.kommune.no\n23.07.2025 14:20:41 - Setting userPrincipalName to value ola.nordmann@eksempel.kommune.no\n23.07.2025 14:20:41 - 173585349|The object already exists.

Fehlerzeilen haben das folgende Format ERROR_CODE|Error message text. Der Fehlercode und die Fehlermeldung geben zusammen Aufschluss über die Ursache. Notieren Sie sich die letzte erfolgreiche Attributzeile vor dem Fehler – dies hilft dabei, einzugrenzen, an welcher Stelle AD den Vorgang abgelehnt hat.

Häufige Ursachen und Lösungen

1. Doppeltes Objekt – Benutzer ist bereits in AD vorhanden

eADM versucht, ein Objekt unter einem Distinguished Name (DN) oder mit einem sAMAccountName das bereits in AD vorhanden ist. AD lehnt den Vorgang mit einer Fehlermeldung wie beispielsweise The object already exists.

Dies kann in folgenden Fällen vorkommen:

• Zwei Mitarbeiter teilen sich denselben generierten sAMAccountName (z. B. werden beide aufgelöst zu 1001on).

• Ein zuvor gelöschtes Benutzerkonto wurde nicht vollständig aus dem AD entfernt, sodass ein Tombstone oder ein wiederverwertetes Objekt zurückbleibt.

• Der Benutzer wurde manuell in AD angelegt, bevor eADM die Bereitstellung versucht hat.

• Zwei Benutzer haben dasselbe Geburtsdatum, was zu einer Kollision bei einer regelbasierten Generierung von Benutzernamen anhand des Datums führt.

Beschluss:

1. Suche in AD nach dem sAMAccountName oder die im Protokoll angezeigte CN, um das konfliktauslösende Objekt zu identifizieren.

2. Öffnen Sie in eADM den betroffenen Benutzer und überprüfen Sie das Feld „AD-Benutzername “. Wenn zwei Benutzer denselben Wert haben, korrigieren Sie den Wert für einen der beiden über die eADM-Konfiguration oder durch Anpassung der Regel zur Benutzernamengenerierung.

3. Falls in AD ein veraltetes Objekt vorhanden ist, entfernen Sie es oder verschieben Sie es aus der Ziel-OU und lösen Sie anschließend einen neuen Synchronisierungszyklus aus.

2. Unzureichende Berechtigungen für das Dienstkonto

Dem Dienstkonto, das eADM für die Verbindung mit AD verwendet, fehlen die Berechtigungen zum Anlegen von Objekten in der Ziel-OU oder der Schreibzugriff auf ein oder mehrere Attribute, die bei der Erstellung festgelegt werden.

Häufige Ursachen:

• Das Dienstkonto verfügt in der Ziel-OU nicht über die Berechtigung „Unterobjekte erstellen “.

• Dem Dienstkonto fehlen Schreibrechte für bestimmte Attribute wie beispielsweise proxyAddresses, manager, oder employeeNumber.

• Die OU-Struktur hat sich nach der Konfiguration der ursprünglichen Delegierung geändert, und die Berechtigungen des Dienstkontos erstrecken sich nicht mehr auf die neue Ziel-OU.

Lösung: Überprüfen Sie die delegierten Berechtigungen für die Ziel-OU in AD. Stellen Sie sicher, dass das eADM-Dienstkonto mindestens über folgende Berechtigungen verfügt:

• Benutzerobjekte in der Ziel-OU anlegen und löschen.

• Schreibzugriff auf alle Attribute, die in der eADM-Exportvorlage für diesen Benutzertyp konfiguriert sind.

Wenden Sie sich an den AD-Administrator des Kunden, um die delegierten Berechtigungen anzupassen. Erteilen Sie dem eADM-Dienstkonto keine Domänenadministratorrechte.

3. Anforderungen an die Passwortkomplexität nicht erfüllt

Wenn eADM so konfiguriert ist, dass bei der Erstellung eines neuen Kontos ein Passwort festgelegt werden muss, lehnt AD die Erstellung ab, wenn das Passwort nicht den Passwortrichtlinien der Domäne entspricht – einschließlich der Anforderungen an die Mindestlänge, die Komplexität oder die Passwortgeschichte.

Lösung: Überprüfen Sie das in der eADM-Exportvorlage konfigurierte Standardkennwort und vergleichen Sie es mit der detaillierten Kennwortrichtlinie der Domäne (falls zutreffend) oder der Standard-Domänenrichtlinie. Das von eADM bei der Kontoerstellung festgelegte Kennwort muss alle Anforderungen der Richtlinie erfüllen.

4. Ungültige Daten oder Schemaverstöße

eADM versucht, einen Wert in ein AD-Attribut zu schreiben, der gemäß dem Schema für diese Domäne nicht zulässig ist – beispielsweise einen Wert mit falschem Datentyp, einen Wert, der nicht unterstützte Zeichen enthält, oder ein fehlendes Pflichtattribut.

Häufige Ursachen:

• Die sAMAccountName enthält Zeichen, die von AD nicht zugelassen sind (z. B. Leerzeichen, Schrägstriche oder erweiterte Zeichen).

• Ein obligatorisches AD-Attribut, das von einer Schemaerweiterung vorgeschrieben ist, wird in der eADM-Exportvorlage nicht abgebildet.

• Die manager Das Attribut verweist auf einen DN, der in AD nicht vorhanden ist, wie aus folgendem hervorgeht: An invalid dn syntax has been specified im Protokoll.

• Die Übergeordneter Pfad (parentPath) in der eADM-Exportvorlage für aktive Benutzer ist für den betroffenen Benutzer falsch konfiguriert oder fehlt, was zu einem ungültigen Ziel-DN führt.

• Der Benutzer wird mit einem CN Ein Wert, der in AD nicht zulässig ist, beispielsweise weil er Zeichen enthält, die AD in einem relativen Distinguished Name nicht zulässt.

• Ein numerisches Feld in der Exportvorlage gibt einen Zeichenfolgenwert aus.

Lösung: Ermitteln Sie die letzte Attributzeile, die vor dem Fehler im Protokoll geschrieben wurde. Überprüfen Sie den Wert, der für dieses Attribut in der eADM-Exportvorlage festgelegt ist, sowie die Quelldaten aus dem HR-System. Korrigieren Sie entweder die Datenzuordnung in eADM oder den Quellwert im HR-System und lösen Sie anschließend eine neue Synchronisierung aus.

5. Netzwerk- oder Verbindungsfehler zum AD-Agenten

Der eADM-Clouddienst kann den lokalen eADM-Client vor Ort nicht erreichen, oder der lokale Client kann den AD-Domänencontroller nicht erreichen. In diesem Fall werden für den betroffenen Synchronisierungszyklus keine Protokolleinträge geschrieben, oder das Protokoll zeigt anstelle eines AD-spezifischen Fehlercodes einen Timeout- oder Verbindungsfehler an.

Beschluss:

1. Stellen Sie sicher, dass der lokale eADM-Clientdienst oder die geplante Aufgabe auf dem lokalen Server ausgeführt wird.

2. Stellen Sie sicher, dass ausgehender HTTPS-Verkehr (Port 443) vom Server zum eADM-Cloud-Endpunkt zugelassen ist.

3. Stellen Sie sicher, dass der Server den AD-Domänencontroller über den erforderlichen LDAP-Port (389 oder 636) erreichen kann.

4. Überprüfen Sie den Windows-Ereignisanzeiger auf dem Server auf Verbindungs- oder Dienstfehler.

6. Mehrdeutige Übereinstimmung – zwei AD-Konten weisen denselben Wert für das „mergeattribute“ auf

Wenn zwei AD-Konten bereits denselben Wert im konfigurierten „mergeattribute“ aufweisen, kann eADM nicht eindeutig feststellen, welches Konto dem zu provisionierenden Benutzer entspricht. Je nach Situation kann dies entweder den Erstellungsvorgang blockieren oder dazu führen, dass eADM das falsche Konto aktualisiert, anstatt ein neues zu erstellen.

Dies kann in folgenden Fällen vorkommen:

• Der Wert des „mergeattribute“-Attributs wurde manuell für ein AD-Konto außerhalb des eADM-Provisioning-Prozesses festgelegt.

• Ein AD-Konto, das aus einer früheren Beschäftigungszeit übrig geblieben ist, ist nach wie vor gültig employeeID oder employeeNumber als neuer Mitarbeiter.

• Zwei Personaldatensätze weisen aufgrund eines Eingabefehlers im Quell-HR-System dieselbe Mitarbeiter-ID oder Mitarbeiternummer auf.

• Ein AD-Konto wurde migriert oder aus einem Backup wiederhergestellt, wobei der Wert des Attributs „mergeattribute“ veraltet war und inzwischen in der Personalabteilung einem anderen Mitarbeiter zugewiesen wurde.

Beschluss:

1. Durchsuchen Sie das AD nach allen Konten, die den im eADM-Protokoll oder im Benutzerdatensatz angezeigten Wert für das „mergeattribute“ aufweisen, zum Beispiel: Get-ADUser -Filter {employeeID -eq "value"} -Properties employeeID.

2. Überprüfen Sie, welches Konto die korrekte, aktuelle Entsprechung zum Personalstammdatensatz ist. Löschen oder korrigieren Sie den Wert des „mergeattribute“-Felds bei allen anderen Konten, die fälschlicherweise denselben Wert aufweisen.

3. Stellen Sie die betroffenen Benutzer in eADM wieder her, damit die Verknüpfungen zu den entsprechenden Benutzern in AD korrigiert werden.

7. Der Wert des „Mergeattribute“-Felds eines bestehenden Kontos stimmt mit einem anderen Benutzer überein

Im Gegensatz zu Ursache 6 ist hier nur ein AD-Konto betroffen – dessen „mergeattribute“-Wert stimmt jedoch zufällig mit der Kennung einer anderen Person überein, in der Regel einer Person, für die gerade eine neue Bereitstellung erfolgt. eADM identifiziert dieses einzelne bestehende Konto als eindeutige Übereinstimmung und aktualisiert es, anstatt ein neues Konto für den neuen Benutzer anzulegen. Aus Sicht von eADM besteht keine Mehrdeutigkeit, sodass dies in der Regel überhaupt keinen Fehler verursacht: Die Synchronisierung scheint erfolgreich zu verlaufen, doch am Ende wird die falsche Person mit dem Konto verknüpft.

Dies kann in folgenden Fällen vorkommen:

• Das HR-System verwendet Mitarbeiternummern nach dem Ausscheiden eines Mitarbeiters erneut, und einem neuen Mitarbeiter wird später dieselbe Nummer zugewiesen, die noch im veralteten AD-Konto des ehemaligen Mitarbeiters vorhanden ist.

• Jemand hat manuell einen falschen Wert eingegeben employeeID oder employeeNumber Wert eines bestehenden AD-Kontos, und dieser Wert stimmt zufällig mit der tatsächlichen Kennung eines anderen Mitarbeiters überein.

• Bei einer Datenmigration oder -wiederherstellung ist ein veralteter „mergeattribute“-Wert für ein Konto zurückgeblieben, das die Personalabteilung inzwischen einer anderen Person zugewiesen hat.

Beschluss:

1. Ermitteln Sie in eADM, mit welchem bestehenden AD-Konto der Datensatz des neuen Benutzers abgeglichen und aktualisiert wurde, anstatt ein neues Konto anzulegen.

2. Stellen Sie sicher, wem dieses AD-Konto tatsächlich gehört und wie der korrekte Wert für „mergeattribute“ für beide betroffenen Personen lauten sollte.

3. Korrigieren Sie den Wert des „mergeattribute“-Feldes bei dem falsch zugeordneten AD-Konto so, dass er den tatsächlichen Eigentümer widerspiegelt, und geben Sie den Wert für die richtige Person frei.

4. Stellen Sie die betroffenen Benutzer in eADM wieder her, damit die Verknüpfungen zu den entsprechenden Benutzern in AD korrigiert werden.

Diagnose-Checkliste

Verwandte Artikel

• Fehlerbehebung bei „System.ServiceModel.FaultException“ in den Protokollen des lokalen eADM-Clients

• Aktualisierung von Benutzerdaten in eADM

Zuletzt aktualisiert: 27. Juli 2026