Ansluta en Azure VM till Entra Domain Services: besluta först

Tre beslut står framför en Windows Server VM som måste använda en hanterad katalog, och anslutningskommandot är det minsta av dem. Väljer du fel katalogmodell lyckas anslutningen medan programmet fortfarande inte kan autentisera. Går namnmatchningen fel dyker felet upp på en plats som ser ut som ett problem med autentiseringsuppgifter.

Bestäm modellen, matchningen och kontot innan du rör servern, sedan körs kommandot en gång.

Vilken av de tre anslutningarna du egentligen vill ha

En enhetsanslutning registrerar en maskin hos Microsoft Entra ID för villkorlig åtkomst och enkel inloggning, och ger inte arbetsbelastningen någon Kerberos-biljett till en domän i lokal stil. En traditionell domänanslutning binder ett datorobjekt i en katalog och ger det ett maskinkonto, grupprincip och domänautentisering. En hanterad domän erbjuder den andra modellen som en tjänst. Namnen låter lika och resultaten inte.

Bara de två sista omfattar en domänkontrollant i vanlig mening, och bara det hanterade alternativet tar bort servrarna från din patchlista.

Beslutet beror oftast på programmet och inte på preferens. Programvara som vill ha en LDAP-bindning, ett tjänstekonto med ett SPN eller grupprincipobjekt hör i domänmodellen. Programvara som bara behöver känna till användarens identitet på en företagsenhet hör oftast inte dit.

DNS-vägen avgör om anslutningen kan slutföras

En domänanslutning börjar med en locator-sökning efter domänens kontrollantposter, så namnmatchningen måste fungera innan några autentiseringsuppgifter kontrolleras. Peka VM:en mot den hanterade domänens katalogadresser, antingen via det virtuella nätverkets DNS-inställningar eller via en villkorad vidarebefordrare som bara skickar den namnrymden dit. En vidarebefordrare som är begränsad till namnrymden är oftast det säkrare valet, eftersom den lämnar resten av VM:ens matchning i fred.

Testa locatorn och inte ett bart värdnamn. En ping mot domännamnet bevisar nästan ingenting, medan en SRV-fråga efter domänkontrollantposterna antingen returnerar de förväntade målen eller misslyckas direkt:

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

Byt ut domännamnet och de två adresserna mot värdena från konfigurationen av den hanterade domänen; siffrorna här är exempel. Om frågan returnerar svar från en annan zon använder VM:en en matchare som inte vidarebefordrar den hanterade namnrymden, och ingen mängd upprepningar av anslutningen ändrar det.

Håll arbetsbelastningen utanför det undernät som den hanterade domänen reserverar för sina egna tjänsteresurser, och håll katalogportarna på den privata vägen. Offentlig exponering av dessa portar är ingen genväg; det är en annan design med en annan riskprofil.

Kontots lämplighet kontrolleras före maskinen

Kontot som utför anslutningen behöver tillstånd att skapa ett datorobjekt i målbehållaren, och det måste kunna autentisera mot den hanterade domänen. Ett konto enbart i molnet som skapades innan den hanterade domänen fanns saknar kanske det lösenordsavledda material som domänen behöver, och en lösenordsändring eller återställning genererar det på nytt. Den detaljen förklarar en klass anslutningsfel som ser ut som fel lösenord när lösenordet är rätt. Testa autentiseringsuppgiften mot domänen innan underhållsfönstret öppnas.

Synkroniserade hybridkonton har egna förutsättningar som ett synligt användarobjekt inte uppfyller på egen hand. Att vara listad i katalogen är inte samma sak som att kunna hämta en biljett från den, så testa kontot före underhållsfönstret och inte under det.

Delegera anslutningsrätten snävt. Att ge varje framtida serveranvändare domänadministratörsmedlemskap så att en registrering kan ske är ett permanent beviljande för ett tillfälligt problem.

Själva anslutningen är ett enda kommando

Med modellen vald, DNS som svarar och kontot lämpligt är åtgärden den vanliga Windows-åtgärden. Prompten håller lösenordet utanför skript och skallhistorik:

Add-Computer -DomainName "ds.corp.example" -Credential (Get-Credential) -PassThru

Kommandot startar inte om maskinen av sig självt i den här formen, så omstarten sker enligt underhållsplanen och med återställningsvägen fortfarande tillgänglig. En server som redan är ansluten till en annan domän behöver en migreringsplan, inte en andra anslutning ovanpå den första.

Anteckna behållaren som datorobjektet hamnade i och kontot som skapade det. Båda spelar roll när maskinen måste anslutas igen efter en ombyggnad, och inget av dem är uppenbart från servern i efterhand.

Vad medlemskap inte ger

Domänmedlemskap gör ingen till lokal administratör och ger inte åtkomst till fjärrskrivbord eller filresurser. Dessa rättigheter konfigureras separat, och på en hanterad domän håller de sig inom dess stödda administrativa omfång.

Nätverksvägen är ett bestående beroende och inte ett installationssteg. Om den privata anslutningen försvinner fortsätter servern att köra med cachelagrade autentiseringsuppgifter tills något behöver katalogen, och då kommer felet i en programlogg och inte bredvid konfigurationen som ändrades.

Microsofts vägledning för Windows Server-anslutning räknar upp de stödda förutsättningarna för arbetsflödet med hanterad domän. Läs den mot de tre besluten ovan och behandla varje avvikelse som ett skäl att stanna och inte som en detalj att kringgå.