Firewalls für Managed Microsoft AD konfigurieren

Von Managed Service für Microsoft Active Directory betriebene Domänencontroller stellen eine Reihe von Diensten bereit, darunter LDAP, DNS, Kerberos und RPC. Abhängig von Ihren Anwendungsfällen benötigen in Google Cloud bereitgestellte virtuelle Maschinen (VMs) sowie lokal ausgeführte Computer möglicherweise Zugriff auf diese Dienste, um Active Directory nutzen zu können.

Um die Angriffsfläche von Domänencontrollern und VMs zu verringern, sollten Sie Firewalls verwenden, um Netzwerkkommunikation zu verbieten, die nicht unbedingt erforderlich ist. In diesem Artikel wird beschrieben, wie Sie Firewalls so konfigurieren, dass sie allgemeine Active Directory-Anwendungsfälle berücksichtigen und andere Netzwerkkommunikationen nicht zulassen.

Anmeldung versus Authentifizierung

Während die Begriffe Anmeldung und Authentifizierung häufig synonym verwendet werden, haben sie im Kontext der Windows-Sicherheit unterschiedliche Bedeutungen. Anmeldung beschreibt den Prozess, der auf dem System stattfindet, auf das ein Nutzer Zugriff erhält. Im Gegensatz dazu wird die Authentifizierung von dem Computer ausgeführt, auf dem sich das Nutzerkonto befindet.

Wenn Sie sich mit einem lokalen Konto bei einem Computer anmelden, werden sowohl die Anmeldung als auch die Authentifizierung vom Zielcomputer ausgeführt. In einer Active Directory-Umgebung wird üblicherweise ein Domänennutzer zum Anmelden verwendet. In diesem Fall wird die Anmeldung vom Zielcomputer ausgeführt, während die Authentifizierung von einem Domänencontroller durchgeführt wird.

Zur Authentifizierung kann ein Kunde entweder Kerberos oder NTLM verwenden. Sobald sich ein Kunde authentifiziert hat, muss der Zielcomputer die Anmeldung verarbeiten. Abhängig vom vom Kunden angeforderten Anmeldetyp erfordert dies möglicherweise eine zusätzliche Interaktion mit Domänencontrollern unter Verwendung von Protokollen wie Kerberos, NTLM, LDAP, RPC, oder SMB .

Da für die Authentifizierung und Verarbeitung von Anmeldungen unterschiedliche Protokolle erforderlich sind, ist es hilfreich, bei der Ermittlung der richtigen Firewall-Konfiguration zwischen den beiden Konzepten zu unterscheiden.

Gängige Anwendungsfälle

In den folgenden Abschnitten werden allgemeine Anwendungsfälle für den Zugriff auf verwaltetes Microsoft AD beschrieben und gezeigt, welche Firewall-Regeln Sie für jeden Anwendungsfall konfigurieren müssen.

Wenn Sie Managed Microsoft AD nicht in ein lokales Active Directory integrieren möchten, müssen Sie nur den ersten Abschnitt dieses Artikels lesen, Zugriff auf Managed Microsoft AD über Ihre VPC. Wenn Sie eine Vertrauensstellung zwischen verwaltetem Microsoft AD und einem lokalen Active Directory erstellen möchten, gilt der gesamte Artikel.

Sie können Firewall-Regelprotokolle verwenden, um zu analysieren, ob möglicherweise zusätzliche Ports erforderlich sind. Da für die implizite Verweigerung des Eingangs die Protokollierung deaktiviert ist, müssen Sie zuerst eine benutzerdefinierte Firewall-Regel mit niedriger Priorität erstellen, die den gesamten eingehenden Datenverkehr verweigert, die Firewall-Protokollierung jedoch aktiviert hat. Mit dieser Regel führt jeder fehlgeschlagene Verbindungsversuch dazu, dass ein Protokolleintrag auf Stackdriver veröffentlicht wird. Da Firewall-Regeln eine erhebliche Menge an Protokollen erzeugen können, sollten Sie die Firewall-Protokollierung nach Abschluss Ihrer Analyse erneut deaktivieren.

