Fejlfinding: Bruger er ikke oprettet i Active Directory via eADM

Denne artikel beskriver de mest almindelige årsager til, at eADM ikke kan oprette en brugerkonto i Active Directory (AD), og indeholder trin til at identificere og løse de enkelte årsager. Den er rettet mod eADM-administratorer og IT-partnere, der administrerer lokale AD-integrationer.

Sådan læser du eADM AD-eksportloggen

Den lokale eADM-klient genererer en detaljeret logfil for hver eksportoperation. Denne logfil er det primære diagnostiske værktøj, når en brugerkonto ikke oprettes i AD.

Logfiler kan downloades via Synkronisering->Status->Mere->Download eADM Client-log. Alternativt findes den normalt i C:\eADM\ eller en undermappe, der er konfigureret under installationen. Hver post følger dette mønster:

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

Ved en vellykket »Create«-operation logges hver enkelt attribut, der indstilles, efterfulgt af en linje uden fejl. Ved en mislykket »Create«-operation logges attributsekvensen, hvorefter operationen afsluttes med en fejlkode og en fejlmeddelelse. Eksempel på en mislykket oprettelse fra en kendt supportsag:

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.

Fejllinjer følger dette format ERROR_CODE|Error message text. Fejlkoden og fejlmeddelelsen angiver tilsammen årsagen. Læg mærke til den sidste linje med en vellykket attribut før fejlen — dette indsnævrer, hvor i AD operationen blev afvist.

Almindelige årsager og løsninger

1. Dobbelt objekt — brugeren findes allerede i AD

eADM forsøger at oprette et objekt med et Distinguished Name (DN) eller med et sAMAccountName der allerede findes i AD. AD afviser handlingen med en fejlmeddelelse som f.eks. The object already exists.

Dette kan forekomme, når:

• To medarbejdere deler den samme genererede sAMAccountName (f.eks. begge beslutter sig for at 1001on).

• En tidligere slettet brugerkonto blev ikke fuldstændigt fjernet fra AD, og der findes stadig en »tombstone« eller et genbrugsobjekt.

• Brugeren blev oprettet manuelt i AD, før eADM forsøgte at foretage provisionering.

• To brugere har samme fødselsdato, hvilket medfører en konflikt i en regel for generering af brugernavne baseret på dato.

Beslutning:

1. Søg i AD efter sAMAccountName eller CN-koden, der fremgår af loggen, for at identificere det objekt, der forårsager konflikten.

2. I eADM skal du åbne den berørte bruger og kontrollere feltet »AD-brugernavn «. Hvis to brugere har samme værdi, skal du rette værdien for den ene af dem via eADM-konfigurationen eller ved at justere reglen for generering af brugernavne.

3. Hvis der findes et forældet objekt i AD, skal du fjerne det eller flytte det ud af målorganisationsenheden (OU) og derefter udløse en ny synkroniseringscyklus.

2. Utilstrækkelige rettigheder på servicekontoen

Den servicekonto, som eADM bruger til at oprette forbindelse til AD, har ikke rettigheder til at oprette objekter i målorganisationsenheden (OU), eller den mangler skriveadgang til et eller flere attributter, der angives under oprettelsen.

Almindelige årsager:

• Servicekontoen har ikke tilladelse til at oprette underordnede objekter i målorganisationsenheden.

• Servicekontoen har ikke skrivetilladelse til bestemte attributter, såsom proxyAddresses, manager, eller employeeNumber.

• OU-strukturen blev ændret, efter at den oprindelige delegering var blevet konfigureret, og servicekontos tilladelser dækker ikke længere den nye mål-OU.

Løsning: Gennemgå de delegerede tilladelser i den pågældende organisationsenhed (OU) i AD. Sørg for, at eADM-servicekontoen som minimum har:

• Opret og slet brugerobjekter i målorganisationsenheden.

• Skriveadgang til alle attributter, der er konfigureret i eADM-eksportskabelonen for den pågældende brugertype.

Kontakt kundens AD-administrator for at justere de delegerede rettigheder. Tildel ikke domæneadministratorrettigheder til eADM-servicekontoen.

3. Kravene til adgangskodens kompleksitet er ikke opfyldt

Hvis eADM er konfigureret til at kræve indtastning af en adgangskode ved oprettelse af en ny konto, vil AD afvise oprettelsen, hvis adgangskoden ikke overholder domænets adgangskodepolitik — herunder krav til minimumslængde, kompleksitet eller adgangskodehistorik.

Løsning: Gennemgå den standardadgangskode, der er konfigureret i eADM-eksportskabelonen, og sammenlign den med domænets detaljerede adgangskodepolitik (hvis relevant) eller standarddomænepolitikken. Den adgangskode, som eADM angiver ved oprettelsen af kontoen, skal opfylde alle krav i politikken.

4. Ugyldige data eller overtrædelse af skemaet

eADM forsøger at skrive en værdi til en AD-attribut, som skemaet ikke tillader for det pågældende domæne — for eksempel en værdi af den forkerte datatype, en værdi, der indeholder tegn, der ikke understøttes, eller en obligatorisk attribut, der mangler.

Almindelige årsager:

• Den sAMAccountName indeholder tegn, der ikke er tilladt i AD (f.eks. mellemrum, skråstreger eller udvidede tegn).

• Et obligatorisk AD-attribut, der kræves af en skemaudvidelse, er ikke kortlagt i eADM-eksportskabelonen.

• Den manager attributten henviser til et DN, der ikke findes i AD, som det fremgår af An invalid dn syntax has been specified i loggen.

