Käyttäjähallinta AD:sta Azure AD:hen

Aapo Kettunen

Centeron asiantuntija-Aapo (aka. Aapo Kettunen) toteutti vastikään projektin asiakkaallemme Fida International ry:lle, jonka tarkoituksena oli siirtää Active Directory:n hallinnan painopistettä omasta ympäristöstä pilven puolelle, eli Azure AD:n puolelle.

Fidalla oli erityinen tarve mahdollistaa salasanan palauttaminen itsepalveluna henkilöille, jotka eivät ole varsinaisessa työsuhteessa järjestöön. Siten heillä ei ollut myöskään EMS-lisenssiä, joka toimenpiteeseen vaaditaan, jos salasana halutaan kirjoittaa takaisin on-premises AD:hen (password writeback). Toimenpide säästi asiakkaan kustannuksia ja helpotti käyttäjien elämää.

  • Lue laajempi asiakastarina Fidasta.
  • Lue myös Ilta-Sanomien Digitodayn (IT-Viikko) artikkeli Fidan palveluiden siirrosta Azureen.

Monilla on käytössä Office 365 ympäristössä, jossa käyttäjien hallinta tehdään omassa on-premises-Active Directory:ssä, josta tieto synkronoidaan Office 365 -ympäristöön (eli Azure Active Directory:yn). Joskus voi tulla tarve siirtää kaikki tai osa paikallisesta Active Directory:sta Office 365:een synkronoiduista käyttäjistä kokonaan pilvikäyttäjiksi.

Tällainen tarve voi tulla, kun osalla käyttäjistä ei ole enää tarvetta AD-tilille, ja kyseisten tunnusten hallinta halutaan siirtää Office 365:een. Tämä voi myös olla yksi vaihe kohti siirtymistä täysin pilvipohjaiseen infraan, joka tarkoittaa perinteisestä on-premises AD:sta luopumista ja toimintojen siirtämistä Azure AD:hen.

Toimenpiteenä tämä ei ole vaikea, kunhan tietää mitä tekee. Tässä blogissa kuvattuprosessi on tehty uusinta Azure AD Connect -työkalua käyttäen, joten tiedostojen sijainnit sekä komennot voivat poiketa aiemmista versioista. Komennot ja toimenpiteet käyttäjäobjektin palautusta Office 365:n roskakorista lukuun ottamatta tulee tehdä palvelimella, jonne Azure AD Connect on asennettu.

Siirrossa käyttäjien salasanat resetoidaan, mutta muuta muutosta loppukäyttäjälle ei siirrosta tule. Koska tilit joudutaan poistamaan O365:stä hetkellisesti, aiheutuu tästä loppukäyttäjälle sähköpostin käyttökatko, joten käyttäjiä on hyvä informoida asiasta myös yleisesti – salasanan vaihtumisen lisäksi.

Aluksi paikalliseen Active Directoryyn luodaan uusi OU (Organizational Unit), johon siirretään käyttäjät, joita halutaan hallita jatkossa Office 365:ssä. Tämä OU voi olla väliaikainen, ja se sekä sinne siirretyt käyttäjät voidaan poistaa muutoksen jälkeen.

Siirrettävien käyttäjien suodatus pois synkronoinnista voidaan tehdä myös AD-attribuutteja käyttämällä. Lisätietoa tästä toimintatavasta löytyy Microsoftin sivuilta.

Ennen synkronointiasetuksiin tehtäviä muutoksia pitää automaattinen synkronointi ottaa pois käytöstä Powershell-komennolla:

Set-ADSyncScheduler -SyncCycleEnabled $False

Riippuen luodusta OU:sta sekä nykyisistä konfiguraatioista, synkronoinnin määrityksiä muutetaan Synchronization Service -työkalulla, vanhemmissa DirSync-versioissa MIISClient:sta (C:\Program Files\Microsoft Azure AD Sync\UIShell\miisclient.exe). Muutokset tehdään Connectors-välilehdeltä paikallisen AD:n Properties-ikkunasta, Configure Directory Partitions -sivulta Containers-kohdasta. Avautuvassa ikkunassa poistetaan valinta luodutusta OU:sta. Mikäli aiemmin luotu OU tehtiin sijaintiin, jota ei muutenkaan synkronoitu, niin tätä ei tarvitse tehdä.

Kun haluttu OU on suodatettu pois käytöstä, niin suoritetaan täysi synkronointi manuaalisesti Powershellin kautta:

Import-Module ADSync
Start-ADSyncSyncCycle -PolicyType Initial

Synkronoinnin edistymistä voi seurata MIISClient:sta Operations-välilehdeltä. Kun synkronointi on mennyt kokonaan läpi, kyseisen OU:n käyttäjät siirtyvät O365:n roskakoriin. Mikäli siirrettäviä käyttäjiä on vähän, ne voidaan palauttaa Office 365 -hallintaportaalista. Käyttäjän palauttaminen vaatii hallintaportaalin kautta tehtyä salasanan resetointia heti palautusvaiheessa. Powershellin kautta palautus voidaan tehdä ilman välitöntä salasanan resetointia, mutta tunnusten käyttäminen vaatii salasanan vaihdon.

Mikäli käyttäjiä on useampi, niin palautus ja salasanan resetointi on järkevää tehdä Powershell-komennoilla ja CSV-tiedostolla, joka sisältää käyttäjän UserPrincipalName-tunnuksen sekä salasanan tiedot. Alapuolella esimerkki tällaisesta tiedostosta. Jos käytät ääkkösiä tai erikoismerkkejä salasanassa, niin tallenna tiedosto UTF-8-koodausta käyttäen.

UPN , Password user@centero.fi , Salasana1234 user2@centero.fi , Salasana1234

Itse Powershell-komennot, joilla palautus tehdään, hakee CSV-tiedostosta UPN-tunnuksen sekä ennalta määritetyt salasanat, ja syöttää ne jokaiselle tiedostossa olevalle käyttäjälle erikseen. Komennossa myös nollataan käyttäjän ImmutableId, joka sisältää paikallisesta Active Directorysta saadun ankkuriattribuutin (oletuksena ObjectGUID) muutetussa muodossa.

$Credential = Get-Credential
Import-Module MsOnline
Connect-MsolService -Credential $Credential
$Users = Import-Csv C:\Temp\users.csv
ForEach ($User in $Users) {

Restore-MsolUser -UserPrincipalName $User.UPN
Set-MsolUser -UserPrincipalName $User.UPN -ImmutableId ”$null
Set-MsolUserPassword -UserPrincipalName $User.UPN -NewPassword $User.Password -ForceChangePassword $false

}

Federoiduissa domaineissa käyttäjän UserPrincipalName täytyy vaihtaa toiseen muotoon (esim. <tenant>.onmicrosoft.com päätteiseksi) ennen ImmutableID:n vaihtoa. Tämä johtuu siitä, että federoiduissa domainissa ei voi olla cloud only -tyyppisiä tunnuksia.

Tehtyjen muutosten jälkeen varmista kirjautumisen toimivuus ja kytke automaattinen synkronointi takaisin käyttöön Powershell-komennolla:

Set-ADSyncScheduler -SyncCycleEnabled $True

 

Laske säästösi

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

« Edellinen artikkeli: Webinaari 19.10.: Teknisen tietoturvan minimivaatimukset
» Seuraava artikkeli: DNS-palvelu ja muuta uutta Microsoft Azure:sta