Tilslut en Azure VM til Entra Domain Services: beslut først
Tre beslutninger kommer før tilslutningen: den katalogmodel, arbejdsbelastningen har brug for, privat DNS, der opløser domænet, og en konto, der kan godkende.
Tre beslutninger står foran en Windows Server VM, der skal bruge en administreret katalogtjeneste, og tilslutningskommandoen er den mindste af dem. Vælger du den forkerte katalogmodel, lykkes tilslutningen, mens programmet stadig ikke kan godkende. Tager du navneopløsningen fejl, viser fejlen sig på et punkt, der ligner et legitimationsproblem.
Afgør modellen, opløsningen og kontoen, før du rører serveren, og så kører kommandoen én gang.
Hvilken af de tre tilslutninger du egentlig vil have
En enhedstilslutning registrerer en maskine hos Microsoft Entra ID til betinget adgang og enkeltlogon og giver ikke arbejdsbelastningen nogen Kerberos-billet til et domæne i lokal stil. En traditionel domænetilslutning binder et computerobjekt ind i en katalog og giver det en maskinkonto, gruppepolitik og domænegodkendelse. Et administreret domæne leverer den anden model som en tjeneste. Navnene lyder ens, og resultaterne gør ikke.
Kun de sidste to involverer en domænecontroller i sædvanlig forstand, og kun den administrerede mulighed fjerner serverne fra din patchliste.
Beslutningen afhænger normalt af programmet og ikke af præference. Software, der vil have en LDAP-binding, en tjenestekonto med et SPN eller gruppepolitikobjekter, hører i domænemodellen. Software, der blot skal kende brugerens identitet på en virksomhedsenhed, hører normalt 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-stien afgør, om tilslutningen kan gennemføres
En domænetilslutning begynder med et locator-opslag efter domænets controllerposter, så navneopløsningen skal virke, før nogen legitimationsoplysning kontrolleres. Peg VM'en mod den administrerede domænes katalogadresser, enten via det virtuelle netværks DNS-indstillinger eller via en betinget videresender, der kun sender det navneområde derhen. En videresender afgrænset til navneområdet er normalt det sikrere valg, fordi den lader resten af VM'ens opløsning være i fred.
Test locatoren i stedet for et bart værtsnavn. En ping til domænenavnet beviser næsten intet, mens en SRV-forespørgsel på domænecontrollerposterne enten returnerer de forventede mål eller fejler med det samme:
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
Erstat domænenavnet og de to adresser med værdierne fra din administrerede domænekonfiguration; tallene her er eksempler. Hvis forespørgslen returnerer en anden zones svar, bruger VM'en en resolver, der ikke videresender det administrerede navneområde, og ingen mængde gentagelser af tilslutningen ændrer det.
Hold arbejdsbelastningen uden for det undernet, som det administrerede domæne reserverer til sine egne tjenesteressourcer, og hold katalogportene på den private sti. Offentlig eksponering af disse porte er ikke en genvej; det er et andet design med en anden risikoprofil.
Kontoens egnethed kontrolleres før maskinen
Den konto, der udfører tilslutningen, skal have tilladelse til at oprette et computerobjekt i målcontaineren og skal kunne godkende mod det administrerede domæne. En konto, der kun findes i skyen og blev oprettet, før det administrerede domæne fandtes, mangler måske det adgangskodeafledte materiale, som domænet har brug for, og en ændring eller nulstilling af adgangskoden gendanner det. Den detalje forklarer en klasse af tilslutningsfejl, der ligner forkerte adgangskoder, når adgangskoden er rigtig. Test legitimationsoplysningen mod domænet, før vedligeholdelsesvinduet åbner.
Synkroniserede hybridkonti har deres egne forudsætninger, som et synligt brugerobjekt ikke opfylder alene. Det er ikke det samme at stå i kataloget som at kunne hente en billet fra det, så test kontoen før vedligeholdelsesvinduet og ikke under det.
Delegér tilslutningsretten snævert. At give enhver fremtidig serverbruger domæneadministrator-medlemskab, så én tilmelding kan ske, er en permanent bevilling til et midlertidigt problem.
Selve tilslutningen er én kommando
Med modellen valgt, DNS der svarer, og kontoen egnet er operationen den sædvanlige Windows-operation. Prompten holder adgangskoden ude af scripts og shell-historik:
Add-Computer -DomainName "ds.corp.example" -Credential (Get-Credential) -PassThru
Kommandoen genstarter ikke maskinen af sig selv i denne form, så genstarten sker under vedligeholdelsesplanen og med gendannelsesstien stadig tilgængelig. En server, der allerede er tilsluttet et andet domæne, har brug for en migreringsplan, ikke en anden tilslutning oven på den første.
Notér den container, computerobjektet landede i, og den konto, der oprettede det. Begge har betydning, når maskinen skal tilsluttes igen efter en genopbygning, og ingen af dem er indlysende fra serveren bagefter.
Hvad medlemskab ikke giver
Domænemedlemskab gør ingen til lokal administrator og giver ikke adgang til fjernskrivebord eller filshare. Disse rettigheder konfigureres separat, og på et administreret domæne bliver de inden for dets understøttede administrative område.
Netværksstien er en vedvarende afhængighed og ikke et opsætningstrin. Hvis den private forbindelse forsvinder, kører serveren videre med cachelagrede legitimationsoplysninger, indtil noget har brug for kataloget, og så ankommer fejlen i en programlog og ikke ved siden af den konfiguration, der blev ændret.
Microsofts vejledning til Windows Server-tilslutning oplister de understøttede forudsætninger for arbejdsgangen med administreret domæne. Læs den op mod de tre beslutninger ovenfor, og behandl enhver uoverensstemmelse som en grund til at stoppe og ikke som en detalje, der skal omgås.