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à.
# Scenari di distribuzione di AD DS
Il supporto di Amazon WorkSpaces è il AWS Directory Service e la progettazione e la distribuzione corrette del servizio di directory sono fondamentali. I sei scenari seguenti si basano su [Active Directory Domain Services](https://docs.aws.amazon.com/quickstart/latest/active-directory-ds/architecture.html) *nella guida AWS rapida* e descrivono le migliori opzioni di distribuzione per AD DS quando vengono utilizzate con Amazon WorkSpaces. La sezione [Considerazioni sulla progettazione](using-multi-region-aws-managed-active-directory-with-amazon-workspaces.md) di questo documento descrive i requisiti specifici e le migliori pratiche per l'utilizzo di AD Connector for WorkSpaces, che è parte integrante del concetto di WorkSpaces progettazione generale.
+ **Scenario 1: utilizzo di AD Connector per l'autenticazione tramite proxy a Servizi di dominio Active Directory locali: in questo scenario, la connettività di rete (VPN/Direct Connect) è disponibile per il cliente, con tutte le autenticazioni inviate AWS tramite proxy tramite Directory Service (AD Connector) all'AD DS** locale del cliente.
+ **Scenario 2: estensione di AD DS locale in AWS (Replica)**: questo scenario è simile allo scenario 1, ma in questo caso viene implementata una replica dell'AD DS del cliente in combinazione AWS con AD Connector, riducendo la latenza delle richieste di autenticazione/query ad AD DS e al catalogo globale di AD DS.
+ **Scenario 3: distribuzione isolata autonoma tramite AWS Directory Service in the AWS Cloud**: si tratta di uno scenario isolato e non include la connettività al cliente per l'autenticazione. Questo approccio utilizza AWS Directory Service (Microsoft AD) e AD Connector. Sebbene questo scenario non si basi sulla connettività con il cliente per l'autenticazione, prevede il traffico delle applicazioni laddove richiesto tramite VPN o Direct Connect.
+ **Scenario 4: AWS Microsoft AD e trust transitivo bidirezionale verso ambienti locali**: questo scenario include il servizio AWS Microsoft AD gestito (MAD) con un trust transitivo bidirezionale verso la foresta Microsoft AD locale.
+ **Scenario 5: AWS Microsoft AD con un VPC di Shared Services**: questo scenario utilizza Managed AWS Microsoft AD in un VPC Shared Services da utilizzare come dominio di identità per più servizi ( AWS Amazon EC2 WorkSpaces, Amazon e così via) mentre utilizza AD Connector per inoltrare le richieste di autenticazione utente LDAP (Lightweight Directory Access Protocol) ai controller di dominio AD.
+ **Scenario 6: AWS Microsoft AD, Shared Services VPC e One-Way Trust to On-Premises AD — Questo scenario è simile allo Scenario 5, ma include domini di identità e risorse diversi che utilizzano un trust unidirezionale rispetto a quello locale**.
È necessario fare diverse considerazioni quando si seleziona lo scenario di distribuzione per Active Directory Domain Services (ADDS). Questa sezione spiega il ruolo di AD Connector con Amazon WorkSpaces e copre alcune considerazioni importanti nella scelta di uno scenario di distribuzione ADDS. Per ulteriori indicazioni sulla progettazione e la pianificazione di ADDS on AWS, consulta la [Guida alla AWS progettazione e alla pianificazione dei servizi di dominio Active Directory](https://d1.awsstatic.com/whitepapers/adds-on-aws.pdf).
# Il ruolo dell' AWS AD Connector con Amazon WorkSpaces
[AWS AD Connector](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_ad_connector.html) è un AWS Directory Service che funge da servizio proxy per un Active Directory. Non memorizza né memorizza nella cache le credenziali utente, ma inoltra le richieste di autenticazione o ricerca all'Active Directory, in locale o in rete. AWS A meno che tu non lo stia utilizzando AWS Managed Microsoft AD, è anche l'unico modo per registrare Active Directory (locale o esteso a AWS) per utilizzarlo con Amazon WorkSpaces (WorkSpaces).
Un AD Connector può puntare al tuo Active Directory locale, a un Active Directory esteso a AWS (AD Domain Controllers su Amazon EC2) o a un. AWS Managed Microsoft AD
AD Connector svolge un ruolo importante nella maggior parte degli scenari di distribuzione descritti nelle sezioni seguenti. L'utilizzo di AD Connector con WorkSpaces offre una serie di vantaggi:
+ Quando viene indirizzato all'Active Directory aziendale, consente agli utenti di utilizzare le credenziali aziendali esistenti per WorkSpaces accedere ad altri servizi, come [Amazon WorkDocs](https://aws.amazon.com/workdocs/).
+ Puoi applicare in modo coerente le politiche di sicurezza esistenti (scadenza della password, blocco degli account, ecc.) indipendentemente dal fatto che gli utenti accedano alle risorse dell'infrastruttura locale o in, ad esempio. Cloud AWS WorkSpaces
+ AD Connector consente una semplice integrazione con l'infrastruttura MFA esistente basata su RADIUS per fornire un ulteriore livello di sicurezza.
+ Consente la segregazione degli utenti. Ad esempio, consente la configurazione di una serie di WorkSpaces opzioni per unità aziendale o persona, poiché più connettori AD possono puntare agli stessi controller di dominio (server DNS) di Active Directory per l'autenticazione degli utenti:
+ Dominio o unità organizzativa di destinazione per l'applicazione mirata di Active Directory Group Policy Objects (GPO)
+ Diversi gruppi di sicurezza per controllare il flusso di traffico da/verso WorkSpaces
+ Diverse opzioni di controllo degli accessi (dispositivi client consentiti) e gruppi di controllo degli accessi IP (accesso limitato agli intervalli IP)
+ Abilitazione selettiva delle autorizzazioni di amministratore locale
+ Autorizzazioni self-service diverse
+ Applicazione selettiva della Multi-Factor Authentication (MFA)
+ Posizionamento delle interfacce di rete WorkSpaces elastiche (ENI) in diversi VPC o sottoreti per l'isolamento
I connettori AD multipli consentono inoltre di supportare un numero maggiore di utenti, se si raggiunge il limite di prestazioni di un singolo connettore AD piccolo o grande. Consulta la [Dimensionamento di AWS Managed Microsoft AD](#sizing-aws-managed-microsoft-ad) sezione per maggiori dettagli.
L'uso di AD Connectors con WorkSpaces è gratuito, a condizione che tu abbia almeno un WorkSpaces utente attivo in un connettore AD piccolo e almeno 100 WorkSpaces utenti attivi in un connettore AD di grandi dimensioni. Per ulteriori informazioni, consulta la pagina [dei prezzi di AWS Directory Services](https://aws.amazon.com/directoryservice/pricing/).
## L'importanza del collegamento di rete a AWS un Active Directory locale
WorkSpaces si basa sulla connettività con Active Directory. Pertanto, la disponibilità del collegamento di rete ad Active Directory è della massima importanza. Ad esempio, se il collegamento di rete nello [Scenario 1](scenario-1-using-ad-connector-to-proxy-authentication-to-on-premises-active-directory-service.md) non è attivo, gli utenti non saranno in grado di autenticarsi e, di conseguenza, non saranno in grado di utilizzarlo. WorkSpaces
Se si desidera utilizzare un Active Directory locale come parte dello scenario, è necessario considerare la resilienza, la latenza e il costo del traffico del collegamento di rete a. AWS In una WorkSpaces distribuzione multiregionale, ciò può comportare più collegamenti di rete in diverse AWS regioni o più AWS Transit Gateway reti con peering stabilito tra di loro per instradare il traffico AD verso il VPC con connettività all'AD locale. Queste considerazioni sui collegamenti di rete si applicano alla maggior parte degli scenari descritti nelle sezioni seguenti, ma sono particolarmente importanti per quegli scenari in cui il traffico AD proveniente da AD Connectors WorkSpaces deve attraversare il collegamento di rete per raggiungere l'Active Directory locale. [ Lo scenario 1](scenario-1-using-ad-connector-to-proxy-authentication-to-on-premises-active-directory-service.md) evidenzia alcune delle avvertenze.
## Utilizzo dell'autenticazione a più fattori con WorkSpaces
Se si prevede di utilizzare Multi-Factor Authentication (MFA) WorkSpaces con, è necessario utilizzare un AD AWS Connector o AWS Managed Microsoft AD un, poiché solo questi servizi consentono la registrazione della directory per l'uso WorkSpaces e la configurazione di RADIUS. Per il posizionamento dei server RADIUS, si applicano le considerazioni relative ai collegamenti di rete illustrate nella [L'importanza del collegamento di rete a AWS un Active Directory locale](#network-link-to-aws-with-on-premises-ad) sezione.
## Separazione dell'account e del dominio delle risorse
Per motivi di sicurezza o per una migliore gestibilità, potrebbe essere opportuno separare il dominio dell'account dal dominio delle risorse. Ad esempio, posizionate gli oggetti del WorkSpaces computer in un dominio di risorse separato, mentre gli utenti fanno parte del dominio dell'account. Un'implementazione come questa può essere utilizzata per consentire a un'organizzazione partner di gestire l' WorkSpacesutilizzo delle politiche di gruppo AD nel dominio delle risorse, senza rinunciare al controllo o concedere l'accesso al dominio dell'account. Ciò può essere ottenuto utilizzando due Active Directory con un Active Directory Trust configurato. Le seguenti sezioni trattano questo argomento in modo più dettagliato:
+ [Scenario 4: AWS Microsoft AD e un trust transitivo bidirezionale per l'ambiente locale](scenario-4-aws-microsoft-ad-and-a-two-way-transitive-trust-to-on-premises.md)
+ [Scenario 6: AWS Microsoft AD, servizi condivisi, VPC e un trust unidirezionale per l'ambiente locale](scenario-6-aws-microsoft-ad-shared-services-vpc-and-a-one-way-trust-to-on-premises.md)
## Implementazioni di Active Directory di grandi dimensioni
È necessario assicurarsi che Active Directory Sites & Services sia configurato di conseguenza. Ciò è particolarmente importante se Active Directory è costituito da un gran numero di controller di dominio in diverse aree geografiche. I sistemi Windows WorkSpaces utilizzano il [meccanismo standard di Microsoft](https://social.technet.microsoft.com/wiki/contents/articles/24457.how-domain-controllers-are-located-in-windows.aspx) per individuare il controller di dominio per il sito di Active Directory a cui sono assegnati. Questo processo DC Locator si basa sul DNS e può essere notevolmente prolungato nel caso in cui venga restituito un lungo elenco di controller di dominio con priorità e peso non specifici nella fase iniziale del processo DC Locator. Ancora più importante, se si viene « WorkSpaces bloccati «su un controller di dominio non ottimale, tutte le comunicazioni successive con questo controller di dominio potrebbero risentire dell'aumento della latenza di rete e della riduzione della larghezza di banda quando si attraversano collegamenti di rete WAN. Ciò rallenterà qualsiasi comunicazione con il controller di dominio, inclusa l'elaborazione di un numero potenzialmente elevato di Group Policy Object (GPO) e i trasferimenti di file dal controller di dominio. A seconda della topologia di rete, può anche aumentare i costi di rete, poiché i dati scambiati tra i controller di dominio WorkSpaces e i controller di dominio potrebbero attraversare inutilmente un percorso di rete più costoso. Consulta le [Considerazioni di natura progettuale](design-considerations.md) sezioni [Progettazione VPC](design-considerations.md) e per indicazioni su DHCP e DNS con la progettazione del tuo VPC e su Siti e servizi di Active Directory.
## Utilizzo di Microsoft Azure Active Directory o Active Directory Domain Services con WorkSpaces
Se intendi usare Microsoft Azure Active Directory con WorkSpaces, puoi usare Azure AD Connect per sincronizzare la tua identità con Active Directory locale o con Active Directory su AWS (Controller di dominio su Amazon EC2 o). AWS Managed Microsoft AD Tuttavia, ciò non ti consentirà di accedere WorkSpaces al tuo Azure Active Directory. Per ulteriori informazioni, vedere la documentazione di [Microsoft Hybrid Identity nella documentazione](https://docs.microsoft.com/en-us/azure/active-directory/hybrid/) di *Microsoft Azure*.
Se desideri aggiungere il tuo WorkSpaces ad Azure Active Directory, dovrai distribuire Microsoft Azure Active Directory Domain Services (Azure AD DS), stabilire la connettività tra AWS e Azure e usare un AD Connector che punti ai controller di dominio Azure AWS AD DS. Per altre informazioni su come configurarlo, vedi il post di blog [Aggiungere ad Azure AD usando Azure Active WorkSpaces Directory](https://aws.amazon.com/blogs/desktop-and-application-streaming/add-your-workspaces-to-azure-ad-using-azure-active-directory-domain-services/) Domain Services.
Quando usi AWS Directory Service s with WorkSpaces, dovrai considerare le dimensioni della WorkSpaces distribuzione e la crescita prevista per dimensionarla in modo appropriato. AWS Directory Service Questa sezione fornisce indicazioni sul dimensionamento AWS Directory Service per l'uso con. WorkSpaces Ti consigliamo inoltre di consultare le AWS Managed Microsoft AD sezioni [Best practice per AD Connector](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ad_connector_best_practices.html) e [Best practice per](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_best_practices.html) la *Guida all'AWS Directory Service amministrazione*.
## Dimensionamento di AD Connector con WorkSpaces
L'Active Directory Connector (AD Connector) è disponibile in due dimensioni, Small e Large. Sebbene non siano previsti limiti di utenti o connessioni, consigliamo di utilizzare un connettore AD piccolo per un massimo di 500 utenti WorkSpaces autorizzati e un connettore AD grande per un massimo di 5000 utenti WorkSpaces autorizzati. Puoi distribuire i carichi di applicazioni su più AD Connector per adattarlo alle tue esigenze di prestazioni. Ad esempio, se devi supportare 1500 WorkSpaces utenti, puoi distribuirli WorkSpaces equamente su tre piccoli AD Connector, ognuno dei quali supporta 500 utenti. Se tutti i tuoi utenti risiedono nello stesso dominio, AD Connector può puntare tutti allo stesso set di server DNS che risolvono il tuo dominio Active Directory.
Nota, se hai iniziato con un connettore AD di piccole dimensioni e la tua WorkSpaces implementazione cresce nel tempo, puoi inviare un ticket di assistenza per modificare le dimensioni del tuo AD Connector da piccole a grandi in modo da gestire il maggior numero di utenti WorkSpaces autorizzati.
## Dimensionamento di AWS Managed Microsoft AD
[AWS Managed Microsoft AD](https://aws.amazon.com/directoryservice/active-directory/)consente di eseguire Microsoft Active Directory come servizio gestito. È possibile scegliere tra Standard Edition ed Enterprise Edition all'avvio del servizio. La Standard Edition è consigliata per le piccole e medie imprese con un massimo di 5.000 utenti e supporta fino a circa 30.000 oggetti di directory, come utenti, gruppi e computer. [L'Enterprise Edition è progettata per supportare fino a 500.000 oggetti di directory e offre anche una funzionalità aggiuntiva, come la replica in più regioni.](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_configure_multi_region_replication.html)
Se devi supportare più di 500.000 oggetti di directory, prendi in considerazione la distribuzione dei controller di dominio Microsoft Active Directory su Amazon EC2. Per il dimensionamento di questi controller di dominio, consulta il documento Microsoft sulla [pianificazione della capacità](https://docs.microsoft.com/en-us/windows-server/administration/performance-tuning/role/active-directory-server/capacity-planning-for-active-directory-domain-services) per i servizi di dominio Active Directory.
# Scenario 1: utilizzo del connettore AD per l'autenticazione tramite proxy al servizio Active Directory Service locale
Questo scenario è destinato ai clienti che non desiderano estendere il servizio AD locale o per AWS i quali una nuova distribuzione di AD DS non è un'opzione. La figura seguente mostra, a livello elevato, ciascuno dei componenti e il flusso di autenticazione degli utenti.
![\[Architettura di esempio che mostra a un livello elevato ogni componente e il flusso di autenticazione degli utenti.\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/best-practices-deploying-amazon-workspaces/images/ad-connector-to-onprem.png)
In questo scenario, AWS Directory Service (AD Connector) viene utilizzato per l'autenticazione di tutti gli utenti o MFA che viene inoltrata tramite proxy tramite AD Connector all'AD DS locale del cliente (dettagliata nella figura seguente). Per i dettagli sui protocolli o sulla crittografia utilizzati per il processo di autenticazione, consulta la [Sicurezza](security.md) sezione di questo documento.
![\[Architettura di esempio che mostra come AD Connector viene utilizzato per l'autenticazione di tutti gli utenti o MFA che viene inoltrata tramite proxy tramite AD Connector all'AD DS locale del cliente.\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/best-practices-deploying-amazon-workspaces/images/user-authentication-auth-gateway.png)
Lo scenario 1 mostra un'architettura ibrida in cui il cliente potrebbe già disporre di risorse AWS, oltre a risorse in un data center locale a cui è possibile accedere tramite Amazon WorkSpaces. Il cliente può sfruttare i server AD DS e RADIUS locali esistenti per l'autenticazione utente e MFA.
Questa architettura utilizza i seguenti componenti o costrutti:
## AWS
+ **Amazon VPC**: creazione di un Amazon VPC con almeno due sottoreti private su due AZ.
+ Set di **opzioni DHCP: creazione di un set** di opzioni DHCP Amazon VPC. Ciò consente di definire nomi di dominio e server di nomi di dominio (DNS) (servizi locali) specificati dal cliente. [Per ulteriori informazioni, fare riferimento ai set di opzioni DHCP.](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_DHCP_Options.html)
+ **Amazon Virtual Private Gateway**: abilita la comunicazione con la propria rete tramite un tunnel VPN IPSec o una AWS Direct Connect connessione.
+ **AWS Directory Service**: AD Connector viene distribuito in un paio di sottoreti private Amazon VPC.
+ **Amazon WorkSpaces**: WorkSpaces vengono distribuiti nelle stesse sottoreti private di AD Connector. Per ulteriori informazioni, consulta la sezione [Active Directory: Siti e servizi](design-considerations.md#active-directory-sites-and-services) di questo documento.
## Customer
+ **Connettività di rete**: endpoint Corporate VPN o Direct Connect.
+ **AD DS: Servizi di** dominio Active Directory aziendali.
+ **MFA (opzionale): server** RADIUS aziendale.
+ Dispositivi per **utenti finali: dispositivi** aziendali o Bring your own license (BYOL) per utenti finali (come Windows, Mac, iPad, tablet Android, zero client e Chromebook) utilizzati per accedere al servizio Amazon. WorkSpaces Consulta [questo elenco di applicazioni client per](https://docs.aws.amazon.com/workspaces/latest/userguide/workspaces-user-getting-started.html#choose-client) dispositivi e browser Web supportati.
Sebbene questa soluzione sia ideale per i clienti che non desiderano implementare AD DS nel cloud, presenta alcuni avvertimenti:
+ **Affidamento alla connettività: in** caso di interruzione della connettività al data center, gli utenti non possono accedere ai rispettivi server e le connessioni esistenti rimarranno attive per tutta la WorkSpaces durata del Kerberos/Ticket-Granting Ticket (TGT).
+ **Latenza**: se esiste una latenza tramite la connessione (questo vale più per la VPN che per Direct Connect), WorkSpaces l'autenticazione e qualsiasi attività relativa ad AD DS, come l'applicazione dei criteri di gruppo (GPO), richiederanno più tempo.
+ **Costi del traffico**: tutte le autenticazioni devono attraversare il collegamento VPN o Direct Connect e quindi dipende dal tipo di connessione. Si tratta di trasferimento dati in uscita da Amazon EC2 a Internet o trasferimento dati in uscita (Direct Connect).
**Nota**
AD Connector è un servizio proxy. Non memorizza né memorizza nella cache le credenziali dell'utente. Al contrario, tutte le richieste di autenticazione, ricerca e gestione vengono gestite dal tuo AD. Nel servizio di directory è richiesto un account con privilegi di delega con diritti di lettura di tutte le informazioni utente e di aggiungere un computer al dominio.
In generale, l' WorkSpaces esperienza dipende in larga misura dal processo di autenticazione di Active Directory illustrato nella figura precedente. In questo scenario, l'esperienza di WorkSpaces autenticazione dipende in larga misura dal collegamento di rete tra l'AD del cliente e il WorkSpaces VPC. Il cliente deve assicurarsi che il collegamento sia altamente disponibile.
# Scenario 2: estensione di AD DS locale in AWS (replica)
Questo scenario è simile allo scenario 1. Tuttavia, in questo scenario, viene implementata una replica dell'AD DS del cliente AWS in combinazione con AD Connector. Ciò riduce la latenza delle richieste di autenticazione o di query a AD DS in esecuzione su Amazon Elastic Compute Cloud (Amazon EC2). La figura seguente mostra una vista di alto livello di ciascuno dei componenti e del flusso di autenticazione degli utenti.
![\[Un'architettura di esempio che mostra una replica dell'AD DS del cliente viene implementata AWS in combinazione con AD Connector.\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/best-practices-deploying-amazon-workspaces/images/extend-customer-ad-cloud.png)
Come nello scenario 1, AD Connector viene utilizzato per l'autenticazione di tutti gli utenti o MFA, che a sua volta viene inoltrata tramite proxy all'AD DS del cliente (fare riferimento [alla](scenario-1-using-ad-connector-to-proxy-authentication-to-on-premises-active-directory-service.md#fig5) figura precedente). In questo scenario, l'AD DS del cliente viene distribuito su AZ su istanze Amazon EC2 che vengono promosse come controller di dominio nella foresta [AD locale del cliente, in esecuzione nel cloud](https://ipwithease.com/what-is-a-forest-in-active-directory/). AWS Ogni controller di dominio viene distribuito in sottoreti private VPC per rendere AD DS altamente disponibile nel cloud. AWS Per le best practice per la distribuzione di AD DS su AWS, consulta la sezione [Considerazioni sulla progettazione](using-multi-region-aws-managed-active-directory-with-amazon-workspaces.md) di questo documento.
Dopo la distribuzione, WorkSpaces le istanze hanno accesso ai controller di dominio basati sul cloud per servizi di directory e DNS sicuri e a bassa latenza. Tutto il traffico di rete, incluse le comunicazioni di AD DS, le richieste di autenticazione e la replica AD, è protetto all'interno delle sottoreti private o attraverso il tunnel VPN del cliente o Direct Connect.
Questa architettura utilizza i seguenti componenti o costrutti:
## AWS
+ **Amazon VPC**: creazione di un Amazon VPC con almeno quattro sottoreti private su due AZ: due per l'AD DS del cliente, due per AD Connector o Amazon. WorkSpaces
+ Set di **opzioni DHCP: creazione di un set** di opzioni DHCP Amazon VPC. Ciò consente al cliente di definire un nome di dominio e un DNS (AD DS locale) specificati. Per ulteriori informazioni, fare riferimento a [DHCP Options](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_DHCP_Options.html) Sets.
+ **Amazon Virtual Private Gateway**: abilita la comunicazione con una rete di proprietà del cliente tramite un tunnel o una connessione VPN IPSec. AWS Direct Connect
+ **Amazon EC2**
+ Controller di dominio AD DS aziendali del cliente distribuiti su istanze Amazon EC2 in sottoreti VPC private dedicate.
+ Server RADIUS (opzionali) del cliente per MFA su istanze Amazon EC2 in sottoreti VPC private dedicate.
+ **AWS Directory Services**: AD Connector viene distribuito in un paio di sottoreti private Amazon VPC.
+ **Amazon WorkSpaces**: WorkSpaces vengono distribuiti nelle stesse sottoreti private di AD Connector. Per ulteriori informazioni, consulta la sezione [Active Directory: Siti e servizi](design-considerations.md#active-directory-sites-and-services) di questo documento.
## Customer
+ **Connettività di rete**: VPN o AWS Direct Connect endpoint aziendali.
+ **AD DS**: AD DS aziendale (necessario per la replica).
+ **MFA (opzionale): server** RADIUS aziendale.
+ 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 l'[elenco delle applicazioni client per](https://docs.aws.amazon.com/workspaces/latest/userguide/workspaces-user-getting-started.html#choose-client) i dispositivi e i browser Web supportati. Questa soluzione non presenta le stesse avvertenze dello scenario 1. Amazon WorkSpaces e AWS Directory Service non fanno affidamento sulla connettività esistente.
+ **Affidamento alla connettività**: se la connettività al data center del cliente viene persa, gli utenti finali possono continuare a lavorare perché l'autenticazione e l'MFA *opzionale* vengono elaborate localmente.
+ **Latenza**: ad eccezione del traffico di replica, tutte le autenticazioni sono locali e a bassa latenza. Fate riferimento alla sezione [Active Directory: Siti e servizi](design-considerations.md#active-directory-sites-and-services) di questo documento.
+ **Costi del traffico**: in questo scenario, l'autenticazione è locale e solo la replica di AD DS deve attraversare il collegamento VPN o Direct Connect, riducendo il trasferimento dei dati.
In generale, l' WorkSpaces esperienza è migliorata e non dipende in larga misura dalla connettività ai controller di dominio locali, come mostrato nella figura precedente. Questo vale anche quando un cliente desidera scalare fino WorkSpaces a migliaia di desktop, in particolare in relazione alle query del catalogo globale di AD DS, poiché questo traffico rimane locale rispetto all'ambiente. WorkSpaces
# Scenario 3: distribuzione isolata autonoma tramite AWS Directory Service in the Cloud AWS
Questo scenario, illustrato nella figura seguente, prevede l'implementazione di AD DS nel AWS cloud in un ambiente isolato autonomo. AWS Il Directory Service viene utilizzato esclusivamente in questo scenario. Invece di gestire completamente AD DS, i clienti possono affidarsi a AWS Directory Service per attività come la creazione di una topologia di directory ad alta disponibilità, il monitoraggio dei controller di dominio e la configurazione di backup e istantanee.
![\[Architettura di esempio che mostra AD DS distribuito nel AWS cloud in un ambiente isolato indipendente.\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/best-practices-deploying-amazon-workspaces/images/cloud-only-ad-microsoft.png)
Come nello scenario 2, AD DS (Microsoft AD) viene distribuito in sottoreti dedicate che si estendono su due AZ, rendendo AD DS altamente disponibile nel cloud. AWS Oltre a Microsoft AD, AD Connector (in tutti e tre gli scenari) viene distribuito per WorkSpaces l'autenticazione o l'MFA. Ciò garantisce la separazione dei ruoli o delle funzioni all'interno di Amazon VPC, che è una best practice standard. Per ulteriori informazioni, consulta la sezione [Considerazioni sulla progettazione](using-multi-region-aws-managed-active-directory-with-amazon-workspaces.md) di questo documento.
Lo Scenario 3 è una configurazione standard completa che funziona bene per i clienti che desiderano AWS gestire la distribuzione, l'applicazione di patch, l'alta disponibilità e il monitoraggio del AWS Directory Service. Lo scenario è ideale anche per la dimostrazione dei concetti, il laboratorio e gli ambienti di produzione grazie alla sua modalità di isolamento.
Oltre alla posizione di AWS Directory Service, questa figura mostra il flusso di traffico da un utente a un'area di lavoro e il modo in cui l'area di lavoro interagisce con il server AD e il server MFA.
Questa architettura utilizza i seguenti componenti o costrutti.
## AWS
+ **Amazon VPC**: creazione di un Amazon VPC con almeno quattro sottoreti private su due AZ, due per AD DS Microsoft AD[, due](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html) per AD Connector o. 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](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_DHCP_Options.html).
+ **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 di sottoreti VPC dedicate (AD DS Managed Service).
+ **Amazon EC2**: server RADIUS «opzionali» per MFA del cliente.
+ **AWS Directory Services**: AD Connector viene distribuito in un paio di sottoreti private Amazon VPC.
+ **Amazon WorkSpaces**: WorkSpaces vengono distribuiti nelle stesse sottoreti private di AD Connector. Per ulteriori informazioni, consulta la sezione [Active Directory: Siti e servizi](design-considerations.md#active-directory-sites-and-services) di questo documento.
## Customer
+ **Opzionale: 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](https://docs.aws.amazon.com/workspaces/latest/userguide/workspaces-user-getting-started.html#choose-client) Web supportati.
Analogamente allo scenario 2, questo scenario non presenta problemi di dipendenza dalla connettività al data center locale del cliente, dalla latenza o dai costi di trasferimento dei dati in uscita (tranne nei casi in cui l'accesso a Internet è abilitato all'interno WorkSpaces del VPC) perché, in base alla progettazione, si tratta di uno scenario isolato o solo su cloud.
# Scenario 4: AWS Microsoft AD e un trust transitivo bidirezionale per l'ambiente locale
Questo scenario, illustrato nella figura seguente, prevede l'implementazione di AWS Managed AD nel AWS cloud, che prevede un trust transitivo bidirezionale verso l'AD locale del cliente. Gli utenti WorkSpaces vengono creati in Managed AD, con AD trust che consente l'accesso alle risorse nell'ambiente locale.
![\[Architettura di esempio che mostra AWS Managed AD distribuito nel AWS cloud, che offre un trust transitivo bidirezionale all'AD locale del cliente.\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/best-practices-deploying-amazon-workspaces/images/cloud-only-transitive-trust.png)
Come nello scenario 3, AD DS (Microsoft AD) viene distribuito in sottoreti dedicate che si estendono su due AZ, rendendo AD DS altamente disponibile nel cloud. AWS
Questo scenario è ideale per i clienti che desiderano disporre di un AWS Directory Service completamente gestito, che include implementazione, applicazione di patch, alta disponibilità e monitoraggio del proprio AWS cloud. Questo scenario consente inoltre WorkSpaces agli utenti di accedere alle risorse aggiunte da un annuncio sulle reti esistenti. Questo scenario richiede l'esistenza di un trust di dominio. I gruppi di sicurezza e le regole del firewall devono consentire la comunicazione tra le due directory attive.
Oltre al posizionamento di AWS Directory Service, la figura precedente illustra il flusso di traffico da un utente a un'area di lavoro e il modo in cui l'area di lavoro interagisce con il server AD e il server MFA.
Questa architettura utilizza i seguenti componenti o costrutti.
## AWS
+ **Amazon VPC**: creazione di un Amazon VPC con almeno quattro sottoreti private su due AZ, due per AD DS Microsoft AD[, due](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html) per AD Connector o. 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](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_DHCP_Options.html).
+ **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 di sottoreti VPC dedicate (AD DS Managed Service).
+ **Amazon EC2**: server RADIUS *opzionali* per MFA per il cliente.
+ **Amazon WorkSpaces**: WorkSpaces vengono distribuiti nelle stesse sottoreti private di AD Connector. Per ulteriori informazioni, consulta la sezione [Active Directory: Siti e servizi](design-considerations.md#active-directory-sites-and-services) 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 l'[elenco delle applicazioni client per i dispositivi e i browser](https://docs.aws.amazon.com/workspaces/latest/userguide/workspaces-user-getting-started.html#choose-client) Web supportati.
Questa soluzione richiede la connettività al data center locale del cliente per consentire il funzionamento del processo di fiducia. Se WorkSpaces gli utenti utilizzano risorse sulla rete locale, è necessario considerare la latenza e i costi di trasferimento dei dati in uscita.
# Scenario 5: AWS Microsoft AD utilizza un servizio condiviso Virtual Private Cloud (VPC)
Questo scenario, illustrato nella figura seguente, prevede l'implementazione di AWS Managed AD nel AWS cloud, che fornisce servizi di autenticazione per carichi di lavoro già ospitati AWS o che sono pianificati per far parte di una migrazione più ampia. La migliore pratica consigliata è quella di avere Amazon WorkSpaces in un VPC dedicato. I clienti devono inoltre creare un'unità organizzativa AD specifica per organizzare gli oggetti del WorkSpaces computer.
Per eseguire la distribuzione WorkSpaces con un VPC con servizi condivisi che ospita Managed AD, implementa un AD Connector (ADC) con un account di servizio ADC creato in Managed AD. L'account di servizio richiede le autorizzazioni per creare oggetti informatici nell'unità organizzativa WorkSpaces designata nei servizi condivisi Managed AD.
![\[Architettura di esempio che mostra un VPC WorkSpaces con servizi condivisi che ospita Managed AD, implementa un AD Connector.\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/best-practices-deploying-amazon-workspaces/images/microsoft-ad-shared-services-vpc.png)
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](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_DHCP_Options.html).
+ **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
+ **AWS Transit Gateway/VPC Peering**: abilita la connettività tra Workspaces VPC e Shared Services VPC
+ **Amazon EC2**: server RADIUS *opzionali* per MFA per il cliente.
+ **Amazon WorkSpaces**: WorkSpaces vengono distribuiti nelle stesse sottoreti private di AD Connector. Per ulteriori informazioni, consulta la sezione [Active Directory: Siti e servizi](design-considerations.md#active-directory-sites-and-services) 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 l'[elenco delle applicazioni client per i dispositivi e i browser](https://docs.aws.amazon.com/workspaces/latest/userguide/workspaces-user-getting-started.html#choose-client) Web supportati.
# 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.](https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/domain-locator-across-a-forest-trust/ba-p/395689) È 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](https://d1.awsstatic.com/Projects/deploy-amazon-workspaces-one-way-trust-with-aws-directory-service.pdf) 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 Directory Service](https://aws.amazon.com/getting-started/hands-on/deploy-workspaces-one-way-trust/) 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](https://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) 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.\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/best-practices-deploying-amazon-workspaces/images/one-way-trust-ad-onprem.png)
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](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_DHCP_Options.html).
+ **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](design-considerations.md#active-directory-sites-and-services) 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](https://docs.aws.amazon.com/workspaces/latest/userguide/workspaces-user-getting-started.html#choose-client) Web supportati.
# Utilizzo di Active Directory AWS gestita in più regioni con Amazon WorkSpaces
[AWS Directory Service for Microsoft Active Directory](https://aws.amazon.com/directoryservice/active-directory/) (MAD) è un servizio Microsoft Active Directory (AD) completamente gestito che può essere abbinato ad Amazon WorkSpaces. I clienti scelgono AWS Managed Microsoft AD perché offre disponibilità elevata, monitoraggio e backup integrati. AWS L'edizione gestita di Microsoft AD Enterprise aggiunge la possibilità di configurare la [replica multiregione](https://aws.amazon.com/blogs/aws/multi-region-replication-now-enabled-for-aws-managed-microsoft-active-directory/). Questa funzionalità configura automaticamente la connettività di rete interregionale, distribuisce i controller di dominio e replica tutti i dati di Active Directory in più aree, garantendo che i carichi di lavoro Windows e Linux che risiedono in tali aree possano connettersi e utilizzare MAD con bassa latenza e alte prestazioni. AWS Le regioni MAD replicate non possono essere [registrate direttamente WorkSpaces](https://docs.aws.amazon.com/workspaces/latest/adminguide/register-deregister-directory.html), tuttavia è possibile registrare una directory MAD replicata WorkSpaces configurando un AD Connector (ADC) in modo che punti ai controller di dominio replicati.
La best practice per l'implementazione di AD Connectors con MAD consiste nel creare un connettore AD per ogni unità aziendale all'interno WorkSpaces dell'ambiente. Ciò ti consentirà di allineare ogni unità aziendale con una specifica unità organizzativa all'interno di Active Directory. È quindi possibile assegnare ad AD Group Policy Objects a livello di unità organizzativa che si allineano direttamente con l'unità di business in questione.
## Architettura
![\[L'architettura di esempio che mostra AD Connectors con MAD consiste nella creazione di un connettore AD per ogni unità aziendale all'interno WorkSpaces dell'ambiente.\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/best-practices-deploying-amazon-workspaces/images/registering-replicated-mad-region.png)
## Implementazione
Per registrare la tua regione MAD replicata WorkSpaces, dovrai creare un AD Connector indirizzato agli IP del tuo controller di dominio MAD. È possibile trovare gli indirizzi IP del controller di dominio MAD accedendo al riquadro di navigazione della [console AWS Directory Service](https://console.aws.amazon.com/directoryservicev2/), selezionando Directory e quindi scegliendo l'ID di directory corretto. Per creare questi connettori AD, segui questa [guida](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ad_connector_getting_started.html). Una volta creati, puoi [registrarli per WorkSpaces](https://docs.aws.amazon.com/workspaces/latest/adminguide/register-deregister-directory.html). Prima di effettuare la distribuzione WorkSpaces nella nuova regione, assicurati di aver aggiornato il set di opzioni [DHCP](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/dhcp_options_set.html) del tuo VPC.