Active Directory -ympäristön tietojen synkronointi Azure AD -palveluun

Azure AD palvelu

azureJos organisaatiossasi on jo käytössä Azure AD -hakemisto ja haaveilet oman sisäisen Active Directory ympäristön tietojen synkronointia Azure AD -palveluun niin lukaiseppa tämä blogi.

Azure AD on siis aina käytössä jos esimerkiksi Office 365 -palvelu on käytössä. Tänne on siis tallennettu kaikki käyttäjät, jotka voivat käyttää Microsoftin pilvipalveluita (Office 365, Microsoft Intune, CRM online jne). Jos organisaatiossa ei ole käytössä synkronointia, pitää kaikki käyttäjät luoda suoraan Azure AD -palveluun.

Azure AD synkronointi

Mikäli organisaatiossa on käytössä myös sisäinen Active Directory, on käyttäjillä olemassa jo siellä tunnukset, ja on toki järkevää pyrkiä käyttämään samaa informaatiota automaattisesti myös Azure AD -hakemistossa. Tämä hakemistojen yhdistäminen tehdään Azure AD Connect (Azure AD sync tai dirsync vanhoilta nimiltään) -työkalulla, joka siis synkronoi omaan sisäiseen Active Directory -hakemistoon tehdyt muutokset automaattisesti Azure AD -palveluun. Tällöin esimerkiksi käyttäjätunnukset tehdään vain yhteen paikkaan eli sisäiseen Active Directoryyn. Synkkaus sitten pitää huolen siitä, että luotu käyttäjätunnus viedään myös Azure AD -palveluun.

Tietojen yhdistäminen

Azure AD Connect on tuotteena helppo asentaa, ja konfiguraatiokin on pienissä organisaatioissa periaatteessa parin perinteisen Next-napin painalluksen takana. Jos organisaatiossa on kuitenkin jo olemassa manuaalisesti luotuja tunnuksia Azure AD -palvelussa, saattaa homma karahtaa kiville. Synkkaustyökalu oletuksena yrittää yhdistää sisäisessä Active Directory -hakemistossa olevia objekteja Azure AD -objekteihin käyttäen userPrincipalName-nimistä attribuuttia. Tämä attribuutti on siis se sähköpostiosoitteen muotoinen käyttäjätunnus sisäisessä Active Directoryssä. Yhdistäminen monesti toimiikin, mikäli käyttäjille on sisäisessä AD:ssa tämä attribuutti määritetty samaksi, kuin käyttäjän sähköpostiosoite. Tätä yhdistämisen attribuuttia voidaan vaihtaa, kun asennetaan Azure AD Connect määrittelemällä kaikki asetukset käsin. Haaste tuleekin siinä että tämä ei olekkaan se ainut yhdistävä tieto, jos Azure AD -palvelussa onkin jo olemassa olevia objekteja.

Mikäs sitten ongelma on?

Synkronointi käyttää olemassa olevien Azure AD -objektien yhdistämiseen aina myös edellisessä kappaleessa mainitun attribuutin lisäksi SMTP-sähköpostiosoitetta. Tätä sanotaan Soft Match -ominaisuudeksi, eikä siihen voi itse vaikuttaa mitenkään. Jälleen ongelmia ei välttämättä tule, mikäli kaikilla Azure AD -palveluun tehdyillä objekteilla (yleensä siis käyttäjiä) on sähköpostiosoite, mutta mitäs jos Azure AD -palvelussa on esimerkiksi käyttäjiä joilla on vain Sharepoint Online, Skype for Business tai CRM Online -lisenssit. Näillä käyttäjillä ei ole sähköpostiosoitetta, koska siihen ei ole lisenssiä, ja näiden käyttäjien osalta synkkaus ei siis toimi, vaan aiheuttaa Azure AD Connect -ohjelmaan hieman hämäävän dublikaattivirheen (Export Error / Attribute Value Must Be Unique / 0x8023134a):

AD-Connect-error

Miten synkkauksen saa toimimaan

Dublikaattivirhe siis johtuu siitä, että yhdistäminen on epäonnistunut kun käyttäjällä ei olekkaan sähköpostiosoitetta. Tämän selvittäminen ei välttämättä ihan heti ratkea, kun tietoja tutkittaessa ne attribuutit, joilla Azure AD Connect on määritetty yhdistämistä tekemään, eivät sisällä dublikaatteja. Jotta homma saadaan toimimaan, niin objekteille joilla ei ole sähköpostiosoitetta Azure AD palvelussa, pitää määrittää käsin linkitys. Tämä ”Hard Match” yhdistäminen tapahtuu määrittämällä Azure AD -objektin tietoihin ImmutableID-arvo. Tämä arvo pitää käsin kaivaa sisäisestä Active Directory -hakemistosta siitä objektista, johon Azure AD objekti halutaan yhdistää. Yleensä arvo mitä tähän ImmutableID-attribuuttiin pitää laittaa, on tekstimuotoinen esitys sisäisen Active Directory objektin ObjectGuid-arvosta. Tämä siis oletuksena. Azure AD Connect voidaan määrittää käyttämään myös eri source anchor -attribuuttia.

Korjauskomento

Helpoiten source anchor -arvon saa tietoon Azure AD Connect sovelluksen historiasta, jossa virheet näkyy. Sieltä voidaan katsoa objektin tiedot jossa synkkaus ei ole onnistunut, ja se näyttää tekstimuodossa tuon ObjectGuid-arvon. Toinen tapa on hakea se AD:sta esimerkiksi PowerShellillä:

  • $ADGuidUser = Get-ADUser -Filter{UserPrincipalName -Eq ”etunimi.sukunimi@yritys.fi”}
  • $ADGuidString = [System.Convert]::ToBase64String($ADGuidUser.ObjectGUID.tobytearray())

Kun tiedetään haluttu source anchor arvo niin se syötetään Azure AD objektiin PowerShell komennolla:

  • set-MsolUser -UserPrincipalName etunimi.sukunimi@yritys.fi -ImmutableId $ADGuidString

Huomaa, että komennot ovat vain esimerkkejä, mutta niistä selviää ajatus miten homma toimii.

Kun muokkaukset on tehty, synkronointi pitäisi onnistua myös objekteille joilla ei ole sähköpostiosoitetta.

Lisää infoa ja ajatuksia, miten miten asian voisi hoitaa jo ennen kuin synkkausta aloitetaan löytyy täältä.

Laske säästösi

Automatisoi sovelluspäivitykset ja lopeta pikkusoftien kanssa painiminen. Centero Software Manager säästää aikaa, rahaa ja hermojasi.

« Edellinen artikkeli: Ongelmia Microsoftin pilvipalveluiden kirjautumisjärjestelmissä
» Seuraava artikkeli: Huomio iPhone- ja iPad-laitteiden käyttäjät