Überlegungen zum Entwurf virtueller Netzwerke und Konfigurationsoptionen für Microsoft Entra Domain Services
Microsoft Entra Domain Services stellt Authentifizierungs- und Verwaltungsdienste für andere Anwendungen und Workloads bereit. Die Netzwerkkonnektivität ist dabei eine Schlüsselkomponente. Ohne ordnungsgemäß konfigurierte virtuelle Netzwerkressourcen können Anwendungen und Workloads nicht mit den von Domain Services bereitgestellten Funktionen kommunizieren und diese auch nicht verwenden. Planen Sie die Anforderungen für Ihr virtuelles Netzwerk, um sicherzustellen, dass Domain Services Ihre Anwendungen und Workloads nach Bedarf bedienen kann.
In diesem Artikel werden Überlegungen und Anforderungen an den Entwurf eines virtuellen Azure-Netzwerks zur Unterstützung von Domain Services erörtert.
Entwurf von Azure Virtual Network
Um die Netzwerkkonnektivität bereitzustellen und Anwendungen und Dienste zur Authentifizierung bei einer verwalteten Domain Services-Domäne zu ermöglichen, verwenden Sie ein virtuelles Azure-Netzwerk und ein Subnetz. Im Idealfall sollte die verwaltete Domäne in einem eigenen virtuellen Netzwerk bereitgestellt werden.
Sie können ein separates Anwendungssubnetz in dasselbe virtuelle Netzwerk einbeziehen, um Ihre Verwaltungs-VM oder leichte Anwendungsworkloads zu hosten. Ein separates virtuelles Netzwerk für größere oder komplexe Anwendungsworkloads, das per Peering mit dem virtuellen Domain Services-Netzwerk verbunden ist, stellt in der Regel den am besten geeignete Entwurf dar.
Andere Entwurfsmöglichkeiten sind zulässig, sofern Sie die in den folgenden Abschnitten für das virtuelle Netzwerk und das Subnetz beschriebenen Anforderungen erfüllen.
Beim Entwerfen des virtuellen Netzwerks für Domain Services gelten die folgenden Überlegungen:
- Domain Services muss in derselben Azure-Region wie Ihr virtuelles Netzwerk bereitgestellt werden.
- Derzeit können Sie nur eine verwaltete Domäne pro Microsoft Entra-Mandant bereitstellen. Die verwaltete Domäne wird in einer einzelnen Region bereitgestellt. Stellen Sie sicher, dass Sie ein virtuelles Netzwerk in einer Region mit Domain Services-Unterstützung erstellen oder auswählen.
- Berücksichtigen Sie die Nähe zu anderen Azure-Regionen und zu den virtuellen Netzwerken, die Ihre Anwendungsworkloads hosten.
- Um die Latenzzeit zu minimieren, belassen Sie Ihre Kernanwendungen in der Nähe oder in derselben Region wie das Subnetz des virtuellen Netzwerks für Ihre verwaltete Domäne. Sie können das Peering virtueller Netzwerke oder VPN-Verbindungen (Virtual Private Network) zwischen virtuellen Azure-Netzwerken verwenden. Diese Verbindungsoptionen werden in einem nachfolgenden Abschnitt erläutert.
- Das virtuelle Netzwerk darf sich nur die von der verwalteten Domäne bereitgestellten DNS-Dienste verlassen.
- Domain Services stellt einen eigenen DNS-Dienst bereit. Das virtuelle Netzwerk muss so konfiguriert sein, dass es diese DNS-Dienstadressen verwendet. Die Namensauflösung für weitere Namespaces kann mithilfe von bedingten Weiterleitungen erfolgen.
- Sie können keine benutzerdefinierten DNS-Servereinstellungen verwenden, um Abfragen von anderen DNS-Servern weiterzuleiten, einschließlich VMs. Ressourcen im virtuellen Netzwerk müssen den von der verwalteten Domäne bereitgestellten DNS-Dienst verwenden.
Wichtig
Nach dem Aktivieren des Diensts können Sie Domain Services nicht in ein anderes virtuelles Netzwerk verschieben.
Eine verwaltete Domäne stellt eine Verbindung mit einem Subnetz in einem virtuellen Azure-Netzwerk her. Berücksichtigen Sie beim Entwerfen dieses Subnetzes für Domain Services Folgendes:
Eine verwaltete Domäne muss in einem eigenen Subnetz bereitgestellt werden. Die Verwendung eines vorhandenen Subnetzes, eines Gatewaysubnetzes oder von Remotegatewayeinstellungen im Peering virtueller Netzwerke wird nicht unterstützt.
Während der Bereitstellung einer verwalteten Domäne wird eine Netzwerksicherheitsgruppe erstellt. Diese Netzwerksicherheitsgruppe enthält die erforderlichen Regeln für eine korrekte Dienstkommunikation.
- Erstellen oder verwenden Sie keine bestehende Netzwerksicherheitsgruppe mit Ihren eigenen benutzerdefinierten Regeln.
Für eine verwaltete Domäne sind 3–5 IP-Adressen erforderlich. Stellen Sie sicher, dass der IP-Adressbereich Ihres Subnetzes diese Anzahl von Adressen bereitstellen kann.
- Die Einschränkung der verfügbaren IP-Adressen kann verhindern, dass die verwaltete Domäne zwei Domänencontroller verwaltet.
Hinweis
Aufgrund der folgenden Probleme sollten Sie keine öffentlichen IP-Adressen für virtuelle Netzwerke und deren Subnetze verwenden:
Knappheit der IP-Adresse: Öffentliche IPv4-IP-Adressen sind begrenzt, und die Nachfrage übersteigt häufig das verfügbare Angebot. Außerdem gibt es potenziell überlappende IP-Adressen mit öffentlichen Endpunkten.
Sicherheitsrisiken: Bei der Verwendung öffentlicher IP-Adressen für virtuelle Netzwerke sind Ihre Geräte direkt dem Internet ausgesetzt, wodurch das Risiko von nicht autorisiertem Zugriff und potenziellen Angriffen erhöht wird. Ohne geeignete Sicherheitsmaßnahmen können Ihre Geräte anfällig für verschiedene Bedrohungen werden.
Komplexität: Die Verwaltung eines virtuellen Netzwerks mit öffentlichen IP-Adressen kann komplexer sein als bei der Verwendung privater IP-Adressen, da der Umgang mit externen IP-Bereichen und die Gewährleistung einer angemessenen Netzwerksegmentierung und -sicherheit erforderlich sind.
Es wird dringend empfohlen, private IP-Adressen zu verwenden. Wenn Sie eine öffentliche IP-Adresse verwenden, stellen Sie sicher, dass Sie der Besitzer/dedizierte Benutzer der ausgewählten IP-Adressen in dem von Ihnen ausgewählten öffentlichen Bereich sind.
Das folgende Beispieldiagramm zeigt einen gültigen Entwurf, bei dem die verwaltete Domäne über ein eigenes Subnetz verfügt, ein Gatewaysubnetz für externe Verbindungen vorhanden ist und Anwendungsworkloads in einem verbundenen Subnetz innerhalb des virtuellen Netzwerks liegen:
Verbindungen mit dem virtuellen Domain Services-Netzwerk
Wie im vorherigen Abschnitt erwähnt, können Sie nur eine verwaltete Domäne in einem einzelnen virtuellen Netzwerk in Azure erstellen, und pro Microsoft Entra-Mandant kann nur eine verwaltete Domäne erstellt werden. Auf der Grundlage dieser Architektur müssen Sie möglicherweise ein oder mehrere virtuelle Netzwerke, die Ihre Anwendungsworkloads hosten, mit dem virtuellen Netzwerk der verwalteten Domäne verbinden.
Sie können Anwendungsworkloads, die in anderen virtuellen Azure-Netzwerken gehostet werden, mit einer der folgenden Methoden verbinden:
- Peering in virtuellen Netzwerken
- Virtuelles privates Netzwerk (VPN)
Peering in virtuellen Netzwerken
Virtuelles Netzwerk-Peering ist ein Mechanismus, der zwei virtuelle Netzwerke über das Azure-Backbone-Netzwerk verbindet, sodass Ressourcen wie virtuelle Computer (VMs) direkt mit privaten IP-Adressen miteinander kommunizieren können. Virtuelles Netzwerk-Peering unterstützt sowohl regionale Peerings, die VNets innerhalb derselben Azure-Region verbinden, als auch globales Peering virtueller Netzwerke, das VNets in verschiedenen Azure-Regionen verbindet. Mit dieser Flexibilität können Sie unabhängig von regionalen Standorten eine verwaltete Domäne mit Ihren Anwendungsworkloads in mehreren virtuellen Netzwerken bereitstellen.
Weitere Informationen finden Sie unter Übersicht über das Peering virtueller Azure-Netzwerke.
Virtuelle private Netzwerke (Virtual Private Networks, VPNs)
Sie können ein virtuelles Netzwerk mit einem anderen virtuellen Netzwerk (VNet-to-VNet) auf dieselbe Weise verbinden, wie Sie ein virtuelles Netzwerk an einem lokalen Standort konfigurieren können. Beide Verbindungen verwenden ein VPN-Gateway, um mit IPsec/IKE einen sicheren Tunnel zu erstellen. Mit diesem Verbindungsmodell können Sie die verwaltete Domäne in einem virtuellen Azure-Netzwerk einsetzen und dann lokale Standorte oder andere Clouds verbinden.
Weitere Informationen zur Verwendung von virtuellen privaten Netzwerken finden Sie unter Konfigurieren einer VNet-zu-VNet-VPN-Gatewayverbindung über das Microsoft Entra Admin Center.
Namensauflösung beim Verbinden virtueller Netzwerke
Virtuelle Netzwerke, die mit dem virtuellen Netzwerk der verwalteten Domäne verbunden sind, verfügen in der Regel über eigene DNS-Einstellungen. Wenn Sie virtuelle Netzwerke verbinden, wird die Namensauflösung für das zu verbindende virtuelle Netzwerk nicht automatisch konfiguriert, um Dienste aufzulösen, die von der verwalteten Domäne bereitgestellt werden. Die Namensauflösung in den zu verbindenden virtuellen Netzwerken muss so konfiguriert sein, dass Anwendungsworkloads die verwaltete Domäne finden können.
Sie können die Namensauflösung mit bedingten DNS-Weiterleitungen auf dem DNS-Server aktivieren, der die zu verbindenden virtuellen Netzwerke unterstützt, oder indem Sie dieselben DNS-IP-Adressen aus dem virtuellen Netzwerk der verwalteten Domäne verwenden.
Von Domain Services verwendete Netzwerkressourcen
Eine verwaltete Domäne erstellt während der Bereitstellung einige Netzwerkressourcen. Diese Ressourcen werden für den erfolgreichen Betrieb und die Verwaltung der verwalteten Domäne benötigt und sollten nicht manuell konfiguriert werden.
Sperren Sie nicht die Netzwerkressourcen, die von Domain Services verwendet werden. Wenn Netzwerkressourcen gesperrt werden, können sie nicht gelöscht werden. Wenn Domänencontroller in diesem Fall neu erstellt werden müssen, müssen neue Netzwerkressourcen mit anderen IP-Adressen erstellt werden.
| Azure-Ressource | BESCHREIBUNG |
|---|---|
| Netzwerkschnittstellenkarte | Domain Services hostet die verwaltete Domäne auf zwei Domänencontrollern (DCs), die auf Azure-VMs unter Windows Server ausgeführt werden. Jeder virtuelle Computer verfügt über eine virtuelle Netzwerkschnittstelle, die sich mit Ihrem virtuellen Subnetz verbindet. |
| Dynamische öffentliche Standard-IP-Adresse | Domain Services kommuniziert mit dem Synchronisierungs- und Verwaltungsdienst über eine öffentliche IP-Adresse mit Standard-SKU. Weitere Informationen zu öffentlichen IP-Adressen finden Sie unter IP-Adresstypen und Zuordnungsmethoden in Azure. |
| Azure Load Balancer Standard | Domain Services verwendet einen Lastenausgleich mit Standard-SKU für die Netzwerkadressenübersetzung (NAT) und den Lastenausgleich (bei Verwendung mit Secure LDAP). Weitere Informationen zu Azure Load Balancer finden Sie unter Was versteht man unter Azure Load Balancer?. |
| Regeln für die Netzwerkadressübersetzung (NAT) | Domain Services erstellt und verwendet zwei NAT-Regeln für eingehenden Datenverkehr für den Lastenausgleich für das sichere PowerShell-Remoting. Wenn ein Lastenausgleich mit Standard-SKU verwendet wird, wird ebenfalls eine NAT-Regel für ausgehenden Datenverkehr genutzt. Für den Lastenausgleich der Basic-SKU ist keine NAT-Regel für ausgehenden Datenverkehr erforderlich. |
| Lastenausgleichsregeln | Wenn eine verwaltete Domäne für sicheres LDAP am TCP-Port 636 konfiguriert ist, werden drei Regeln erstellt und für einen Lastenausgleich verwendet, um den Datenverkehr zu verteilen. |
Warnung
Löschen oder ändern Sie keine Netzwerkressourcen, die von Domain Services erstellt wurden (z. B. das manuelle Konfigurieren des Lastenausgleichs oder der Regeln). Wenn Sie eine der Netzwerkressourcen löschen oder ändern, kann es zu einem Ausfall von Domain Services kommen.
Netzwerksicherheitsgruppen und erforderliche Ports
Eine Netzwerksicherheitsgruppe (NSG) enthält eine Liste von Regeln, die den Netzwerkdatenverkehr in einem virtuellen Azure-Netzwerk gestatten oder ablehnen. Wenn Sie eine verwaltete Domäne bereitstellen, wird eine Netzwerksicherheitsgruppe mit mehreren Regeln erstellt, mit denen der Dienst Authentifizierungs- und Verwaltungsfunktionen bereitstellen kann. Diese standardmäßige Netzwerksicherheitsgruppe ist dem virtuellen Subnetz zugeordnet, in dem Ihre verwaltete Domäne bereitgestellt wird.
Die folgenden Abschnitte decken Netzwerksicherheitsgruppen und Anforderungen für eingehende und ausgehende Ports ab.
Eingehende Konnektivität
Die folgenden Regeln für eingehenden Datenverkehr für die Netzwerksicherheitsgruppe sind erforderlich, damit die verwaltete Domäne Authentifizierungs- und Verwaltungsdienste bereitstellen kann. Bearbeiten oder löschen Sie diese Regeln für die Netzwerksicherheitsgruppe nicht für das virtuelle Subnetz Ihrer verwalteten Domäne.
| `Source` | Quelldiensttag | Source port ranges | Destination | Dienst | Zielportbereiche | Protocol | Aktion | Erforderlich | Zweck |
|---|---|---|---|---|---|---|---|---|---|
| Diensttag | AzureActiveDirectoryDomainServices | * | Any | WinRM | 5986 | TCP | Allow | Ja | Verwaltung Ihrer Domäne |
| Diensttag | CorpNetSaw | * | Any | RDP | 3389 | TCP | Allow | Optional | Debuggen für Support |
Beachten Sie, dass das Diensttag CorpNetSaw nicht verfügbar ist, wenn das Microsoft Entra Admin Center verwendet wird. Die Netzwerksicherheitsgruppen-Regel für CorpNetSaw muss in diesem Fall mithilfe von PowerShell hinzugefügt werden.
Domain Services erfordert auch die Standardsicherheitsregeln „AllowVnetInBound“ und „AllowAzureLoadBalancerInBound“.
Die AllowVnetInBound-Regel lässt allen Datenverkehr innerhalb des VNet zu, sodass die DCs ordnungsgemäß kommunizieren und replizieren können sowie der Domänenbeitritt und andere Domänendienste für Domänenmitglieder zugelassen werden können. Weitere Informationen über die erforderlichen Ports für Windows finden Sie unter Dienstübersicht und Netzwerkportanforderungen für Windows.
Die Regel „AllowAzureLoadBalancerInBound“ ist ebenfalls erforderlich, damit der Dienst über den Lastenausgleich ordnungsgemäß kommunizieren kann, um die DCs zu verwalten. Diese Netzwerksicherheitsgruppe schützt Domain Services. Sie ist erforderlich, damit die verwaltete Domäne ordnungsgemäß funktioniert. Löschen Sie diese Netzwerksicherheitsgruppe nicht. Der Lastenausgleich funktioniert ohne sie nicht ordnungsgemäß.
Falls erforderlich, können Sie die erforderliche Netzwerksicherheitsgruppe und Regeln mithilfe Azure PowerShell erstellen.
Warnung
Wenn Sie eine falsch konfigurierte Netzwerksicherheitsgruppe oder eine benutzerdefinierte Routingtabelle mit dem Subnetz verknüpfen, in dem die verwaltete Domäne bereitgestellt wird, werden die Möglichkeiten von Microsoft zur Wartung und Verwaltung der Domäne möglicherweise beeinträchtigt. Die Synchronisierung zwischen Ihrem Microsoft Entra-Mandanten und Ihrer verwalteten Domäne wird ebenfalls beeinträchtigt. Beachten Sie alle aufgeführten Anforderungen, um eine nicht unterstützte Konfiguration zu vermeiden, die Probleme beim Synchronisieren, Patchen oder Verwalten zur Folge haben könnte.
Wenn Sie Secure LDAP verwenden, können Sie bei Bedarf eine Regel für den erforderlichen TCP-Port 636 hinzufügen, um externen Datenverkehr zuzulassen. Das Hinzufügen dieser Regel hat nicht zur Folge, dass Ihre NSG-Regeln in einen nicht unterstützten Zustand versetzt werden. Weitere Informationen finden Sie unter Beschränken des Secure LDAP-Zugriffs über das Internet.
Die Azure-SLA gilt nicht für Bereitstellungen, bei denen eine nicht ordnungsgemäß konfigurierte Netzwerksicherheitsgruppe oder benutzerdefinierte Routingtabelle das Durchführen von Updates oder die Verwaltung blockiert. Eine fehlerhafte Netzwerkkonfiguration kann auch die Anwendung von Sicherheitspatches verhindern.
Ausgehende Konnektivität
Für die ausgehende Konnektivität können Sie entweder weiterhin AllowVnetOutbound und AllowInternetOutBound verwenden oder den ausgehenden Datenverkehr mithilfe der in der folgenden Tabelle aufgeführten Diensttags einschränken. Wenn Sie Log Analytics verwenden, fügen Sie EventHub zu ausgehenden Zielen hinzu.
Stellen Sie sicher, dass keine andere NSG mit höherer Priorität die ausgehende Konnektivität verweigert. Wenn die ausgehende Konnektivität verweigert wird, funktioniert die Replikation zwischen Replikatgruppen nicht.
| Nummer des ausgehenden Ports | Protocol | Quelle | Ziel | Aktion | Erforderlich | Zweck |
|---|---|---|---|---|---|---|
| 443 | TCP | Any | AzureActiveDirectoryDomainServices | Allow | Ja | Kommunikation mit dem Microsoft Entra Domain Services-Verwaltungsdienst. |
| 443 | TCP | Any | AzureMonitor | Allow | Ja | Überwachung der VMs |
| 443 | TCP | Any | Speicher | Allow | Ja | Kommunikation mit Azure Storage |
| 443 | TCP | Beliebig | Microsoft Entra ID | Zulassen | Ja | Kommunikation mit Microsoft Entra ID. |
| 443 | TCP | Any | GuestAndHybridManagement | Allow | Ja | Automatisierte Verwaltung von Sicherheitspatches. |
Hinweis
Die Tags „AzureUpdateDelivery“ und „AzureFrontDoor.FirstParty“ sind ab dem 1. Juli 2024 veraltet. Microsoft Entra Domain Services verwaltet WindowsUpdate unabhängig, wodurch die Notwendigkeit für diese Tags entfällt. NSG-Anpassungen sind nicht erforderlich, mit oder ohne veraltete Tags.
Port 5986 (Verwaltung mit PowerShell-Remoting)
- Wird zum Ausführen von Verwaltungsaufgaben mithilfe von PowerShell-Remoting in Ihrer verwalteten Domäne verwendet.
- Ohne Zugriff auf diesen Port kann Ihre verwaltete Domäne nicht aktualisiert, konfiguriert, gesichert oder überwacht werden.
- Sie können den eingehenden Zugriff auf diesen Port auf das Diensttag AzureActiveDirectoryDomainServices beschränken.
Port 3389 (Verwaltung über Remotedesktop)
- Dieser Port wird für Remotedesktopverbindungen mit Domänencontrollern in Ihrer verwalteten Domäne verwendet und kann nicht geändert oder in einen anderen Port gekapselt werden.
- Die Standardregel für die Netzwerksicherheitsgruppe verwendet das Diensttag CorpNetSaw, um den Datenverkehr weiter einzuschränken.
- Dieses Diensttag gestattet nur sicheren Zugriff auf Arbeitsstationen im Microsoft-Unternehmensnetzwerk, um den Remotedesktop für die verwaltete Domäne zu verwenden.
- Der Zugriff ist nur mit geschäftlicher Begründung gestattet, z. B. für Verwaltungs- oder Problembehandlungsszenarien.
- Diese Regel kann auf Ablehnen festgelegt werden, um dann nur bei Bedarf auf Zulassen festgelegt zu werden. Die meisten Verwaltungs- und Überwachungsaufgaben werden mit PowerShell-Remoting durchgeführt. RDP wird nur in dem seltenen Fall verwendet, dass Microsoft zur erweiterten Problembehandlung eine Remoteverbindung mit Ihrer verwalteten Domäne herstellen muss.
Sie können das Diensttag CorpNetSaw nicht manuell über das Portal auswählen, wenn Sie versuchen, diese Regel für Netzwerksicherheitsgruppen zu bearbeiten. Sie müssen Azure PowerShell oder die Azure CLI verwenden, um eine Regel manuell zu konfigurieren, die das Diensttag CorpNetSaw verwendet.
Beispielsweise können Sie das folgende Skript verwenden, um eine Regel zu erstellen, die RDP zulässt:
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
Benutzerdefinierte Routen
Benutzerdefinierte Routen werden standardmäßig nicht erstellt und sind nicht erforderlich, damit Domain Services ordnungsgemäß funktioniert. Wenn Sie Routingtabellen verwenden müssen, vermeiden Sie Änderungen an der Route 0.0.0.0. Änderungen an dieser Route führen zu Unterbrechungen von Domain Services und versetzen die verwaltete Domäne in einen nicht unterstützten Status.
Sie müssen auch eingehenden Datenverkehr von den IP-Adressen, die in den jeweiligen Azure-Diensttags enthalten sind, an das Subnetz der verwalteten Domäne weiterleiten. Weitere Informationen zu Diensttags und der zugehörigen IP-Adresse finden Sie unter IP-Bereiche und Diensttags von Azure – Public Cloud.
Achtung
Diese IP-Bereiche des Azure-Rechenzentrums können sich ohne vorherige Ankündigung ändern. Stellen Sie sicher, dass Sie über Prozesse zur Überprüfung verfügen, dass Sie über die neuesten IP-Adressen verfügen.
Nächste Schritte
Weitere Informationen zu einigen der von Domain Services verwendeten Netzwerkressourcen und Verbindungsoptionen finden Sie in den folgenden Artikeln: