Een Azure VM koppelen aan Entra Domain Services: eerst beslissen

Drie beslissingen staan voor een Windows Server VM die een beheerde directory moet gebruiken, en de koppelopdracht is de kleinste ervan. Kies het verkeerde directorymodel en de koppeling slaagt terwijl de toepassing zich nog steeds niet kan authenticeren. Ga de naamresolutie mis en de fout verschijnt op een punt dat op een aanmeldgegevensprobleem lijkt.

Bepaal het model, de resolutie en het account voordat u de server aanraakt, dan draait de opdracht één keer.

Welke van de drie koppelingen u echt wilt

Een apparaatkoppeling registreert een machine bij Microsoft Entra ID voor voorwaardelijke toegang en eenmalige aanmelding, en geeft de workload geen Kerberos-ticket naar een domein in lokale stijl. Een traditionele domeinkoppeling bindt een computerobject in een directory en geeft het een machineaccount, groepsbeleid en domeinauthenticatie. Een beheerd domein levert dat tweede model als dienst. De namen klinken vergelijkbaar en de uitkomsten niet.

Alleen de laatste twee omvatten een domeincontroller in de gewone zin, en alleen de beheerde optie haalt de servers van uw patchlijst.

De beslissing hangt meestal van de toepassing af en niet van voorkeur. Software die een LDAP-binding, een serviceaccount met een SPN of groepsbeleidsobjecten wil, hoort in het domeinmodel. Software die alleen de identiteit van de gebruiker op een bedrijfsapparaat hoeft te kennen, hoort daar meestal niet.

Het DNS-pad bepaalt of de koppeling kan afronden

Een domeinkoppeling begint met een locator-opzoeking voor de controllerrecords van het domein, dus naamresolutie moet werken voordat enige aanmeldgegevens worden gecontroleerd. Wijs de VM naar de directoryadressen van het beheerde domein, via de DNS-instellingen van het virtuele netwerk of via een voorwaardelijke doorstuurder die alleen die naamruimte daarheen stuurt. Een doorstuurder die tot de naamruimte beperkt is, is meestal de veiligere keuze, omdat die de rest van de resolutie van de VM met rust laat.

Test de locator en niet een kale hostnaam. Een ping naar de domeinnaam bewijst bijna niets, terwijl een SRV-query voor de controllerrecords ofwel de verwachte doelen teruggeeft ofwel onmiddellijk mislukt:

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

Vervang de domeinnaam en de twee adressen door de waarden uit uw configuratie van het beheerde domein; de getallen hier zijn voorbeelden. Als de query antwoorden uit een andere zone teruggeeft, gebruikt de VM een resolver die de beheerde naamruimte niet doorstuurt, en geen enkele herhaling van de koppeling verandert dat.

Houd de workload buiten het subnet dat het beheerde domein voor zijn eigen dienstbronnen reserveert, en houd de directorypoorten op het privépad. Openbare blootstelling van die poorten is geen kortere weg; het is een ander ontwerp met een ander risicoprofiel.

De geschiktheid van het account wordt vóór de machine gecontroleerd

Het account dat de koppeling uitvoert, heeft toestemming nodig om een computerobject in de doelcontainer te maken, en het moet zich tegen het beheerde domein kunnen authenticeren. Een alleen-cloudaccount dat is aangemaakt voordat het beheerde domein bestond, mist mogelijk het van het wachtwoord afgeleide materiaal dat het domein nodig heeft, en een wachtwoordwijziging of -reset genereert het opnieuw. Dat detail verklaart een klasse koppelingsfouten die op verkeerde wachtwoorden lijken terwijl het wachtwoord juist is. Test de aanmeldgegevens tegen het domein voordat het onderhoudsvenster opengaat.

Gesynchroniseerde hybride accounts hebben hun eigen voorwaarden waaraan een zichtbaar gebruikersobject niet alleen voldoet. In de directory vermeld staan is niet hetzelfde als er een ticket uit kunnen halen, dus test het account vóór het onderhoudsvenster en niet eronder.

Delegeer het koppelrecht nauw. Elke toekomstige servergebruiker lidmaatschap van domeinbeheerder geven zodat één inschrijving kan plaatsvinden, is een permanente toekenning voor een tijdelijk probleem.

De koppeling zelf is één opdracht

Met het model gekozen, DNS die antwoordt en het account geschikt, is de handeling de gewone Windows-handeling. De prompt houdt het wachtwoord buiten scripts en shellgeschiedenis:

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

De opdracht start de machine in deze vorm niet zelf opnieuw, dus de herstart gebeurt volgens het onderhoudsplan en met het herstelpad nog beschikbaar. Een server die al aan een ander domein is gekoppeld, heeft een migratieplan nodig, niet een tweede koppeling over de eerste heen.

Noteer de container waarin het computerobject terechtkwam en het account dat het heeft gemaakt. Beide zijn van belang wanneer de machine na een herbouw opnieuw moet worden gekoppeld, en geen van beide is achteraf vanaf de server duidelijk.

Wat lidmaatschap niet geeft

Domeinlidmaatschap maakt niemand lokaal beheerder en geeft geen toegang tot extern bureaublad of bestandsshares. Die rechten worden apart geconfigureerd, en op een beheerd domein blijven ze binnen het ondersteunde administratieve bereik.

Het netwerkpad is een blijvende afhankelijkheid en geen installatiestap. Als de privéverbinding verdwijnt, blijft de server draaien met gebufferde aanmeldgegevens tot iets de directory nodig heeft, en dan komt de fout in een toepassingslog en niet naast de configuratie die is gewijzigd.

Microsofts richtlijnen voor het koppelen van Windows Server sommen de ondersteunde voorwaarden op voor de werkstroom met een beheerd domein. Lees ze tegen de drie beslissingen hierboven, en behandel elke afwijking als een reden om te stoppen en niet als een detail om te omzeilen.