Koble en Azure VM til Entra Domain Services: bestem først
Tre beslutninger kommer før tilkoblingen: katalogmodellen arbeidsbelastningen trenger, privat DNS som løser domenet, og en konto som kan autentisere.
Tre beslutninger står foran en Windows Server VM som må bruke en administrert katalog, og tilkoblingskommandoen er den minste av dem. Velger du feil katalogmodell, lykkes tilkoblingen mens programmet fortsatt ikke kan autentisere. Går navneoppslaget galt, dukker feilen opp på et punkt som ser ut som et legitimasjonsproblem.
Avgjør modellen, oppslaget og kontoen før du rører serveren, så kjører kommandoen én gang.
Hvilken av de tre tilkoblingene du egentlig vil ha
En enhetstilkobling registrerer en maskin hos Microsoft Entra ID for betinget tilgang og enkeltpålogging, og gir ikke arbeidsbelastningen noen Kerberos-billett til et domene i lokal stil. En tradisjonell domenetilkobling binder et datamaskinobjekt inn i en katalog og gir det en maskinkonto, gruppepolicy og domeneautentisering. Et administrert domene leverer den andre modellen som en tjeneste. Navnene høres like ut, og resultatene gjør det ikke.
Bare de to siste innebærer en domenekontroller i vanlig forstand, og bare det administrerte alternativet fjerner serverne fra oppdateringslisten din.
Beslutningen avhenger vanligvis av programmet og ikke av preferanse. Programvare som vil ha en LDAP-binding, en tjenestekonto med et SPN eller gruppepolicyobjekter, hører i domenemodellen. Programvare som bare trenger å vite brukerens identitet på en bedriftsenhet, hører vanligvis ikke der.
| Model | What the server gets | Where it appears |
|---|---|---|
| Entra device join | Device identity and conditional access signals | Microsoft Entra ID |
| Managed domain join | Machine account, Kerberos, group policy | The managed directory |
| Self-hosted AD DS | The same, plus every controller you operate | Your own forest |
DNS-veien avgjør om tilkoblingen kan fullføres
En domenetilkobling begynner med et lokatoroppslag etter domenets kontrollerposter, så navneoppslaget må virke før noen legitimasjon kontrolleres. Pek VM-en mot den administrerte domenets katalogadresser, enten via det virtuelle nettverkets DNS-innstillinger eller via en betinget videresender som bare sender det navnerommet dit. En videresender begrenset til navnerommet er vanligvis det tryggere valget, fordi den lar resten av VM-ens oppslag være i fred.
Test lokatoren i stedet for et bart vertsnavn. En ping mot domenenavnet beviser nesten ingenting, mens en SRV-spørring etter domenekontrollerpostene enten returnerer de forventede målene eller feiler med en gang:
Resolve-DnsName -Name "_ldap._tcp.dc._msdcs.ds.corp.example" -Type SRV -Server 10.20.0.4
Test-NetConnection -ComputerName 10.20.0.4 -Port 53
Erstatt domenenavnet og de to adressene med verdiene fra konfigurasjonen av det administrerte domenet; tallene her er eksempler. Hvis spørringen returnerer svar fra en annen sone, bruker VM-en en oppløser som ikke videresender det administrerte navnerommet, og ingen mengde gjentakelser av tilkoblingen endrer det.
Hold arbeidsbelastningen utenfor subnettet det administrerte domenet reserverer til sine egne tjenesteressurser, og hold katalogportene på den private veien. Offentlig eksponering av disse portene er ikke en snarvei; det er et annet design med en annen risikoprofil.
Kontoens egnethet kontrolleres før maskinen
Kontoen som utfører tilkoblingen trenger tillatelse til å opprette et datamaskinobjekt i målbeholderen, og den må kunne autentisere mot det administrerte domenet. En konto bare i skyen som ble opprettet før det administrerte domenet fantes, mangler kanskje passordavledet materiale som domenet trenger, og en passordendring eller tilbakestilling genererer det på nytt. Den detaljen forklarer en klasse tilkoblingsfeil som ser ut som feil passord når passordet er riktig. Test legitimasjonen mot domenet før vedlikeholdsvinduet åpnes.
Synkroniserte hybridkonti har egne forutsetninger som et synlig brukerobjekt ikke oppfyller alene. Å stå oppført i katalogen er ikke det samme som å kunne hente en billett fra den, så test kontoen før vedlikeholdsvinduet og ikke under det.
Deleger tilkoblingsretten smalt. Å gi hver fremtidige serverbruker domeneadministrator-medlemskap slik at én registrering kan skje, er en permanent tillatelse for et midlertidig problem.
Selve tilkoblingen er én kommando
Med modellen valgt, DNS som svarer og kontoen egnet, er operasjonen den vanlige Windows-operasjonen. Ledeteksten holder passordet utenfor skript og skallhistorikk:
Add-Computer -DomainName "ds.corp.example" -Credential (Get-Credential) -PassThru
Kommandoen starter ikke maskinen på nytt av seg selv i denne formen, så omstarten skjer under vedlikeholdsplanen og med gjenopprettingsveien fortsatt tilgjengelig. En server som allerede er koblet til et annet domene, trenger en migreringsplan, ikke en ny tilkobling oppå den første.
Noter beholderen datamaskinobjektet havnet i, og kontoen som opprettet det. Begge er viktige når maskinen må kobles til på nytt etter en gjenoppbygging, og ingen av dem er åpenbare fra serveren i ettertid.
Hva medlemskap ikke gir
Domenemedlemskap gjør ingen til lokal administrator og gir ikke tilgang til eksternt skrivebord eller filutdeling. Disse rettighetene konfigureres separat, og på et administrert domene holder de seg innenfor det støttede administrative omfanget.
Nettverksveien er en vedvarende avhengighet og ikke et oppsettsteg. Hvis den private forbindelsen forsvinner, fortsetter serveren å kjøre med bufret legitimasjon til noe trenger katalogen, og da kommer feilen i en programlogg og ikke ved siden av konfigurasjonen som ble endret.
Microsofts veiledning for Windows Server-tilkobling lister opp de støttede forutsetningene for arbeidsflyten med administrert domene. Les den opp mot de tre beslutningene ovenfor, og behandle enhver avvikelse som en grunn til å stoppe og ikke som en detalj som skal omgås.