Vianmääritys: eADM ei ole luonut käyttäjää Active Directoryyn

Tässä artikkelissa kuvataan yleisimmät syyt, joiden vuoksi eADM ei onnistu luomaan käyttäjätiliä Active Directoryyn (AD), ja annetaan ohjeet kunkin syyn tunnistamiseen ja korjaamiseen. Artikkeli on tarkoitettu eADM-järjestelmänvalvojille ja IT-kumppaneille, jotka hallinnoivat paikallisia AD-integraatioita.

Kuinka lukea eADM AD -vientilokia

eADM:n paikallinen asiakasohjelma tallentaa yksityiskohtaisen lokitiedoston jokaisesta vientitoiminnosta. Tämä lokitiedosto on tärkein vianmääritystyökalu, kun käyttäjätiliä ei ole luotu AD:hen.

Lokitiedostot voi ladata valitsemalla Synkronointi → Tila → Lisää → Lataa eADM-asiakasohjelman loki. Vaihtoehtoisesti ne löytyvät yleensä kansiosta C:\eADM\ tai asennuksen yhteydessä määritetty alikansio. Jokainen merkintä noudattaa seuraavaa kaavaa:

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

Onnistuneessa Create-operaatiossa kirjataan lokiin jokainen asetettu attribuutti, minkä jälkeen ei tule virheriviä. Epäonnistuneessa Create-operaatiossa kirjataan lokiin attribuuttien järjestys, minkä jälkeen operaatio päättyy virhekoodiin ja virheilmoitukseen. Esimerkki epäonnistuneesta luomisesta tunnetusta tukitapauksesta:

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.

Virherivit noudattavat seuraavaa muotoa ERROR_CODE|Error message text. Virhekoodi ja virheilmoitus yhdessä paljastavat syyn. Kirjoita muistiin viimeinen onnistunut attribuuttirivi ennen virhettä — tämä auttaa rajaamaan, missä vaiheessa AD hylkäsi toiminnon.

Yleisiä syitä ja ratkaisuja

1. Kaksoiskappale — käyttäjä on jo olemassa AD:ssä

eADM yrittää luoda objektin, jolla on erottuva nimi (DN) tai jolla on sAMAccountName joka on jo olemassa AD:ssä. AD hylkää toiminnon ja antaa virheilmoituksen, kuten The object already exists.

Tämä voi tapahtua, kun:

• Kaksi työntekijää jakaa saman luodun sAMAccountName (esim. molemmat johtavat tulokseen 1001on).

• Aiemmin poistettu käyttäjätili ei ole poistettu kokonaan AD:stä, ja siitä on jäljellä tombstone-merkintä tai kierrätetty objekti.

• Käyttäjä luotiin manuaalisesti AD:ssä ennen kuin eADM yritti suorittaa käyttöönoton.

• Kahdella käyttäjällä on sama syntymäpäivä, mikä aiheuttaa ristiriidan päivämäärään perustuvassa käyttäjätunnuksen luontisäännössä.

Päätös:

1. Etsi AD:stä sAMAccountName tai lokissa näkyvä CN, jonka avulla ristiriidassa oleva kohde voidaan tunnistaa.

2. Avaa eADM:ssä kyseinen käyttäjä ja tarkista AD-käyttäjänimi-kenttä. Jos kahdella käyttäjällä on sama arvo, korjaa toisen käyttäjän arvo joko eADM:n asetusten kautta tai muokkaamalla käyttäjänimen luontisääntöä.

3. Jos AD:ssä on vanhentunut objekti, poista se tai siirrä se pois kohde-OU:sta ja käynnistä sitten uusi synkronointikierros.

2. Palvelutilin käyttöoikeudet eivät ole riittävät

Palvelutilillä, jota eADM käyttää yhteyden muodostamiseen AD:hen, ei ole oikeuksia luoda objekteja kohde-OU:ssa tai sillä ei ole kirjoitusoikeutta yhteen tai useampaan attribuuttiin, jotka määritetään luomisen yhteydessä.

Yleisimmät syyt:

• Palvelutilillä ei ole ”Luo aliobjekteja” -oikeutta kohde-OU:ssa.

• Palvelutilillä ei ole kirjoitusoikeutta tiettyihin attribuutteihin, kuten proxyAddresses, manager, tai employeeNumber.

• OU-rakenne muuttui sen jälkeen, kun alkuperäinen valtuutus oli määritetty, eikä palvelutilin käyttöoikeudet enää kata uutta kohde-OU:ta.

