Szenario 4: AWS Microsoft AD und eine bidirektionale transitive Vertrauensstellung zu On-Premises - Bewährte Methoden für die Bereitstellung von WorkSpaces

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Szenario 4: AWS Microsoft AD und eine bidirektionale transitive Vertrauensstellung zu On-Premises

In diesem Szenario, das in der folgenden Abbildung dargestellt ist, wird AWS Managed AD in der AWS Cloud bereitgestellt, die eine bidirektionale transitive Vertrauensstellung zum On-Premises-AD des Kunden hat. Benutzer und WorkSpaces werden in Managed AD erstellt, wobei die AD-Vertrauensstellung den Zugriff auf Ressourcen in der On-Premises-Umgebung ermöglicht.

Beispielarchitektur mit AWS Managed AD, das in der AWS Cloud bereitgestellt wird, die eine bidirektionale transitive Vertrauensstellung zum On-Premises-AD des Kunden hat.

Abbildung 9: AWS Microsoft AD und eine bidirektionale transitive Vertrauensstellung zu On-Premises

Wie in Szenario 3 wird AD DS (Microsoft AD) in dedizierten Subnetzen bereitgestellt, die sich über zwei AZs erstrecken, wodurch AD DS in der AWS Cloud hochverfügbar wird.

Dieses Szenario eignet sich gut für Kunden, die über einen vollständig verwalteten AWS Directory Service verfügen möchten, einschließlich Bereitstellung, Patching, Hochverfügbarkeit und Überwachung ihrer AWS Cloud. In diesem Szenario können WorkSpaces Benutzer auch auf AD-verbundene Ressourcen in ihren vorhandenen Netzwerken zugreifen. In diesem Szenario muss eine Domain-Vertrauensstellung vorhanden sein. Sicherheitsgruppen und Firewall-Regeln müssen die Kommunikation zwischen den beiden aktiven Verzeichnissen ermöglichen.

Zusätzlich zur Platzierung von AWS Directory Service gibt die vorherige Abbildung Aufschluss über den Datenverkehr von einem Benutzer zu einem Workspace und die Interaktion des Workspace mit dem AD-Server und dem MFA-Server.

Diese Architektur verwendet die folgenden Komponenten oder Konstrukte.

AWS

  • Amazon VPC – Erstellen einer Amazon VPC mit mindestens vier privaten Subnetzen in zwei AZs – zwei für AD DS Microsoft AD, zwei für AD Connector oder WorkSpaces.

  • DHCP-Optionssatz – Erstellen eines Amazon VPC DHCP-Optionssatzes. Auf diese Weise kann ein Kunde einen bestimmten Domänennamen und DNS (Microsoft AD) definieren. Weitere Informationen finden Sie unter DHCP-Optionssätze.

  • Optional: Amazon Virtual Private Gateway – Aktivieren Sie die Kommunikation mit einem kundeneigenen Netzwerk über einen IPsec-VPN-Tunnel (VPN) oder eine - AWS Direct Connect Verbindung. Verwenden Sie für den Zugriff auf On-Premises-Backend-Systeme.

  • AWS Directory Service – Microsoft AD wird in einem dedizierten Paar von VPC-Subnetzen (AD DS Managed Service) bereitgestellt.

  • Amazon EC2Optionale RADIUS-Server für MFA vom Kunden.

  • Amazon WorkSpaces – WorkSpaces werden in denselben privaten Subnetzen wie der AD Connector bereitgestellt. Weitere Informationen finden Sie im Abschnitt Active Directory: Sites and Services dieses Dokuments.

Customer

  • Netzwerkkonnektivität – Unternehmens-VPN oder - AWS Direct Connect Endpunkte.

  • Endbenutzergeräte – Unternehmens- oder BYOL-Endbenutzergeräte (wie Windows, Macs, iPads, Android-Tablets, Null-Clients und Chromebooks), die für den Zugriff auf den Amazon- WorkSpaces Service verwendet werden. Weitere Informationen finden Sie in der Liste der Clientanwendungen für unterstützte Geräte und Webbrowser.

Diese Lösung erfordert Konnektivität zum On-Premises-Rechenzentrum des Kunden, damit der Vertrauensprozess ausgeführt werden kann. Wenn WorkSpaces Benutzer Ressourcen im On-Premises-Netzwerk verwenden, müssen die Kosten für Latenz und ausgehende Datenübertragung berücksichtigt werden.