<Ongelma>
Meidän paikallisessa AD:ssa on ulkopuolisille konsulteille luotu tunnukset, jotta he pääsevät kirjautumaan meidän sovelluksiin X ja Y.
Nyt olemme siirtämässä näitä sovelluksia X ja Y SaaS-pohjaisiksi ja otamme niihin käyttöön Azure AD -autentikoinnin meidän Azure AD:ta vasten.
Emme kuitenkaan haluaisi lisensoida Azure AD:ssa meidän ulkopuolisia konsultteja pelkästään siksi, että autentikaatio toimisi heille näihin sovelluksiin X ja Y.
Guest-kutsuminen näille konsulteille meidän Azure AD:hen on myös poissuljettu vaihtoehto, koska kutsuttavia on niin paljon.
Lisäksi jotta pääsee kirjautumaan sovelluksiin X ja Y, pitää tunnuksen domain-osa olla meidän firman domain.
Auttakee!
</Ongelma>
Suurin piirtein tällainen tapaus putosi taikurin hattuun tässä syksyllä. Taikuri siinä tovin pudisti päätään ja oli jo tuomitsemassa koko tilanteen. Onneksi tällä kertaa asiakas oli taikuria valveutuneempi ja osasi ohjata ihmettelemään dokumentointia aiheesta.
Tästä innostuneena taikuri suorastaan vauhkoontui ja alkoi virittelemään omaa demoympäristöään.
<Taikatemppu>
Taustalla pitää toki olla käytössä Azure AD Connect tai Azure AD Cloud Sync, jotta moinen puljaus onnistuu.
Tässä taikatempussa keskitytään Azure AD Connectiin, joka on se yleisimmin käytössä oleva synkka yrityksen paikallisen AD:n ja Azure AD:n välillä.
1.
Avainasemassa on attribuutti nimeltä User type.
Tätä attribuuttia ei lähtökohtaisesti synkronoida paikallisesta AD:sta, vaan se pitää erikseen ottaa käyttöön Azure AD Connectissa.
Nyt on hyvä heti alkuun huomioida, että kun tuo attribuutti otetaan mukaan synkronointiin, pitää meidän jatkossa aina kertoa molemmat tapaukset eli mitkä AD:n tunnukset ovat Membereitä ja mitkä tunnukset Guesteja. Ei riitä, että kerromme pelkästään mitkä tunnukset AD:ssa ovat Guesteja Azure AD:ssa.
Member = Tällaisena synkkautuu kaikki AD-käyttäjät, kun User type -attribuuttia ei synkata. Eli yleisimmin firman oma työntekijä.
Guest = Azure AD:n vieraskäyttäjä.
2.
On päätettävä logiikka, jolla erotellaan Memberit ja Guestit Azure AD Connectille.
Yleisin tapa on ottaa käyttöön jokin sellainen attribuutti, jota ei käytetä mihinkään muuhun tarkoitukseen.
Tällä kertaa attribuutiksi valikoituu AD:ssa käyttäjäobjektin attribuutti: msDS-cloudExtensionAttribute2
Logiikkamme tässä taikatempussa on:
– Jos msDS-cloudExtensionAttribute2-attribuutissa lukee Guest –> Käyttäjätunnus synkronoituu Azure AD:hen Guestina
– Jos msDS-cloudExtensionAttribute2-attribuutissa lukee jotain muuta kuin Guest (esim. tyhjä) –> Käyttäjätunnus synkronoituu Azure AD:hen Memberinä
3.
Kirjoitetaan kaikkien niiden AD-tunnusten msDS-cloudExtensionAttribute2 -attribuuttiin arvo Guest, jotka jatkossa halutaan Azure AD:hen Guesteina.
Tähän ei ole mitään yhtä oikeaa tapaa. Jos tunnuksia on paljon, kannattaa värkkäillä PowerShell-skripti, jolla tuo arvo ajetaan massana.
Yksittäisiin tunnuksiin on helpointa käyttää ADUC:ia (tai jos haluaa ensin testata muutamalla käyttäjällä)
Ja sitten hommiin itse Azure AD Connectin kanssa.
Automaattinen synkka kannattaa ensin ottaa pois päältä, ettei kesken kaiken lähde synkka pyörimään.
Tämä käy ajamalla synkkapalvelimella Powershell-komento:
Set-ADSyncScheduler -SyncCycleEnabled $false
Avataan palvelimella Synchronization Service Manager ja mennään käpistelemään Azure AD:n yhdistintä.
Otetaan synkkaan mukaan attribuutti: User type
Varmistetaan myös, että meidän valittu attribuutti msDS-cloudExtensionAttribute2 on mukana paikallisen AD:n yhdistimessä
Kun tarvittavat attribuutit on otettu synkkaan mukaan, päästään tekemään itse säännöt.
Avataan synkkapalvelimella Synchronization Rules Editor
Luodaan kopio paikallisen AD:n säännöstä In from AD – User Common
Luodaan ensimmäiseksi sääntö, jossa kerrotaan mitkä AD:n käyttäjät synkataan Azure AD:hen Membereinä.
Säännön voi nimetä miten haluaa, tässä se on nimetty In from AD – Internals
Precedence jokin sellainen järjestysnumero, jota ei vielä ole käytössä. Luvun tulee olla väliltä 1-99.
Jos tämä on ensimmäinen custom-sääntösi, kannattaa arvoksi laittaa 1.
Sitten tärkeä osuus eli säännölle määritellään Scope johon sääntö osuu.
Aikaisemmin päätimme, että haluamme Membereiksi Azure AD:hen kaikki sellaiset joilla
msDS-cloudExtensionAttribute2-attribuutissa lukee jotain muuta kuin Guest (esim. tyhjä)
Laitetaan tämä säännön Scopeen.
Eli nyt tämä sääntö tulee osumaan vain niihin synkattaviin AD-käyttäjiin, joilla msDS-cloudExtensionAttribute2-attribuutti on jotain muuta kuin Guest.
Seuraavaksi lisätään tähän sääntöön vielä User type -attribuutin kuljetus.
Tallennetaan sääntö.
Seuraavaksi luodaan vastaavalla tavalla sääntö Guesteille.
Eli otetaan kopio taas säännöstä In from AD – User Common ja laitetaan tähän sääntöön hieman eri arvot.
Nyt meillä on 2 sääntöä luotuna, joissa kerrotaan mitkä AD:n tunnukset ovat Membereitä ja mitkä Guesteja.
Vielä pitää luoda Azure AD:n suuntaan sääntö, jolla User type -attribuutti kuljetetaan.
Valitaan suunnaksi Outbound, jotta päästään luomaan sääntö, joka ottaa kantaa Azure AD:n suuntaan.
Annetaan tällekin säännölle kuvaava nimi ja Precedenceksi vaikkapa 3 (jos ei ennestään käytössä).
Scopeen arvot:
Ja lopuksi itse User type -attribuutin kuljetus Azure AD:hen.
Nyt olisi kaikki valmiina synkkaamista varten.
Suljetaan Synchronization Rules Editor ja Synchronization Service Manager jos ovat vielä auki.
Ajetaan PowerShellilla täysi synkkakierros komennolla:
Start-ADSyncSyncCycle initial
Tarkastetaan Synchronization Service Managerin Operations -välilehdeltä, että synkka pyörähti koko kierroksen onnistuneesti
Tämän jälkeen voidaankin sitten tarkastaa pilven päästä miltä meidän Guestina synkatut AD-käyttäjät näyttävät.
Kurkataan tässä tapauksessa meidän Veijo Vierasta Azure AD:n päästä:
Siellähän se meidän Veijo näyttää Guestina majailevan!
Palautetaan vielä automaattinen synkka päälle PowerShell-komennolla
Set-ADSyncScheduler -SyncCycleEnabled $true
</Taikatemppu>
Alla vielä muutama huomio tästä taikatempusta.
<Huomiot>
Ennen kuin alkaa tekemään tällaista taikatemppua omaan ympäristöönsä, on tärkeää ymmärtää sen oman Azure AD Connectin toiminta.
Eli onko sinne jo tehty custom-sääntöjä jotka mahd. vaikuttavat tämän toteuttamiseen.
Azure AD Connect olisi hyvä myös päivitellä uusimpaan versioon samassa rytäkässä, varsinkin jos versio alkaa olemaan 6-12kk vanha.
Taikuri itse ei onnistunut kaivamaan tietoa, onko tämä User type -attribuutin synkkaaminen tullut mahdolliseksi jossain tietyssä Azure AD Connect -versiossa vai onnistuuko vanhemmaltakin versiolta.
Tässä taikatempussa valittiin logiikaksi tietyn attribuution tietty arvo, joka taasen määrittää sen onko käyttäjä Guest vai Member Azure AD:ssa.
Toisia tapojakin on toki. Microsoftin dokumentissa Guest-arvon määräytyvyys päätellään käyttäjän AD-tunnuksen UserPrincipalNamen domain osiosta.
</Huomiot>
– Pilviguru / Huru-ukko Jasu Snell
