Teamsin käytön laajenemisen myötä monet organisaatiot ovat saaneet Azure AD -ympäristöönsä lisää vieraita, toivottavasti enimmäkseen kutsuttuja. 😉 Lämpimän tervetulotoivotuksen lisäksi vierailta saatetaan nykyään vaatia myös vahvaa tunnistautumista Conditional Accessiin tehdyn säännön avulla.
Tähän liittyy kuitenkin kaksi kysymystä, jotka saattavat jäädä vähemmälle huomiolle:
- Miten vierailijatunnuksilla ja ulkoisille tunnuksille kohdennettavat Conditional Access -säännöt vaikuttavat palveluiden käyttöön?
- Miten kutsuttu vieras voi hallita vahvan tunnistautumisen asetuksia?
Conditional Access -sääntöjen vaikutus ulkopuolisiin tunnuksiin
Vahvan tunnistautumisen (Multi-factor Authentication, MFA) vaatiminen vierailijatunnuksilta tai ulkoisilta tunnuksilta on tehty kohtalaisen helpoksi Conditional Access -säännön avulla. Tehdään esimerkiksi uusi sääntö näitä käyttäjiä varten, kohdennetaan sääntö All guest and external users -valinnalla ja vaaditaan MFA kaikkien pilvisovellusten osalta. Mahdolliset paikalliset mausteet vielä kyytiin ja annos on valmis.
Tämä tietysti asettaa kaikki tulevat ja nykyiset vieraskäyttäjät rekisteröimään MFA:n käyttöön, ja käyttämään sitä saapuessaan organisaationne ovelle, kuten pitääkin.
Mutta samalla voi alkaa ilmetä yllättäviä haasteita. Etenkin Microsoftin sähköpostin salauspalvelua (Office 365 Message Encryption, OME) käytettäessä ulkoiset käyttäjät eivät välttämättä saa heille lähetettyjä salattuja sähköposteja auki Outlook-sovelluksessa. Miksi näin?
Kun salattu viesti lähetetään, käytetään salaukseen Azure Rights Management -palvelua, joka on osa Azure Information Protectionia. Kun vastaanottaja koittaa avata viestiä Outlookilla, se ei saa kysyttyä lähettäjän organisaation Azure RM -palvelulta lupaa avaamiselle, koska MFA seisoo portilla poikittain, ja Outlook toteaa ns. ”Pidä tunkkis!”. Selainpohjaisella Outlookilla tätä ongelmaa ei välttämättä ilmene, joten se voi toimia kiertotienä. Mutta tämä täytyy vastaanottajan itse keksiä.
Tilanteen ratkaisemiseksi on kaksi tapaa:
- Kutsutaan käyttäjä vierailijatunnukseksi, jolloin käyttäjä on tunnettu vierailija Azure AD:n näkökulmasta
- Otetaan MFA vaatimus pois ulkoisilta käyttäjiltä Azure Information Protection -sovelluksen osalta
Näistä jälkimmäinen lienee parempi sekä käytännön, että tietoturvan näkökulmasta, kun tarkoitus ei ole keräillä turhia vierailijatunnuksia omaan Azure AD:hen roikkumaan.
Monivaiheisen tunnistautumisen asetusten hallinta vierailijatunnuksella
Kun vierailijalta vaaditaan MFA:ta, hän pääsee rekisteröimään sen käyttöönsä samalla tavalla kuin sisäisetkin käyttäjät. Tässä ei sinänsä ole mitään koukkua. Mutta kun käyttäjän pitäisi muuttaa esimerkiksi tunnistautumiseen käytettäviä menetelmiä, mistä hän sen tekee?
Tämä onnistuu hyvin pitkälti samalla tavalla, kuin käyttäjä päivittäisi oman organisaationsa osalta näitä tietoja, mutta käyttäjän pitää vaihtaa organisaatiota ennen asetuksiin siirtymistä. Käytännössä siis:
- Kirjaudutaan https://myaccount.microsoft.com/ osoitteeseen.
- Portaalin oikeasta reunasta löytyy painike, josta aukeaa lista kaikista organisaatioista, joihin käyttäjä on kutsuttu:
- Valitaan organisaatio, jonka osalta tunnistautumisen tiedot halutaan päivittää.
- Tämän jälkeen valitaan vasemmalta valikosta Turvatieto (Security info) -kohta:
- Näin pitäisi näkyä nyt vierasorganisaatioon rekisteröidyt tunnistautumismenetelmät ja päästään päivittämään niitä.
- Paluu omaan organisaatioon voidaan tehdä organisaatiovalikosta valitsemalla oma organisaatio.
Jos edellisessä organisaatiolistauksessa näkyi paljon vanhoja ja turhia organisaatioita, voidaan listata kaikki organisaatiot painamalla vasemmalta Organisaatiot painiketta, ja poistua halutuista organisaatioista. Jos poistutaan vahingossa väärästä organisaatiosta, pitää kutsu pyytää uudelleen.
– Pilvikuiskaaja Riku Mustila
One Comment