Ratkaisu: Tarkista AD:n kohde-OU:ssa olevat delegoidut käyttöoikeudet. Varmista, että eADM-palvelutilillä on vähintään seuraavat oikeudet:

• Luo ja poista käyttäjäobjekteja kohde-OU:ssa.

• Kirjoitusoikeus kaikkiin kyseisen käyttäjätyypin eADM-vientimallissa määritettyihin attribuutteihin.

Ota yhteyttä asiakkaan AD-järjestelmänvalvojaan valtuutettujen käyttöoikeuksien muokkaamiseksi. Älä myönnä eADM-palvelutilille toimialueen järjestelmänvalvojan oikeuksia.

3. Salasanan monimutkaisuusvaatimukset eivät täyty

Jos eADM on määritetty asettamaan salasana uuden tilin luomisen yhteydessä, AD hylkää tilin luomisen, jos salasana ei täytä toimialueen salasanakäytäntöä – mukaan lukien vähimmäispituus, monimutkaisuusvaatimukset tai salasanahistoriaa koskevat vaatimukset.

Ratkaisu: Tarkista eADM-vientimallissa määritetty oletussalasana ja vertaa sitä toimialueen tarkkaan salasanaohjeeseen (jos sellainen on) tai toimialueen oletusohjeeseen. eADM:n tilin luomisen yhteydessä asettaman salasanan on täytettävä kaikki ohjeiden vaatimukset.

4. Virheelliset tiedot tai skeemarikkomus

eADM yrittää kirjoittaa AD-attribuuttiin arvon, jota skeema ei salli kyseiselle toimialueelle — esimerkiksi arvon, jonka tietotyyppi on väärä, arvon, joka sisältää tuettuja merkkejä, tai puuttuvan pakollisen attribuutin.

Yleisimmät syyt:

• The sAMAccountName sisältää merkkejä, joita AD ei salli (esim. välilyöntejä, kauttaviivoja tai laajennettuja merkkejä).

• Schema-laajennuksen edellyttämää pakollista AD-attribuuttia ei ole määritetty eADM-vientimallissa.

• The manager attribuutti viittaa DN:ään, jota ei ole AD:ssä, kuten seuraavasta käy ilmi An invalid dn syntax has been specified lokissa.

• The Yläpolku (parentPath) aktiivisten käyttäjien eADM-vientimallissa määritetty tieto on virheellinen tai puuttuu kyseisen käyttäjän osalta, minkä seurauksena kohde-DN on virheellinen.

• Käyttäjä luodaan käyttämällä CN arvo, joka ei ole AD:ssä sallittu, esimerkiksi sellainen, joka sisältää merkkejä, joita AD ei salli suhteellisessa erottavassa nimessä.

• Vientimallin numeerinen kenttä lähettää merkkijonoarvon.

Ratkaisu: Selvitä, mikä on viimeinen attribuuttirivi, joka on kirjattu lokiin ennen virhettä. Tarkista kyseiselle attribuutille asetettu arvo eADM-vientimallissa sekä HR-järjestelmän lähdetiedoissa. Korjaa joko tietojen kartoitus eADM:ssä tai lähdearvo HR-järjestelmässä ja käynnistä sitten uusi synkronointi.

5. Verkko- tai yhteysongelma AD-agenttiin

eADM-pilvipalvelu ei pääse yhteyteen paikallisen eADM-asiakasohjelman kanssa, tai paikallinen asiakasohjelma ei pääse yhteyteen AD-toimialueen ohjauskoneen kanssa. Tällöin kyseiselle synkronointikierrokselle ei tallenneta lokimerkintöjä, tai lokissa näkyy aikakatkaisu- tai yhteysvirhe AD-kohtaisen virhekoodin sijaan.

Päätös:

1. Varmista, että eADM:n paikallinen asiakaspalvelu tai ajoitettu tehtävä on käynnissä paikallisella palvelimella.

2. Tarkista, että ulospäin suuntautuva HTTPS-liikenne (portti 443) on sallittu palvelimelta eADM-pilvipalvelun päätepisteeseen.

3. Varmista, että palvelin pystyy muodostamaan yhteyden AD-toimialueen ohjauskoneeseen vaaditulla LDAP-portilla (389 tai 636).

4. Tarkista palvelimen Windowsin tapahtumienvalvonnasta, onko siellä yhteys- tai palveluvirheitä.

6. Epäselvä vastaavuus — kahdella AD-tilillä on sama mergeattribute-arvo