• Den Overordnet sti (parentPath) som er konfigureret i eADM-eksportskabelonen for aktive brugere, er forkert eller mangler for den pågældende bruger, hvilket resulterer i et ugyldigt mål-DN.

• Brugeren oprettes med en CN en værdi, der ikke er gyldig i AD, f.eks. en værdi, der indeholder tegn, som AD ikke tillader i et relativt distinkt navn.

• Et numerisk felt i eksportskabelonen sender en strengværdi.

Løsning: Find den sidste attributlinje, der blev skrevet til loggen umiddelbart før fejlen. Kontroller den værdi, der er angivet for dette attribut i eADM-eksportskabelonen, samt kildedataene fra HR. Ret enten datamappingen i eADM eller kildeværdien i HR-systemet, og udløs derefter en ny synkronisering.

5. Netværks- eller forbindelsesfejl til AD-agenten

eADM-skytjenesten kan ikke oprette forbindelse til den lokale eADM-klient på stedet, eller den lokale klient kan ikke oprette forbindelse til AD-domænecontrolleren. I dette tilfælde skrives der ingen logposter for den berørte synkroniseringscyklus, eller loggen viser en timeout- eller forbindelsesfejl i stedet for en AD-specifik fejlkode.

Beslutning:

1. Kontroller, at den lokale eADM-klienttjeneste eller den planlagte opgave kører på den lokale server.

2. Kontroller, at udgående HTTPS-trafik (port 443) er tilladt fra serveren til eADM-cloud-endpointet.

3. Kontroller, at serveren kan oprette forbindelse til AD-domænecontrolleren på den påkrævede LDAP-port (389 eller 636).

4. Kontroller Windows-hændelsesviseren på serveren for fejl vedrørende forbindelsen eller tjenesterne.

6. Tvetydigt match — to AD-konti har samme værdi for mergeattribute

Hvis to AD-konti allerede har samme værdi i det konfigurerede mergeattribute, kan eADM ikke entydigt fastslå, hvilken konto der svarer til den bruger, der skal oprettes. Afhængigt af situationen kan dette enten forhindre oprettelsen eller medføre, at eADM opdaterer den forkerte konto i stedet for at oprette en ny.

Dette kan forekomme, når:

• Værdien for mergeattribute blev indstillet manuelt på en AD-konto uden for eADM’s provisioneringsproces.

• En AD-konto, der er tilbage fra en tidligere ansættelsesperiode, har stadig de samme employeeID eller employeeNumber som nyansat.

• To HR-poster har samme medarbejder-ID eller medarbejdernummer på grund af en fejl ved indtastningen i det oprindelige HR-system.

• En AD-konto er blevet migreret eller gendannet fra en sikkerhedskopi med en forældet »mergeattribute«-værdi, som sidenhen er blevet tildelt en anden medarbejder i HR.

Beslutning:

1. Søg i AD efter alle konti, der har den værdi for »mergeattribute«, der vises i eADM-loggen eller brugeroplysningerne, for eksempel: Get-ADUser -Filter {employeeID -eq "value"} -Properties employeeID.

2. Bekræft, hvilken konto der er den korrekte og aktuelle modstykke til HR-posten. Slet eller ret værdien for »mergeattribute« på alle andre konti, der fejlagtigt har den samme værdi.

3. Gendan de berørte brugere i eADM, så sammenkædningerne til de tilsvarende brugere i AD bliver rettet.

7. Værdien af attributten »Merge« på en eksisterende konto stemmer overens med en anden bruger

I modsætning til årsag 6 er der her kun tale om én AD-konto — men værdien af dens »mergeattribute« stemmer tilfældigvis overens med identifikatoren for en anden person, som regel en, der netop er ved at blive oprettet. eADM identificerer denne ene eksisterende konto som et sikkert match og opdaterer den i stedet for at oprette en ny konto til den nye bruger. Set fra eADM’s perspektiv er der ingen tvetydighed, så dette medfører typisk slet ingen fejl: synkroniseringen ser ud til at lykkes, men den forkerte person ender med at blive knyttet til kontoen.

Dette kan forekomme, når:

• HR-systemet genbruger medarbejdernumre, når en medarbejder fratræder, og en nyansat tildeles senere det samme nummer, som stadig er knyttet til den tidligere medarbejders inaktive AD-konto.

• Nogen har manuelt indtastet det forkerte employeeID eller employeeNumber en værdi på en eksisterende AD-konto, og denne værdi falder tilfældigvis sammen med en anden medarbejders faktiske identifikator.

• En dataoverførsel eller -gendannelse har efterladt en forældet værdi for attributten »mergeattribute« på en konto, som HR sidenhen har tildelt en anden person.

Beslutning:

1. I eADM skal du angive, hvilken eksisterende AD-konto den nye brugers oplysninger er blevet matchet med og opdateret i forhold til, i stedet for at der oprettes en ny konto.

2. Bekræft, hvem den pågældende AD-konto rent faktisk tilhører, og hvad den korrekte værdi for »mergeattribute« bør være for begge de involverede personer.

3. Ret værdien for »mergeattribute« på den AD-konto, der er blevet fejlagtigt matchet, så den afspejler den faktiske ejer, og frigør dermed værdien til den rette person.

4. Gendan de berørte brugere i eADM, så sammenkædningerne til de tilsvarende brugere i AD bliver rettet.

Diagnostisk tjekliste

Relaterede artikler

• Fejlfinding af System.ServiceModel.FaultException i eADM-lokale klientlogfiler

• Opdatering af brugerdata i eADM

Senest opdateret: 27. juli 2026