Probleemoplossing: Gebruiker niet aangemaakt in Active Directory door eADM

In dit artikel worden de meest voorkomende redenen beschreven waarom eADM er niet in slaagt een gebruikersaccount aan te maken in Active Directory (AD), en worden stappen gegeven om elke oorzaak op te sporen en op te lossen. Het artikel is bedoeld voor eADM-beheerders en IT-partners die AD-integraties op locatie beheren.

Hoe lees je het eADM AD-exportlogboek?

De lokale eADM-client maakt voor elke exportbewerking een gedetailleerd logboek aan. Dit logboek is het belangrijkste hulpmiddel voor diagnose wanneer er geen gebruikersaccount in AD is aangemaakt.

Logbestanden kunnen worden gedownload via Synchronisatie -> Status -> Meer -> eADM Client-logboek downloaden. Daarnaast zijn ze doorgaans te vinden in C:\eADM\ of een submap die tijdens de installatie is geconfigureerd. Elk item volgt dit patroon:

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

Bij een geslaagde Create-bewerking wordt elk ingesteld attribuut geregistreerd, gevolgd door een regel zonder foutmelding. Bij een mislukte Create-bewerking wordt de reeks attributen geregistreerd, waarna de bewerking wordt afgebroken met een foutcode en een foutmelding. Voorbeeld van een mislukte aanmaakbewerking uit een bekende supportcase:

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.

Foutregels hebben de volgende indeling ERROR_CODE|Error message text. De foutcode en het foutbericht geven samen de oorzaak aan. Let op de laatste regel met een succesvol kenmerk vóór de fout — hierdoor kun je beter vaststellen op welk punt AD de bewerking heeft afgewezen.

Veelvoorkomende oorzaken en oplossingen

1. Dubbel object — gebruiker bestaat al in AD

eADM probeert een object aan te maken met een Distinguished Name (DN) of met een sAMAccountName die al in AD bestaat. AD wijst de bewerking af met een foutmelding zoals The object already exists.

Dit kan gebeuren wanneer:

• Twee medewerkers delen hetzelfde gegenereerde sAMAccountName (bijv. beide worden omgezet naar 1001on).

• Een eerder verwijderd gebruikersaccount is niet volledig uit AD verwijderd en er is nog een tombstone of gerecycled object achtergebleven.

• De gebruiker was handmatig aangemaakt in AD voordat eADM de provisioning probeerde uit te voeren.

• Twee gebruikers hebben dezelfde geboortedatum, wat leidt tot een conflict in een regel voor het genereren van gebruikersnamen op basis van de datum.

Besluit:

1. Zoek in AD naar de sAMAccountName of het CN dat in het logboek wordt weergegeven om het object te identificeren dat het conflict veroorzaakt.

2. Open in eADM de betreffende gebruiker en controleer het veld ‘AD-gebruikersnaam ’. Als twee gebruikers dezelfde waarde hebben, corrigeer dan de waarde voor een van hen via de eADM-configuratie of door de regel voor het genereren van gebruikersnamen aan te passen.

3. Als er een verouderd object in AD staat, verwijder dit dan of verplaats het uit de doel-OU en start vervolgens een nieuwe synchronisatiecyclus.

2. Onvoldoende rechten voor het serviceaccount

Het serviceaccount dat eADM gebruikt om verbinding te maken met AD, beschikt niet over de rechten om objecten aan te maken in de doel-OU, of heeft geen schrijftoegang tot een of meer attributen die tijdens het aanmaken worden ingesteld.

Veelvoorkomende oorzaken:

• Het serviceaccount beschikt niet over de machtiging ‘Child Objects aanmaken ’ voor de doel-OU.

• Het serviceaccount beschikt niet over schrijfrechten voor bepaalde attributen, zoals proxyAddresses, managerof employeeNumber.

• De OU-structuur is gewijzigd nadat de oorspronkelijke delegatie was geconfigureerd, en de machtigingen van het serviceaccount gelden niet langer voor de nieuwe doel-OU.

Oplossing: Controleer de gedelegeerde machtigingen voor de betreffende OU in AD. Zorg ervoor dat het eADM-serviceaccount minimaal beschikt over:

• Maak gebruikersobjecten aan en verwijder deze in de doel-OU.

• Schrijftoegang tot alle attributen die in de eADM-exporttemplaat voor dat gebruikerstype zijn geconfigureerd.

Neem contact op met de AD-beheerder van de klant om de gedelegeerde rechten aan te passen. Verleen geen domeinbeheerdersrechten aan het eADM-serviceaccount.

3. Niet voldaan aan de vereisten inzake wachtwoordcomplexiteit

Als eADM zo is geconfigureerd dat er bij het aanmaken van een nieuw account een wachtwoord moet worden ingesteld, zal AD het aanmaken weigeren als het wachtwoord niet voldoet aan het wachtwoordbeleid van het domein — met inbegrip van vereisten inzake minimale lengte, complexiteit of wachtwoordgeschiedenis.

Oplossing: Controleer het standaardwachtwoord dat in de eADM-exportsjabloon is geconfigureerd en vergelijk dit met het gedetailleerde wachtwoordbeleid van het domein (indien van toepassing) of het standaarddomeinbeleid. Het wachtwoord dat door eADM bij het aanmaken van het account is ingesteld, moet aan alle beleidsvereisten voldoen.

4. Ongeldige gegevens of schemaovertreding

eADM probeert een waarde te schrijven naar een AD-attribuut die volgens het schema niet is toegestaan voor dat domein — bijvoorbeeld een waarde met het verkeerde gegevenstype, een waarde die niet-ondersteunde tekens bevat, of een ontbrekend verplicht attribuut.

Veelvoorkomende oorzaken:

• De sAMAccountName bevat tekens die door AD niet zijn toegestaan (bijvoorbeeld spaties, schuine strepen of speciale tekens).

• Een verplicht AD-attribuut dat door een schema-uitbreiding wordt vereist, is niet toegewezen in de eADM-exporttemplaate.

• De manager het attribuut verwijst naar een DN die niet in AD voorkomt, zoals blijkt uit An invalid dn syntax has been specified in het logboek.

• De Bovenliggende pad (parentPath) die in het eADM-exportsjabloon voor actieve gebruikers is geconfigureerd, is onjuist of ontbreekt voor de betreffende gebruiker, waardoor een ongeldige doel-DN ontstaat.

• De gebruiker wordt aangemaakt met een CN een waarde die niet geldig is in AD, bijvoorbeeld omdat deze tekens bevat die AD niet toestaat in een Relative Distinguished Name.

• Een numeriek veld in het exportsjabloon stuurt een tekenreekswaarde.

Oplossing: Zoek in het logboek de laatste attribuutregel die vóór de fout is geschreven. Controleer de waarde die voor dat attribuut is ingesteld in het eADM-exportsjabloon en de brongegevens uit HR. Corrigeer ofwel de gegevenstoewijzing in eADM, ofwel de bronwaarde in het HR-systeem, en start vervolgens een nieuwe synchronisatie.

5. Netwerk- of verbindingsstoring met de AD-agent

De eADM-cloudservice kan geen verbinding maken met de lokale eADM-client op locatie, of de lokale client kan geen verbinding maken met de AD-domeincontroller. In dat geval worden er geen logboekvermeldingen bijgeschreven voor de betreffende synchronisatiecyclus, of wordt in het logboek een time-out of verbindingsfout weergegeven in plaats van een AD-specifieke foutcode.

Besluit:

1. Controleer of de lokale eADM-clientdienst of de geplande taak op de on-premises-server actief is.

2. Controleer of uitgaand HTTPS-verkeer (poort 443) van de server naar het eADM-cloud-eindpunt is toegestaan.

3. Controleer of de server de AD-domeincontroller kan bereiken via de vereiste LDAP-poort (389 of 636).

4. Controleer de Windows-gebeurtenisviewer op de server op verbindings- of servicefouten.

6. Dubbelzinnige overeenkomst — dezelfde waarde voor het mergeattribute bij twee AD-accounts