Zugriff auf verwaltetes Microsoft AD über Ihre VPC

Wenn Sie das Standardnetzwerk zum Bereitstellen von verwaltetem Microsoft AD verwenden, ist keine weitere Konfiguration erforderlich, damit VMs in der VPC auf Active Directory zugreifen können.

Wenn Sie Ihre VPC-Konfiguration oder Firewall-Regeln angepasst haben, müssen Sie sicherstellen, dass Ihre Firewall-Konfiguration weiterhin die Kommunikation mit verwaltetem Microsoft AD zulässt. In den folgenden Abschnitten werden Firewall-Regeln beschrieben, die Sie möglicherweise erstellen müssen.

Auflösung von Domainnamen

Wenn eine VM versucht, einen DNS-Namen aufzulösen, fragt sie einen Domänencontroller nicht direkt ab. Stattdessen wird die DNS-Abfrage an den Metadatenserver gesendet, der der Standard-DNS-Server ist, der für Compute Engine-VMs konfiguriert ist. Der Metadatenserver leitet die Abfrage dann an eine private DNS-Weiterleitungszone von Cloud DNS weiter, die von Managed Microsoft AD erstellt wurde. Diese Weiterleitungszone leitet die Abfrage dann an den entsprechenden Domänencontroller weiter.

Sie müssen keine Firewall-Regeln konfigurieren, um diesen Anwendungsfall zu aktivieren. Die Kommunikation mit Cloud-DNS ist für VMs in einer VPC immer zulässig, und verwaltetes Microsoft AD ermöglicht standardmäßig weitergeleitete DNS-Anforderungen von Cloud-DNS-Cloud-DNS .

Authentifizierung bei einer VM mit Kerberos

Ein Nutzer, der sich bei einer VM angemeldet hat, benötigt möglicherweise Zugriff auf einen Dienst, der von einer anderen VM bereitgestellt wird. Ein Nutzer kann beispielsweise versuchen, eine RDP-Verbindung zu öffnen, auf eine Dateifreigabe zuzugreifen oder auf eine HTTP-Ressource zuzugreifen, für die eine Authentifizierung erforderlich ist.

Damit sich ein Nutzer mit Kerberos bei der Server-VM authentifizieren kann, muss die Client-VM zuerst ein entsprechendes Kerberos-Ticket von einem der verwalteten Microsoft AD-Controller erhalten.

Damit sich VMs mithilfe von Kerberos bei einem anderen Nutzer authentifizieren können, muss die folgende Kommunikation gemäß den Firewall-Regeln zulässig sein:

Aktion Von An Protokolle
1 Allow Client-VM Managed Microsoft AD-Subnetz Kerberos (UDP/88, TCP/88)
LDAP (UDP/389, TCP/389)
2 Zulassen Client-VM Server-VM Protokoll für den Zugriff auf die VM, z. B. HTTP (TCP/80, TCP/443) oder RDP (TCP/3389)
3 Allow Server-VM Managed Microsoft AD-Subnetz Siehe Anmeldungen verarbeiten.

Authentifizierung bei einer VM mit NTLM

Obwohl Windows in den meisten Fällen Kerberos gegenüber NTLM bevorzugt, müssen Kunden gelegentlich auf die Verwendung von NTLM zur Authentifizierung zurückgreifen. NTLM basiert auf der Pass-Through-Authentifizierung und erfordert daher, dass der Server mit einem der verwalteten Microsoft AD-Domänencontroller kommuniziert, um den Nutzer zu authentifizieren.

Damit VMs andere VMs mithilfe von NTLM authentifizieren können, muss die folgende Kommunikation gemäß den Firewall-Regeln zulässig sein:

Aktion Von An Protokolle
1 Allow Client-VM Server-VM Protokoll für den Zugriff auf die VM, z. B. HTTP (TCP/80, TCP/443) oder RDP (TCP/3389)
2 Zulassen Client-VM Managed Microsoft AD-Subnetz Siehe Anmeldungen verarbeiten.

Domänenbeitritt und Verarbeitung von Anmeldungen

