Entra Domain Services: viimeinen askel on-prem AD:n alasajossa

Työasemat on siirretty Entra ID:hen ja Intuneen, sähköposti ja tiedostot ovat pilvessä. Silti konesalissa pyörii kaksi vanhaa domain controlleria, koska “siellä on vielä se yksi järjestelmä”. Sen yhden järjestelmän takia ylläpidetään palvelimia, varmuuskopioita, patchausta ja usein myös VPN-yhteyksiä.

Tämä tulee vastaan jatkuvasti, eikä moni tiedä, että väliin on olemassa työkalu, jolla viimeiset riippuvuudet hoidetaan ilman omia domain controllereita. Se on Entra Domain Services, ja se on mielestäni yksi Microsoftin huonoiten tunnetuista palveluista suhteessa siihen, kuinka paljon se voi yksinkertaistaa ympäristöä.

Mitä Entra Domain Services on ja mitä se ei ole

Entra Domain Services (Entra DS, aiemmin Azure AD Domain Services) on Azure-palvelu, joka tarjoaa perinteiset Active Directory Domain Services -toiminnot pilvestä: Windows-toimialueen jäsenyyden, kirjautumisen AD-tunnuksilla, LDAP-hakemiston, Kerberos- ja NTLM-autentikoinnin sekä ryhmäkäytännöt. Käytännössä Microsoft pystyttää ja ylläpitää kaksi domain controlleria valitsemaasi Azure-alueeseen. Sinä et näe niitä palvelimina etkä kirjaudu niihin, vaan käytät vain domainia.

Tärkein asia, joka kannattaa ymmärtää heti alussa: Entra DS on oma erillinen toimialue, ei nykyisen on-prem AD:n laajennus. Käyttäjät, ryhmät ja salasanojen tiivisteet synkronoituvat siihen yksisuuntaisesti Entra ID:stä. Jos ympäristössä on on-prem AD, ketju on siis AD DS → Entra ID → Entra DS. Mitään ei kirjoiteta takaisinpäin.

Erillisyys tarkoittaa myös rajoituksia, jotka on hyvä tietää ennen suunnittelua:

• Et saa Domain Admin- tai Enterprise Admin -oikeuksia. Hallinta tapahtuu rajatulla AAD DC Administrators -ryhmällä ja erillisellä hallintapalvelimella tai -työasemalla, johon on asennettu RSAT-työkalut.
• AD-skeemaa ei voi laajentaa. Jos sovellus vaatii skeemamuutoksia, tämä ei ole se työkalu.
• Entra ID:stä synkronoituja objekteja ei voi muokata Entra DS:n puolella. LDAP-kirjoitus toimii vain domainissa itse luotuihin objekteihin.
• Trustit ovat rajoitettuja: vain forest trust, ei external trust, ja vain Enterprise- tai Premium-tasolla.
• AD Certificate Servicesiä ei voi ottaa käyttöön domainissa lainkaan, koska Enterprise CA vaatii Enterprise Admin -oikeudet ja muutoksia hakemistoon. Sama koskee muita AD:n oheisrooleja, jotka tarvitsevat vastaavia oikeuksia.
• Sertifikaatti- ja älykorttipohjainen tunnistus ei toimi. Käyttäjällä pitää olla salasana, jonka tiiviste synkronoituu.

Jos nämä rajoitukset eivät ole ongelma, palvelu on todella huoleton. Microsoft hoitaa patchauksen, replikoinnin, varmuuskopiot ja korkean käytettävyyden.

Neljä tilannetta, joissa Entra DS ratkaisi ongelman

Nämä ovat ympäristöistä, joissa olen ollut mukana. Yksityiskohdat on yleistetty.

Palvelimien käyttöoikeudet puhtaassa pilviympäristössä. Organisaatiolla ei ollut on-prem AD:ta lainkaan, mutta Azuressa oli kasvava joukko palvelimia kehittäjille. Käyttöoikeuksia ja tunnusten elinkaarta hallittiin palvelin kerrallaan paikallisilla tunnuksilla, mikä ei kestä kauaa. Entra DS otettiin käyttöön, palvelimet liitettiin uuteen domainiin ja käyttöoikeudet, esimerkiksi RDP, annettiin ryhmien kautta. Kun kehittäjä lähtee, tunnus poistuu Entra ID:stä ja samalla kaikista palvelimista.

Viimeiset AD-riippuvaiset palvelimet ja AD:n alasajo. Tämä on se yleisin tapaus. Työasemat olivat jo puhtaasti Entra-liitettyjä ja Intunella hallittuja, ja AD haluttiin ajaa alas. Muutama palvelin oli kuitenkin edelleen riippuvainen domainista, eikä niistä päästy vielä eroon. Ratkaisu: Entra DS käyttöön, salasanat synkronoitiin on-premistä Entra ID:n kautta, VPN Azuren ja konesalin välille, palvelimet vaihdettiin uuteen domainiin yksi kerrallaan ja testattiin. Kun viimeinen palvelin oli siirretty, vanha AD ajettiin alas. Tämä on juuri se tilanne, jossa Entra DS on korvaaja: ei koko AD:lle alusta asti, vaan sen viimeiselle vaiheelle.

Uusi sovellus vaati LDAPS:n. Puhdas pilviympäristö, jossa päätettiin ottaa käyttöön ohjelmisto, joka autentikoi käyttäjät vain LDAP:n yli. Ilman Entra DS:ää vaihtoehdot olisivat olleet oman domain controllerin pystyttäminen Azureen tai sovelluksen vaihtaminen. Entra DS otettiin käyttöön, LDAPS kytkettiin päälle sertifikaatilla, ja sovelluksen julkinen IP luvitettiin. Käyttöönotto kesti iltapäivän.

Iso legacy-järjestelmä, mutta vain muutama käyttäjä. Laaja ympäristö, jossa oli paljon historiaa ja iso on-prem AD-infra, ja samaan aikaan menossa tietoturvan modernisointi. Yksi kallis, vanha järjestelmä vaati LDAP:n, mutta sitä käytti vain kourallinen ihmisiä. Se olisi voitu kytkeä suoraan on-prem AD:hen, mutta se olisi tarkoittanut verkkoavauksia domain controllereille ja muutoksia AD-ympäristöön. Sen sijaan otettiin Entra DS, synkronoitiin siihen vain pieni rajattu ryhmä tunnuksia ja päivitettiin samalla LDAP → LDAPS. Lopputulos: suppea, eristetty AD vain niille, jotka sitä oikeasti tarvitsevat, ei muutoksia vanhaan ympäristöön, ja palvelu pyörii käytännössä itsekseen.

Yhteinen nimittäjä kaikissa: konkreettinen, nimetty riippuvuus, jota ei voitu poistaa heti. Ei “saatetaan joskus tarvita”.

Milloin Entra DS:ää ei kannata ottaa

Kolme virhettä, jotka näen useimmin:

Ostetaan varmuuden vuoksi. Jos et osaa nimetä sovellusta tai palvelinta, joka tarvitsee Kerberosta, NTLM:ää, LDAP:ia tai domain-liitosta, et tarvitse Entra DS:ää. Se maksaa joka kuukausi riippumatta siitä, käytetäänkö sitä. Entra ID ja Intune hoitavat modernin työasemaympäristön ilman domainia.

Luullaan, että se on nykyisen AD:n laajennus. Ei ole. Se on erillinen domain, johon vanhan AD:n ryhmäkäytännöt, OU-rakenne tai skeemalaajennukset eivät siirry. Jos odotus on “sama AD, mutta pilvessä”, oikea vaihtoehto on domain controller Azure-virtuaalikoneessa, ja siihen liittyy sitten kaikki se ylläpito, josta haluttiin eroon.

Käytetään tekosyynä olla modernisoimatta, tai päinvastoin. Yksi legacy-sovellus muuttuu helposti syyksi pitää koko AD elossa. Entra DS:n oikea käyttö on juuri se, että vanha LDAP- tai Kerberos-sovellus ei enää estä muun infran modernisointia. Sovellus saa jäädä, AD ei. Jos sovelluksen voi myöhemmin korvata SAML- tai OIDC-integraatiolla, sekin kannattaa, mutta se ei ole ehto aloittamiselle.

Mitä pitää tietää ennen käyttöönottoa

Itse käyttöönotto on ohjattu ja kestää alle tunnin, mutta muutama päätös pitää tehdä oikein heti, koska niitä ei voi korjata jälkikäteen. Tarkat rajoitukset ja SKU-tasot löytyvät Microsoftin dokumentaatiosta.

