War diese Seite hilfreich?
Ihr Feedback ist uns wichtig. Teilen Sie uns Ihre Meinung mit.
Weiteres Feedback?
1500 verbleibende Zeichen
Exportieren (0) Drucken
Alle erweitern

Richtlinien für die Bereitstellung von Windows Server Active Directory auf virtuellen Computern in Azure

Letzte Aktualisierung: Juni 2015

In diesem Dokument werden wichtige Unterschiede zwischen der lokalen Bereitstellung von Active Directory-Domänendiensten (AD DS) und Active Directory-Verbunddiensten (AD FS) von Windows Server und der Bereitstellung dieser Dienste auf virtuellen Computern (VMs) in Azure erläutert.

Inhaltsverzeichnis

Dieses Dokument richtet sich an Nutzer, die bereits Erfahrung mit der Bereitstellung von Active Directory in einer lokalen Umgebung aufweisen. Hierin werden die Unterschiede zwischen Active Directory-Bereitstellungen auf virtuellen Computern/in virtuellen Netzwerken in Azure und herkömmlichen lokalen Active Directory-Bereitstellungen erörtert. Azure-Virtuelle Computer und Azure-Virtuelle Netzwerke sind Bestandteil eines IaaS (Infrastructure-as-a-Service)-Angebots, das Organisationen die Nutzung von Verarbeitungsressourcen in der Cloud ermöglicht.

Benutzer, die nicht mit AD-Bereitstellungen vertraut sind, sollten sich im Bereitstellungshandbuch zu AD DS bzw. unter Planen der AD FS-Bereitstellung informieren.

In diesen Ausführungen wird davon ausgegangen, dass der Leser mit folgenden Konzepten vertraut ist:

  • Bereitstellung und Verwaltung von Windows Server AD DS

  • Bereitstellung und Konfiguration von DNS zur Unterstützung einer Windows Server AD DS-Infrastruktur

  • Bereitstellung und Verwaltung von Windows Server AD FS

  • Bereitstellen, Konfigurieren und Verwalten von Anwendungen der vertrauenden Seite (Websites und Webdienste), die Windows Server AD FS-Token nutzen können

  • Allgemeine Erfahrung mit virtuellen Computern, z. B. mit der Konfiguration virtueller Computer, Datenträger und Netzwerke

In diesem Dokument werden die Anforderungen an ein hybrides Bereitstellungsszenario aufgezeigt, in dem Windows Server AD DS oder AD FS teilweise lokal und teilweise auf virtuellen Computern in Azure bereitgestellt wird. Zunächst werden wichtige Unterschiede zwischen der Ausführung von Windows Server AD DS und AD FS auf virtuellen Computern in Azure und der lokalen Ausführung herausgestellt und wichtige Entscheidungen erörtert, die sich auf den Entwurf und die Bereitstellung auswirken. Anschließend wird ausführlicher auf Richtlinien zu den einzelnen Entscheidungspunkten eingegangen und erläutert, wie sie auf die unterschiedlichen Bereitstellungsszenarien angewendet werden.

Die Konfiguration von Azure Active Directory, d. h. eines REST-basierten Diensts, der Funktionen zur Identitätsverwaltung und Zugriffssteuerung für Cloud-Anwendungen bereitstellt, wird in diesem Dokument nicht behandelt. Azure Active Directory (AD) und Windows Server AD DS sind jedoch für den parallelen Einsatz konzipiert und bieten gemeinsam eine Identitäts- und Zugriffsverwaltungslösung für moderne hybride IT-Umgebungen und Anwendungen. Die Unterschiede und Beziehungen zwischen Windows Server AD DS und Azure AD lassen sich anhand folgender Beispiele verdeutlichen:

  1. Sie können Windows Server AD DS auf virtuellen Computern in Azure in der Cloud ausführen, wenn Sie Ihr lokales Rechenzentrum mithilfe von Azure auf die Cloud ausweiten.

  2. Sie können Azure AD verwenden, um Benutzern das einmalige Anmelden bei SaaS (Software-as-a-Service)-Anwendungen zu ermöglichen. Beispielsweise nutzt Microsoft Office 365 diese Technologie, die auch von Anwendungen in Azure oder anderen Cloudplattformen verwendet werden kann.

  3. So können Sie Benutzern über den Zugriffssteuerungsdienst von Azure AD die Möglichkeit geben, sich mit ihren Facebook-, Google- oder Microsoft-Identitäten oder unter Verwendung anderer Identitätsanbieter bei Anwendungen anzumelden, die in der Cloud oder lokal gehostet werden.

Weitere Informationen zu den Unterschieden finden Sie unter Azure-Identität.

Sie können den Bereitschaftstest für virtuelle Computer in Azure herunterladen und ausführen. Dieser Test prüft Ihre lokale Umgebung automatisch und erstellt einen spezifischen Bericht gemäß der Anleitungen in diesem Thema, um Sie bei der Migration Ihrer Umgebung zu Azure zu unterstützen.

Sie sollten sich zunächst die Lernprogramme, Anleitungen und Videos zu den folgenden Themen ansehen:

Die grundlegenden Voraussetzungen für die Bereitstellung von Windows Server Active Directory auf virtuellen Computern in Azure unterscheiden sich nur geringfügig von denen für die lokale Bereitstellung auf virtuellen Computern (und zum Teil auf physischen Computern). Beispiel für Windows Server AD DS: Wenn die Domänencontroller (DCs), die Sie auf virtuellen Computern in Azure bereitstellen, als Replikate in einer vorhandenen lokalen Unternehmensdomäne/-gesamtstruktur fungieren, kann die Azure-Bereitstellung weitgehend genauso wie ein anderer zusätzlicher Windows Server Active Directory-Standort behandelt werden. Das heißt, in Windows Server AD DS müssen Subnetze definiert, ein Standort erstellt, die Subnetze mit dem Standort verknüpft und unter Verwendung geeigneter Standortverknüpfungen mit anderen Standorten verbunden werden. Allerdings gibt es einige Unterschiede, die auf alle Azure-Bereitstellungen zutreffen, und wieder andere, die abhängig vom jeweiligen Bereitstellungsszenario variieren. Im Folgenden werden zwei grundlegende Unterschiede verdeutlicht, auf die in den nachstehenden Abschnitten ausführlicher eingegangen wird:

  1. Virtuelle Computer in Azure benötigen u. U. eine Verbindung mit dem lokalen Unternehmensnetzwerk.

    Um virtuelle Computer in Azure wieder mit einem lokalen Unternehmensnetzwerk zu verbinden, ist ein virtuelles Netzwerk in Azure erforderlich. Dieses Netzwerk bietet eine Standort-zu-Standort- oder Standort-zu-Punkt-VPN-Komponente (VPN = virtuelles privates Netzwerk), die in der Lage ist, eine nahtlose Verbindung zwischen virtuellen Computern in Azure und lokalen Computern herzustellen. Die VPN-Komponente könnte auch verwendet werden, um lokalen Computern, die Domänenmitglieder sind, den Zugriff auf eine Windows Server Active Directory-Domäne zu ermöglichen, deren Domänencontroller ausschließlich auf virtuellen Computern in Azure gehostet werden. Allerdings sollte beachtet werden, dass die Authentifizierung und andere Vorgänge, die von Windows Server Active Directory abhängig sind, bei einem Ausfall des VPNs ebenfalls fehlschlagen. Obwohl Benutzer vielleicht in der Lage sind, sich mithilfe vorhandener zwischengespeicherter Anmeldeinformationen anzumelden, verursachen alle Peer-zu-Peer- oder Client-zu-Server-Authentifizierungsversuche, für die noch Tickets ausgestellt werden müssen bzw. deren Tickets abgelaufen sind, einen Fehler.

    Unter Virtuelles Netzwerk finden Sie ein Demovideo und eine Liste schrittweiser Lernprogramme, darunter auch Konfigurieren eines Standort-zu-Standort-VPNs im Verwaltungsportal.

    noteHinweis
    Sie können Windows Server Active Directory auch in einem virtuellen Netzwerk in Azure bereitstellen, das keine Verbindung mit einem lokalen Netzwerk aufweist. Bei den Richtlinien in diesem Thema wird jedoch davon ausgegangen, dass ein virtuelles Netzwerk in Azure verwendet wird, weil es IP-Adressierungsfunktionen bietet, die für Windows Server unverzichtbar sind.

  2. Statische IP-Adressen müssen mithilfe von Azure PowerShell konfiguriert werden.

    Dynamische Adressen werden standardmäßig zugewiesen. Verwenden Sie jedoch stattdessen das Cmdlet Set-AzureStaticVNetIP, um eine statische IP-Adresse zuzuweisen. Auf diese Weise wird eine statische IP-Adresse zugewiesen, die nach einer Dienstreparatur und dem Herunterfahren/Neustarten des virtuellen Computers beibehalten wird. Weitere Informationen finden Sie unter Konfigurieren einer statischen internen IP-Adresse (DIP) für einen virtuellen Computer.

Im Folgenden werden einige wichtige Azure-Technologien erläutert. Die Begriffsliste erhebt keinen Anspruch auf Vollständigkeit und soll zum besseren Verständnis dieses Dokuments beitragen.

  • Virtuelle Computer in Azure: Das IaaS-Angebot in Azure, das Kunden die Bereitstellung von VMs ermöglicht, die nahezu jede Serverarbeitsauslastung unterstützen, die traditionell lokal ausgeführt wurde.

  • Virtuelles Netzwerk in Azure: Der Netzwerkdienst in Azure, mit dem Kunden virtuelle Netzwerke in Azure erstellen und verwalten und über ein virtuelles privates Netzwerk (VPN) sicher mit ihrer eigenen lokalen Netzwerkinfrastruktur verbinden können.

  • Virtuelle IP-Adresse (VIP): Eine Internet-IP-Adresse, die nicht an einen bestimmten Computer oder eine bestimmte Netzwerkschnittstellenkarte gebunden ist. Cloud-Diensten wird eine VIP für den Empfang von Netzwerkdatenverkehr zugewiesen, der an eine Azure-VM umgeleitet wird. Eine VIP ist eine Eigenschaft eines Cloud-Diensts, der einen oder mehrere virtuelle Computer in Windows Azure umfassen kann. Beachten Sie auch, dass ein virtuelles Netzwerk in Azure einen oder mehrere Cloud-Dienste enthalten kann. VIPs bieten systemeigene Lastenausgleichsfunktionen.

  • Dynamische IP-Adresse (DIP): Dies ist die IP-Adresse, die nur intern ist. Sie sollte als statische IP-Adresse (mithilfe des Cmdlets Set-AzureStaticVNetIP) für virtuelle Computer konfiguriert werden, die die DC-/DNS-Serverrollen hosten.

  • Dienstreparatur: Das Verfahren, mit dem ein Dienst von Azure automatisch wieder in einen Ausführungsstatus versetzt wird, nachdem der Ausfall des Diensts erkannt wurde. Die Dienstreparatur ist eine der Funktionen von Azure, die Verfügbarkeit und Resilienz unterstützt. Obwohl dieser Fall wahrscheinlich nicht eintritt, ist die Folge eines Dienstreparaturereignisses für einen auf einer VM ausgeführten DC vergleichbar mit einem ungeplanten Neustart, weist jedoch einige Nebeneffekte auf:

    • Der virtuelle Netzwerkadapter in der VM ändert sich

    • Die MAC-Adresse des virtuellen Netzwerkadapters ändert sich

    • Die Prozessor-/CPU-ID der VM ändert sich

    • Die IP-Konfiguration des virtuellen Netzwerkadapters ändert sich nicht, solange der virtuelle Computer an ein virtuelles Netzwerk angefügt und die IP-Adresse des virtuellen Computers statisch ist.

    Allerdings hat keiner dieser Umstände Einfluss auf Windows Server Active Directory, da keine Abhängigkeit von der MAC-Adresse oder der Prozessor-/CPU-ID besteht. Wie bereits erwähnt, wird außerdem empfohlen, alle Windows Server Active Directory-Bereitstellungen in Azure in einem virtuellen Azure-Netzwerk auszuführen.

Für die Bereitstellung von Windows Server Active Directory-DCs auf virtuellen Computern in Azure gelten dieselben Richtlinien wie für die lokale Ausführung von DCs auf einem virtuellen Computer. Die Ausführung virtualisierter DCs ist sicher, solange die Richtlinien zum Sichern und Wiederherstellen von DCs eingehalten werden. Weitere Informationen zu Einschränkungen und Richtlinien für die Ausführung virtualisierter DCs finden Sie unter Ausführen von Domänencontrollern in Hyper-V.

Es kann vorkommen, dass Hypervisoren Technologien bereitstellen oder trivialisieren, die in vielen verteilten Systemen, einschließlich Windows Server Active Directory, Probleme verursachen. Beispielsweise können Sie auf einem physischen Server einen Datenträger klonen, Rollbacks für den Serverstatus mithilfe nicht unterstützter Methoden ausführen, SANs verwenden usw. Diese Aufgaben auf einem physischen Server auszuführen, ist jedoch wesentlich schwieriger, als die Momentaufnahme eines virtuellen Computers in einem Hypervisor wiederherzustellen. Azure bietet Funktionen, die denselben unerwünschten Effekt verursachen können. Beispielsweise sollten Sie darauf verzichten, VHD-Dateien von DCs zu kopieren, anstatt regelmäßige Sicherungen auszuführen, da deren Wiederherstellung zu einer ähnlichen Situation wie die Verwendung von Momentaufnahme-Wiederherstellungsfunktionen führen kann.

Derartige Rollbacks verursachen USN-Blasen, die dauerhafte Statusabweichungen zwischen DCs bewirken können. Die Folgen sind unter anderem:

  • Fortbestehende Objekte

  • Inkonsistente Kennwörter

  • Inkonsistente Attributwerte

  • Schemakonflikte, wenn für den Schemamaster ein Rollback ausgeführt wird

Weitere Informationen zu den Auswirkungen auf DCs finden Sie unter USN und USN-Rollback.

Ab Windows Server 2012 sind erweiterten Sicherheitsmerkmale in AD DS integriert. Diese Sicherheitsmerkmale schützen virtualisierte Domänencontroller vor den bereits erwähnten Problemen, wenn die zugrunde liegende Hypervisor-Plattform VM-GenerationID unterstützt. Azure bietet Unterstützung für VM-GenerationID. Die Domänencontroller, auf denen Windows Server 2012 oder höher auf virtuellen Computern in Azure ausgeführt wird, weisen folglich die erweiterten Sicherheitsmerkmale auf.

noteHinweis
Sie sollten einen virtuellen Computer herunterfahren und neu starten, der die Domänencontrollerrolle in Azure im Gastbetriebssystem ausführt, anstatt die Option Herunterfahren im Azure-Verwaltungsportal zu verwenden. Wenn Sie das Verwaltungsportal zum Herunterfahren eines virtuellen Computers verwenden, wird der virtuelle Computer jetzt freigegeben. Ein freigegebener virtueller Computer hat den Vorteil, dass keine Gebühren anfallen, allerdings wird auch die VM-Generations-ID zurückgesetzt, was für einen Domänencontroller nicht wünschenswert ist. Beim Zurücksetzen der VM-Generations-ID wird auch die Aufrufkennung der AD DS-Datenbank zurückgesetzt, der RID-Pool verworfen und SYSVOL als nicht autorisierend gekennzeichnet. Weitere Informationen finden Sie unter Einführung in die Virtualisierung der Active Directory-Domänendienste (AD DS) (Stufe 100) und Safely Virtualizing DFSR (Sichere Virtualisierung der DFSR, in englischer Sprache).

Viele Windows Server AD DS-Bereitstellungsszenarien sind für die Bereitstellung als VMs in Azure gut geeignet. Angenommen, ein Unternehmen in Europa benötigt eine Lösung, um Benutzer an einem Remotestandort in Asien zu authentifizieren. Aufgrund der Bereitstellungskosten und mangelnder Fachkenntnisse in der Serververwaltung nach der Bereitstellung hat das Unternehmen bisher keine Windows Server Active Directory-Domänencontroller in Asien bereitgestellt. Folglich werden Authentifizierungsanforderungen aus Asien von Domänencontrollern in Europa verarbeitet, was Leistungseinbußen nach sich zieht. In diesem Fall können Sie einen Domänencontroller auf einem virtuellen Computer bereitstellen und festlegen, dass dieser innerhalb des Azure-Rechenzentrums in Asien ausgeführt werden muss. Wenn dieser Domänencontroller an ein virtuelles Netzwerk in Azure angefügt wird, das direkt mit dem Remotestandort verbunden ist, lässt sich die Authentifizierungsleistung verbessern.

Azure eignet sich ebenfalls als Ersatzlösung für ansonsten kostenträchtige Standorte zur Notfallwiederherstellung. Die relativ geringen Kosten, die für das Hosten einer kleineren Anzahl von Domänencontrollern und eines einzelnen virtuellen Netzwerks in Azure anfallen, sprechen für diese interessante Alternative.

Schließlich können Sie eine Netzwerkanwendung, wie SharePoint, in Azure bereitstellen, die zwar Windows Server Active Directory erfordert, aber keine Abhängigkeit vom lokalen Netzwerk oder dem Windows Server Active Directory-Unternehmenssystem aufweist. In diesem Fall würden die Anforderungen des SharePoint-Servers durch die Bereitstellung einer isolierten Gesamtstruktur in Azure optimal erfüllt. Auch hier wird die Bereitstellung von Netzwerkanwendungen unterstützt, für die eine Verbindung mit dem lokalen Netzwerk und dem Active Directory-Unternehmenssystem erforderlich ist.

noteHinweis
Da sie eine Layer-3-Verbindung bereitstellt, ist die VPN-Komponente, die ein virtuelles Azure-Netzwerk und ein lokales Netzwerk verbindet, auch in der Lage, lokal ausgeführte Mitgliedsserver zu unterstützen, um die als virtuelle Azure-Computer unter Azure Virtual Network ausgeführten Domänencontroller zu nutzen. Ist das VPN jedoch nicht verfügbar, können lokale Computer und Azure-basierte Domänencontroller nicht mehr miteinander kommunizieren, sodass Authentifizierungs- und verschiedene andere Fehler auftreten.  

  • Für jedes Windows Server Active Directory-Bereitstellungsszenario, das mehrere virtuelle Computer umfasst, ist die Verwendung eines virtuellen Azure-Netzwerks erforderlich, um konsistente IP-Adressen zu gewährleisten. In diesem Leitfaden wird davon ausgegangen, dass DCs in einem virtuellen Netzwerk in Azure ausgeführt werden.

  • Wie für lokale Domänencontroller werden statische IP-Adressen empfohlen. Eine statische IP-Adresse kann nur mithilfe von Azure PowerShell konfiguriert werden. Lesen Sie dazu Konfigurieren einer statischen internen IP-Adresse (DIP) für einen virtuellen Computer. Wenn Sie Überwachungssysteme oder andere Lösungen verwenden, die auf eine statische IP-Adresskonfiguration im Gastbetriebssystem prüfen, können Sie die gleiche statische IP-Adresse den Netzwerkadaptereigenschaften des virtuellen Computers zuweisen. Denken Sie jedoch daran, dass der Netzwerkadapter verworfen wird, wenn für den virtuellen Computer eine Dienstreparatur ausgeführt oder er im Verwaltungsportal heruntergefahren und die Zuordnung seiner Adresse aufgehoben wird. In diesem Fall muss die statische IP-Adresse im Gastbetriebssystem zurückgesetzt werden.

  • Die Bereitstellung von VMs in einem virtuellen Netzwerk bedeutet (oder erfordert) nicht, dass wieder eine Verbindung mit einem lokalen Netzwerk hergestellt wird, sondern das virtuelle Netzwerk bietet lediglich die Möglichkeit dazu. Sie müssen ein virtuelles Netzwerk für die private Kommunikation zwischen Azure und Ihrem lokalen Netzwerk erstellen und einen VPN-Endpunkt im lokalen Netzwerk bereitstellen. Das VPN wird von Azure für das lokale Netzwerk geöffnet. Weitere Informationen finden Sie unter Überblick über virtuelle Netzwerke und Konfigurieren eines Standort-zu-Standort-VPNs im Verwaltungsportal.

    noteHinweis
    Eine Option zum Erstellen eines Punkt-zu-Standort-VPNs besteht darin, einzelne Windows-basierte Computer direkt mit einem virtuellen Netzwerk in Azure zu verbinden.

  • Unabhängig davon, ob Sie ein virtuelles Netzwerk erstellen oder nicht, fallen in Azure Gebühren für ausgehenden, aber nicht für eingehenden Datenverkehr an. Die Höhe des durch eine Bereitstellung verursachten ausgehenden Datenverkehrs kann durch unterschiedliche Konfigurationen von Windows Server Active Directory beeinflusst werden. Wenn Sie beispielsweise einen RODC (Read-Only Domain Controller = schreibgeschützter Domänencontroller)bereitstellen, wird der ausgehende Datenverkehr eingeschränkt, da keine ausgehende Replikation stattfindet. Die Entscheidung, einen RODC bereitzustellen, muss jedoch gegen die Anforderung abgewogen werden, Schreibvorgänge für den Domänencontroller auszuführen, und die Kompatibilität, die Anwendungen und Dienste am Standort mit RODCs aufweisen, muss berücksichtigt werden. Weitere Informationen zu Gebühren für Datenverkehr finden Sie in der Azure-Preisübersicht.

  • Während Sie bei lokalen virtuellen Computern exakt steuern können, welche Serverressourcen, z. B. Arbeitsspeicherkapazität, Datenträgergröße usw., zum Einsatz kommen, müssen Sie in Azure aus einer Liste vorkonfigurierter Servergrößen auswählen. Für einen DC wird neben einem Betriebssystem-Datenträger auch ein Datenträger zum Speichern der Windows Server Active Directory-Datenbank benötigt.