Jos kahdella AD-tilillä on jo sama arvo määritetyssä mergeattribute-attribuutissa, eADM ei pysty yksiselitteisesti määrittämään, mikä tili vastaa luotavaa käyttäjää. Tilanteesta riippuen tämä voi joko estää luontitoiminnon tai johtaa siihen, että eADM päivittää väärän tilin uuden tilin luomisen sijaan.

Tämä voi tapahtua, kun:

• Mergeattribute-arvo on määritetty manuaalisesti AD-tilille eADM:n käyttöönottoprosessin ulkopuolella.

• Aiemmasta työsuhteesta jäljelle jäänyt AD-tili on edelleen voimassa employeeID tai employeeNumber uudeksi työntekijäksi.

• Kahdessa henkilöstötietueessa on sama työntekijätunnus (employeeID) tai työntekijänumero (employeeNumber) lähdehenkilöstöjärjestelmässä tapahtuneen tietojen syöttövirheen vuoksi.

• AD-tili on siirretty tai palautettu varmuuskopiosta, ja sen mergeattribute-arvo oli vanhentunut, minkä jälkeen se on myöhemmin määritetty uudelleen toiselle työntekijälle henkilöstöhallinnossa.

Päätös:

1. Etsi AD:stä kaikki tilit, joiden mergeattribute-arvo on sama kuin eADM-lokissa tai käyttäjätietueessa näkyvä arvo, esimerkiksi: Get-ADUser -Filter {employeeID -eq "value"} -Properties employeeID.

2. Varmista, mikä tili vastaa oikein ja ajantasaisesti HR-tietuetta. Poista tai korjaa mergeattribute-arvo kaikista muista tileistä, joilla on virheellisesti sama arvo.

3. Palauta kyseiset käyttäjät eADM-järjestelmään, jotta linkit vastaaviin AD-käyttäjiin korjautuvat.

7. Olemassa olevan tilin Mergeattribute-arvo vastaa toista käyttäjää

Toisin kuin syy 6:ssa, tässä on kyseessä vain yksi AD-tili – mutta sen mergeattribute-arvo sattuu vastaamaan toisen henkilön tunnistetta, yleensä juuri käyttöönotettavan käyttäjän tunnistetta. eADM tunnistaa tämän olemassa olevan tilin luotettavaksi vastaavuudeksi ja päivittää sen sen sijaan, että luo uuden tilin uudelle käyttäjälle. eADM:n näkökulmasta tilanteessa ei ole epäselvyyttä, joten tämä ei yleensä aiheuta lainkaan virhettä: synkronointi näyttää onnistuneen, mutta tilille liitetään lopulta väärä henkilö.

Tämä voi tapahtua, kun:

• HR-järjestelmä käyttää työntekijänumeroita uudelleen työntekijän lähdettyä, ja uudelle työntekijälle annetaan myöhemmin sama numero, joka on edelleen entisen työntekijän vanhentuneella AD-tilillä.

• Joku on syöttänyt virheellisen tiedon manuaalisesti employeeID tai employeeNumber arvo olemassa olevassa AD-tilissä, ja kyseinen arvo sattuu vastaamaan toisen työntekijän todellista tunnistetta.

• Tietojen siirron tai palautuksen seurauksena tilille jäi vanhentunut mergeattribute-arvo, vaikka henkilöstöosasto on sittemmin siirtänyt kyseisen tilin toiselle henkilölle.

Päätös:

1. Määritä eADM-järjestelmässä, mihin olemassa olevaan AD-tiliin uuden käyttäjän tiedot on yhdistetty ja päivitetty, sen sijaan että luotaisiin uusi tili.

2. Varmista, kenelle kyseinen AD-tili tosiasiassa kuuluu, ja mikä on oikea mergeattribute-arvo molemmille osapuolille.

3. Korjaa virheellisesti yhdistettyyn AD-tiliin liitetty mergeattribute-arvo niin, että se vastaa tilin todellista omistajaa, jolloin arvo vapautuu oikealle henkilölle.

4. Palauta kyseiset käyttäjät eADM-järjestelmään, jotta linkit vastaaviin AD-käyttäjiin korjautuvat.

Diagnoosiluettelo

Aiheeseen liittyvät artikkelit

• System.ServiceModel.FaultException -virheen vianmääritys eADM:n paikallisen asiakassovelluksen lokitiedostoissa

• Käyttäjätietojen päivittäminen eADM-järjestelmässä

Viimeksi päivitetty: 31. heinäkuuta 2026