Um als Domänenmitglied zu arbeiten und Anmeldungen von Nutzern zu verarbeiten, muss ein Computer in der Lage sein, mit Active Directory zu interagieren. Der genaue Satz der verwendeten Protokolle hängt vom Anmeldetyp ab, den einzelne Kunden anfordern. Um alle gängigen Szenarien zu unterstützen, sollten Sie die folgende Kombination von Protokollen zulassen.

Aktion Von An Protokolle
1 Allow Server-VM Managed Microsoft AD-Subnetz Kerberos (UDP/88, TCP/88)
NTP (UDP/123)
RPC (TCP/135, TCP/49152-65535)
LDAP (UDP/389, TCP/389)
SMB (UDP/445, TCP/445)
LDAP GC (TCP/3268)

Abhängig von Ihrem genauen Anwendungsfall möchten Sie möglicherweise auch die folgenden Protokolle zulassen:

Aktion Von An Protokolle
1 Allow Server-VM Managed Microsoft AD-Subnetz Kerberos-Passwortänderung (UDP/464, TCP/464)
Secure LDAP (TCP/636, TCP/3269)

Managed Microsoft AD verwalten

Sie müssen eine domänenverbundene VM verwenden, um Managed Microsoft AD zu verwalten. Um Tools wie Active Directory-Verwaltungscenter auf dieser VM verwenden zu können, muss die VM auch auf die Active Directory-Webdienste zugreifen können, die von Managed Microsoft AD-Domänencontrollern bereitgestellt werden.

Aktion Von An Protokolle
1 Zulassen Administrator VM Managed Microsoft AD-Subnetz AD-Webdienste (TCP/9389)

Verbinden von Managed Microsoft AD mit einem lokalen Active Directory

Um Managed Microsoft AD mit einem lokalen Active Directory zu verbinden, müssen Sie eine Vertrauensstellung zwischen Gesamtstrukturen erstellen. Darüber hinaus sollten Sie die DNS-Namensauflösung zwischen Google Cloud und Ihrer lokalen Umgebung aktivieren.

Vertrauensbildung und -überprüfung

Um eine Gesamtstrukturvertrauensstellung zu erstellen und zu überprüfen, müssen die Managed Microsoft AD-Domänencontroller und die Stammdomänencontroller Ihrer lokalen Gesamtstruktur in der Lage sein, bidirektional zu kommunizieren.

Um die Erstellung und Überprüfung von Vertrauensstellungen zu aktivieren, konfigurieren Sie Ihre lokale Firewall so, dass eingehender und ausgehender Datenverkehr zugelassen wird, der diesen Merkmalen entspricht:

Aktion Von An Protokolle
1 Allow Lokale AD Verwaltetes Microsoft Active Directory DNS (UDP/53, TCP/53)
Kerberos (UDP/88, TCP/88)
Kerberos-Passwortänderung (UDP/464, TCP/464)
RPC (TCP/135, TCP/49152-65535)
LDAP (UDP/389, TCP/389)
SMB (UDP/445, TCP/445)
2 Allow Verwaltetes Microsoft Active Directory Lokale AD DNS (UDP/53, TCP/53)
Kerberos (UDP/88, TCP/88)
Kerberos-Passwortänderung (UDP/464, TCP/464)
RPC (TCP/135, TCP/49152-65535)
LDAP (UDP/389, TCP/389)
SMB (UDP/445, TCP/445)

Managed Microsoft AD ist vorkonfiguriert, damit der Datenverkehr diesen Merkmalen entspricht. Sie müssen also keine zusätzlichen Firewall-Regeln in Google Cloud konfigurieren.

Auflösen von lokalen Google Cloud-DNS-Namen

Es gibt zwei Möglichkeiten, wie Sie lokalen Computern erlauben können, DNS-Namen in Managed Microsoft AD aufzulösen: DNS-Delegierung und bedingte DNS-Weiterleitung.

DNS-Delegierung

Die von verwaltetem Microsoft AD verwendete DNS-Domain ist möglicherweise eine Unterdomäne der lokal verwendeten DNS-Domain. Beispielsweise können Sie cloud.example.com für verwaltetes Microsoft AD verwenden, während Sie example.com vor Ort verwenden. Damit lokale Kunden die DNS-Namen von Google Cloud-Ressourcen auflösen können, können Sie die DNS-Delegierung einrichten.

