Azure Active Directory identiteedi kontseptsioonid

Oktoobris ja Novembris sai Microsofti Eesti kontoris läbi viidud neli erinevat Modernse töökoha tehnilise juurutuse seminari ja üks nendest seminaridest oli Identiteet: Pilves, maapeal või mõlemas kohas korraga. Seminaril sai räägitud ja näidatud lähemalt milliseid erinevaid Azure Active Directory (Azure AD) identiteedi kontseptsioone on olemas, kuidas seadistada sünkroniseeritud identiteeti ja mis juhtumi puhul millist teed minna.

Kui Azure Active Directory´st lähemalt rääkida, siis tegemist on pilvepõhise identiteedi ja ligipääsu halduslahendusega ehk IDaaS (Identity as a Service) teenusega. Azure AD ei ole lihtne domeenikontroller pilves, vaid tegemist on küllaltki võimeka teenusega, mis pakub tänases päevas väga palju erinevaid lisaväärtuseid nt. kasutajate iseteenindus, mitme faktori autentimine, privilegeeritud kontode haldus, riskipõhine kontode haldus jne.

Identiteedi teemaline seminar oli teine seminar kohe peale juurutust ja planeerimist. Kui küsida, MIKS, siis vastus on väga lihtne. Kogu seadmehaldus on läinud identiteedi põhiseks. See tähendab, et kui sa soovid seadet haldus alla võtta, peab sul ennem kasutaja olemas olema. Soovid seadmele tarkvara, seadistusi jne paigaldada, siis kõik need paigaldatakse otse kasutajale, mitte enam seadmele. Põhjus miks me seda nii teeme on väga lihtne – tänases päevas on kasutajal rohkem kui üks seade mida ta kasutab igapäevaseks töö tegemiseks.

Oma seminaridel olen alati näidanud slaidi, kus on kirjas olnud järgnev lause:

Everything starts with identity and it will be one of the foundations of your enterprise mobility strategy

Iga Enterprise Mobility +Security projekt algab planeerimise faasist ning peale selle läbimist jätkub identiteedi seadistamisega. Vaadates viimase aasta klientide projekte ja koolitusi, siis enamasti on näha, et väga palju planeerimise faasile aega ei ole investeeritud. Enamasti on sisse ostetud kõige odavam konsultant või majasiselt teinud „Next -> Next -> Finish“ tüüpi installatsiooni kohalik IT tehnik ning asi unustatud. Tegelikkuses ei tohiks see aga nii käia. Minu soovitus on alati olnud, et tuleks täpsemalt vaadata reaalseid ettevõte vajadusi ja selle pealt otsus teha. Üks asi on seadistada ära  konkreetne identiteedi lahendus, kuid teine asi on juurutada tulevikus erinevad Azure AD pakutavad teenused sinna peale. Kui planeerimist teha, siis skoobis peaks sees olema mõlemad punktid. Kui alguses on asjad läinud valesti või mõned olulised asjad jäänud kahe silma vahele, siis pärast nende muudatuste tegemine tootmises võib olla küllaltki valuline ja keeruline. Lühidalt, kui Te alustate identiteedi ülesse seadistamist, siis kindlasti võtke aega selle teema arutamiseks. Kui ettevõtte siseselt puudub vajalik kompetents, siis soovitan julgelt see teenusena sisse osta.

Kui ettevõte on soetanud omale Enterprise Mobility +Security E3 paketi, siis on võimalik kasutada Azure AD P1 teenuseid ja Enterprise Mobility +Security E5 paketi puhul Azure AD P2 teenuseid.

Tulles tagasi Azure AD identiteedi kontseptsioonide juurde, siis tänases päevas on neid kokku neli erinevat.

  • Cloud Only ehk Pilv ainult
  • Synchronized ehk Sünkroniseeritud mudel
  • Federated ehk Federeeritud mudel
  • Pass-Through Authentication

Pass-Through on nendest kõige uuem lahendus mida Microsoft tutvustas esimest korda 2016 Ignite ajal ja Ignite 2017 ajal lasti teenus ametlikult ka välja. Järgnevalt vaatame lähemalt kõike nelja erinevat identiteedi kontseptsiooni ning millised on nende plussid ja miinused.

„Pilv ainult“ identiteet

Pilv ainult“ identiteedi puhul on tegemist kõige lihtsama identiteedi lahendusega. Selle juhtumi puhul haldad kasutajaid otse veebipõhise Azure AD portaali kaudu ja ühtki kasutajat oma maja sisesest domeenikontrollist ei sünkroniseeri. „Pilv ainult“ lahendus sobib ideaalselt uutele ettevõtetele või ettevõttel kellel on majas mõni üksik server ja planeeritakse neist loobuda. „Pilv ainult“ lahendust on kasutanud või kasutavad siiamaani ka mõned suuremad asutused, kes kunagi alustasid Exchange Online teenuse tarbimist ja teatud põhjustel pole seda tänaseni muutnud. Sellises olukorras on kasutajatel kaks erinevat kontot ja parooli, mis lõppkasutaja kohapealt võib olla üsnagi ebamugav kogemus.

Pilv ainult“ puhul:

  • Haldad kasutaja kontosid ja seadistusi otse läbi Azure AD portaali
  • Pole vaja paigaldada lisa servereid ja teenuseid
  • Lihtne hallata
  • Madalad kulud

Sünkroniseeritud identiteet

Sünkroniseeritud identiteedi puhul sünkroniseeritakse olemasolevad kasutajad majasisesest domeenikontrollerist otse Azure AD´sse. Selleks, et seda teha, tuleb paigaldada üks lisa server kuhu paigaldatakse teenus nimega Azure AD Connect. Azure AD Connect puhul on tegemist sünkroniseerimis tööriistaga, mis teatud aja tagant kontrollib uusi kasutajaid või muudatusi ja siis sünkroniseerib need otse Azure AD´sse.

Azure AD Connect sünkroniseermise sammud

Azure AD Connect on tasuta tööriist mis on alla laetav Microsofti veebilehelt. Azure AD Connecti on võimalik ka paigaldada otse domeenikontrolleri peale aga seda ma ei soovitaks teha. Azure AD Connecti paigaldamist vaatame lähemalt mõnes teises postituses.

Rääkides sünkroniseeritud identiteedist, siis ausalt öeldes pole see minu arust kõige parem mõiste sellele lahendusele, kuna kui me vaatame Microsofti mõistes sünkroniseeritud, federeeritud ja PTA identiteedi lahendusi, siis tegelikkuses on tegemist hübriid identiteedi mudeliga ehk siis 1 kasutaja millega saab ligi nii pilve kui ka oma maja sisestele teenustele. Teiseks kui Te soovite federeeritud või PTA lahendust, siis igal juhul tuleb alati seadistada Azure AD Connect. Nende kolme erineva lahenduse puhul lihtsustame lõppkasutaja ja haldus kogemust.

PS! Sünkroniseeritud identiteedi lahenduse puhul tuleb ka domeenikontrollerist sünkroniseerida kasutaja parooli räsid.

Sünkroniseeritud identiteedi puhul:

  • Sama kasutaja ja parool
  • Minimaalselt vähemalt 1 lisa server Azure AD Connect jaoks
  • Hea lahendus ettevõttele kellel on olemas oma maja sisesed domeenikontrollerid ning kes soovivad kasutada sama kasutajanime ja parooli mõlemas otsas.

Federeeritud identiteet

Federeeritud identiteedi mudel puhul on tegemist kõige kallima ja keerukama lahendusega. Selleks, et kasutusele võtta federeeritud identiteet on vaja nelja erinevat serverit ja lisaks sellele veel Load Balancerid. Esimese asjana tuleb seadistada ära Active Directory Federation Services ehk ADFS teenus ja peale seda saab ringi konverteerida oma Azure AD domeeni. ADFS keskkond peab olema kindlasti kõrge käideldavusega, kuna juhul kui ADFS keskkond peaks maha kukkuma, siis ei ole võimalik ka pilve teenustele ligi pääseda.

