Felsökning: Användaren har inte skapats i Active Directory av eADM

Den här artikeln beskriver de vanligaste orsakerna till att eADM inte lyckas skapa ett användarkonto i Active Directory (AD) och innehåller steg för att identifiera och åtgärda varje orsak. Den riktar sig till eADM-administratörer och IT-partner som hanterar lokala AD-integrationer.

Så här läser du eADM:s AD-exportlogg

Den lokala eADM-klienten skapar en detaljerad logg för varje exportåtgärd. Denna logg är det främsta diagnostiska verktyget när ett användarkonto inte skapas i AD.

Loggfilerna kan laddas ner via Synkronisering->Status->Mer->Ladda ner eADM Client-logg. Alternativt finns den vanligtvis i C:\eADM\ eller en undermapp som konfigurerats under installationen. Varje post följer följande mönster:

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

Vid en lyckad skapningsoperation loggas varje attribut som anges, följt av en rad som anger att inga fel har uppstått. Vid en misslyckad skapningsoperation loggas attributsekvensen och därefter avslutas med en felkod och ett felmeddelande. Exempel på en misslyckad skapning från ett känt supportärende:

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.

Felrader följer följande format ERROR_CODE|Error message text. Felkoden och felmeddelandet tillsammans anger orsaken. Notera den sista raden med attribut som lyckades innan felet uppstod – detta hjälper dig att avgränsa var i AD som åtgärden avvisades.

Vanliga orsaker och lösningar

1. Dubblett – användaren finns redan i AD

eADM försöker skapa ett objekt med ett distinkt namn (DN) eller med ett sAMAccountName som redan finns i AD. AD avvisar åtgärden med ett felmeddelande av typen The object already exists.

Detta kan inträffa när:

• Två anställda delar samma genererade sAMAccountName (t.ex. båda leder till 1001on).

• Ett tidigare raderat användarkonto har inte tagits bort helt från AD, och det finns fortfarande kvar en ”tombstone” eller ett återanvänt objekt.

• Användaren skapades manuellt i AD innan eADM försökte genomföra tilldelningen.

• Två användare har samma födelsedatum, vilket orsakar en konflikt i en regel för generering av användarnamn baserad på datum.

Beslut:

1. Sök i annonserna efter sAMAccountName eller det CN-nummer som anges i loggen för att identifiera det objekt som orsakar konflikten.

2. Öppna den berörda användaren i eADM och kontrollera fältet ”AD-användarnamn ”. Om två användare har samma värde ska du korrigera värdet för en av dem via eADM-konfigurationen eller genom att justera regeln för generering av användarnamn.

3. Om det finns ett inaktuellt objekt i AD ska du ta bort det eller flytta det från målorganisationsenheten (OU) och därefter starta en ny synkroniseringscykel.

2. Otillräckliga behörigheter för tjänstekontot

Det servicekonto som eADM använder för att ansluta till AD saknar behörighet att skapa objekt i målorganisationsenheten (OU), eller saknar skrivbehörighet till ett eller flera attribut som anges vid skapandet.

Vanliga orsaker:

• Servicekontot har inte behörigheten ”Skapa underordnade objekt” för målorganisationsenheten.

• Servicekontot saknar skrivbehörighet för vissa attribut, till exempel proxyAddresses, manager, eller employeeNumber.

• OU-strukturen ändrades efter att den ursprungliga delegeringen hade konfigurerats, och tjänstekontots behörigheter omfattar inte längre den nya mål-OU:n.

Lösning: Granska de delegerade behörigheterna för målorganisationsenheten (OU) i AD. Se till att eADM-tjänstekontot åtminstone har följande:

• Skapa och ta bort användarobjekt i målorganisationsenheten.

• Skrivbehörighet till alla attribut som har konfigurerats i eADM-exportmallen för den användartypen.

Kontakta kundens AD-administratör för att justera de delegerade behörigheterna. Bevilja inte behörigheter som domänadministratör till eADM-tjänstekontot.

3. Kraven på lösenordets komplexitet är inte uppfyllda

Om eADM är konfigurerat så att ett lösenord måste anges vid skapandet av ett nytt konto kommer AD att avvisa skapandet om lösenordet inte uppfyller domänens lösenordspolicy – inklusive krav på minsta längd, komplexitetsregler eller krav på lösenordshistorik.

Lösning: Granska det standardlösenord som har konfigurerats i eADM-exportmallen och jämför det med domänens detaljerade lösenordspolicy (om sådan finns) eller standarddomänpolicyn. Det lösenord som eADM anger vid skapandet av kontot måste uppfylla alla policykrav.

4. Ogiltiga data eller brott mot schemat

eADM försöker skriva in ett värde i ett AD-attribut som schemat inte tillåter för den domänen – till exempel ett värde av fel datatyp, ett värde som innehåller tecken som inte stöds eller ett obligatoriskt attribut som saknas.

Vanliga orsaker:

• Den sAMAccountName innehåller tecken som inte är tillåtna enligt AD (t.ex. mellanslag, snedstreck eller utökade tecken).

• Ett obligatoriskt AD-attribut som krävs enligt en schemautvidgning är inte mappat i eADM-exportmallen.

• Den manager attributet hänvisar till ett DN som inte finns i AD, vilket framgår av An invalid dn syntax has been specified i loggen.