Bei Verwendung der DNS-Delegierung wird zunächst versucht, den DNS-Namen einer Google Cloud-Ressource aufzulösen, wobei ein lokaler DNS-Server abgefragt wird. Der DNS-Server leitet den Kunden dann an Cloud-DNS weiter, wodurch die Anforderung an einen Ihrer Managed Microsoft AD-Domänencontroller weitergeleitet wird.

Um Cloud-DNS lokalen Netzwerken zugänglich zu machen, muss eine Serverrichtlinie erstellt und eingeholt werden. Dadurch wird eine eingehende Weiterleitungs-IP-Adresse erstellt, die Teil Ihrer VPC ist.

Um die Weiterleitungsadresse von lokal zu verwenden, konfigurieren Sie Ihre lokale Firewall so, dass Datenverkehr zugelassen wird, der den folgenden Merkmalen entspricht.

Aktion Von An Protokolle
1 Allow Lokale AD Verwaltetes Microsoft Active Directory DNS (UDP/53, TCP/53)
Kerberos (UDP/88, TCP/88)
Kerberos-Passwortänderung (UDP/464, TCP/464)
RPC (TCP/135, TCP/49152-65535)
LDAP (UDP/389, TCP/389)
SMB (UDP/445, TCP/445)
2 Allow Verwaltetes Microsoft Active Directory Lokale AD DNS (UDP/53, TCP/53)
Kerberos (UDP/88, TCP/88)
Kerberos-Passwortänderung (UDP/464, TCP/464)
RPC (TCP/135, TCP/49152-65535)
LDAP (UDP/389, TCP/389)
SMB (UDP/445, TCP/445)

Bedingte DNS-Weiterleitung

Die von Managed Microsoft AD verwendete DNS-Domain ist möglicherweise keine Unterdomäne der lokal verwendeten DNS-Domain. Beispielsweise können Sie cloud.example.com für verwaltetes Microsoft AD verwenden, während Sie corp.example.local vor Ort verwenden.

In Szenarien, in denen die DNS-Domänen keine Beziehung zueinander haben, können Sie die bedingte DNS-Weiterleitung in Ihrem lokalen Active Directory-DNS einrichten. Alle Abfragen, die dem von Managed Microsoft AD verwendeten DNS-Namen entsprechen, werden dann an Cloud DNS weitergeleitet.

Um die bedingte DNS-Weiterleitung zu verwenden, müssen Sie zuerst eine DNS-Richtlinie einrichten, die die eingehende DNS-Weiterleitung aktiviert. Um die resultierende Weiterleitungsadresse von lokal zu verwenden, konfigurieren Sie Ihre lokale Firewall so, dass ein Datenverkehr mit den folgenden Merkmalen zugelassen wird.

Aktion Von An Protokolle
1 Allow Lokale AD DNS-Weiterleitungs-IP-Adresse DNS (UDP/53, TCP/53)

Erstellen Sie auf der Google Cloud-Seite eine -Firewall-Regel, um eingehenden Datenverkehr zu ermöglichen, der diesen Kriterien entspricht.

Sie müssen keine Firewall-Regeln konfigurieren, um die Kommunikation vom DNS-Forwarder zum Cloud-DNS zu ermöglichen (2).

Auflösen lokaler DNS-Namen aus Google Cloud

Managed Microsoft AD verwendet die bedingte DNS-Weiterleitung, um DNS-Namen in Ihrer lokalen Gesamtstruktur aufzulösen. Damit Clients, die in Google Cloud ausgeführt werden, auch DNS-Namen auflösen können, die von einem lokalen Active Directory verwaltet werden, können Sie in Cloud DNS DNS eine private Weiterleitungszone erstellen, die Abfragen an lokale Domänencontroller weiterleitet.

Um das Auflösen lokaler DNS-Namen aus Google Cloud zu aktivieren, konfigurieren Sie Ihre lokale Firewall so, dass eingehender Datenverkehr gemäß der folgenden Tabelle zugelassen wird.