Ja, Sie können Windows Server AD FS auf virtuellen Computern in Azure bereitstellen und die bewährten Methoden für die lokale Bereitstellung der AD FS gelten auch für die AD FS-Bereitstellung in Azure. Einige der bewährten Methoden (z. B. Lastenausgleich und hohe Verfügbarkeit) erfordern jedoch Technologien, die den Leistungsumfang überschreiten, den die AD FS selbst bietet. Sie müssen von der zugrunde liegenden Infrastruktur bereitgestellt werden. Im Folgenden lernen Sie einige dieser bewährten Methoden kennen und erfahren, wie Sie sie mithilfe von virtuellen Computern in Azure und einem Azure-VNet umsetzen können.

  1. Verbinden Sie Sicherheitstokendienst-Server (STS-Server) nie direkt mit dem Internet.

    Dies ist wichtig, da die Sicherheitstoken von der STS-Rolle ausgegeben werden. Daher sollten STS-Server, wie z. B. AD FS-Server, das gleiche Maß an Schutz erhalten wie ein Domänencontroller. Wenn ein Sicherheitstokendienst nicht mehr sicher ist, können böswillige Benutzer Zugriffstoken (die manipulierte Ansprüche enthalten können) für Anwendungen der vertrauenden Seite und andere STS-Server in vertrauenden Organisationen ausgeben.

  2. Stellen Sie Active Directory-Domänencontroller für alle Benutzerdomänen im selben Netzwerk wie die AD FS-Server bereit.

    AD FS-Server verwenden den Active Directory-Domänendienst zum Authentifizieren von Benutzern. Es wird empfohlen, Domänencontroller im selben Netzwerk wie die AD FS-Server bereitzustellen. Dadurch wird die Geschäftskontinuität für den Fall gewährleistet, dass die Verbindung zwischen dem Azure-Netzwerk und Ihrem lokalen Netzwerk unterbrochen ist, und außerdem die Latenz verringert und die Leistung bei Anmeldungen verbessert.

  3. Stellen Sie mehrere AD FS-Knoten für hohe Verfügbarkeit und Lastenausgleich bereit.

    Der Ausfall einer Anwendung, die über die Active Directory-Verbunddienste (AD FS) verwaltet wird, ist in den meisten Fällen nicht hinnehmbar, da Anwendungen, die Sicherheitstoken benötigen, häufig unternehmenskritisch sind. Aus diesem Grund und aufgrund der Tatsache, dass sich die AD FS jetzt im kritischen Pfad für den Zugriff auf unternehmenskritische Anwendungen befinden, müssen die AD FS hohe Verfügbarkeit aufweisen, was über mehrerer AD FS-Proxys und AS FS-Server bewerkstelligt wird. Zur Verteilung von Anforderungen werden normalerweise Lastenausgleichsmodule verwendet, die sowohl den AD FS-Proxys als auch den AD FS-Servern vorgelagert sind.

  4. Stellen Sie einen oder mehrere Webanwendungsproxy-Knoten für den Internetzugriff bereit.

    Wenn Benutzer Zugriff auf Anwendungen benötigen, die durch die AD FS geschützt sind, müssen die AD FS über das Internet verfügbar sein. Zu diesem Zweck stellen Sie den Webanwendungsproxy-Dienst bereit. Es wird dringend empfohlen, mehr als einen Knoten bereitzustellen, um hohe Verfügbarkeit und Lastenausgleich zu gewährleisten.

  5. Schränken Sie den Zugriff von den Webanwendungsproxy-Knoten auf interne Netzwerkressourcen ein.

    Damit externe Benutzer auf die AD FS über das Internet zugreifen zu können, müssen Sie Webanwendungsproxy-Knoten (oder einen AD FS-Proxy in früheren Versionen von Windows Server) bereitstellen. Die Webanwendungsproxy-Knoten sind direkt mit dem Internet verbunden. Sie müssen nicht in eine Domäne eingebunden sein, und sie benötigen nur über die TCP-Ports 443 und 80 Zugriff auf die AD FS-Server. Es empfiehlt sich, die Kommunikation mit allen anderen Computern (insbesondere Domänencontrollern) zu blockieren.

    Dies wird normalerweise lokal mithilfe einer DMZ umgesetzt. Firewalls arbeiten in einen Positivlisten-Betriebsmodus, um den Datenverkehr aus der DMZ zum lokalen Netzwerk einzuschränken (es wird also nur Datenverkehr von den angegebenen IP-Adressen und über die angegebenen Ports erlaubt und der verbleibende Datenverkehr blockiert).

Das folgende Diagramm zeigt, wie dies in einer herkömmlichen lokalen AD FS-Bereitstellung aussieht.

ADFS lokal mit DMZ

Da Azure jedoch keine systemeigene Firewall mit vollem Funktionsumfang bereitstellt, muss der Datenverkehr mithilfe anderer Optionen beschränkt werden. In der folgenden Tabelle sind die einzelnen Optionen mit ihren Vor- und Nachteilen aufgeführt.

 

Option Vorteil Nachteil

Azure-Netzwerk-ACLs

Geringere Kosten und einfachere Erstkonfiguration

Zusätzliche Netzwerk-ACL-Konfiguration erforderlich, wenn der Bereitstellung neue virtuelle Computer hinzugefügt werden.

Barracuda NG Firewall

Positivlisten-Betriebsmodus, keine Netzwerk-ACL-Konfiguration erforderlich

Höhere Kosten und Komplexität bei der anfänglichen Einrichtung.

Die allgemeinen Schritte zum Bereitstellen der AD FS sehen in diesem Fall wie folgt aus:

  1. Erstellen Sie ein virtuelles Netzwerk mit standortübergreifenden Verbindungen, entweder über ein VPN oder mithilfe von ExpressRoute.

  2. Stellen Sie Domänencontroller im virtuellen Netzwerk bereit. Dieser Schritt ist nicht obligatorisch, aber empfohlen.

  3. Stellen Sie in die Domäne eingebundene AD FS-Server im virtuellen Netzwerk bereit.

  4. Erstellen Sie eine interne Gruppe mit Lastenausgleich , die die AD FS-Server enthält und eine neue private IP-Adresse (DIP) innerhalb des virtuellen Netzwerks verwendet.

    1. Aktualisieren Sie das DNS, indem Sie den vollqualifizierten Domänennamen (FQDN) so erstellen, dass er auf die private IP-Adresse (DIP) der internen Gruppe mit Lastenausgleich verweist.

  5. Erstellen Sie einen Cloud-Dienst (oder ein separates virtuelles Netzwerk) für die Webanwendungsproxy-Knoten.

  6. Stellen Sie die Webanwendungsproxy-Knoten im Cloud-Dienst oder virtuellen Netzwerk bereit.

    1. Erstellen Sie eine externe Gruppe mit Lastenausgleich, die die Webanwendungsproxy-Knoten enthält.

    2. Aktualisieren Sie den externen DNS-Namen (FQDN) so, dass er auf die öffentliche IP-Adresse (VIP) des Cloud-Diensts verweist.

    3. Konfigurieren Sie die AD FS-Proxys zur Verwendung des FQDN, der der internen Gruppe mit Lastenausgleich für die AD FS-Server entspricht.

    4. Aktualisieren Sie anspruchsbasierte Websites so, dass sie den externen FQDN für ihre Anspruchsanbieter verwenden.

  7. Schränken Sie den Zugriff vom Webanwendungsproxy auf jeden Computer im virtuellen AD FS-Netzwerk ein.

Um den Datenverkehr einzuschränken, muss die Gruppe mit Lastenausgleich für den Azure-internen Lastenausgleich so konfiguriert sein, dass Datenverkehr nur über die TCP-Ports 80 und 443 möglich ist und der verbleibende Datenverkehr an die interne DIP der Gruppe mit Lastenausgleich verweigert wird.

ADFS-Netzwerk-ACLs

Datenverkehr an die AD FS-Server wird nur von den folgenden Quellen erlaubt:

  • Dem Azure-internen Lastenausgleich.

  • Der IP-Adresse eines Administrators im lokalen Netzwerk.

WarningWarnung
Das Design muss verhindern, dass Webanwendungsproxy-Knoten andere virtuelle Computer im virtuellen Netzwerk in Azure oder andere Speicherorte im lokalen Netzwerk erreichen. Dies kann durch Konfigurieren von Firewallregeln im lokalen Gerät für ExpressRoute-Verbindungen oder im VPN-Gerät für Standort-zu-Standort-VPN-Verbindungen erfolgen.

Ein Nachteil bei dieser Option besteht darin, dass die Netzwerk-ACLs für mehrere Geräte konfiguriert werden müssen, darunter für den internen Lastenausgleich, die AD FS-Server und alle anderen Server, die dem virtuellen Netzwerk hinzugefügt werden. Wenn Sie ein Gerät hinzufügen, ohne Netzwerk-ACLs zum Einschränken von Datenverkehr an das Gerät zu konfigurieren, kann die gesamte Bereitstellung gefährdet sein. Falls sich die IP-Adressen der Webanwendungsproxy-Knoten jemals ändern, müssen die Netzwerk-ACLs zurückgesetzt werden (die Proxys sollten also zur Verwendung von statischen DIPs konfiguriert sein).

ADFS unter Azure mit Netzwerk-ACLs

Eine andere Möglichkeit ist die Verwendung der Barracuda NG Firewall zur Steuerung des Datenverkehrs zwischen AD FS-Proxyservern und den AD FS-Servern. Die Barracuda NG Firewall entspricht den bewährten Methoden für Sicherheit und hohe Verfügbarkeit und reduziert den Verwaltungsaufwand nach der Ersteinrichtung, da sie Firewallverwaltung im Positivlistenmodus bietet und direkt in einem virtuellen Netzwerk in Azure installiert werden kann. Dadurch müssen Sie keine Netzwerk-ACLs konfigurieren, wenn Sie die Bereitstellung um neue Server erweitern. Allerdings ist bei dieser Option die anfängliche Bereitstellung komplexer und der Kostenaufwand höher.

In diesem Szenario werden zwei virtuelle Netzwerke statt einem einzigen bereitgestellt. VNet 1 enthält die Proxys und VNet2 enthält die Sicherheitstokendienste und die Netzwerkverbindung mit dem Unternehmensnetzwerk. VNet1 ist daher physisch (obgleich virtuell) vom VNet2 isoliert und darum auch vom Unternehmensnetzwerk. VNet 1 wird dann mit einer speziellen Tunneling-Technologie, der Transport Independent Network Architecture (TINA), mit VNet2 verbunden. Der TINA-Tunnel wird mithilfe einer Barracuda NG Firewall an jedes VNet angebunden, wobei sich in jedem der VNets eine Barracuda befindet. Um hohe Verfügbarkeit zu gewährleisten, empfiehlt sich die Bereitstellung von zwei Barracuda NG Firewalls in jedem VNet: einer aktiven und einer passiven. Sie bieten äußerst umfangreiche Firewallfunktionen, die dem Betrieb einer herkömmlichen lokalen DMZ in Azure praktisch gleichkommen.

ADFS unter Azure mit Firewall

Weitere Informationen finden Sie unter 2. AD FS: Ausweiten einer Ansprüche unterstützenden lokalen Front-End-Anwendung auf das Internet.

Alternative zur AD FS-Bereitstellung, wenn SSO nur für Office 365 benötigt wird

Wenn Sie die Anmeldung nur für Office 365 ermöglichen möchten, gibt es eine weitere Alternative zur AD FS-Bereitstellung. In diesem Fall können Sie einfach DirSync mit Kennwortsynchronisierung lokal bereitstellen. Das Endergebnis ist das gleiche, die Bereitstellung jedoch viel einfacher, da Sie für diesen Ansatz weder die AD FS noch Azure benötigen.

In der folgenden Tabelle wird verglichen, wie die Anmeldeprozesse mit und ohne Bereitstellung von AD FS funktionieren.

 

Einmaliges Anmelden für Office 365 mit AD FS und DirSync Identische Anmeldung für Office 365 bei Verwendung von DirSync und Kennwortsynchronisierung
  1. Der Benutzer meldet sich am Unternehmensnetzwerk an und wird für Windows Server Active Directory authentifiziert.

  2. Der Benutzer versucht, auf Office 365 (@contoso.com) zuzugreifen.

  3. Office 365 leitet den Benutzer an Azure AD um.

  4. Da Azure AD den Benutzer nicht authentifizieren kann und davon ausgeht, dass die lokale AD FS-Bereitstellung vertrauenswürdig ist, leitet es den Benutzer an AD FS um.

  5. Der Benutzer sendet ein Kerberos-Ticket an den AD FS-Sicherheitstokendienst.

  6. AD FS wandelt das Kerberos-Ticket in das erforderliche Tokenformat bzw. die Ansprüche um und leitet den Benutzer an Azure AD um.

  7. Der Benutzer authentifiziert sich bei Azure AD (eine weitere Transformation findet statt).

  8. Azure AD leitet den Benutzer an Office 365 um.

  9. Der Benutzer wird automatisch bei Office 365 angemeldet.

  1. Der Benutzer meldet sich am Unternehmensnetzwerk an und wird für Windows Server Active Directory authentifiziert.

  2. Der Benutzer versucht, auf Office 365 (@contoso.com) zuzugreifen.

  3. Office 365 leitet den Benutzer an Azure AD um.

  4. Azure AD kann Kerberos-Tickets nicht direkt übernehmen. Folglich besteht keine Vertrauensbeziehung, und der Benutzer wird aufgefordert, Anmeldeinformationen einzugeben.

  5. Der Benutzer gibt das gleiche lokale Kennwort ein. Dieses wird von Azure AD anhand des Benutzernamens und Kennworts überprüft, die per DirSync synchronisiert wurden.

  6. Azure AD leitet den Benutzer an Office 365 um.

  7. Der Benutzer kann sich an Office 365 und OWA anmelden, indem er das Azure AD-Token verwendet.

In einem Szenario, in dem DirSync mit Kennwortsynchronisierung für Office 365 (ohne AD FS) verwendet wird, handelt es sich weniger um eine einmalige Anmeldung, sondern vielmehr um immer dieselbe Anmeldung. Dies bedeutet einfach, dass Benutzer die gleichen lokalen Anmeldeinformationen immer wieder eingeben müssen, wenn sie auf Office 365 zugreifen. Beachten Sie, dass diese Daten durch den Browser des Benutzers gespeichert werden können, um nachfolgende Eingabeaufforderungen zu verringern.

Zusätzlicher Denkanstoß

  • Wenn Sie einen AD FS-Proxy auf einem virtuellen Computer in Azure bereitstellen, wird eine Verbindung mit den AD FS-Servern benötigt. Bei lokalen Servern empfiehlt es sich, die Standort-zu-Standort-VPN-Verbindungsfunktion des virtuellen Netzwerks zu nutzen, um den Webanwendungsproxy-Knoten die Kommunikation mit ihren AD FS-Servern zu ermöglichen.

  • Wenn Sie einen AD FS-Server auf einem virtuellen Computer in Azure bereitstellen, sind Verbindungen mit Windows Server Active Directory-Domänencontrollern, Attributspeichern und Konfigurationsdatenbanken erforderlich und möglicherweise auch eine ExpressRoute- oder Standort-zu-Standort-VPN-Verbindung zwischen dem virtuellen Netzwerk in Azure und dem lokalen Netzwerk.

  • Der gesamte ausgehende Datenverkehr von virtuellen Computern in Azure ist gebührenpflichtig. Aus Kostengründen ist es sinnvoll, die Webanwendungsproxy-Knoten unter Azure bereitzustellen und die AD FS-Server lokal auszuführen. Wenn die AD FS-Server auch auf virtuellen Computern in Azure bereitgestellt werden, entstehen zusätzliche Kosten durch die Authentifizierung lokaler Benutzer. Ausgehender Datenverkehr verursacht Kosten unabhängig davon, ob die ExpressRoute- oder VPN-Standort-zu-Standort-Verbindung genutzt wird.

  • Wenn Sie sich dazu entschließen, die in Azure integrierten Funktionen für den Serverlastenausgleich zu verwenden, um die hohe Verfügbarkeit von AD FS-Servern zu gewährleisten, sollten Sie berücksichtigen, dass der Lastenausgleich Überprüfungen ausführt, mit deren Hilfe die Integrität der virtuellen Computer innerhalb des Cloud-Diensts festgestellt wird. Bei virtuellen Computern in Azure muss (im Gegensatz zu Web- oder Workerrollen) eine benutzerdefinierte Überprüfung verwendet werden, da der Agent, der auf die Standardüberprüfungen reagiert, auf virtuellen Computern in Azure nicht vorhanden ist. Der Einfachheit halber können Sie eine benutzerdefinierte TCP-Überprüfung verwenden – dies erfordert lediglich, dass eine TCP-Verbindung erfolgreich hergestellt (ein TCP-SYN-Segment gesendet und mit einem TCP-SYN-ACK-Segment darauf reagiert) wird, um die Integrität des virtuellen Computers zu bestimmen. Für die benutzerdefinierte Überprüfung kann jeder TCP-Port konfiguriert werden, an dem die virtuellen Computer aktiv lauschen. Anleitungen hierzu finden Sie unter Konfigurieren einer Gruppe mit Lastenausgleich.

    noteHinweis
    Computer, die dieselbe Portgruppe (z. B. Port 80 und 443) direkt für das Internet verfügbar machen müssen, können nicht denselben Cloud-Dienst verwenden. Daher wird empfohlen, einen dedizierten Cloud-Dienst für Windows Server AD FS-Server zu erstellen, um mögliche Überschneidungen zwischen den Portanforderungen einer Anwendung und Windows Server AD FS zu vermeiden.

Im folgenden Abschnitt werden allgemeine Bereitstellungsszenarien erörtert und wichtige Aspekte aufgezeigt, die berücksichtigt werden müssen. Jedes Szenario bietet Links zu Informationen, in denen die wichtigsten Entscheidungen und Faktoren ausführlich erläutert werden.

AD DS-Bereitstellung nur für die Cloud

Abbildung 1

SharePoint wird auf einem virtuellen Computer in Azure bereitgestellt, und die Anwendung weist keine Abhängigkeiten von Ressourcen im Unternehmensnetzwerk auf. Die Anwendung benötigt Windows Server AD DS, ist jedoch NICHT auf die Windows Server AD DS-Unternehmensinfrastruktur angewiesen. Es werden weder Kerberos noch Verbundvertrauensstellungen benötigt, da Benutzer durch die Anwendung in der Windows Server AD DS-Domäne selbst bereitgestellt werden, die auch in der Cloud auf virtuellen Computern in Azure gehostet wird.

  • Netzwerktopologie: Erstellen Sie ein virtuelles Netzwerk in Azure ohne standortübergreifende Verbindungen (auch als Standort-zu-Standort-Konnektivität bezeichnet).

  • DC-Bereitstellungskonfiguration: Stellen Sie einen neuen Domänencontroller in einer neuen Windows Server Active Directory-Gesamtstruktur bereit, die nur eine Domäne umfasst. Diese sollte zusammen mit dem Windows-DNS-Server bereitgestellt werden.

  • Windows Server Active Directory-Standorttopologie: Verwenden Sie den Windows Server Active Directory-Standardstandort (alle Computer befinden sich in "Standardname-des-ersten-Standorts").

  • IP-Adressierung und DNS:

    • Legen Sie eine statische IP-Adresse für den Domänencontroller mithilfe des Azure PowerShell-Cmdlets Set-AzureStaticVNetIP fest.

    • Installieren und konfigurieren Sie Windows Server-DNS auf dem bzw. den Domänencontrollern in Azure.

    • Konfigurieren Sie die Eigenschaften für das virtuelle Netzwerke mit dem Namen und der IP-Adresse des virtuellen Computers, der die Domänencontroller- und DNS-Serverrollen hostet.

  • Globaler Katalog: Der erste Domänencontroller in der Gesamtstruktur muss ein globaler Katalogserver sein. Zusätzliche DCs sollten auch als globale Kataloge (Global Catalogs = GCs) konfiguriert werden, da der globale Katalog in einer aus einer Einzeldomäne bestehenden Gesamtstruktur keine zusätzliche Leistung vom Domänencontroller beansprucht.

  • Platzierung von Windows Server AD DS-Datenbank und SYSVOL: Fügen Sie den als virtuelle Azure-Computer ausgeführten Domänencontrollern einen Datenträger hinzu, um die Windows Server Active Directory-Datenbank, Protokolle und SYSVOL zu speichern.

  • Sicherung und Wiederherstellung: Bestimmen Sie, wo Sicherungen des Systemstatus gespeichert werden sollen. Fügen Sie der DC-VM ggf. einen weiteren Datenträger zum Speichern von Sicherungen hinzu.

