Scenario 6: AWS Microsoft AD, servizi condivisi, VPC e un trust unidirezionale per l'ambiente locale - Procedure ottimali per l'implementazione WorkSpaces

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Scenario 6: AWS Microsoft AD, servizi condivisi, VPC e un trust unidirezionale per l'ambiente locale

Questo scenario, come illustrato nella figura seguente, utilizza un Active Directory locale esistente per gli utenti e introduce un Active Directory gestito separato nel AWS cloud per ospitare gli oggetti informatici associati a. WorkSpaces Questo scenario consente di gestire gli oggetti del computer e le politiche di gruppo di Active Directory in modo indipendente dall'Active Directory aziendale.

Questo scenario è utile quando una terza parte desidera gestire Windows WorkSpaces per conto di un cliente in quanto consente alla terza parte di definire e controllare le politiche WorkSpaces e le politiche ad esse associate, senza la necessità di concedere alla terza parte l'accesso all'AD del cliente. In questo scenario, viene creata un'unità organizzativa (OU) di Active Directory specifica per organizzare gli oggetti del WorkSpaces computer in Shared Services AD.

Nota

Amazon Linux WorkSpaces richiede l'esistenza di un trust bidirezionale per poter essere creato.

Per distribuire Windows WorkSpaces con gli oggetti computer creati nel VPC di Shared Services che ospita Managed Active Directory utilizzando utenti del dominio di identità del cliente, distribuisci un Active Directory Connector (ADC) che faccia riferimento all'AD aziendale. Utilizza un account di servizio ADC creato nell'AD aziendale (dominio di identità) che dispone di autorizzazioni delegate per la creazione di oggetti informatici nell'unità organizzativa (OU) configurata per Windows WorkSpaces nell'AD gestita da Shared Services e che dispone di autorizzazioni di lettura per l'Active Directory aziendale (dominio di identità).

Per garantire che la funzione Domain Locator sia in grado di autenticare WorkSpaces gli utenti nel sito AD desiderato per il dominio di identità, assegna un nome a entrambi i siti AD per le WorkSpaces sottoreti Amazon in modo identico come indicato nella documentazione Microsoft. È consigliabile avere controller di dominio AD del dominio di identità e del dominio Shared Services nella stessa AWS regione di Amazon WorkSpaces.

Per istruzioni dettagliate sulla configurazione di questo scenario, consulta la guida all'implementazione per configurare un trust unidirezionale per Amazon WorkSpaces con AWS Directory Services

In questo scenario viene stabilito un trust transitivo unidirezionale tra il VPC AWS Managed Microsoft AD di Shared Services e l'AD locale. La Figura 11 mostra la direzione dell'attendibilità e dell'accesso e il modo in cui AWS AD Connector utilizza l'account del servizio AD Connector per creare oggetti informatici nel dominio delle risorse.

Un forest trust viene utilizzato in base alle raccomandazioni di Microsoft per garantire che l'autenticazione Kerberos venga utilizzata ogni volta che è possibile. WorkSpaces Riceverai Group Policy Objects (GPO) dal tuo dominio di risorse in. AWS Managed Microsoft AD Inoltre, WorkSpaces esegui l'autenticazione Kerberos con il tuo dominio di identità. Affinché ciò funzioni in modo affidabile, è consigliabile estendere il dominio di identità AWS come già spiegato in precedenza. Ti consigliamo di consultare la guida Deploy Amazon WorkSpaces using a One-Way Trust Resource Domain con AWS Directory Service implementazione per ulteriori dettagli.

Sia l'AD Connector che il tuo WorkSpaces devono essere in grado di comunicare con i controller di dominio del tuo dominio di identità e del tuo dominio di risorse. Per ulteriori informazioni, consulta i requisiti relativi all'indirizzo IP e alla porta WorkSpaces nella Amazon WorkSpaces Administration Guide.

Se utilizzi più AD Connectors, è consigliabile che ciascuno di AD Connectors utilizzi il proprio account di servizio AD Connector.

Un'architettura di esempio che mostra un Windows WorkSpaces con gli oggetti computer creati nel VPC di Shared Services che ospita Managed Active Directory utilizzando utenti del dominio di identità del cliente.

Figura 11: AWS Microsoft, servizi condivisi, VPC e trust unidirezionale per AD in locale

Questa architettura utilizza i seguenti componenti o costrutti:

AWS

  • Amazon VPC: creazione di un Amazon VPC con almeno due sottoreti private su due AZ, due per AD Connector e. WorkSpaces

  • Set di opzioni DHCP: creazione di un set di opzioni DHCP Amazon VPC. Ciò consente a un cliente di definire un nome di dominio e un DNS (Microsoft AD) specificati. Per ulteriori informazioni, fare riferimento ai set di opzioni DHCP.

  • Opzionale: Amazon virtual private gateway: abilita la comunicazione con una rete di proprietà del cliente tramite un tunnel VPN (VPN) o una connessione IPSec. AWS Direct Connect Utilizzalo per accedere ai sistemi di back-end locali.

  • AWS Directory Service: Microsoft AD distribuito in una coppia dedicata di sottoreti VPC (AD DS Managed Service), AD Connector.

  • Transit Gateway/VPC Peering: abilita la connettività tra Workspaces VPC e Shared Services VPC.

  • Amazon EC2: server RADIUS «opzionali» per MFA del cliente.

  • Amazon WorkSpaces: WorkSpaces vengono distribuiti nelle stesse sottoreti private di AD Connector. Per ulteriori informazioni, consulta la sezione Active Directory: Siti e servizi di questo documento.

Customer

  • Connettività di rete: VPN o AWS Direct Connect endpoint aziendali.

  • Dispositivi per utenti finali: dispositivi per utenti finali aziendali o BYOL (come Windows, Mac, iPad, tablet Android, zero client e Chromebook) utilizzati per accedere al servizio Amazon. WorkSpaces Consulta questo elenco di applicazioni client per dispositivi e browser Web supportati.