Aktion Von An Protokolle
1 Allow Verwaltetes Microsoft Active Directory Lokale AD DNS (UDP/53, TCP/53)
2 Zulassen Cloud DNS (35.199.192.0/19) Lokale AD DNS (UDP/53, TCP/53)

Google Cloud erlaubt standardmäßig den entsprechenden Ausgangsverkehr.

Zugriff auf lokale Managed Microsoft AD-Ressourcen

Wenn die Managed Microsoft AD-Gesamtstruktur so eingerichtet ist, dass sie Ihrer lokalen Gesamtstruktur vertraut, möchten Sie möglicherweise, dass lokale Nutzer und Computer auf Ressourcen in der Managed Microsoft AD-Gesamtstruktur zugreifen können.

Authentifizierung bei einer lokalen VM mit Kerberos

Ein Nutzer, der sich bei einem lokalen Computer angemeldet hat, benötigt möglicherweise Zugriff auf einen Dienst, der von einer VM bereitgestellt wird, die in Google Cloud ausgeführt wird und Mitglied einer Managed Microsoft AD-Gesamtstruktur ist. Ein Nutzer kann beispielsweise versuchen, eine RDP-Verbindung zu öffnen, auf eine Dateifreigabe zuzugreifen oder auf eine HTTP-Ressource zuzugreifen, für die eine Authentifizierung erforderlich ist.

Damit Nutzer sich mit Kerberos bei der Server-VM authentifizieren können, muss der Clientcomputer ein entsprechendes Kerberos-Ticket erhalten. Dies erfordert die Kommunikation mit einem der lokalen Domänencontroller sowie mit einem der Managed Microsoft AD-Domänencontroller.

Um die Authentifizierung lokaler VMs mithilfe von Kerberos zu ermöglichen, konfigurieren Sie Ihre lokale Firewall so, dass der folgende Ausgangsverkehr zugelassen wird.

Aktion Von An Protokolle
1 Zulassen Client-Maschine (lokal) Managed Microsoft AD-Subnetz LDAP (UDP/389, TCP/389)
Kerberos (UDP/88, TCP/88)
2 Allow Client-Maschine (lokal) Server-VM (Google Cloud) Von der Anwendung verwendetes Protokoll, z. B. HTTP (TCP/80, TCP/443) oder RDP (TCP/3389)
3 Allow Server-VM Managed Microsoft AD-Subnetz Siehe Anmeldungen verarbeiten.

Erstellen Sie auf der Google Cloud-Seite Firewall-Regeln, um eingehenden Datenverkehr für (1) und (2) zuzulassen. Der Datenverkehr zum Managed Microsoft AD (3) ist standardmäßig zulässig.

Authentifizierung bei einer lokalen VM mit NTLM

Wenn Sie NTLM verwenden, um einen Nutzer aus einer lokalen Active Directory-Gesamtstruktur bei einer Server-VM zu authentifizieren, die einer Managed Microsoft AD-Gesamtstruktur zugeordnet ist, müssen die Managed Microsoft AD-Domänencontroller mit den lokalen Domänencontrollern kommunizieren.

Um die Authentifizierung lokaler VMs mithilfe von NTLM zu ermöglichen, konfigurieren Sie Ihre lokale Firewall so, dass eingehender und ausgehender Datenverkehr wie folgt zugelassen wird.

Aktion Von An Protokolle
1 Zulassen Client-Maschine (lokal) Server-VM (Google Cloud) Von der Anwendung verwendetes Protokoll, z. B. HTTP (TCP/80, TCP/443) oder RDP (TCP/3389)
2 Allow Server-VM Managed Microsoft AD-Subnetz Siehe Anmeldungen verarbeiten.
3 Zulassen Managed Microsoft AD-Subnetz Lokale AD LDAP (UDP/389, TCP/389)
SMB (UDP/445, TCP/445)

Erstellen Sie auf der Google Cloud-Seite Firewall-Regeln, um eingehenden Datenverkehr für (1) zuzulassen. Der Ausgangsverkehr für (2) und (3) ist standardmäßig zulässig.