Verbund mit standortübergreifender Konnektivität

Abbildung 2

Eine Ansprüche unterstützende Anwendung, die erfolgreich lokal bereitgestellt und von Unternehmensanwendern genutzt wird, soll Direktzugriffe aus dem Internet unterstützen. Die Anwendung fungiert als Web-Front-End für eine SQL-Datenbank, in der Daten gespeichert und abgerufen werden. Die von der Anwendung verwendeten SQL-Server befinden sich ebenfalls im Unternehmensnetzwerk. Zwei Windows Server AD FS-Sicherheitstokendienste und ein Lastenausgleichsmodul wurden lokal bereitgestellt, um Unternehmensanwendern den Zugriff zu ermöglichen. Zusätzlich müssen jetzt sowohl Geschäftspartner mit eigenen Unternehmenskonten als auch bestehende Unternehmensanwender in der Lage sein, direkt über das Internet auf die Anwendung zuzugreifen.

In dem Bestreben, die Bereitstellungs- und Konfigurationsanforderungen unter den neuen Voraussetzungen zu vereinfachen und zu erfüllen, werden zwei zusätzliche Web-Front-Ends und zwei Windows Server AD FS-Proxyserver auf virtuellen Computern in Azure installiert. Alle vier VMs werden direkt im Internet verfügbar gemacht und mithilfe der Standort-zu-Standort-VPN-Funktion des virtuellen Netzwerks in Azure mit dem lokalen Netzwerk verbunden.

  • Netzwerktopologie: Erstellen Sie ein virtuelles Netzwerk in Azure, und konfigurieren Sie standortübergreifende Verbindungen.

    noteHinweis
    Stellen Sie bei allen Windows Server AD FS-Zertifikaten sicher, dass die in der Zertifikatvorlage definierte URL und die resultierenden Zertifikate für die Windows Server AD FS-Instanzen, die in Azure ausgeführt werden, erreichbar sind. Möglicherweise sind dazu standortübergreifende Verbindungen zu Teilen Ihrer Public Key-Infrastruktur erforderlich. Wenn der Endpunkt der Zertifikatsperrliste beispielsweise LDAP-basiert ist und ausschließlich lokal gehostet wird, sind standortübergreifende Verbindungen erforderlich. Falls dies nicht erwünscht ist, müssen u. U. Zertifikate von einer Zertifizierungsstelle verwendet werden, auf deren Zertifikatsperrliste über das Internet zugegriffen werden kann.

  • Cloud-Dienstkonfiguration: Stellen Sie sicher, dass Sie über zwei Cloud-Dienste verfügen, um zwei VIPs mit Lastenausgleich bereitzustellen. Die VIP des ersten Cloud-Diensts wird an die zwei virtuellen Windows Server AD FS-Proxycomputer an den Ports 80 und 443 weitergeleitet. Die virtuellen Windows Server AD FS-Proxycomputer werden so konfiguriert, dass sie auf die IP-Adresse des lokalen Lastenausgleichsmoduls verweisen, das den Windows Server AD FS-Sicherheitstokendiensten vorgelagert ist. Die VIP des zweiten Cloud-Diensts wird an die zwei virtuellen Computer weitergeleitet, die das Web-Front-End ausführen – ebenfalls an den Ports 80 und 443. Konfigurieren Sie eine benutzerdefinierte Überprüfung, um sicherzustellen, dass der Lastenausgleich Datenverkehr nur an funktionsfähige virtuelle Windows Server AD FS-Proxycomputer und Web-Front-End-Computer weiterleitet.

  • Verbundserverkonfiguration: Konfigurieren Sie Windows Server AD FS als Verbundserver (Sicherheitstokendienst), um Sicherheitstoken für die in der Cloud erstellte Windows Server Active Directory-Gesamtstruktur zu generieren. Legen Sie Vertrauensstellungen der Verbundanspruchsanbieter für die unterschiedlichen Partner fest, deren Identitäten akzeptiert werden sollen, und konfigurieren Sie Vertrauensstellungen der vertrauenden Seite für die verschiedenen Anwendungen, für die Token generiert werden sollen.

    In den meisten Szenarien werden Windows Server AD FS-Proxyserver aus Sicherheitsgründen mit Internetzugriff bereitgestellt, während deren Entsprechung, die Windows Server AD FS-Verbundserver, ohne direkte Internetverbindung ausgeführt werden. Unabhängig vom Bereitstellungsszenario müssen Sie den Cloud-Dienst mit einer VIP konfigurieren, die eine öffentlich verfügbar gemachte IP-Adresse und einen entsprechenden Port bereitstellt, über die ein Lastenausgleich zwischen den beiden Windows Server AD FS-Sicherheitstokendiensten oder -Proxyinstanzen ausgeführt werden kann.

  • Windows Server AD FS-Konfiguration für hohe Verfügbarkeit: Um Failover und Lastenausgleich zu ermöglichen, empfiehlt sich die Bereitstellung einer Windows Server AD FS-Farm mit mindestens zwei Servern. Beispielsweise könnten Sie die interne Windows-Datenbank (WID) für Windows Server AD FS-Konfigurationsdaten verwenden und eingehende Anforderungen mithilfe der Funktion für internen Lastenausgleich von Azure auf die Server in der Farm verteilen.

    Weitere Informationen finden Sie im Bereitstellungshandbuch zu AD DS 2.0.

Standortübergreifende AD DS-Bereitstellung

Abbildung 3

Eine LDAP-fähige Anwendung, welche die integrierte Windows-Authentifizierung unterstützt und Windows Server AD DS als Repository für Konfigurations- und Benutzerprofildaten verwendet, wird auf einem virtuellen Computer in Azure bereitgestellt. Die Anwendung soll die vorhandene Windows Server AD DS-Unternehmensinfrastruktur nutzen und einmaliges Anmelden ermöglichen. Außerdem unterstützt sie keine Ansprüche. Zusätzlich müssen Benutzer in der Lage sein, direkt über das Internet auf die Anwendung zuzugreifen. Zur Leistungs- und Kostenoptimierung werden neben der Anwendung zwei zusätzliche Domänencontroller, die Teil der Unternehmensdomäne sind, in Azure bereitgestellt.

  • Netzwerktopologie: Erstellen Sie ein virtuelles Netzwerk in Azure mit standortübergreifender Konnektivität.

  • Installationsmethode: Stellen Sie Replikatdomänencontroller aus der Windows Server Active Directory-Unternehmensdomäne bereit. Für einen Replikat-DC können Sie Windows Server AD DS auf der VM installieren und optional mithilfe der Funktion "Installieren von Medium" (Install From Media, IFM) die Datenmenge reduzieren, die während der Installation auf den neuen DC repliziert werden muss. Ein entsprechendes Lernprogramm finden Sie unter Installieren eines Active Directory-Replikatdomänencontrollers in Azure. Selbst bei Verwendung von IFM ist es u. U. effizienter, den virtuellen DC lokal zu erstellen und die gesamte VHD in die Cloud zu verschieben, anstatt Windows Server AD DS während der Installation zu replizieren. Aus Sicherheitsgründen wird empfohlen, die VHD aus dem lokalen Netzwerk zu löschen, nachdem sie in Azure kopiert wurde.

  • Windows Server Active Directory-Standorttopologie: Erstellen Sie eine neue Azure-Website in Active Directory-Standorte und -Dienste. Erstellen Sie ein Windows Server Active Directory-Subnetzobjekt, das das virtuelle Netzwerk in Azure darstellt, und fügen Sie der Website das Subnetz hinzu. Erstellen Sie eine neue Standortverknüpfung, die die neue Azure-Website und die Website umfasst, in der der VPN-Endpunkt des virtuellen Netzwerks in Azure enthalten ist, um den Datenverkehr zwischen Windows Server Active Directory und Azure zu steuern und zu optimieren.

  • IP-Adressierung und DNS:

    • Legen Sie eine statische IP-Adresse für den Domänencontroller mithilfe des Azure PowerShell-Cmdlets Set-AzureStaticVNetIP fest.

    • Installieren und konfigurieren Sie Windows Server-DNS auf dem bzw. den Domänencontrollern in Azure.

    • Konfigurieren Sie die Eigenschaften für das virtuelle Netzwerke mit dem Namen und der IP-Adresse des virtuellen Computers, der die Domänencontroller- und DNS-Serverrollen hostet.

  • Geografisch verteilte DCs: Konfigurieren Sie ggf. zusätzliche virtuelle Netzwerke. Wenn Ihre Active Directory-Standorttopologie Domänencontroller in einer geografischen Region erfordert, die anderen Azure-Regionen entspricht, möchten Sie ggf. entsprechende Active Directory-Standorte erstellen.

  • Schreibgeschützte DCs: Abhängig davon, ob für den Domänencontroller Schreibvorgänge ausgeführt werden sollen und ob die Anwendungen und Dienste auf der Website mit RODCs kompatibel sind, können Sie einen RODC in der Azure-Website bereitstellen. Weitere Informationen zur Anwendungskompatibilität finden Sie unter Anwendungskompatibilität mit Domänencontrollern ohne Schreibzugriff.

  • Globaler Katalog: Globale Kataloge werden für die Verarbeitung von Anmeldeanforderungen in Gesamtstrukturen mit mehreren Domänen benötigt. Wenn Sie in der Azure-Website keinen GC bereitstellen, entstehen Kosten für ausgehenden Datenverkehr, weil Authentifizierungsanforderungen dazu führen, dass GCs in anderen Websites abgefragt werden. Um diesen Datenverkehr zu verringern, können Sie in "Active Directory-Standorte und -Dienste" das Zwischenspeichern der universellen Gruppenmitgliedschaft für die Azure-Website aktivieren.

    Wenn Sie einen GC bereitstellen, konfigurieren Sie die Standortverknüpfungen und zugehörigen Kosten, damit der GC in der Azure-Website von anderen GCs, die dieselben Domänenteilpartitionen replizieren müssen, nicht als bevorzugter Quell-DC behandelt wird.

  • Platzierung von Windows Server AD DS-Datenbank und SYSVOL: Fügen Sie den auf virtuellen Azure-Computern ausgeführten Domänencontrollern einen Datenträger hinzu, um die Windows Server Active Directory-Datenbank, Protokolle und SYSVOL zu speichern.

  • Sicherung und Wiederherstellung: Bestimmen Sie, wo Sicherungen des Systemstatus gespeichert werden sollen. Fügen Sie der DC-VM ggf. einen weiteren Datenträger zum Speichern von Sicherungen hinzu.