• Den Överordnad sökväg (parentPath) som har konfigurerats i eADM-exportmallen för aktiva användare är felaktig eller saknas för den berörda användaren, vilket resulterar i ett ogiltigt mål-DN.

• Användaren skapas med en CN ett värde som inte är giltigt i AD, till exempel ett värde som innehåller tecken som AD inte tillåter i ett relativt distinkt namn.

• Ett numeriskt fält i exportmallen skickar ett strängvärde.

Lösning: Identifiera den sista attributraden som skrevs till loggen före felet. Granska det värde som anges för det attributet i eADM-exportmallen och källdata från HR. Korrigera antingen datamappningen i eADM eller källvärdet i HR-systemet och starta sedan en ny synkronisering.

5. Nätverks- eller anslutningsfel till AD-agenten

Molntjänsten eADM kan inte nå den lokala eADM-klienten på plats, eller så kan den lokala klienten inte nå AD-domänkontrollern. I detta fall skrivs inga loggposter för den berörda synkroniseringscykeln, eller så visar loggen ett tidsöverskridande eller ett anslutningsfel istället för en AD-specifik felkod.

Beslut:

1. Kontrollera att den lokala eADM-klienttjänsten eller det schemalagda uppdraget körs på den lokala servern.

2. Kontrollera att utgående HTTPS-trafik (port 443) är tillåten från servern till eADM-molnets slutpunkt.

3. Kontrollera att servern kan nå AD-domänkontrollanten via den önskade LDAP-porten (389 eller 636).

4. Kontrollera Windows Händelsevisare på servern för att se om det finns anslutnings- eller tjänstefel.

6. Tvetydig matchning – samma värde för mergeattribute som delas av två AD-konton

Om två AD-konton redan har samma värde i det konfigurerade mergeattributet kan eADM inte entydigt avgöra vilket konto som motsvarar den användare som ska tilldelas behörigheter. Beroende på situationen kan detta antingen blockera skapningsåtgärden eller leda till att eADM uppdaterar fel konto istället för att skapa ett nytt.

Detta kan inträffa när:

• Värdet för attributet ”merge” angavs manuellt för ett AD-konto utanför eADM:s tilldelningsprocess.

• Ett AD-konto som finns kvar från en tidigare anställningsperiod har fortfarande samma employeeID eller employeeNumber som nyanställd.

• Två HR-poster har samma employeeID eller employeeNumber på grund av ett inmatningsfel i källsystemet för personaladministration.

• Ett AD-konto har migrerats eller återställts från en säkerhetskopia med ett föråldrat värde för attributet ”merge”, som sedan dess har tilldelats en annan anställd i HR.

Beslut:

1. Sök i AD efter alla konton som har det värde för mergeattribute som visas i eADM-loggen eller användarpost, till exempel: Get-ADUser -Filter {employeeID -eq "value"} -Properties employeeID.

2. Kontrollera vilket konto som är det rätta och aktuella motsvarigheten till HR-posten. Rensa eller korrigera värdet för ”mergeattribute” på alla andra konton som felaktigt har samma värde.

3. Återställ de berörda användarna i eADM så att kopplingarna till motsvarande användare i AD korrigeras.

7. Värdet för attributet ”Merge” på ett befintligt konto stämmer överens med en annan användare

Till skillnad från orsak 6 är endast ett AD-konto inblandat här – men värdet för dess mergeattribute råkar stämma överens med identifieraren för en annan person, oftast någon som just håller på att tilldelas behörigheter. eADM identifierar detta enda befintliga konto som en säker träff och uppdaterar det, istället för att skapa ett nytt konto för den nya användaren. Ur eADM:s perspektiv föreligger ingen tvetydighet, så detta ger vanligtvis inte upphov till något fel alls: synkroniseringen verkar lyckas, men fel person kopplas till slut till kontot.

Detta kan inträffa när:

• HR-systemet återanvänder personalnummer efter att en anställd har slutat, och en nyanställd tilldelas senare samma nummer som fortfarande finns kvar på den tidigare anställdes inaktiva AD-konto.

• Någon har manuellt angett fel employeeID eller employeeNumber värdet på ett befintligt AD-konto, och det värdet råkar sammanfalla med en annan medarbetares faktiska identifierare.

• En datamigrering eller återställning har lett till att ett föråldrat värde för attributet ”mergeattribute” finns kvar på ett konto som HR sedan dess har tilldelat en annan person.

Beslut:

1. I eADM ska du identifiera vilket befintligt AD-konto den nya användarens uppgifter har matchats mot och uppdaterats utifrån, istället för att ett nytt konto skapas.

2. Kontrollera vem det aktuella AD-kontot egentligen tillhör och vilket värde för ”mergeattribute” som är korrekt för båda de berörda personerna.

3. Korrigera värdet för ”mergeattribute” på det felaktigt kopplade AD-kontot så att det återspeglar dess faktiska ägare, vilket frigör värdet för rätt person.

4. Återställ de berörda användarna i eADM så att kopplingarna till motsvarande användare i AD korrigeras.

Diagnostisk checklista

Relaterade artiklar

• Felsökning av System.ServiceModel.FaultException i eADM:s lokala klientloggar

• Uppdatering av användardata i eADM

Senast uppdaterad: 31 juli 2026