Verarbeiten von Anmeldungen für Nutzer der lokalen Gesamtstruktur

Um eine Anmeldung für einen Nutzer der lokalen Gesamtstruktur zu verarbeiten, muss eine VM in der Lage sein, mit dem lokalen Active Directory zu interagieren. Der genaue Satz der verwendeten Protokolle hängt vom Anmeldetyp ab, den der Client angefordert hat. Um alle gängigen Szenarien zu unterstützen, konfigurieren Sie Ihre lokale Firewall so, dass eingehender Datenverkehr zugelassen wird, der diesen Merkmalen entspricht.

Aktion Von An Protokolle
1 Zulassen Server-VM (Google Cloud) Lokales AD-Subnetz Kerberos (UDP/88, TCP/88)
NTP (UDP/123)
RPC (TCP/135, TCP/49152-65535)
LDAP (UDP/389, TCP/389)
SMB (UDP/445, TCP/445)
LDAP GC (TCP/3268)

Abhängig von Ihrem genauen Anwendungsfall möchten Sie möglicherweise auch die folgenden Protokolle zulassen.

  • Kerberos-Passwortänderung (UDP/464, TCP/464)
  • Sicheres LDAP (TCP/636, TCP/3269)

Auf der Seite "Managed Microsoft AD" ist der entsprechende Ausgangsverkehr standardmäßig zulässig.

Auf administrativen VMs planen Sie möglicherweise nicht, Anmeldungen von Nutzern der lokalen Gesamtstruktur zuzulassen. Eine Aktivität, die Sie wahrscheinlich auf administrativen VMs ausführen müssen, ist das Verwalten von Gruppenmitgliedschaften. Wenn Sie die Objektauswahl verwenden, um auf einen Nutzer oder eine Gruppe aus Ihrer lokalen Gesamtstruktur zu verweisen, benötigt die Objektauswahl Zugriff auf die lokalen Domänencontroller. Damit dies funktioniert, benötigt die administrative VM denselben Zugriff auf Ihre lokalen Active Directory-Domänencontroller wie für die Verarbeitung von Anmeldungen für Nutzer der lokalen Gesamtstruktur.

Zugriff auf lokale Active Directory-Ressourcen über Google Cloud

Wenn Ihre lokale Gesamtstruktur so eingerichtet ist, dass sie der verwalteten Microsoft AD-Gesamtstruktur vertraut, möchten Sie möglicherweise, dass Nutzer aus der Managed Microsoft AD-Gesamtstruktur auf lokale Ressourcen zugreifen können.

Authentifizierung bei einer lokalen VM mit Kerberos

Ein Nutzer, der sich bei einer in Google Cloud ausgeführten VM angemeldet hat und Mitglied der Managed Microsoft AD-Gesamtstruktur ist, benötigt möglicherweise Zugriff auf einen Dienst, der von einem lokalen Computer bereitgestellt wird, der Mitglied Ihrer lokalen Gesamtstruktur ist. Beispielsweise kann der Nutzer versuchen, eine RDP-Verbindung zu öffnen, auf eine Dateifreigabe zuzugreifen oder auf eine HTTP-Ressource zuzugreifen, für die eine Authentifizierung erforderlich ist.

Damit sich der Nutzer mit Kerberos beim lokalen Computer authentifizieren kann, muss die VM ein entsprechendes Kerberos-Ticket erhalten. Dies erfordert zunächst die Kommunikation mit einem der Managed Microsoft AD-Controller und dann mit den lokalen Domänencontrollern.

Um die Authentifizierung lokaler VMs mithilfe von Kerberos zu ermöglichen, konfigurieren Sie Ihre lokale Firewall so, dass eingehender Datenverkehr zugelassen wird, der den folgenden Merkmalen entspricht.