In der folgenden Tabelle sind die in den vorherigen Szenarien angesprochenen Technologiebereiche von Windows Server Active Directory zusammengefasst. Außerdem enthält sie Entscheidungshilfen und Links zu ausführlicheren Informationen. Einige Technologiebereiche sind u. U. nicht auf alle Bereitstellungsszenarien anwendbar, und manche Technologiebereiche sind möglicherweise wichtiger für ein Bereitstellungsszenario als andere.

Wenn Sie beispielsweise einen Replikat-DC in einem virtuellen Netzwerk bereitstellen und die Gesamtstruktur nur eine einzelne Domäne umfasst, hat die Bereitstellung eines globalen Katalogservers in diesem Fall keinen entscheidenden Einfluss auf das Bereitstellungsszenario, da kein zusätzlicher Replikationsbedarf entsteht. Verfügt die Gesamtstruktur andererseits über mehrere Domänen, kann sich die Entscheidung, einen globalen Katalog in einem virtuellen Netzwerk bereitzustellen, auf die verfügbare Bandbreite, die Leistung, die Authentifizierung, Verzeichnissuchen usw. auswirken.

 

Nummer

Technologiebereich von Windows Server Active Directory

Entscheidungen

Faktoren

1

Netzwerktopologie

Erstellen Sie ein virtuelles Netzwerk?

Notwendigkeit, auf Unternehmensressourcen zuzugreifen

Authentifizierung

Kontenverwaltung

2

DC-Bereitstellungskonfiguration

  • Soll eine getrennte Gesamtstruktur ohne Vertrauensstellungen bereitgestellt werden?

  • Soll eine neue Gesamtstruktur mit Verbund bereitgestellt werden?

  • Soll eine neue Gesamtstruktur mit Windows Server Active Directory-Gesamtstruktur-Vertrauensstellung für Kerberos bereitgestellt werden?

  • Soll eine Unternehmensgesamtstruktur durch die Bereitstellung eines Replikat-DCs erweitert werden?

  • Soll eine Unternehmensgesamtstruktur durch die Bereitstellung einer neuen untergeordneten Domäne oder Domänenstruktur erweitert werden?

Sicherheit

Compliance

Kosten

Resilienz und Fehlertoleranz

Anwendungskompatibilität

3

Windows Server Active Directory-Standorttopologie

Wie werden Subnetze, Standorte und Standortverknüpfungen beim virtuellen Netzwerk in Azure konfiguriert, um den Datenverkehr zu optimieren und die Kosten zu minimieren?

Subnetz- und Standortdefinitionen

Standortverknüpfungseigenschaften und Änderungsbenachrichtigung

Replikationskomprimierung

4

IP-Adressierung und DNS

Wie werden IP-Adressen und Namensauflösung konfiguriert?

Verwenden Sie das Cmdlet "Set-AzureStaticVNetIP", um eine statische IP-Adresse zuzuweisen.

Installieren Sie einen Windows Server-DNS-Server, und konfigurieren Sie die Eigenschaften für das virtuelle Netzwerke mit dem Namen und der IP-Adresse des virtuellen Computers, der die Domänencontroller- und DNS-Serverrollen hostet.

5

Geografisch verteilte DCs

Wie wird auf DCs in getrennten virtuellen Netzwerken repliziert?

Wenn Ihre Active Directory-Standorttopologie Domänencontroller in einer geografischen Region erfordert, die anderen Azure-Regionen entspricht, möchten Sie ggf. entsprechende Active Directory-Standorte erstellen. Konfigurieren Sie VNet-zu-VNet-Verbindungen für die Replikation zwischen Domänencontrollern in separaten VNets.

6

Schreibgeschützte DCs

Werden schreibgeschützte oder beschreibbare DCs verwendet?

HBI/PII-Attribute filtern

Geheime Schlüssel filtern

Ausgehenden Datenverkehr einschränken

7

Globaler Katalog

Soll ein globaler Katalog installiert werden?

Bei einer Gesamtstruktur mit einer Domäne alle DCs als GCs konfigurieren

Bei einer Gesamtstruktur mit mehreren Domänen sind GCs zur Authentifizierung erforderlich

8

Installationsmethode

Wie wird ein DC in Azure installiert?

  • AD DS mithilfe von Windows PowerShell oder Dcpromo installieren

– oder –

  • VHD eines lokalen virtuellen DCs verschieben

9

Platzierung von Windows Server AD DS-Datenbank und SYSVOL

Wo sollen Windows Server AD DS-Datenbank, Protokolle und SYSVOL gespeichert werden?

Standardwerte von "Dcpromo.exe" ändern

ImportantWichtig
Diese wichtigen Active Directory-Dateien MÜSSEN auf Azure-Datenträgern für normale Daten anstatt auf Betriebssystem-Datenträgern gespeichert werden, die einen Schreibcache implementieren.

10

Sicherung und Wiederherstellung

Wie werden Daten geschützt und wiederhergestellt?

Systemstatus sichern

11

Verbundserverkonfiguration

Soll eine neue Gesamtstruktur mit Verbund in der Cloud bereitgestellt werden?

Soll AD FS lokal bereitgestellt und ein Proxy in der Cloud verfügbar gemacht werden?

Sicherheit

Compliance

Kosten

Anwendungszugriff durch Geschäftspartner

12

Cloud-Dienstkonfiguration

Beim erstmaligen Erstellen eines virtuellen Computers wird implizit ein Cloud-Dienst bereitgestellt. Müssen zusätzliche Cloud-Dienste bereitgestellt werden?

Müssen eine oder mehrere VMs direkt im Internet verfügbar gemacht werden?

Erfordert der Dienst Lastenausgleich?

13

Anforderungen von Verbundservern an öffentliche und private IP-Adressierung (DIP oder VIP)

Ist es erforderlich, dass auf die Windows Server AD FS-Instanz direkt aus dem Internet zugegriffen werden kann?

Benötigt die in der Cloud bereitgestellte Anwendung eine eigene IP-Adresse und einen eigenen Port mit Internetzugriff?

Einen Cloud-Dienst für jede für die Bereitstellung erforderliche VIP erstellen

14

Windows Server AD FS-Konfiguration für hohe Verfügbarkeit

Wie viele Knoten enthält die Windows Server AD FS-Serverfarm?

Wie viele Knoten sollen in der Windows Server AD FS-Proxyfarm bereitgestellt werden?

Resilienz und Fehlertoleranz

Um die IP-Adresskonsistenz- und DNS-Anforderungen von Windows Server AD DS zu erfüllen, muss zunächst ein virtuelles Netzwerk in Azure erstellt werden, dem anschließend virtuelle Computer hinzugefügt werden. Während der Erstellung müssen Sie entscheiden, ob die Konnektivität optional auf das lokale Unternehmensnetzwerk ausgeweitet werden soll, wodurch virtuelle Computer in Azure unter Verwendung herkömmlicher VPN-Technologien transparent mit lokalen Computern verbunden werden. Zu diesem Zweck muss am Rand des Unternehmensnetzwerks ein VPN-Endpunkt verfügbar gemacht werden. Dies bedeutet, dass die Initiierung des VPNs von Azure zum Unternehmensnetzwerk und nicht umgekehrt erfolgt.

Beachten Sie, dass bei der Ausweitung eines virtuellen Netzwerks auf das lokale Netzwerk neben den Standardgebühren für die einzelnen VMs zusätzliche Gebühren anfallen. Dies gilt insbesondere für die CPU-Zeit des virtuellen Netzwerkgateways in Azure sowie für ausgehenden Datenverkehr, der von den einzelnen VMs generiert wird, die über das VPN mit lokalen Computern kommunizieren. Weitere Informationen zu Gebühren für Netzwerkdatenverkehr finden Sie in der Azure-Preisübersicht.

Die Konfiguration des DCs richtet sich nach den Anforderungen des Diensts, der in Azure ausgeführt werden soll. Beispielsweise können Sie eine neue, von Ihrer eigenen Unternehmensgesamtstruktur isolierte Gesamtstruktur bereitstellen, um eine Machbarkeitsstudie, eine neue Anwendung oder ein anderes kurzfristiges Projekt zu testen, die bzw. das zwar Verzeichnisdienste, aber keinen spezifischen Zugriff auf die internen Unternehmensressourcen erfordert.

Ein Vorteil besteht darin, dass ein isolierter Gesamtstruktur-DC nicht mit lokalen DCs repliziert wird. So generiert das System selbst weniger ausgehenden Netzwerkdatenverkehr und trägt direkt zur Kostensenkung bei. Weitere Informationen zu Gebühren für Netzwerkdatenverkehr finden Sie in der Azure-Preisübersicht.

Ein weiteres Beispiel ist ein Dienst, für den bestimmte Datenschutzanforderungen gelten, der jedoch vom Zugriff auf das interne Windows Server Active Directory abhängig ist. Wenn es zulässig ist, Daten für den Dienst in der Cloud zu hosten, können Sie eine neue untergeordnete Domäne für die interne Gesamtstruktur in Azure bereitstellen. In diesem Fall können Sie einen DC für die neue untergeordnete Domäne bereitstellen (zur Berücksichtigung von Datenschutzaspekten allerdings ohne den globalen Katalog). In Verbindung mit der Bereitstellung eines Replikat-DCs erfordert dieses Szenario ein virtuelles Netzwerk für die Verbindung mit den lokalen DCs.

Wenn Sie eine neue Gesamtstruktur erstellen, entscheiden Sie sich für die Verwendung von Active Directory-Vertrauensstellungen oder Verbundvertrauensstellungen. Die Anforderungen an Kompatibilität, Sicherheit, Konformität, Kosten und Resilienz müssen gegeneinander abgewogen werden. Um beispielsweise die selektive Authentifizierung zu nutzen, könnten Sie eine neue Gesamtstruktur in Azure bereitstellen und eine Windows Server Active Directory-Vertrauensstellung zwischen der lokalen und der Gesamtstruktur in der Cloud erstellen. Wenn die Anwendung jedoch Ansprüche unterstützt, könnten Sie Verbundvertrauensstellungen anstelle von Active Directory-Gesamtstruktur-Vertrauensstellungen bereitstellen. Ein weiterer Faktor sind die Kosten, die entstehen, weil entweder durch die Erweiterung des lokalen Windows Server Active Directory-Systems in die Cloud mehr Daten repliziert werden oder weil aufgrund der Authentifizierungs- und Abfragelast mehr ausgehender Datenverkehr generiert wird.