Als twee AD-accounts al dezelfde waarde hebben in het geconfigureerde mergeattribute, kan eADM niet eenduidig vaststellen welk account overeenkomt met de gebruiker voor wie de provisioning plaatsvindt. Afhankelijk van de situatie kan dit ertoe leiden dat de aanmaakbewerking wordt geblokkeerd of dat eADM het verkeerde account bijwerkt in plaats van een nieuw account aan te maken.

Dit kan gebeuren wanneer:

• De waarde van het mergeattribute is handmatig ingesteld voor een AD-account, buiten het provisioningproces van eADM om.

• Een overgebleven AD-account uit een eerdere dienstperiode is nog steeds hetzelfde employeeID of employeeNumber als nieuwe medewerker.

• Twee HR-records hebben hetzelfde employeeID of employeeNumber als gevolg van een invoerfout in het bron-HR-systeem.

• Een AD-account is gemigreerd of uit een back-up hersteld met een verouderde waarde voor het `mergeattribute`-attribuut, dat inmiddels in HR aan een andere medewerker is toegewezen.

Besluit:

1. Zoek in AD naar alle accounts met de waarde van het mergeattribute die in het eADM-logboek of het gebruikersrecord wordt weergegeven, bijvoorbeeld: Get-ADUser -Filter {employeeID -eq "value"} -Properties employeeID.

2. Controleer welk account het juiste, actuele equivalent is van het HR-record. Wis of corrigeer de waarde van het mergeattribute bij elk ander account dat ten onrechte dezelfde waarde heeft.

3. Herstel de betreffende gebruikers in eADM, zodat de koppelingen naar de bijbehorende gebruikers in AD worden gecorrigeerd.

7. De waarde van het attribuut ‘Merge’ op een bestaand account komt overeen met een andere gebruiker

In tegenstelling tot oorzaak 6 is hier slechts één AD-account bij betrokken — maar de waarde van het `mergeattribute` komt toevallig overeen met de identificatiecode van een andere persoon, meestal iemand voor wie net een account wordt aangemaakt. eADM identificeert dit ene bestaande account als een betrouwbare overeenkomst en werkt het bij, in plaats van een nieuw account voor de nieuwe gebruiker aan te maken. Vanuit het perspectief van eADM is er geen onduidelijkheid, dus dit levert doorgaans helemaal geen foutmelding op: de synchronisatie lijkt te slagen, maar uiteindelijk wordt de verkeerde persoon aan het account gekoppeld.

Dit kan gebeuren wanneer:

• Het HR-systeem hergebruikt personeelsnummers nadat een medewerker het bedrijf heeft verlaten, en aan een nieuwe medewerker wordt later hetzelfde nummer toegewezen dat nog steeds gekoppeld is aan het verouderde AD-account van de voormalige medewerker.

• Iemand heeft handmatig de verkeerde gegevens ingevoerd employeeID of employeeNumber waarde van een bestaand AD-account, en die waarde komt toevallig overeen met de daadwerkelijke identificatiecode van een andere medewerker.

• Door een gegevensmigratie of -herstel is er een verouderde waarde voor het mergeattribute achtergebleven op een account dat HR inmiddels aan een andere persoon heeft toegewezen.

Besluit:

1. Geef in eADM aan met welk bestaand AD-account het record van de nieuwe gebruiker is gekoppeld en bijgewerkt, in plaats van dat er een nieuw account wordt aangemaakt.

2. Ga na aan wie dat AD-account daadwerkelijk toebehoort en wat de juiste waarde van het `mergeattribute`-attribuut voor beide betrokken personen zou moeten zijn.

3. Pas de waarde van het mergeattribute aan bij het verkeerd gekoppelde AD-account, zodat deze de daadwerkelijke eigenaar weergeeft, waardoor de waarde weer beschikbaar komt voor de juiste persoon.

4. Herstel de betreffende gebruikers in eADM, zodat de koppelingen naar de bijbehorende gebruikers in AD worden gecorrigeerd.

Diagnostische checklist

Gerelateerde artikelen

• Problemen met System.ServiceModel.FaultException oplossen in de logbestanden van de lokale eADM-client

• Gebruikersgegevens bijwerken in eADM

Laatst bijgewerkt: 31 juli 2026