Aktion Von An Protokolle
1 Zulassen Client-VM (Google Cloud) Managed Microsoft AD-Subnetz Kerberos (UDP/88, TCP/88)
LDAP (UDP/389, TCP/389)
Impliziert durch Verarbeitungslogons
2 Zulassen Client-VM (Google Cloud) Lokale AD Kerberos (UDP/88, TCP/88)
LDAP (UDP/389, TCP/389)
3 Zulassen Client-VM (Google Cloud) Server-Maschine (lokal) Von der Anwendung verwendetes Protokoll, z. B. HTTP (TCP/80, TCP/443) oder RDP (TCP/3389)

Auf der Google Cloud-Seite ist der entsprechende Ausgangsverkehr standardmäßig zulässig.

Authentifizierung bei einer lokalen VM mithilfe von NTLM

Wenn Sie NTLM verwenden, um einen Nutzer aus der Managed Microsoft AD-Gesamtstruktur bei einem Server zu authentifizieren, der mit Ihrer lokalen Gesamtstruktur verbunden ist, müssen die lokalen Domänencontroller in der Lage sein, mit den Managed Microsoft AD-Domänencontrollern zu kommunizieren:

Um die Authentifizierung lokaler VMs mithilfe von Kerberos zu ermöglichen, konfigurieren Sie Ihre lokale Firewall so, dass eingehender und ausgehender Datenverkehr zugelassen wird, der diesen Merkmalen entspricht.

Aktion Von An Protokolle
1 Zulassen Client-VM (Google Cloud) Server-Maschine (lokal) Von der Anwendung verwendetes Protokoll, z. B. HTTP (TCP/80, TCP/443) oder RDP (TCP/3389)
2 Allow Lokale AD Managed Microsoft AD-Subnetz LDAP (UDP/389, TCP/389)
SMB (UDP/445, TCP/445)

Auf der Google Cloud-Seite ist der Ausgangsverkehr für (1) und der Eingangsverkehr für (2) standardmäßig zulässig.

Verarbeiten von Anmeldungen für Nutzer der Managed Microsoft AD-Gesamtstruktur

Um eine Anmeldung für einen Nutzer der Managed Microsoft AD-Gesamtstruktur zu verarbeiten, muss ein lokal ausgeführter Computer in der Lage sein, mit Managed Microsoft AD-Domänencontrollern zu interagieren. Der genaue Satz der verwendeten Protokolle hängt vom Anmeldetyp ab, den der Client angefordert hat. Um alle gängigen Szenarien zu unterstützen, sollten Sie die folgende Kombination von Protokollen zulassen.

Aktion Von An Protokolle
1 Allow Server-Maschine (lokal) Managed Microsoft AD-Subnetz Kerberos (UDP/88, TCP/88)
NTP (UDP/123)
RPC (TCP/135, TCP/49152-65535)
LDAP (UDP/389, TCP/389)
SMB (UDP/445, TCP/445)
LDAP GC (TCP/3268)

Abhängig von Ihrem genauen Anwendungsfall möchten Sie möglicherweise auch die folgenden Protokolle zulassen.

  • Kerberos-Passwortänderung (UDP/464, TCP/464)
  • Sicheres LDAP (TCP/636, TCP/3269)

Stellen Sie sicher, dass Ihre lokalen Firewalls einen Datenverkehr zulassen, der diesen Merkmalen entspricht. Sie müssen in Google Cloud keine Firewall-Regeln konfigurieren, um den entsprechenden eingehenden Datenverkehr für Managed Microsoft AD zu aktivieren.

Auf Verwaltungscomputern ist möglicherweise nicht geplant, Anmeldungen von Benutzern der Managed Microsoft AD-Gesamtstruktur zuzulassen. Eine Aktivität, die Sie wahrscheinlich auf Verwaltungscomputern ausführen müssen, ist das Verwalten von Gruppenmitgliedschaften. Wenn Sie die Objektauswahl verwenden, um auf einen Nutzer oder eine Gruppe aus der Managed Microsoft AD-Gesamtstruktur zu verweisen, benötigt die Objektauswahl Zugriff auf die Managed Microsoft AD-Domänencontroller. Damit dies funktioniert, benötigt der Verwaltungscomputer denselben Zugriff auf die Managed Microsoft AD-Domänencontroller wie für die Verarbeitung von Anmeldungen für Nutzer der Managed Microsoft AD-Gesamtstruktur.