Außerdem wird Ihre Wahl durch Anforderungen an Verfügbarkeit und Fehlertoleranz beeinflusst. Bei einem Verbindungsausfall sind alle Anwendungen, die entweder eine Kerberos-Vertrauensstellung oder eine Verbundvertrauensstellung nutzen, u. U. nicht mehr funktionsfähig, es sei denn, in Azure wurde eine entsprechende Infrastruktur für solche Fälle Fall implementiert. Alternative Bereitstellungskonfigurationen wie (beschreibbare oder schreibgeschützte) Replikat-DCs erhöhen die Toleranz gegenüber Verbindungsausfällen.

Standorte und Standortverknüpfungen müssen ordnungsgemäß definiert werden, um den Datenverkehr zu optimieren und die Kosten gering zu halten. Standorte, Standortverknüpfungen und Subnetze wirken sich auf die Replikationstopologie zwischen DCs und den Fluss des Authentifizierungsdatenverkehrs aus. Nachdem Sie sich die folgenden Gebühren für Datenverkehr vergegenwärtigt haben, sollten Sie DCs entsprechend den Anforderungen Ihres Bereitstellungsszenarios bereitstellen und konfigurieren:

  • Für die Gatewaynutzung wird eine Schutzgebühr pro Stunde erhoben:

    • Das Gateway kann nach Bedarf gestartet und beendet werden.

    • Nach der Beendigung werden alle Azure-VMs vom Unternehmensnetzwerk isoliert.

  • Eingehender Datenverkehr ist kostenfrei.

  • Ausgehender Datenverkehr wird gemäß der Azure-Preisübersicht abgerechnet. Die Eigenschaften von Standortverknüpfungen zwischen lokalen und Cloud-Standorten können wie folgt optimiert werden:

    • Bei Verwendung mehrerer virtueller Netzwerke sollten Sie die Standortverknüpfungen und deren Kosten so konfigurieren, dass Windows Server AD DS die Azure-Website nicht vorrangig vor anderen Websites behandelt, die dieselben Servicelevels gebührenfrei anbieten. Sie haben auch die Möglichkeit, die Option "Brücke zwischen allen Standortverknüpfungen herstellen" zu deaktivieren (die standardmäßig aktiviert ist). Dadurch wird sichergestellt, dass nur Replikationen zwischen direkt miteinander verbundenen Standorten stattfinden. Die direkte Replikation zwischen DCs an transitiv verbundenen Standorten ist nicht mehr möglich, sondern muss über einen oder mehrere gemeinsame Standorte erfolgen. Wenn die dazwischen geschalteten Standorte nicht mehr verfügbar sind, erfolgt zwischen DCs an transitiv verbundenen Standorten selbst dann keine Replikation, wenn zwischen den Standorten eine Verbindung besteht. Wenn in einigen Bereichen weiterhin transitiv repliziert werden soll, erstellen Sie Standortverknüpfungsbrücken, die die geeigneten Standortverknüpfungen und Standorte enthalten, z. B. lokale Standorte oder Unternehmensnetzwerke.

    • Konfigurieren Sie Standortverknüpfungskosten so, dass unbeabsichtigter Datenverkehr vermieden wird. Wenn beispielsweise die Einstellung "Am nächstgelegenen Standort suchen" aktiviert ist, sollten Sie sicherstellen, dass die virtuellen Netzwerkstandorte nicht am nächsten liegen, indem Sie die Kosten für das Standortverknüpfungsobjekt erhöhen, durch das die Azure-Website mit dem Unternehmensnetzwerk verbunden wird.

    • Konfigurieren Sie Standortverknüpfungsintervalle und Zeitpläne entsprechend den Konsistenzanforderungen und der Objektänderungsrate. Richten Sie den Replikationszeitplan nach der Latenztoleranz aus. Da DCs nur den letzten Status eines Werts replizieren, lassen sich durch ein verringertes Replikationsintervall Kosten einsparen, sofern die Objektänderungsrate ausreicht.

  • Wenn die Kosteneindämmung im Vordergrund steht, stellen Sie sicher, dass eine Replikationsplanung vorliegt und keine Änderungsbenachrichtigung aktiviert ist. Dies ist die Standardkonfiguration bei der Replikation zwischen Standorten. Wenn Sie einen RODC in einem virtuellen Netzwerk bereitstellen, ist dies nicht von Bedeutung, da der RODC bei der Replikation von Änderungen keinen ausgehenden Datenverkehr erzeugt. Falls Sie jedoch einen beschreibbaren DC bereitstellen, sollten Sie darauf achten, die Standortverknüpfung so zu konfigurieren, dass Updates nicht zu häufig repliziert werden. Wenn Sie einen globalen Katalogserver (GC) bereitstellen, vergewissern Sie sich, dass an jedem anderen Standort, der über einen GC verfügt, Domänenpartitionen von einem Quell-DC an einen Standort repliziert werden, der mit einer oder mehreren Standortverknüpfungen verbunden ist, die kostengünstiger sind als der GC in der Azure-Website.

  • Der durch die Replikation zwischen Standorten generierte Netzwerkdatenverkehr lässt sich weiter einschränken, indem Sie den Komprimierungsalgorithmus der Replikation ändern. Der Komprimierungsalgorithmus wird durch den REG_DWORD-Registrierungseintrag des Komprimierungsalgorithmus unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\Replicator gesteuert. Der Standardwert 3 entspricht dem Xpress-Komprimierungsalgorithmus. Sie können den Wert auf 2 festlegen, wodurch der Algorithmus in MSZip geändert wird. In den meisten Fällen erhöht sich die Komprimierung, allerdings auf Kosten der CPU-Auslastung. Weitere Informationen finden Sie unter Funktionsweise der Active Directory-Replikationstopologie.

Virtuelle Computer in Azure erhalten standardmäßig Adressen mit DHCP-Lease. Da dynamische Adressen virtueller Netzwerke in Azure während der Lebensdauer eines virtuellen Computers beibehalten werden, sind die Voraussetzungen für Windows Server AD DS erfüllt.

Wenn Sie daher eine dynamische Adresse in Azure verwenden, handelt es sich tatsächlich um eine statische IP-Adresse, da sie während der Dauer der Lease routingfähig ist und der Leasezeitraum der Lebensdauer des Cloud-Diensts entspricht.

Wenn der virtuelle Computer heruntergefahren wird, wird die Zuordnung der dynamischen Adresse jedoch aufgehoben. Um die Aufhebung der Zuordnung der IP-Adresse zu verhindern, können Sie mithilfe von "Set-AzureStaticVNetIP" eine statische IP-Adresse zuweisen.

Für die Namensauflösung sollten Sie Ihre eigene DNS-Serverinfrastruktur bereitstellen (bzw. erweitern). Die erweiterten Anforderungen der Windows Server AD DS-Namensauflösung werden von dem in Azure bereitgestellten DNS nicht erfüllt. Beispielsweise werden u. a. keine dynamischen SRV-Einträge unterstützt. Die Namensauflösung ist ein wichtiges Konfigurationselement für DCs und in die Domäne eingebundene Clients. DCs müssen in der Lage sein, Ressourceneinträge zu registrieren und die Ressourceneinträge anderer DCs aufzulösen.

Aus Gründen der Leistung und Fehlertoleranz ist es am besten, den Windows Server-DNS-Dienst auf den DCs zu installieren, die in Azure ausgeführt werden. Konfigurieren Sie dann die Eigenschaften des virtuellen Netzwerks in Azure mit dem Namen und der IP-Adresse des DNS-Servers. Wenn andere virtuelle Computer im virtuellen Netzwerk gestartet werden, werden deren Einstellungen für die DNS-Clientauflösung mit dem DNS-Server als Bestandteil der dynamischen IP-Adresszuordnung konfiguriert.

noteHinweis
Es ist nicht möglich, lokale Computer einer Active Directory-Domäne von Windows Server AD DS, die in Azure gehostet wird, direkt über das Internet hinzuzufügen. Aufgrund der Portanforderungen für Active Directory und des Domänenbeitrittsvorgangs ist es unpraktisch, die erforderlichen Ports und faktisch auch einen vollständigen DC direkt im Internet verfügbar zu machen.

VMs registrieren ihren DNS-Namen automatisch beim Start oder bei einer Namensänderung.

Weitere Informationen zu diesem Beispiel sowie ein weiteres Beispiel, das veranschaulicht, wie Sie den erste virtuellen Computer bereitstellen und AD DS darauf installieren, finden Sie unter Installieren einer neuen Active Directory-Gesamtstruktur in Windows Azure. Weitere Informationen zur Verwendung von Windows PowerShell finden Sie unter Erste Schritte mit Azure PowerShell und Azure-Verwaltungs-Cmdlets.

Windows Azure bietet Vorteile, wenn mehrere DCs in unterschiedlichen virtuellen Netzwerken gehostet werden:

  • Fehlertoleranz für mehrere Standorte

  • Physische Nähe zu Zweigniederlassungen (geringere Latenz)

Weitere Informationen zum Konfigurieren der direkten Kommunikation zwischen virtuellen Netzwerken finden Sie unter Konfigurieren von VNet-zu-VNet-Verbindungen.

Sie müssen entscheiden, ob schreibgeschützte oder beschreibbare DCs bereitgestellt werden sollen. Möglicherweise tendieren Sie zur Bereitstellung von RODCs, da sie nicht physisch gesteuert werden, aber für die Bereitstellung an Standorten konzipiert sind, an denen ihre physische Sicherheit gefährdet ist, z. B. in Zweigniederlassungen.

Obwohl Windows Azure nicht den physischen Sicherheitsrisiken von Zweigniederlassungen ausgesetzt ist, sind RODCs möglicherweise trotzdem kosteneffizienter, da die RODC-Funktionen aus sehr unterschiedlichen Gründen für diese Umgebungen geeignet sind. Beispielsweise tritt bei RODCs keine ausgehende Replikation auf, und sie sind in der Lage, geheime Schlüssel (Kennwörter) selektiv aufzufüllen. Andererseits verursacht das Fehlen dieser geheimen Schlüssel u. U. ausgehendem Datenverkehr, da sie bei der Authentifizierung eines Benutzers oder Computers überprüft werden müssen. Geheime Schlüssel können jedoch selektiv vorab aufgefüllt und zwischengespeichert werden.

RODCs bieten einen zusätzlichen Vorteil im Hinblick auf HBI-Informationen (High Business Impact, hohe Geschäftsrelevanz) und personenbezogene Daten, weil Sie dem Attributsatz mit RODC-Filter (Filtered Attribute Set, FAS) Attribute mit sensiblen Daten hinzufügen können. FAS ist ein anpassbarer Satz von Attributen, die nicht auf RODCs repliziert werden. FAS kann als Schutzmechanismus verwendet werden, falls Sie nicht berechtigt oder gewillt sind, personenbezogene Daten oder HBI-Informationen in Windows Azure zu speichern. Weitere Informationen finden Sie unter Attributsatz mit RODC-Filter.