• Domain-nimeä ei voi vaihtaa. Valitse nimi, jonka omistat ja joka on reititettävissä internetissä (esimerkiksi ads.yritys.fi). Se ei tarkoita, että palvelu olisi julkinen, mutta se välttää nimikonfliktit myöhemmin.
• Oma virtuaaliverkko Azuressa. Entra DS elää vNetissä, eikä verkkoa voi vaihtaa jälkikäteen sen enempää kuin domain-nimeäkään. Jos on-prem-palvelimien pitää liittyä domainiin, tarvitaan VPN tai ExpressRoute. Muista myös DNS: domainiin liitettävien koneiden pitää löytää Entra DS:n domain controllerit.
• Salasanatiivisteet ja alkusynkronointi. Kerberos ja NTLM tarvitsevat salasanatiivisteet, joita Entra ID ei oletuksena säilytä Entra DS:n tarvitsemassa muodossa. Jos käyttäjät synkronoituvat on-prem AD:sta, Password Hash Synchronization pitää olla päällä, ja täysi synkronointi pakotetaan PowerShell-skriptillä. Pilvikäyttäjät näkyvät Entra DS:ssä vasta, kun he ovat vaihtaneet salasanansa kerran, jotta tiivisteet syntyvät. Tämä yllättää lähes aina, joten viesti käyttäjille kannattaa suunnitella etukäteen. Alkusynkronointi voi kestää tunteja, joten testaus kannattaa aloittaa vasta, kun Domain Services Health -näkymä näyttää synkronoinnin valmiiksi. Sen jälkeen muutokset ovat kokemukseni mukaan näkyneet ilman mainittavaa viivettä.
• SKU-taso. Standard, Enterprise ja Premium eroavat suositellussa objektimäärässä, autentikointivolyymissa, varmuuskopiotiheydessä ja trustien määrässä. Tason voi vaihtaa jälkikäteen. Pienelle ja keskisuurelle ympäristölle Standard riittää, ellei tarvita forest trustia on-prem AD:hen siirtymävaiheen ajaksi.
• LDAPS. Jos sovellus käyttää LDAPS:ää, tarvitset sertifikaatin. Jos yhteys tulee internetistä, Entra DS:lle avataan julkinen IP ja pääsy rajataan lähdeosoitteisiin.
• Hinta. Laskutus on tuntiperusteista per replica set, ja tarkat hinnat kannattaa katsoa Azuren hintasivulta. Suuruusluokka Standard-tasolla on reilu sata euroa kuukaudessa. Se on halpa verrattuna kahden domain controllerin ylläpitoon, mutta ei ilmainen, joten sitä ei kannata jättää päälle ilman käyttöä.

Muistilista

• Nimeä riippuvuudet. Listaa sovellukset ja palvelimet, jotka oikeasti tarvitsevat Kerberosta, NTLM:ää, LDAP:ia tai domain-liitosta. Jos lista on tyhjä, et tarvitse Entra DS:ää.
• Tarkista, voiko riippuvuuden korvata. SAML tai OIDC on parempi kuin LDAP, jos sovellus tukee sitä. Jos ei tue, se ei ole syy lykätä muuta modernisointia.
• Päätä domain-nimi huolella. Sitä ei voi vaihtaa.
• Suunnittele salasananvaihto ja viestintä. Pilvikäyttäjien on vaihdettava salasana kerran, synkronoiduille pitää olla PHS päällä.
• Rajaa synkronoitavat käyttäjät. Jos vain kourallinen tarvitsee palvelua, synkronoi vain heidät. Pienempi hyökkäyspinta ja selkeämpi ympäristö.
• Aseta tavoite palvelun sammuttamiselle. Kirjaa ylös, minkä sovelluksen takia Entra DS on olemassa. Kun se on korvattu, sammuta myös Entra DS.

Entra DS ei ole määränpää, vaan väline. Se mahdollistaa siirtymävaiheen, jossa on-prem AD:sta luovutaan hallitusti ja samalla jatketaan kohti täysin pilvipohjaista ympäristöä. Kun tietää, että tällainen työkalu on olemassa, matkalla kohti yksinkertaisempaa IT:tä on yksi kynnys vähemmän.