Federeeritud identiteet on klientide seas kõige populaarsem. Põhjuseid selleks on mitmeid. Esiteks Office 365 konsultandid on seda meeletus koguses juurutanud ilma, et klient üldse aru saanud miks neil seda vaja on. Mõned konsultandid on öelnud, et ilma selleta Office 365 teenuseid kasutada ei saa, mis ei vasta aga tõele. Teiseks ADFS on väga võimekas oma funktsionaalsuse kohapealt ja sinna on võimalik integreerida väga palju erinevaid teisi lahendusi nt Eesti enda ID-kaart, SMART-ID, vastavuskontrollid jne.

Kolmandaks federeeritud identiteedi puhul ei ole vaja sünkroniseerida kasutajate parooli räsisid, mis võib olla nõue konkreetselt turvaosakonnalt. Neljandaks federeeritud identiteedi puhul on Teil võimalik saada SSO ehk Single Sign On. See tähendab seda, et seadmesse logides ei ole vaja enam pilve teeustesse ligipääsemiseks kasutaja nime ja parooli sisestada.

Kui Teil täna ADFS keskkonda ei ole, siis ma soovitaks mitte  valida federeeritud identiteedi lahendust. ADFS on rohkem kui ainult SSO. ADFSi juurutus on 90% planeerimist ja 10% seadistamist.

Federeeritud identiteedi puhul:

  • SSO pilve teenustele
  • Pole vaja sünkroniseerida parooli räsisid pilve, kuid on soovitatav seda ikkagi teha
  • Kasutaja parooli kontrollitakse vastu oma maja domeenikontrollerit
  • Kõige kallim identiteedi lahendus.

Pass-Through Authentication

PTA identiteedi puhul on tegemist kõige uuema lahendusega Microsofti poolt. PTA lahenduse puhul on meil sama kasutaja ja parool mõlemas otsas aga parooli kontrollitakse vastu oma maja domeenikontrollerit. Just nagu federeeritud identiteedi puhul. Kui küsida, et mis vahe on federeeritud ja PTA lahendusel, siis PTA on kindlasti odavam, kui federeeritud. Muidugi PTA ei ole nii paindlik ja rohke funktsionaalsusega nagu federeeritud identiteet, kuid enamasti on kliendid federeeritud identiteeti juurutanud ainult SSO pärast. PTA suudab tänases päevas pakkuda kahte asja, et kliendid saaksid oma ADFS taristu eemaldada ja ringi lülituda PTA identiteedile.

Vaadates allolevat graafikut, siis me näeme, et ADFS juhtumi puhul läheb keerukus suureks aga samas on väärtus samuti kõrge. PTA lahenduse puhul saame kaks olulist asja – SSO ja paroolide kontrollimise vastu oma maja domeenikontrollerit. PTA lahenduse puhul on väärtus peaaegu sama kõrge kui ADFSi puhul aga lahendus ise ei ole nii keerukas ja kulukas kui ADFS´i puhul.

Kui teil täna on juurutatud federeeritud identiteet, siis ma soovitaks kaaluda ümberkolimist PTA peale. Kogemus näitab, et ADFS funktsionaalsusest kasutatakse ära ainult SSO ja sellisel juhul ei ole mõistlik säärast taristut üleval hoida – saab lihtsamalt!

PS! PTA identiteedi juurutamisel on vaja vähemalt kahte serverit. Üks server kus on Azure AD Connect aktiivsena ja teine on nii nimetatud Staging režiimis.

PTA identiteedi puhul:

  • Lihtsam ja odavam kui federeeritud identiteet
  • Võimaldab kontrollida kasutaja parooli vastu oma maja domeenikontrollerit
  • Võimaldab SSO (Seamless Single Sign-On).
  • Võimalik juurutada ka tasuta Azure AD versioonide puhul.

Tunnuspilt on võetud siit