Stellen Sie sicher, dass Anwendungen mit den zu verwendenden RODCs kompatibel sind. Viele Anwendungen, die Windows Server Active Directory unterstützen, funktionieren problemlos mit RODCs, während andere nur eingeschränkt leistungsfähig sind oder fehlschlagen, wenn sie keinen Zugriff auf einen beschreibbaren DC haben. Weitere Informationen finden Sie unter Anwendungskompatibilität mit Domänencontrollern ohne Schreibzugriff.

Ob Sie einen globalen Katalog installieren, liegt in Ihrem Ermessen. In einer Gesamtstruktur mit nur einer Domäne sollten Sie alle DCs als globale Katalogserver (GCs) konfigurieren. Da kein zusätzlicher Datenverkehr durch Replikationen verursacht wird, bleiben die Kosten unverändert.

In einer Gesamtstruktur mit mehreren Domänen werden GCs zur Erweiterung universeller Gruppenmitgliedschaften während des Authentifizierungsprozesses benötigt. Wenn Sie keinen GC bereitstellen, generieren Arbeitsauslastungen im virtuellen Netzwerk, die gegenüber einem DC in Windows Azure authentifiziert werden, indirekt ausgehenden Authentifizierungsdatenverkehr, um während jedes Authentifizierungsversuchs lokale GCs abzufragen.

Die Kosten für GCs sind schwieriger einzuschätzen, da sie (teilweise) die einzelnen Domänen hosten. Wenn die Arbeitsauslastung für das Hosting eines Internetdiensts und die Authentifizierung von Benutzern gegenüber Windows Server AD DS zuständig ist, sind die Kosten u. U. gar nicht vorhersehbar. Um GC-Abfragen außerhalb des Cloud-Standorts während der Authentifizierung zu reduzieren, können Sie das Zwischenspeichern der universellen Gruppenmitgliedschaft aktivieren.

Sie müssen entscheiden, wie die DCs im virtuellen Netzwerk installiert werden:

Sie sollten (im Gegensatz zu "Web"- oder "Workerrollen"-VMs in Azure) nur virtuelle Computer in Azure für DCs verwenden. da sie dauerhaft sind und die Dauerhaftigkeit des Status für einen DC eine Voraussetzung darstellt. Virtuelle Computer in Azure sind für Arbeitsauslastungen wie DCs ausgelegt.

Verwenden Sie nicht SYSPREP zum Bereitstellen oder Klonen von DCs. Das Klonen von Domänencontrollern wird erst ab Windows Server 2012 unterstützt. Die Klonfunktion erfordert VMGenerationID-Unterstützung im zugrunde liegenden Hypervisor. VMGenerationID wird von Hyper-V in Windows Server 2012, virtuellen Netzwerken in Windows Azure sowie von anderen Anbietern von Virtualisierungssoftware unterstützt.

Legen Sie fest, wo Windows Server AD DS-Datenbank, Protokolle und SYSVOL angelegt werden sollen. Sie müssen auf Azure-Datenträgern für normale Daten bereitgestellt werden. “

noteHinweis
Azure-Datenträger für normale Daten sind auf 1 TB beschränkt.

Schreibvorgänge von Datenlaufwerken werden standardmäßig nicht zwischengespeichert. An einen virtuellen Computer angefügte Datenlaufwerke verwenden Write-Through-Caching. Beim Write-Through-Caching wird sichergestellt, dass für den Schreibvorgang ein Commit im permanenten Azure-Speicher ausgeführt wird, bevor die Transaktion aus Sicht des VM-Betriebssystems abgeschlossen ist. So wird Dauerhaftigkeit gewährleistet, während sich Schreibvorgänge nur geringfügig verlangsamen.

Dies ist für Windows Server AD DS von Bedeutung, da vom DC getroffene Annahmen durch das Write-Behind-Datenträgercaching ungültig werden. Windows Server AD DS versucht, den Schreibcache zu deaktivieren, dies liegt jedoch im Ermessen des Datenträger-E/A-Systems. Falls der Schreibcache nicht deaktiviert wird, kann unter bestimmten Umständen ein USN-Rollback auftreten, was zu fortbestehenden Objekten und anderen Problemen führt.

Gehen Sie als bewährte Methode für virtuelle DCs wie folgt vor:

  • Stellen Sie die Host-Cache-Einstellung des Azure-Datenlaufwerks auf NONE. Dies verhindert Probleme beim Schreibcaching für AD DS-Vorgänge.

  • Speichern Sie Datenbank, Protokolle und SYSVOL auf demselben oder auf getrennten Datenträgern. In der Regel handelt es sich dabei um einen Datenträger, der von dem für das Betriebssystem selbst verwendeten Datenträger getrennt verwaltet wird. Die wichtigste Voraussetzung besteht darin, dass die Windows Server AD DS-Datenbank und SYSVOL nicht auf einem Betriebssystem-Datenträgertyp in Azure gespeichert werden. Diese Komponenten werden bei der AD DS-Installation standardmäßig im Ordner %systemroot% gespeichert, der für Azure NICHT geeignet ist.

Beachten Sie, welche Sicherungs- und Wiederherstellungsszenarien für DCs im Allgemeinen sowie spezifischer für DCs auf virtuellen Computern unterstützt werden. Siehe Überlegungen zum Sichern und Wiederherstellen virtualisierter Domänencontroller.

Zum Sichern des Systemstatus sollte ausschließlich Sicherungssoftware verwendet werden, die speziell für die Sicherungsanforderungen von Windows Server AD DS geeignet ist, z. B. die Windows Server-Sicherung.

Das Kopieren oder Klonen der VHD-Dateien von DCs stellt keine Alternative zu regelmäßigen Sicherungen dar. Im Fall einer Wiederherstellung führt die Verwendung geklonter oder kopierter VHDs ohne Windows Server 2012 und einen unterstützten Hypervisor zu USN-Blasen.

Die Konfiguration von Windows Server AD FS-Verbundservern (Sicherheitstokendiensten) richtet sich teilweise danach, ob die in Azure bereitgestellten Anwendungen auf Ressourcen im lokalen Netzwerk zugreifen müssen.

Unter der Voraussetzung, dass sie folgende Kriterien erfüllen, können die Anwendungen vom lokalen Netzwerk isoliert bereitgestellt werden.

  • Sie akzeptieren SAML-Sicherheitstoken

  • Sie können im Internet verfügbar gemacht werden

  • Sie greifen nicht auf lokale Ressourcen zu

In diesem Fall konfigurieren Sie Windows Server AD FS-Sicherheitstokendienste wie folgt:

  1. Konfigurieren Sie eine isolierte, aus einer Domäne bestehende Gesamtstruktur in Azure.

  2. Ermöglichen Sie den Verbundzugriff auf die Gesamtstruktur, indem Sie eine Windows Server AD FS-Verbundserverfarm konfigurieren.

  3. Konfigurieren Sie Windows Server AD FS (Verbundserverfarm und Verbundserver-Proxyfarm) in der lokalen Gesamtstruktur.

  4. Stellen Sie eine Verbundvertrauensstellung zwischen den lokalen und Azure-Instanzen von Windows Server AD FS her.

Wenn die Anwendungen andererseits Zugriff auf lokale Ressourcen benötigen, können Sie Windows Server AD FS mit der Anwendung in Azure wie folgt konfigurieren:

  1. Konfigurieren Sie Verbindungen zwischen lokalen Netzwerken und Azure.

  2. Konfigurieren Sie eine Windows Server AD FS-Verbundserverfarm in der lokalen Gesamtstruktur.

  3. Konfigurieren Sie eine Windows Server AD FS-Verbundserver-Proxyfarm in Azure.

Diese Konfiguration hat den Vorteil, dass nicht so viele lokale Ressourcen verfügbar gemacht werden, und ist mit der Konfiguration von Windows Server AD FS mit Anwendungen in einem Umkreisnetzwerk vergleichbar.

Beachten Sie, dass in beiden Szenarien Vertrauensstellungen mit mehreren Identitätsanbietern hergestellt werden können, wenn eine Zusammenarbeit zwischen Geschäftspartnern erforderlich ist.

Cloud-Dienste sind erforderlich, wenn Sie eine VM direkt im Internet oder eine Anwendung mit Internetzugriff und Lastenausgleich verfügbar machen möchten. Dies ist möglich, weil jeder Cloud-Dienst eine einzelne konfigurierbare VIP bietet.

Jeder virtuelle Computer in Azure erhält eine DIP. Eine DIP ist eine private Adresse, auf die nur in Azure zugegriffen werden kann. In den meisten Fällen ist es jedoch erforderlich, eine VIP für Windows Server AD FS-Bereitstellungen zu konfigurieren. Die VIP ist notwendig, um Windows Server AD FS-Endpunkte, die von Verbundpartnern und Clients für die Authentifizierung und laufende Verwaltung verwendet werden, im Internet verfügbar zu machen. Eine VIP ist eine Eigenschaft eines Cloud-Diensts, der einen oder mehrere virtuelle Computer in Azure enthält. Wenn die Ansprüche unterstützende Anwendung, die in Azure bereitgestellt wird, und Windows Server AD FS beide über Internetzugriff verfügen und allgemeine Ports gemeinsam verwenden, benötigen beide eine eigene VIP. Daher ist es erforderlich, einen Cloud-Dienst für die Anwendung und einen zweiten für Windows Server AD FS zu erstellen.

Definitionen der Begriffe VIP und DIP finden Sie unter Begriffe und Definitionen.

Obwohl es möglich ist, eigenständige Windows Server AD FS-Verbunddienste bereitzustellen, wird bei Produktionsumgebungen empfohlen, eine Farm mit mindestens zwei Knoten sowohl für AD FS-Sicherheitstokendienste als auch -Proxys bereitzustellen.

Informationen dazu, wie Sie die optimale Bereitstellungskonfiguration für Ihre spezifischen Anforderungen ermitteln, finden Sie unter Überlegungen zur AD FS 2.0-Bereitstellungstopologie im Entwurfshandbuch zu AD FS 2.0.

noteHinweis
Um Lastenausgleich für Windows Server AD FS-Endpunkte in Azure zu aktivieren, konfigurieren Sie alle Mitglieder der Windows Server AD FS-Farm im selben Cloud-Dienst und verwenden die Lastenausgleichsfunktion von Azure für den HTTP-Port (standardmäßig 80) und den HTTPS-Port (standardmäßig 443). Weitere Informationen finden Sie unter Azure-Lastenausgleichsüberprüfung.

Der Windows Server-Netzwerklastenausgleich (Network Load Balancing, NLB) wird in Azure nicht unterstützt.

Anzeigen:
© 2015 Microsoft