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 6: AWS Microsoft AD, VPC für gemeinsam genutzte Services und eine unidirektionale Vertrauensstellung zu On-Premises
Dieses Szenario verwendet, wie in der folgenden Abbildung gezeigt, ein vorhandenes On-Premises-Active-Directory für Benutzer und führt ein separates Managed Active Directory in AWS Cloud ein, um die mit dem verknüpften Computerobjekte zu hosten WorkSpaces. In diesem Szenario können die Computerobjekte und Active-Directory-Gruppenrichtlinien unabhängig vom Unternehmens-Active-Directory verwaltet werden.
Dieses Szenario ist nützlich, wenn ein Drittanbieter Windows im Namen WorkSpaces eines Kunden verwalten möchte, da er es dem Dritten ermöglicht, die mit ihm verknüpften - WorkSpaces und -Richtlinien zu definieren und zu kontrollieren, ohne dem Drittanbieter Zugriff auf das Kunden-AD gewähren zu müssen. In diesem Szenario wird eine bestimmte Active-Directory-Organisationseinheit (OU) erstellt, um die WorkSpaces Computerobjekte im Shared Services AD zu organisieren.
Anmerkung
Amazon Linux WorkSpaces benötigt eine bidirektionale Vertrauensstellung, damit sie erstellt werden können.
Um Windows WorkSpaces mit den Computerobjekten bereitzustellen, die in der Shared Services VPC erstellt wurden, die Managed Active Directory mithilfe von Benutzern aus der Kundenidentitätsdomäne hostet, stellen Sie einen Active Directory Connector (ADC) bereit, der auf das Unternehmens-AD verweist. Verwenden Sie ein im Unternehmens-AD (Identitätsdomäne) erstelltes microSD-Servicekonto, das über delegierte Berechtigungen zum Erstellen von Computerobjekten in der Organisationseinheit (OU) verfügt, die für Windows WorkSpaces im Shared Services Managed AD konfiguriert wurde und über Leseberechtigungen für das Unternehmens-Active Directory (Identitätsdomäne) verfügt.
Um sicherzustellen, dass die Domain Locator-Funktion WorkSpaces Benutzer auf der gewünschten AD-Site für die Identitäts-Domain authentifizieren kann, benennen Sie die AD-Sites beider Domains für die Amazon WorkSpaces Subnets identisch gemäß der Microsoft-Dokumentation
Ausführliche Anweisungen zur Konfiguration dieses Szenarios finden Sie im Implementierungshandbuch zum Einrichten einer unidirektionalen Vertrauensstellung für Amazon WorkSpaces mit AWS Directory Services
In diesem Szenario richten wir eine einseitige transitive Vertrauensstellung zwischen dem AWS Managed Microsoft AD in der Shared Services VPC und dem On-Premises-AD ein. Abbildung 11 zeigt die Vertrauens- und Zugriffsrichtung und wie AWS AD Connector das AD-Connector-Servicekonto verwendet, um Computerobjekte in der Ressourcendomäne zu erstellen.
Eine Gesamtstruktur-Vertrauensstellung wird gemäß Microsoft-Empfehlung verwendet, um sicherzustellen, dass die Kerberos-Authentifizierung wann immer möglich verwendet wird. Ihre WorkSpaces erhalten Gruppenrichtlinienobjekte (GPOs) von Ihrer Ressourcen-Domain in der AWS Managed Microsoft AD. Darüber hinaus WorkSpaces führen Sie die Kerberos-Authentifizierung mit Ihrer Identitätsdomäne durch. Damit dies zuverlässig funktioniert, empfiehlt es sich, Ihre Identitätsdomäne auf zu erweitern, AWS wie oben bereits erläutert. Wir empfehlen, den Leitfaden Bereitstellen von Amazon WorkSpaces mithilfe einer One-Way-Trust-Ressourcendomäne mit AWS Directory Service
Sowohl der AD Connector als auch Ihr WorkSpacesmüssen mit den Domain-Controllern Ihrer Identitätsdomäne und Ihrer Ressourcendomäne kommunizieren können. Weitere Informationen finden Sie unter IP-Adresse und Port-Anforderungen für WorkSpaces im Amazon- WorkSpaces Administratorhandbuch.
Wenn Sie mehrere AD Connectors verwenden, hat es sich bewährt, dass jeder der AD Connectors sein eigenes AD Connector Service-Konto verwendet.
Abbildung 11: AWS Microsoft, VPC für gemeinsam genutzte Services und eine unidirektionale Vertrauensstellung zu AD On-Premises
Diese Architektur verwendet die folgenden Komponenten oder Konstrukte:
AWS
-
Amazon VPC – Erstellen einer Amazon VPC mit mindestens zwei privaten Subnetzen in zwei AZs – zwei für AD Connector und 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), AD Connector bereitgestellt.
-
Transit Gateway/VPC Peering – Aktivieren Sie die Konnektivität zwischen Workspaces VPC und der Shared Services VPC.
-
Amazon EC2 – Vom Kunden „optionale“ RADIUS-Server für MFA.
-
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 dieser Liste der Clientanwendungen für unterstützte Geräte und Webbrowser.
