Vieraslajikäyttäjät – nyt automaationa!
Vieraskäyttäjien leviäminen pitkin vehreitä Azure AD -maastoja on ollut Teams-rynnäkön jälkeen väistämätöntä. Samalla vieraskäyttäjien rooli on kasvanut vain Teams-käytöstä entistä laajemmalle alueelle Microsoft 365 -työkuormissa. Ja nyt tämä leviäminen on automatisoitavissa organisaatiotasoisesti. Eli tyvekit päälle, kohta roiskuu!
Ottakaa siis vastaan Cross-tenant Synchronization!
Vaan onko tässä automaation määrässä enää mitään tolkkua? Saattaa ollakin, ja alla koitan hieman avata mistä on kyse, kenen varpaille siinä voi astua, ja miten kirves pysyy pois omilta varpailta. Ja onhan meillä jo Cross-tenant Access, joka hieman avasi latua tällekin toiminnolle, joten ei tätäkään pelästyä kannata.
Jos Cross-tenant access on terminä kuin kedon outo yrtti, kannattaa lukaista tässä tai jossain muussa välissä sitä käsittelevä lyhytkirjelmä tosta noin: Ristiin rastiin tenantista toiseen, eli Azure AD cross-tenant access in a nutshell
Cross-tenant accessin isovelipuoli steroideilla
Cross-tenant Synchronization vastaa monien organisaatioiden multi-tenant yhteistoiminnan huutoon, ehkä. Tehtaan suunnittelupöydällä on päällimmäisenä kissana ollut se, että saman organisaation eri tenantteihin jaetut käyttäjät voisivat päästä vähemmällä vaivalla käsiksi toisessa tenantissa oleviin resursseihin.
Paino kohdassa ”saman organisaation”
Tätä ei lähtökohtaisesti suositella käytettäväksi ihan minkä tahansa kumppaniorganisaation käyttäjien automaattiseen synkronointiin sinne sun tänne, tai etenkään tonne. Syynä voi olla mm. se, että oletusastuksilla äkkiä tempaistuna lähdeorganisaation käyttäjät saattavat ihan jok’ikinen putkahtaa kohdeorganisaation Azure AD:n jäseniksi (member). Tämä on siis eri asia kuin vieraskäyttäjä (guest). Jäsenillä kun on heti kättelyssä enemmän valtaa ympäristössä, johon heidät on tällä mankelilla automaattisesti survottu. Saman pesuveden mukana sinne toiseen organisaation saattaa livahtaa paljonkin ko. käyttäjään liittyvää metatietoa osoitteiden, osastojen ym. muodossa.
Pahinta mitä tällä siis voi tehdä, on tunkea puolihuomaamatta koko oma organisaatio toiseen tenanttiin jäseniksi, kaikkien Azure AD -metatietojen kera. Ja sitten tulee siivouskomentoa sieltä toisesta päästä.
It takes two to tango, sano pelimanni!
Onneksemme ei niitä käyttäjiä ihan yksipuolisesti voi ruveta toise(e)n tenanttiin survomaan. Kohdeympäristön pääkäyttäjän pitää määrittää Cross-tenant access -asetuksiin lähdeympäristön tenant ja Inbound-asetuksista sallia vieraskäyttäjien synkronointi ja automaattinen kutsun hyväksyminen ympäristöönsä. Myös vahvan tunnistautumisen asetukset kannattaa säätää haluttuun asentoon. Jos yhteistyö halutaan mahdollisimman sujuvaksi, ja voidaan luottaa toisen organisaation vahvan tunnistautumisen olevan vaaditulla tasolla, kannattaa ne merkata luotetuiksi.
Lähdeympäristön päässä on sitten hieman enemmän säädettävää. Cross-tenant access -asetuksiin pitää ensin määrittää kohdeympäristön tenant ja Outbound-asetuksista sallia käyttäjien automaattinen hyväksyntä kohdeympäristöön.
Sitten päästään vasta konfiguroimaan tätä Helvetinkonetta itseään!
Perusasetuksista on suotavaa laittaa vikailmoitukset tulemaan komppanian päivystäjälle, ja myös keksiä jokin raja ei-toivotulle käyttäjien massapoistolle synkronoinnin toimesta. Myös scope kannattaa säätää valittuihin käyttäjiin, jollei se sitä ole.
Kannattaa kiinnittää huomiota etenkin Mappings-osuuteen. Sieltä löytyy mm. lähdeobjektien suodatin, jolla voi sanella Azure AD -attribuuttien perusteella mitkä tunnukset kuuluvat tämän mappings-taulun synkronoinnin piiriin.
Edellä mainittu Scope asetus edellyttää, että käyttäjät on myös ylipäätään lisätty provisiointipalvelun piiriin.
Ja lisäksi on syytä käydä läpi ajatuksella tämä alla oleva taulu synkronoitavista attribuuteista ja niiden asennosta. Harkintaa vaativat kohdat on korostettu punaisella.
Tämän lievän sekavuuden,muutaman asetusvivun ja pohdinnon jälkeen voidaan vääntää sitten Provisioning Status asentoon On, nostaa jalat kissan viereen pöydälle, ja odottaa pidemmän kahvitauon mittainen tovi että naapurin galaksi räjähtää käyttäjistä.
Mitäs nyt ainakin kannattaisi miettiä etukäteen?
Kuten edellä nähty kuva- ja sanakavalkadi saattoi yrittää vihjata, tätä ei kannata mennä vääntämään päälle ihan vain akateemisesta mielenkiinnosta, tai ratkaisuna ”kaikkiin ongelmiin”.
- Mikä on synkronoinnin syy, seuraus ja tavoite, ja onko nämä varmasti sama ja haluttu asia?
- Halutaanko käyttäjät guest vai member rooliin kohdeympäristössä?
- Mitä Azure AD:n tietoja käyttäjistä halutaan viedä kohdeympäristöön?
- Mitkä tunnukset haluat synkata kohdeympäristöön?
- Kannattaa ainakin alkuun testata tätä pienemmällä porukalla
- Miten tunnusten elinkaari huomioidaan synkronoinnin yhteydessä?
- Eli millä ehdoilla tunnus kuuluu synkronoinnin piiriin tai tippuu siitä pois?
- Jos tunnus lähtee pois synkronoinnin piiristä, synkronointi laittaa sen kohdeympäristössä poistettujen käyttäjien laariin odottelemaan lopullista kadotusta
- Miten vahvan tunnistautumisen (MFA) pitäisi käyttäytyä?
- Haluaako kohdeympäristön pääkäyttäjä luottaa lähdeympäristön vahvaan tunnistautumiseen, ja onko oma ympäristö ns. Paraatikunnossa, että näin kehtaa edes ehdottaa tehtäväksi?
- Mitä tapahtuu niille käyttäjille, jotka on jo mahdollisesti aiemmin lisätty kohdeympäristöön?
- Synkroninti luultavasti päivittää ainakin niiden käyttäjien Azure AD -tietoja
Jaa että tästä ohjeesta puuttuu jotain?
Hyvin havaittu, koska tämän tarkoitus ei ole antaa täsmällisen suoria ohjeita miten näistä aineksista se pommi kasataan. Niitä on tunnetusti internetti täynnä. Myöskään tehtaan manuaali ei yhtään häpeä blogikonsulenttien tulkintojen rinnalla, joten kannattaa mennä tavaamaan ajatuksella sitä, jos mielenkiinto heräsi.
Configure cross-tenant synchronization (preview) – Microsoft Entra | Microsoft Learn
Eikä laiskan insismöörin kannata kirjottaa mitään sellaista uusiksi, mitä ChatGPT* ei voisi tehdä 😉
*Tämä blogitieteiden helmi on kirjoitettu vielä omin pikku kätösin. Valitettavasti.
– Pilvikuiskaaja Riku Mustila
