Overwegingen en configuratieopties voor het ontwerpen van virtuele netwerken voor Microsoft Entra Domain Services
Microsoft Entra Domain Services biedt verificatie- en beheerservices voor andere toepassingen en workloads. Netwerkconnectiviteit is een belangrijk onderdeel. Zonder correct geconfigureerde virtuele netwerkbronnen kunnen toepassingen en workloads niet communiceren met en de functies van Domain Services gebruiken. Plan uw vereisten voor het virtuele netwerk om ervoor te zorgen dat Domain Services uw toepassingen en workloads naar behoefte kan leveren.
In dit artikel vindt u een overzicht van ontwerpoverwegingen en vereisten voor een virtueel Azure-netwerk ter ondersteuning van Domain Services.
Ontwerp van virtueel Azure-netwerk
Als u netwerkconnectiviteit wilt bieden en toepassingen en services wilt toestaan om te verifiëren bij een door Domain Services beheerd domein, gebruikt u een virtueel Azure-netwerk en -subnet. In het ideale geval moet het beheerde domein worden geïmplementeerd in een eigen virtueel netwerk.
U kunt een afzonderlijk toepassingssubnet in hetzelfde virtuele netwerk opnemen om uw beheer-VM of lichte toepassingsworkloads te hosten. Een afzonderlijk virtueel netwerk voor grotere of complexe toepassingsworkloads, gekoppeld aan het virtuele Domain Services-netwerk, is meestal het meest geschikte ontwerp.
Andere ontwerpen zijn geldig, mits u voldoet aan de vereisten die worden beschreven in de volgende secties voor het virtuele netwerk en subnet.
Wanneer u het virtuele netwerk voor Domain Services ontwerpt, zijn de volgende overwegingen van toepassing:
- Domain Services moeten worden geïmplementeerd in dezelfde Azure-regio als uw virtuele netwerk.
- Op dit moment kunt u slechts één beheerd domein per Microsoft Entra-tenant implementeren. Het beheerde domein wordt geïmplementeerd in één regio. Zorg ervoor dat u een virtueel netwerk maakt of selecteert in een regio die Domain Services ondersteunt.
- Overweeg de nabijheid van andere Azure-regio's en de virtuele netwerken waarop uw toepassingsworkloads worden gehost.
- Als u de latentie wilt minimaliseren, houdt u uw kerntoepassingen dicht bij of in dezelfde regio als het subnet van het virtuele netwerk voor uw beheerde domein. U kunt peering van virtuele netwerken of VPN-verbindingen (Virtual Private Network) tussen virtuele Azure-netwerken gebruiken. Deze verbindingsopties worden in een volgende sectie besproken.
- Het virtuele netwerk kan niet afhankelijk zijn van andere DNS-services dan die services die worden geleverd door het beheerde domein.
- Domain Services biedt een eigen DNS-service. Het virtuele netwerk moet worden geconfigureerd voor het gebruik van deze DNS-serviceadressen. Naamomzetting voor extra naamruimten kan worden uitgevoerd met behulp van voorwaardelijke doorstuurservers.
- U kunt geen aangepaste DNS-serverinstellingen gebruiken om query's van andere DNS-servers, waaronder op VM's, om te leiden. Resources in het virtuele netwerk moeten gebruikmaken van de DNS-service die wordt geleverd door het beheerde domein.
Belangrijk
U kunt Domain Services niet verplaatsen naar een ander virtueel netwerk nadat u de service hebt ingeschakeld.
Een beheerd domein maakt verbinding met een subnet in een virtueel Azure-netwerk. Ontwerp dit subnet voor Domain Services met de volgende overwegingen:
Een beheerd domein moet worden geïmplementeerd in een eigen subnet. Het gebruik van een bestaand subnet, gatewaysubnet of instellingen voor externe gateways in de peering van het virtuele netwerk wordt niet ondersteund.
Er wordt een netwerkbeveiligingsgroep gemaakt tijdens de implementatie van een beheerd domein. Deze groep bevat de vereiste regels voor de juiste servicecommunicatie.
- Maak of gebruik geen netwerkbeveiligingsgroep met uw eigen aangepaste regels.
Voor een beheerd domein zijn 3-5 IP-adressen vereist. Zorg ervoor dat het IP-adresbereik van uw subnet dit aantal adressen kan opgeven.
- Als u de beschikbare IP-adressen beperkt, kan voorkomen dat het beheerde domein twee domeincontrollers onderhoudt.
Notitie
Gebruik geen openbare IP-adressen voor virtuele netwerken en hun subnetten vanwege de volgende problemen:
Overschrijding van het IP-adres: openbare IPv4-ip-adressen zijn beperkt en hun vraag overschrijdt vaak het beschikbare aanbod. Er zijn mogelijk overlappende IP-adressen met openbare eindpunten.
Beveiligingsrisico's: Als u openbare IP-adressen gebruikt voor virtuele netwerken, worden uw apparaten rechtstreeks aan internet blootgesteld, waardoor het risico op onbevoegde toegang en mogelijke aanvallen toeneemt. Zonder de juiste beveiligingsmaatregelen kunnen uw apparaten kwetsbaar worden voor verschillende bedreigingen.
Complexiteit: het beheren van een virtueel netwerk met openbare IP-adressen kan complexer zijn dan het gebruik van privé-IP-adressen, omdat hiervoor externe IP-bereiken nodig zijn en de juiste netwerksegmentatie en -beveiliging moeten worden gegarandeerd.
Het wordt sterk aanbevolen om privé-IP-adressen te gebruiken. Als u een openbaar IP-adres gebruikt, moet u ervoor zorgen dat u de eigenaar/toegewezen gebruiker bent van de gekozen IP-adressen in het openbare bereik dat u hebt gekozen.
In het volgende voorbeelddiagram ziet u een geldig ontwerp waarbij het beheerde domein een eigen subnet heeft, er een gatewaysubnet is voor externe connectiviteit en toepassingsworkloads zich in een verbonden subnet in het virtuele netwerk bevinden:
Verbinding maken van het virtuele Domain Services-netwerk
Zoals u in de vorige sectie hebt genoteerd, kunt u slechts een beheerd domein maken in één virtueel netwerk in Azure en kan er slechts één beheerd domein worden gemaakt per Microsoft Entra-tenant. Op basis van deze architectuur moet u mogelijk een of meer virtuele netwerken verbinden die uw toepassingsworkloads hosten met het virtuele netwerk van uw beheerde domein.
U kunt toepassingsworkloads verbinden die worden gehost in andere virtuele Azure-netwerken met behulp van een van de volgende methoden:
- Peering op virtueel netwerk
- Virtueel particulier netwerk (VPN)
Peering op virtueel netwerk
Peering van virtuele netwerken is een mechanisme dat twee virtuele netwerken in dezelfde regio verbindt via het Backbone-netwerk van Azure. Wereldwijde peering van virtuele netwerken kan een virtueel netwerk verbinden tussen Azure-regio's. Zodra de twee virtuele netwerken zijn gekoppeld, kunnen resources, zoals VM's, rechtstreeks met elkaar communiceren met behulp van privé-IP-adressen. Met peering voor virtuele netwerken kunt u een beheerd domein implementeren met uw toepassingsworkloads die zijn geïmplementeerd in andere virtuele netwerken.
Zie het overzicht van peering van virtuele Azure-netwerken voor meer informatie.
Virtual Private Networking (VPN)
U kunt een virtueel netwerk op dezelfde manier verbinden met een ander virtueel netwerk (VNet-naar-VNet) als u een virtueel netwerk kunt configureren op een on-premises sitelocatie. Beide verbindingen gebruiken een VPN-gateway om een beveiligde tunnel te maken met IPsec/IKE. Met dit verbindingsmodel kunt u het beheerde domein implementeren in een virtueel Azure-netwerk en vervolgens on-premises locaties of andere clouds verbinden.
Lees Een VNet-naar-VNet-VPN-gatewayverbinding configureren met behulp van het Microsoft Entra-beheercentrum voor meer informatie over het gebruik van virtuele privénetwerken.
Naamomzetting bij het verbinden van virtuele netwerken
Virtuele netwerken die zijn verbonden met het virtuele netwerk van het beheerde domein hebben doorgaans hun eigen DNS-instellingen. Wanneer u virtuele netwerken verbindt, wordt naamomzetting niet automatisch geconfigureerd voor het verbindende virtuele netwerk om services op te lossen die worden geleverd door het beheerde domein. Naamomzetting voor de verbonden virtuele netwerken moet worden geconfigureerd om toepassingsworkloads in staat te stellen het beheerde domein te vinden.
U kunt naamomzetting inschakelen met behulp van voorwaardelijke DNS-doorstuurservers op de DNS-server die de virtuele netwerken ondersteunen of met behulp van dezelfde DNS-IP-adressen van het virtuele netwerk van het beheerde domein.
Netwerkbronnen die worden gebruikt door Domain Services
Een beheerd domein maakt enkele netwerkresources tijdens de implementatie. Deze resources zijn nodig voor een geslaagde werking en het beheer van het beheerde domein en moeten niet handmatig worden geconfigureerd.
Vergrendel de netwerkresources die worden gebruikt door Domain Services niet. Als netwerkresources worden vergrendeld, kunnen ze niet worden verwijderd. Wanneer domeincontrollers in dat geval opnieuw moeten worden opgebouwd, moeten nieuwe netwerkresources met verschillende IP-adressen worden gemaakt.
| Azure-resource | Beschrijving |
|---|---|
| Netwerkinterfacekaart | Domain Services host het beheerde domein op twee domeincontrollers (DC's) die worden uitgevoerd op Windows Server als virtuele Azure-machines. Elke VM heeft een virtuele netwerkinterface die verbinding maakt met het subnet van uw virtuele netwerk. |
| Dynamisch openbaar IP-adres | Domain Services communiceert met de synchronisatie- en beheerservice met behulp van een openbaar IP-adres van de Standard-SKU. Zie IP-adrestypen en toewijzingsmethoden in Azure voor meer informatie over openbare IP-adressen. |
| Azure Standard Load Balancer | Domain Services maakt gebruik van een Standard SKU-load balancer voor NAT (Network Address Translation) en taakverdeling (wanneer deze wordt gebruikt met Secure LDAP). Zie Wat is Azure Load Balancer? |
| Nat-regels (Network Address Translation) | Domain Services maakt en gebruikt twee binnenkomende NAT-regels op de load balancer voor beveiligde externe communicatie met PowerShell. Als er een standard-SKU-load balancer wordt gebruikt, heeft deze ook een uitgaande NAT-regel. Voor de Basic SKU-load balancer is er geen uitgaande NAT-regel vereist. |
| Regels voor load balancers | Wanneer een beheerd domein is geconfigureerd voor Secure LDAP op TCP-poort 636, worden er drie regels gemaakt en gebruikt op een load balancer om het verkeer te distribueren. |
Waarschuwing
Verwijder of wijzig geen netwerkresource die door Domain Services is gemaakt, zoals het handmatig configureren van de load balancer of regels. Als u een van de netwerkbronnen verwijdert of wijzigt, kan er een storing in de Domain Services-service optreden.
Netwerkbeveiligingsgroepen en vereiste poorten
Een netwerkbeveiligingsgroep (NSG) bevat een lijst met regels waarmee netwerkverkeer in een virtueel Azure-netwerk wordt toegestaan of geweigerd. Wanneer u een beheerd domein implementeert, wordt er een netwerkbeveiligingsgroep gemaakt met een set regels waarmee de service verificatie- en beheerfuncties kan bieden. Deze standaardnetwerkbeveiligingsgroep is gekoppeld aan het subnet van het virtuele netwerk waar uw beheerde domein in is geïmplementeerd.
De volgende secties hebben betrekking op netwerkbeveiligingsgroepen en vereisten voor binnenkomende en uitgaande poorten.
Binnenkomende connectiviteit
De volgende regels voor binnenkomende netwerkbeveiligingsgroepen zijn vereist voor het beheerde domein om verificatie- en beheerservices te bieden. Bewerk of verwijder deze regels voor netwerkbeveiligingsgroepen niet voor het subnet van het virtuele netwerk voor uw beheerde domein.
| Bron | Bronservicetag | Poortbereiken van bron | Bestemming | Service | Poortbereiken van doel | Protocol | Actie | Vereist | Doel |
|---|---|---|---|---|---|---|---|---|---|
| Servicetag | AzureActiveDirectoryDomainServices | * | Alle | WinRM | 5986 | TCP | Toestaan | Ja | Beheer van uw domein. |
| Servicetag | CorpNetSaw | * | Alle | RDP | 3389 | TCP | Toestaan | Optioneel | Foutopsporing voor ondersteuning |
Houd er rekening mee dat de CorpNetSaw-servicetag niet beschikbaar is via het Microsoft Entra-beheercentrum en dat de regel voor de netwerkbeveiligingsgroep voor CorpNetSaw moet worden toegevoegd met behulp van PowerShell.
Domain Services is ook afhankelijk van de standaardbeveiligingsregels AllowVnetInBound en AllowAzureLoadBalancerInBound.
De regel AllowVnetInBound staat al het verkeer binnen het VNet toe, waardoor de DC's correct kunnen communiceren en repliceren, evenals domeindeelname en andere domeinservices toestaan aan domeinleden. Zie serviceoverzicht en netwerkpoortvereisten voor Windows voor meer informatie over vereiste poorten voor Windows.
De regel AllowAzureLoadBalancerInBound is ook vereist, zodat de service correct kan communiceren via de loadbalancer om de DC's te beheren. Deze netwerkbeveiligingsgroep beveiligt Domain Services en is vereist om het beheerde domein correct te laten werken. Verwijder deze netwerkbeveiligingsgroep niet. De load balancer werkt niet correct zonder de load balancer.
Indien nodig kunt u de vereiste netwerkbeveiligingsgroep en -regels maken met behulp van Azure PowerShell.
Waarschuwing
Wanneer u een onjuist geconfigureerde netwerkbeveiligingsgroep of een door de gebruiker gedefinieerde routetabel koppelt aan het subnet waarin het beheerde domein is geïmplementeerd, kunt u de mogelijkheid van Microsoft verstoren om het domein te onderhouden en te beheren. Synchronisatie tussen uw Microsoft Entra-tenant en uw beheerde domein wordt ook onderbroken. Volg alle vermelde vereisten om een niet-ondersteunde configuratie te voorkomen die synchronisatie, patches of beheer kan verbreken.
Als u Secure LDAP gebruikt, kunt u de vereiste TCP-poort 636-regel toevoegen om zo nodig extern verkeer toe te staan. Als u deze regel toevoegt, worden de regels voor de netwerkbeveiligingsgroep niet in een niet-ondersteunde status opgeslagen. Zie Secure LDAP-toegang vergrendelen via internet voor meer informatie
De Azure SLA is niet van toepassing op implementaties die worden geblokkeerd voor updates of beheer door een onjuist geconfigureerde netwerkbeveiligingsgroep of door de gebruiker gedefinieerde routetabel. Een verbroken netwerkconfiguratie kan ook voorkomen dat beveiligingspatches worden toegepast.
Uitgaande connectiviteit
Voor uitgaande connectiviteit kunt u AllowVnetOutbound en AllowInternetOutBound behouden of uitgaand verkeer beperken met behulp van ServiceTags in de volgende tabel. De ServiceTag voor AzureUpdateDelivery moet worden toegevoegd via PowerShell. Als u Log Analytics gebruikt, voegt u EventHub toe aan uitgaande bestemmingen.
Zorg ervoor dat geen andere NSG met een hogere prioriteit de uitgaande connectiviteit weigert. Als uitgaande connectiviteit wordt geweigerd, werkt replicatie niet tussen replicasets.
| Uitgaand poortnummer | Protocol | Bron | Doel | Actie | Vereist | Doel |
|---|---|---|---|---|---|---|
| 443 | TCP | Alle | AzureActiveDirectoryDomainServices | Toestaan | Ja | Communicatie met de Microsoft Entra Domain Services-beheerservice. |
| 443 | TCP | Alle | AzureMonitor | Toestaan | Ja | Bewaking van de virtuele machines. |
| 443 | TCP | Alle | Storage | Toestaan | Ja | Communicatie met Azure Storage. |
| 443 | TCP | Alle | Microsoft Entra ID | Toestaan | Ja | Communicatie met Microsoft Entra ID. |
| 443 | TCP | Alle | AzureUpdateDelivery | Toestaan | Ja | Communicatie met Windows Update. |
| 80 | TCP | Alle | AzureFrontDoor.FirstParty | Toestaan | Ja | Download van patches van Windows Update. |
| 443 | TCP | Alle | GuestAndHybridManagement | Toestaan | Ja | Geautomatiseerd beheer van beveiligingspatches. |
Poort 5986 - beheer met externe communicatie van PowerShell
- Wordt gebruikt voor het uitvoeren van beheertaken met behulp van externe communicatie van PowerShell in uw beheerde domein.
- Zonder toegang tot deze poort kan uw beheerde domein niet worden bijgewerkt, geconfigureerd, geback-upd of bewaakt.
- U kunt binnenkomende toegang tot deze poort beperken tot de servicetag AzureActiveDirectoryDomainServices .
Poort 3389 - beheer met extern bureaublad
- Wordt gebruikt voor verbindingen met extern bureaublad met domeincontrollers in uw beheerde domein.
- De standaardregel voor netwerkbeveiligingsgroepen maakt gebruik van de CorpNetSaw-servicetag om het verkeer verder te beperken.
- Met deze servicetag kunnen alleen werkstations voor veilige toegang op het bedrijfsnetwerk van Microsoft extern bureaublad worden gebruikt voor het beheerde domein.
- Toegang is alleen toegestaan met zakelijke redenen, zoals voor beheer- of probleemoplossingsscenario's.
- Deze regel kan worden ingesteld op Weigeren en wordt alleen ingesteld op Toestaan wanneer dat nodig is. De meeste beheer- en bewakingstaken worden uitgevoerd met behulp van externe communicatie van PowerShell. RDP wordt alleen gebruikt in het zeldzame geval dat Microsoft extern verbinding moet maken met uw beheerde domein voor geavanceerde probleemoplossing.
U kunt de CorpNetSaw-servicetag niet handmatig selecteren in de portal als u deze regel voor netwerkbeveiligingsgroepen probeert te bewerken. U moet Azure PowerShell of de Azure CLI gebruiken om handmatig een regel te configureren die gebruikmaakt van de CorpNetSaw-servicetag .
U kunt bijvoorbeeld het volgende script gebruiken om een regel te maken die RDP toestaat:
Get-AzNetworkSecurityGroup -Name "nsg-name" -ResourceGroupName "resource-group-name" | Add-AzNetworkSecurityRuleConfig -Name "new-rule-name" -Access "Allow" -Protocol "TCP" -Direction "Inbound" -Priority "priority-number" -SourceAddressPrefix "CorpNetSaw" -SourcePortRange "*" -DestinationPortRange "3389" -DestinationAddressPrefix "*" | Set-AzNetworkSecurityGroup
Door de gebruiker gedefinieerde routes
Door de gebruiker gedefinieerde routes worden niet standaard gemaakt en zijn niet nodig om Domain Services correct te laten werken. Als u routetabellen moet gebruiken, moet u geen wijzigingen aanbrengen in de route 0.0.0.0 . Wijzigingen in deze route verstoren Domain Services en plaatst het beheerde domein in een niet-ondersteunde status.
U moet ook binnenkomend verkeer routeren van de IP-adressen die zijn opgenomen in de respectieve Azure-servicetags naar het subnet van het beheerde domein. Zie Azure IP Ranges and Service Tags - Public Cloud (Openbare cloud) voor meer informatie over servicetags en het bijbehorende IP-adres.
Let op
Deze IP-bereiken van Het Azure-datacenter kunnen zonder kennisgeving worden gewijzigd. Zorg ervoor dat u processen hebt om te controleren of u de meest recente IP-adressen hebt.
Volgende stappen
Zie de volgende artikelen voor meer informatie over enkele netwerkresources en verbindingsopties die door Domain Services worden gebruikt: