Erweitern einer lokalen AD FS-Instanz auf Azure

Diese Referenzarchitektur implementiert ein sicheres hybrides Netzwerk, das Ihr lokales Netzwerk auf Azure ausweitet, und verwendet Active Directory-Verbunddienste (AD FS), um eine Verbundauthentifizierung und -autorisierung für Komponenten durchzuführen, die in Azure ausgeführt werden.

Aufbau

Laden Sie eine Visio-Datei dieser Architektur herunter.

Workflow

• AD DS-Subnetz. Der AD DS-Server befinden sich in ihrem eigenen Subnetz mit Regeln für Netzwerksicherheitsgruppen (NSG), die als Firewall fungieren.

• AD DS-Server. Domänencontroller, die als virtuelle Computer in Azure ausgeführt werden. Diese Server bieten Authentifizierung von lokalen Identitäten in der Domäne.

• AD FS-Subnetz. Die AD FS-Server befinden sich in ihrem eigenen Subnetz mit NSG-Regeln, die als Firewall fungieren.

• AD FS-Server. Die AD FS-Server bieten Verbundautorisierung und -authentifizierung. In dieser Architektur führen sie die folgenden Aufgaben aus:

  • Empfangen von Sicherheitstoken, die Ansprüche enthalten, die ein Partnerverbundserver im Auftrag eines Partnerbenutzers stellt. AD FS überprüft, ob die Token gültig sind, bevor die Ansprüche an die in Azure ausgeführte Webanwendung übergeben werden, um die Anforderungen zu autorisieren.

    Die in Azure ausgeführte Anwendung ist die vertrauende Seite. Die Partnerverbundserver muss Ansprüche ausgeben, die von der Webanwendung verstanden werden. Die Partnerverbundserver werden als Kontopartner bezeichnet, weil sie Anforderungen im Auftrag von authentifizierten Konten in der Partnerorganisation übergeben. Die AD FS-Server werden als Ressourcenpartner bezeichnet, weil sie Zugriff auf Ressourcen (die Webanwendung) ermöglichen.

  • Authentifizieren und Autorisieren eingehender Anforderungen von externen Benutzern, die einen Webbrowser oder ein Gerät ausführen, der oder das Zugriff auf Webanwendungen benötigt, mit AD DS und dem Active Directory-Geräteregistrierungsdienst.

  Die AD FS-Server sind als eine Farm konfiguriert, auf die über einen Azure-Lastenausgleich zugegriffen wird. Diese Implementierung verbessert die Verfügbarkeit und die Skalierbarkeit. Die AD FS-Server sind nicht direkt im Internet verfügbar. Der gesamte Internet-Datenverkehr wird über AD FS-Webanwendungs-Proxyserver und eine DMZ (auch als Umkreisnetzwerk bezeichnet) gefiltert.

  Weitere Informationen zur Funktionsweise von AD FS finden Sie in der Übersicht über Active Directory-Verbunddienste (AD FS). Darüber hinaus enthält der Artikel AD FS-Bereitstellung in Azure eine ausführliche Schritt-für-Schritt-Einführung in die Implementierung.

• AD FS-Proxysubnetz. Die AD FS-Proxyserver können in ihrem eigenen Subnetz enthalten sein, in dem NSG-Regeln Schutz bieten. Die Server in diesem Subnetz werden dem Internet über eine Reihe von virtuellen Netzwerkgeräten verfügbar gemacht, die eine Firewall zwischen Ihrem virtuellen Azure-Netzwerk und dem Internet bereitstellen.

• AD FS-Webanwendungs-Proxyserver (WAP-Server) . Diese virtuellen Computer fungieren als AD FS-Server für eingehende Anforderungen von Partnerorganisationen und externen Geräten. Die WAP-Server fungieren als Filter, der die AD FS-Server gegen direkten Zugriff aus dem Internet abschirmt. So wie bei den AD FS-Servern bietet Ihnen Bereitstellen der WAP-Server in einer Farm mit Lastenausgleich größere Verfügbarkeit und Skalierbarkeit, als dies bei Bereitstellung einer Sammlung von eigenständigen Servern der Fall ist.

  Hinweis

  Ausführliche Informationen zum Installieren von WAP-Servern finden Sie unter Installieren und Konfigurieren des Webanwendungsproxy-Servers.

• Partnerorganisation. Eine Partnerorganisation, die eine Webanwendung ausführt, die Zugriff auf eine Webanwendung anfordert, die in Azure ausgeführt wird. Der Verbundserver in der Partnerorganisation authentifiziert Anforderungen lokal und sendet Sicherheitstoken, die Ansprüche enthalten, an AD FS, der in Azure ausgeführt wird. AD FS in Azure überprüft die Sicherheitstoken und kann, wenn die Token gültig sind, die Ansprüche an die in Azure ausgeführte Webanwendung übergeben, um sie zu autorisieren.

  Hinweis

  Sie können auch mit einem Azure-Gateway einen VPN-Tunnel konfigurieren, um für vertrauenswürdige Partner direkten Zugriff auf AD FS zu ermöglichen. Anforderungen, die von diesen Partnern eingehen, durchlaufen nicht den WAP-Server.

Komponenten

Diese Architektur erweitert die Implementierung, die unter Erweitern von AD DS auf Azure beschrieben ist. Sie enthält die folgenden Komponenten.

• AD DS-Subnetz
• AD DS-Server
• AD FS-Subnetz
• AD FS-Server
• AD FS-Proxysubnetz
• AD FS-Webanwendungsproxy /(WAP)-Server

Szenariodetails

AD FS kann lokal gehostet werden, aber wenn Ihre Anwendung eine hybride Anwendung ist, in der einige Teile in Azure implementiert sind, kann es effizienter sein, AD FS in der Cloud zu replizieren.

Das vorherige Diagramm zeigt die folgenden Szenarien:

• Anwendungscode von einer Partnerorganisation greift auf eine Webanwendung zu, die in Ihrem Azure VNet gehostet wird.
• Ein externer registrierter Benutzer mit Anmeldeinformationen, die in Active Directory Domain Services (DS) gespeichert sind, greift auf eine Webanwendung zu, die in Ihrem Azure VNet gehostet wird.
• Ein Benutzer, der über ein autorisiertes Gerät eine Verbindung mit Ihrem virtuellen Netzwerk (VNet) hergestellt hat, führt eine Webanwendung aus, die in Ihrem Azure VNet gehostet wird.

In dieser Referenzarchitektur liegt der Schwerpunkt auf passivem Verbund, in dem die Verbundserver entscheiden, wie und wann ein Benutzer authentifiziert werden muss. Der Benutzer gibt Anmeldeinformationen an, wenn die Anwendung gestartet wird. Dieser Mechanismus wird am häufigsten von Webbrowsern verwendet und beinhaltet ein Protokoll, das den Browser zu einer Website umleitet, auf der sich der Benutzer authentifiziert. AD FS unterstützt auch aktiven Verbund, bei dem eine Anwendung die jeweiligen Anmeldeinformationen bereitstellt, ohne dass weiterer Benutzereingriff erforderlich ist. Dieses Szenario ist aber nicht Bestandteil dieser Architektur.

Andere Überlegungen finden Sie unter Auswählen einer Lösung für die Integration einer lokalen Active Directory-Instanz in Azure.

Mögliche Anwendungsfälle

Typische Einsatzmöglichkeiten für diese Architektur sind:

• Hybridanwendungen, in denen Workloads teilweise lokal und teilweise in Azure ausgeführt werden.
• Lösungen, in denen Verbundautorisierung verwendet wird, um Webanwendungen für Partnerorganisationen verfügbar zu machen
• Systeme, die Zugriff über Webbrowser ermöglichen, die außerhalb der Firewall der Organisation ausgeführt werden
• Systeme, die Benutzern Zugriff auf Webanwendungen ermöglichen, indem sie eine Verbindung von einem autorisierten externen Gerät herstellen, etwa ein Remotecomputer, ein Notebook oder ein anderes mobiles Gerät

Empfehlungen

Die folgenden Empfehlungen gelten für die meisten Szenarios. Sofern Sie keine besonderen Anforderungen haben, die Vorrang haben, sollten Sie diese Empfehlungen befolgen.

Netzwerkempfehlungen

Konfigurieren Sie die Netzwerkschnittstelle für jeden der virtuellen Computer, die AD FS und WAP-Server hosten, mit statischen privaten IP-Adressen.

Geben Sie den AD FS-VMs keine öffentlichen IP-Adressen. Weitere Informationen hierzu finden Sie im Abschnitt Sicherheitshinweise.

Legen Sie die IP-Adresse des bevorzugten und die des sekundären DNS-Servers (Domain Name System) für die Netzwerkschnittstellen für jeden virtuellen AD FS- und WAP-Computer so fest, dass sie auf die virtuellen Active Directory Domain Services-Computer verweisen. DNS sollte auf den virtuellen Active Directory Domain Services-Computern ausgeführt werden. Dieser Schritt ist notwendig, damit jeder virtuelle Computer der Domäne beitreten kann.

AD FS-Installation

Der Artikel Bereitstellen einer Verbundserverfarm enthält ausführliche Anweisungen zum Installieren und Konfigurieren von AD FS. Führen Sie die folgenden Aufgaben aus, bevor Sie den ersten AD FS-Server in der Farm konfigurieren:

1. Rufen Sie ein öffentlich vertrauenswürdiges Zertifikat ab, mit dem eine Serverauthentifizierung vorgenommen wird. Der Antragstellername muss den Namen enthalten, den Clients dazu verwenden, auf den Verbunddienst zuzugreifen. Dies kann der DNS-Name sein, der für den Lastenausgleich registriert ist, etwa adfs.contoso.com (aus Sicherheitsgründen sollten Sie keine Platzhalterzeichen, z.B. * . contoso.com, verwenden). Verwenden Sie auf allen virtuellen Computern, die als AD FS-Server fungieren, dasselbe Zertifikat. Sie können ein Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle erwerben, wird in Ihrer Organisation aber Active Directory-Zertifikatdienste verwendet, können Sie Ihr eigenes Zertifikat erstellen.

   Alternativer Antragstellername wird vom Geräteregistrierungsdienst (Device Registration Service, DRS) verwendet, um Zugriff von externen Geräten zu ermöglichen. Dieser Name muss in der Form enterpriseregistration.contoso.com vorliegen.

   Weitere Informationen hierzu finden Sie unter Abrufen und Konfigurieren eines SSL-Zertifikats (Secure Sockets Layer) für AD FS.

2. Generieren Sie auf dem Domänencontroller einen neuen Stammschlüssel für den Schlüsselverteilungsdienst. Legen Sie die effektive Zeit auf die aktuelle Zeit abzüglich 10 Stunden fest (diese Konfiguration verringert die Verzögerung, die auftreten kann, wenn Schlüssel in der Domäne verteilt und synchronisiert werden). Dieser Schritt ist erforderlich, damit das Gruppendienstkonto erstellt werden kann, mit dem der AD FS-Dienst ausgeführt wird. Im folgenden PowerShell-Befehl ist beispielhaft gezeigt, wie dies ausgeführt wird:

   Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)
   

3. Fügen Sie jeden virtuellen Computer, der als AD FS-Server fungiert, zur Domäne hinzu.

AD FS-Vertrauensstellung

Richten Sie eine Verbundvertrauensstellung zwischen Ihrer AD FS-Installation und den Verbundservern jeder Partnerorganisation ein. Konfigurieren Sie jegliche erforderliche Ansprüchefilterung und -zuordnung.

• DevOps-Mitarbeiter in jeder Partnerorganisation müssen eine Vertrauensstellung der vertrauenden Seite für die Webanwendungen hinzufügen, auf die über Ihre AD FS-Server zugegriffen werden kann.
• DevOps-Mitarbeiter in Ihrer Organisation müssen eine Anspruchsanbieter-Vertrauensstellung konfigurieren, damit Ihre AD FS-Server den Ansprüchen vertrauen können, die von Partnerorganisationen bereitgestellt werden.
• DevOps-Mitarbeiter in Ihrer Organisation müssen außerdem AD FS so konfigurieren, dass Ansprüche an die Webanwendungen Ihrer Organisation übergeben werden.

Weitere Informationen hierzu finden Sie unter Establishing Federation Trust (Einrichten einer Verbundvertrauensstellung).

Veröffentlichen Sie die Webanwendungen Ihrer Organisation, und machen Sie diese für externe Partner verfügbar, indem Sie Präauthentifizierung durch die WAP-Server verwenden. Weitere Informationen hierzu finden Sie unter Publish Applications using AD FS Preauthentication (Veröffentlichen von Anwendungen mit AD FS-Vorauthentifizierung).

AD FS unterstützt Tokentransformation und -ergänzung. Microsoft Entra-ID stellt dieses Feature nicht bereit. Wenn Sie die Vertrauensstellungen einrichten, können Sie mit AD FS:

• Anspruchstransformationen für Autorisierungsregeln konfigurieren. Beispielsweise können Sie Gruppensicherheit aus einer Darstellung, die von einer Nicht-Microsoft-Partnerorganisation verwendet wird, zu einer anderen Darstellung zuordnen, die von Active Directory DS in Ihrer Organisation autorisiert werden kann.
• Ansprüche aus einem Format in ein anderes transformieren. Beispielsweise können Sie von SAML 2.0 zu SAML 1.1 zuordnen, wenn Ihre Anwendung nur SAML 1.1-Ansprüche unterstützt.

AD FS-Überwachung

Das Microsoft System Center-Management Pack für Active Directory Federation Services 2012 R2 bietet sowohl eine proaktive als auch eine reaktive Überwachung Ihrer AD FS-Bereitstellung für den Verbundserver. Dieses Management Pack überwacht Folgendes:

• Ereignisse, die der AD FS-Dienst in seinen Ereignisprotokollen speichert
• Die Leistungsdaten, die von den AD FS-Leistungsindikatoren gesammelt werden
• Die Gesamtintegrität des AD FS-Systems und der Webanwendungen (vertrauende Seiten); stellt außerdem Benachrichtigung für schwerwiegende Probleme und Warnungen bereit

Eine andere Option ist AD FS mit Microsoft Entra Connect Health überwachen. Microsoft Entra Connect Health bietet eine stabile Überwachung Ihrer lokalen Identitätsinfrastruktur. Mit Connect Health können Sie eine zuverlässige Verbindung mit Microsoft 365 und Microsoft Online Services sicherstellen. Diese Zuverlässigkeit wird durch Überwachungsfunktionen für Ihre wichtigen Identitätskomponenten erreicht. Darüber hinaus ermöglicht Connect Health den einfachen Zugriff auf die wichtigen Datenpunkte dieser Komponenten.

Überlegungen

Diese Überlegungen beruhen auf den Säulen des Azure Well-Architected Frameworks, d. h. einer Reihe von Grundsätzen, mit denen die Qualität von Workloads verbessert werden kann. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.

Effiziente Leistung

Leistungseffizienz ist die Fähigkeit Ihrer Workload, auf effiziente Weise eine den Anforderungen der Benutzer entsprechende Skalierung auszuführen. Weitere Informationen finden Sie unter Übersicht über die Säule „Leistungseffizienz“.

Die folgenden Aspekte, die aus dem Artikel Planen der AD FS-Bereitstellung zusammengefasst sind, bieten einen Ausgangspunkt zum Anpassen der Größe von AD FS-Farmen:

• Wenn Sie weniger als 1000 Benutzer haben, erstellen Sie keine dedizierten Server, sondern installieren Sie stattdessen AD FS auf jedem der Active Directory DS-Server in der Cloud. Verwenden Sie dazu mindestens zwei Active Directory DS-Server, damit Verfügbarkeit sichergestellt ist. Erstellen Sie einen einzelnen WAP-Server.
• Wenn Sie zwischen 1000 und 15 000 Benutzer haben, erstellen Sie zwei dedizierte AD FS-Server und zwei dedizierte WAP-Server.
• Wenn Sie zwischen 15 000 und 60 000 Benutzer haben, erstellen Sie drei bis fünf dedizierte AD FS-Server und mindestens zwei dedizierte WAP-Server.

Diese Überlegungen gehen davon aus, dass Sie in Azure VMs mit dualem Quad-Core (Standard D4_v2 oder besser) verwenden.

Wenn Sie die interne Windows-Datenbank verwenden, um die AD FS-Konfigurationsdaten zu speichern, sind Sie auf acht AD FS-Server in der Farm beschränkt. Wenn Sie davon ausgehen, dass Sie zukünftig mehr benötigen, verwenden Sie SQL Server. Weitere Informationen hierzu finden Sie unter The Role of the AD FS Configuration Database (Die Rolle der AD FS-Konfigurationsdatenbank).

Zuverlässigkeit

Zuverlässigkeit stellt sicher, dass Ihre Anwendung Ihre Verpflichtungen gegenüber den Kunden erfüllen kann. Weitere Informationen finden Sie in der Überblick über die Säule „Zuverlässigkeit“.

Erstellen Sie eine AD FS-Farm mit mindestens zwei Servern, um die Verfügbarkeit des Diensts zu erhöhen. Verwenden Sie verschiedene Speicherkonten für jeden virtuellen AD FS-Computer in der Farm. Mit diesem Ansatz wird sichergestellt, dass ein Fehler in einem Speicherkonto nicht die gesamte Farm unzugänglich macht.

Erstellen Sie getrennte Azure-Verfügbarkeitsgruppen für die virtuellen AD FS- und WAP-Computer. Stellen Sie sicher, dass in jeder Gruppe mindestens zwei virtuelle Computer vorhanden sind. Jede Verfügbarkeitsgruppe muss mindestens zwei Upgdatedomänen und zwei Fehlerdomänen haben.

Konfigurieren Sie die Lastenausgleiche für die virtuellen AD FS- und WAP-Computer wie folgt:

• Verwenden Sie einen Azure-Lastenausgleich, um externen Zugriff auf die virtuellen WAP-Computer zu bieten, und einen internen Lastenausgleich, um die Last auf die AD FS-Server in der Farm zu verteilen.

• Übergeben Sie an die AD FS/WAP-Server nur Datenverkehr, der am Port 443 (HTTPS) ankommt.

• Geben Sie dem Lastenausgleich eine statische IP-Adresse.

• Erstellen Sie einen Integritätstest, indem Sie HTTP für /adfs/probe verwenden. Weitere Informationen finden Sie unter Hardware Load Balancer Health Checks and Web Application Proxy/AD FS 2012 R2 (Hardware-Load Balancer-Integritätsprüfungen und Webanwendungsproxy/AD FS 2012 R2).

  Hinweis

  AD FS-Server verwenden das SNI-Protokoll (Server Name Indication), daher schlägt ein Versuch, den Test über einen HTTPS-Endpunkt aus dem Lastenausgleich auszuführen, fehl.

• Fügen Sie einen DNS-A-Datensatz zu der Domäne für den AD FS-Lastenausgleich hinzu. Geben Sie die IP-Adresse des Lastenausgleichs an, und geben sie ihm einen Namen in der Domäne (z.B. „adfs.contoso.com“). Dies ist der Name, den Clients und WAP-Server verwenden, um auf die AD FS-Serverfarm zuzugreifen.

Sie können entweder SQL Server oder die interne Windows-Datenbank verwenden, um die AD FS-Konfigurationsinformationen zu speichern. Die interne Windows-Datenbank bietet grundlegende Redundanz. Änderungen werden direkt nur in eine der AD FS-Datenbanken im AD FS-Cluster geschrieben, während die anderen Server Pullreplikation verwenden, um ihre Datenbanken auf dem neuesten Stand zu halten. Wird SQL Server verwendet, können vollständige Datenbankredundanz und hohe Verfügbarkeit bereitgestellt werden, indem Failoverclustering oder Spiegelung verwendet wird.

Sicherheit

Sicherheit bietet Schutz vor vorsätzlichen Angriffen und dem Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Übersicht über die Säule „Sicherheit“.

Da für AD FS HTTPS verwendet wird, müssen Sie darauf achten, dass die NSG-Regeln für das Subnetz, in dem die virtuellen Computer auf Webebene enthalten sind, HTTPS-Anforderungen zulassen. Diese Anforderungen können aus dem lokalen Netzwerk, aus den Subnetzen, die die Webebene, die Geschäftsebene, die Datenebene, die private DMZ oder die öffentliche DMZ enthalten, oder aus dem Subnetz stammen, das die AD FS-Server enthält.

Verhindern Sie, dass AD FS-Server direkt für das Internet verfügbar gemacht werden. AD FS-Server sind zur Domäne gehörende Computer, die die vollständige Autorisierung haben, Sicherheitstoken zu gewähren. Wenn ein Server kompromittiert ist, kann ein böswilliger Benutzer Token für Vollzugriff auf alle Webanwendungen und alle Verbundserver ausgeben, die durch AD FS geschützt sind. Muss Ihr System Anforderungen von externen Benutzern verarbeiten, die nicht über vertrauenswürdige Partnerwebsites zugreifen, sollten Sie diese Anforderungen mit WAP-Servern verarbeiten. Weitere Informationen hierzu finden Sie unter Where to Place a Federation Server Proxy (Platzieren eines Verbundserverproxys).

Platzieren Sie AD FS-Server und WAP-Server in getrennten Subnetzen mit jeweils eigener Firewall. Sie können NSG-Regeln verwenden, um Firewallregeln zu definieren. Alle Firewalls müssen Datenverkehr über den Port 443 (HTTPS) zulassen.

Beschränken Sie direkten Anmeldezugriff auf die AD FS- und WAP-Server. Nur DevOps-Mitarbeiter sollten Verbindungen herstellen können. Binden Sie die WAP-Server nicht in die Domäne ein.

Sie sollten erwägen, eine Reihe von virtuellen Netzwerkgeräten zu verwenden, die zu Überwachungszwecken ausführliche Informationen zu dem Datenverkehr protokollieren, der in Ihrem virtuellen Netzwerk empfangen wird.

Kostenoptimierung

Bei der Kostenoptimierung geht es um die Suche nach Möglichkeiten, unnötige Ausgaben zu reduzieren und die Betriebseffizienz zu verbessern. Weitere Informationen finden Sie unter Übersicht über die Säule „Kostenoptimierung“.

Hier sind die Überlegungen zu den Kosten für die Dienste angegeben, die in dieser Architektur verwendet werden.

AD Domain Services

Ziehen Sie in Betracht, Active Directory Domain Services als gemeinsam genutzten Dienst zu verwenden, der von mehreren Workloads genutzt wird, um die Kosten zu senken. Weitere Informationen finden Sie unter Active Directory Domain Services – Preise.

Active Directory-Verbunddienste (AD FS)

Informationen zu den Editionen von Microsoft Entra ID finden Sie unter Preise für Microsoft Entra. Das Feature „AD-Verbunddienste“ ist in allen Editionen verfügbar.

Optimaler Betrieb

DevOps-Mitarbeiter sollten darauf vorbereitet sein, die folgenden Aufgaben auszuführen:

• Verwalten der Verbundserver, einschließlich Verwaltung der AD FS-Farm, Verwaltung der Vertrauensrichtlinien auf den Verbundservern und Verwaltung der Zertifikate, die von den Verbunddiensten verwendet werden.
• Verwalten der WAP-Server, einschließlich Verwaltung der WAP-Farm und -Zertifikate.
• Verwalten von Webanwendungen, einschließlich Konfigurieren der vertrauenden Seiten, der Authentifizierungsmethoden und der Anspruchszuordnungen.
• Sichern der AD FS-Komponenten.

Andere Überlegungen zu DevOps finden Sie unter DevOps: Erweitern von Active Directory Domain Services (AD DS) auf Azure.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautor:

• Sarah Parkes | Senior Cloud Solution Architect

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte

• Dokumentation zu Azure Active Directory
• Verwalten der Identität in mehrinstanzenfähigen Anwendungen
• Sicherheit der Identitätsverwaltung
• Azure Firewall

Zugehörige Ressourcen

• Bereitstellen von AD DS in einem virtuellen Azure-Netzwerk
• Microsoft Entra-Identitäts- und Zugriffsverwaltung für AWS