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à.
# Autenticazione basata su certificati
È possibile utilizzare l'autenticazione basata su certificati con flotte di WorkSpaces applicazioni unite a Microsoft Active Directory. Ciò elimina la richiesta all'utente di inserire la password del dominio Active Directory quando effettua l'accesso. Utilizzando l'autenticazione basata su certificati con il dominio Active Directory, puoi:
+ Affidarti al gestore di identità digitale SAML 2.0 per autenticare l'utente e fornire asserzioni SAML che corrispondano a quest'ultimo in Active Directory.
+ Creare un'esperienza di accesso Single Sign-On con un minor numero di richieste all'utente.
+ Abilitare flussi di autenticazione senza password utilizzando il gestore di identità digitale SAML 2.0.
L'autenticazione basata su certificati utilizza le risorse Private Certificate Authority ( AWS AWS Private CA) presenti nel tuo. Account AWS Con AWS Private CA, puoi creare gerarchie di autorità di certificazione (CA) private, tra cui root e subordinate. CAs Puoi anche creare una gerarchia personalizzata di CA e utilizzarla per emettere certificati per l'autenticazione degli utenti interni. [Per ulteriori informazioni, consulta Cos'è. AWS Private CA](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html)
Quando utilizzi AWS Private CA per l'autenticazione basata su certificati, WorkSpaces Applications richiede automaticamente i certificati per gli utenti al momento della prenotazione della sessione per ogni istanza del parco WorkSpaces applicazioni. Autentica gli utenti in Active Directory tramite una smart card virtuale fornita con i certificati.
L'autenticazione basata su certificati (CBA) è supportata nelle flotte di WorkSpaces applicazioni aggiunte al dominio (sia flotte a sessione singola che multisessione) che eseguono istanze Windows. Per abilitare CBA su flotte multisessione, è necessario utilizzare un'immagine Applications che utilizza un agente Applications rilasciato il 02-07-2025 o successivamente. WorkSpaces WorkSpaces In alternativa, l'immagine deve utilizzare gli aggiornamenti gestiti delle immagini delle WorkSpaces applicazioni rilasciati il 02-11-2025 o successivamente.
**Topics**
+ [Prerequisiti](certificate-based-authentication-prereq.md)
+ [Abilitazione dell'autenticazione basata su certificati](certificate-based-authentication-enable.md)
+ [Gestione dell'autenticazione basata su certificati](certificate-based-authentication-manage.md)
+ [Abilita la condivisione PCA tra account](pca-sharing.md)
# Prerequisiti
Prima di utilizzare l'autenticazione basata su certificati, completa le seguenti fasi.
1. Configura un parco istanze unito a un dominio e configura SAML 2.0. Assicurati di utilizzare il formato `username@domain.com` `userPrincipalName` per SAML\$1Subject. `NameID` Per ulteriori informazioni, consulta [Fase 5: creazione delle asserzioni per la risposta di autenticazione SAML](external-identity-providers-setting-up-saml.md#external-identity-providers-create-assertions).
**Nota**
Non abilitare **Accesso tramite smart card per Active Directory** nello stack se desideri utilizzare l'autenticazione basata su certificati. Per ulteriori informazioni, consulta [Smart card](feature-support-USB-devices-qualified.md#feature-support-USB-devices-qualified-smart-cards).
1. Usa la versione dell'agente WorkSpaces Applications 10-13-2022 o successiva con la tua immagine. Per ulteriori informazioni, consulta [Mantieni l'immagine WorkSpaces delle tue applicazioni Amazon Up-to-Date](keep-image-updated.md).
1. Configura l'attributo `ObjectSid` nella tua asserzione SAML. Puoi utilizzare questo attributo per eseguire una mappatura efficace con l'utente di Active Directory. L'autenticazione basata su certificati non riesce se l'attributo `ObjectSid` non corrisponde all'identificatore di sicurezza (SID) di Active Directory per l'utente specificato in SAML\$1Subject `NameID`. Per ulteriori informazioni, consulta [Fase 5: creazione delle asserzioni per la risposta di autenticazione SAML](external-identity-providers-setting-up-saml.md#external-identity-providers-create-assertions). `ObjectSid`È obbligatorio per l'autenticazione basata su certificati dopo il 10 settembre 2025. Per ulteriori informazioni, vedere [KB5014754: Modifiche all'autenticazione basata su certificati](https://support.microsoft.com/en-us/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16) nei controller di dominio Windows.
1. Aggiungi l'autorizzazione `sts:TagSession` alla policy di attendibilità dei ruoli IAM che utilizzi con la configurazione SAML 2.0. Per ulteriori informazioni, consulta [Passare i tag di sessione in AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html.html). Tale autorizzazione è necessaria per utilizzare l'autenticazione basata su certificati. Per ulteriori informazioni, consulta [Fase 2: Creazione di un ruolo IAM di federazione SAML 2.0](external-identity-providers-setting-up-saml.md#external-identity-providers-grantperms).
1. Crea un'autorità di certificazione (CA) AWS privata utilizzando Private CA, se non ne hai una configurata con Active Directory. AWS Per utilizzare l'autenticazione basata su certificati è necessaria una CA privata. Per ulteriori informazioni, consulta [Pianificazione dell'implementazione delle AWS Private CA](https://docs.aws.amazon.com/privateca/latest/userguide/PcaPlanning.html). Le seguenti impostazioni della CA AWS privata sono comuni per molti casi d'uso dell'autenticazione basata su certificati:
+ **Opzioni per tipo CA**
+ **Modalità di utilizzo del certificato CA per certificati di breve durata**: consigliata se utilizzi la CA solo per emettere certificati agli utenti finali per l'autenticazione basata su certificati.
+ **Gerarchia a livello singolo con una CA root**: scegli una CA subordinata se desideri effettuare l'integrazione con una gerarchia CA esistente.
+ **Opzioni per algoritmo chiave**: RSA 2048
+ **Opzioni per il nome distinto dell'oggetto**: utilizza l'opzione più appropriata per identificare questa CA nell'archivio delle autorità di certificazione root attendibili di Active Directory.
+ **Opzioni di revoca del certificato**: distribuzione CRL
**Nota**
L'autenticazione basata su certificati richiede un punto di distribuzione CRL online accessibile sia dall'istanza del parco WorkSpaces applicazioni che dal controller di dominio. Ciò richiede un accesso non autenticato al bucket Amazon S3 configurato AWS per le voci private CA CRL o CloudFront una distribuzione con accesso al bucket Amazon S3 se blocca l'accesso pubblico. Per ulteriori informazioni su queste opzioni, consulta [Pianificazione di un elenco di revoche di certificati (CRL)](https://docs.aws.amazon.com/privateca/latest/userguide/crl-planning.html).
1. Etichetta la tua CA privata con una chiave autorizzata a designare la CA da utilizzare con `euc-private-ca` l'autenticazione basata sui certificati delle applicazioni. WorkSpaces Questa chiave non richiede un valore. Per ulteriori informazioni, consulta [Gestione dei tag per l'autorità di certificazione privata](https://docs.aws.amazon.com/privateca/latest/userguide/PcaCaTagging.html). Per ulteriori informazioni sulle politiche AWS gestite utilizzate con WorkSpaces Applications per concedere le autorizzazioni alle risorse del tuo computer, consulta. Account AWS[AWS Politiche gestite necessarie per accedere alle risorse WorkSpaces delle applicazioni](managed-policies-required-to-access-appstream-resources.md)
1. L'autenticazione basata su certificati utilizza smart card virtuali per l'accesso. Per ulteriori informazioni, consulta [Linee guida per abilitare l'accesso alle smart card con autorità di certificazione di terze parti](https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/enabling-smart-card-logon-third-party-certification-authorities). Completare la procedura riportata di seguito.
1. Configura i controller di dominio con un certificato di controller di dominio per autenticare gli utenti di smart card. Se disponi di un'autorità di certificazione aziendale di Active Directory Certificate Services configurata in Active Directory, questa registra automaticamente i controller di dominio con i certificati per consentire l'accesso tramite smart card. Se non disponi di Active Directory Certificate Services, consulta [Requisiti per i certificati dei controller di dominio emessi da una CA di terze parti](https://learn.microsoft.com/en-US/troubleshoot/windows-server/windows-security/requirements-domain-controller). AWS consiglia alle autorità di certificazione aziendali di Active Directory di gestire automaticamente la registrazione per i certificati dei controller di dominio.
**Nota**
Se utilizzi AWS Managed Microsoft AD, puoi configurare Certificate Services su un'istanza Amazon EC2 che soddisfi i requisiti per i certificati dei controller di dominio. Vedi [Implementazione di Active Directory su un nuovo Amazon Virtual Private Cloud](https://docs.aws.amazon.com/launchwizard/latest/userguide/launch-wizard-ad-deploying-new-vpc.html), ad esempio implementazioni di Managed AWS Microsoft AD configurate con Active Directory Certificate Services.
Con AWS Managed Microsoft AD e Active Directory Certificate Services, devi anche creare regole in uscita dal gruppo di sicurezza VPC del controller all'istanza Amazon EC2 che esegue Certificate Services. Devi fornire al gruppo di sicurezza l'accesso alla porta TCP 135 e alle porte da 49152 a 65535 per abilitare la registrazione automatica dei certificati. Inoltre, l'istanza Amazon EC2 deve anche consentire l'accesso in entrata sulle stesse porte dalle istanze di dominio, inclusi i controller di dominio. Per ulteriori informazioni sull'individuazione del gruppo di sicurezza per AWS Managed Microsoft AD, consulta [Configurare le sottoreti e i gruppi di sicurezza VPC](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_tutorial_setup_trust_prepare_mad.html#tutorial_setup_trust_open_vpc).
1. Sulla console CA AWS privata o con l'SDK o la CLI, esporta il certificato CA privato. Per ulteriori informazioni, consulta [Esportazione di un certificato privato](https://docs.aws.amazon.com/acm/latest/userguide/export-private.html).
1. Pubblica la CA privata in Active Directory. Accedi a un controller di dominio o a un computer aggiunto al dominio. Copia il certificato della CA privata su qualsiasi `\` ed esegui i seguenti comandi come amministratore di dominio. È inoltre possibile utilizzare Group Policy e Microsoft PKI Health Tool (PKIView) per pubblicare la CA. Per ulteriori informazioni, consulta [Istruzioni per la configurazione](https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/enabling-smart-card-logon-third-party-certification-authorities#configuration-instructions).
```
certutil -dspublish -f \ RootCA
```
```
certutil -dspublish -f \ NTAuthCA
```
Assicurati che i comandi vengano completati correttamente, quindi rimuovi il file della CA privata. A seconda delle impostazioni di replica di Active Directory, la pubblicazione da parte della CA sui controller di dominio e sulle istanze del parco di WorkSpaces applicazioni può richiedere diversi minuti.
**Nota**
Active Directory deve distribuire automaticamente la CA alle Trusted Root Certification Authorities e agli Enterprise NTAuth Stores per le istanze del parco di WorkSpaces applicazioni quando queste si aggiungono al dominio.
Per i sistemi operativi Windows, la distribuzione della CA (Certificate Authority) avviene automaticamente. Tuttavia, per Rocky Linux e Red Hat Enterprise Linux, è necessario scaricare i certificati CA root dalla CA utilizzata da WorkSpaces Applications Directory Config. Se i tuoi certificati CA root KDC sono diversi, devi scaricare anche quelli. Prima di utilizzare l'autenticazione basata su certificati, è necessario importare questi certificati su un'immagine o un'istantanea.
Nell'immagine dovrebbe esserci un file chiamato/. `etc/sssd/pki/sssd_auth_ca_db.pem` Avrà un aspetto simile al seguente:
```
-----BEGIN CERTIFICATE-----
Base64-encoded certificate chain from ACM Private CA
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Base64-encoded certificate body from ACM private CA
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Base64-encoded root CA KDC certificate chain
-----END CERTIFICATE-----
```
**Nota**
Quando si copia un'immagine tra regioni o account o si riassocia un'immagine a una nuova Active Directory, è necessario riconfigurare questo file con i certificati pertinenti su un generatore di immagini e creare nuovamente un'istantanea prima dell'uso.
Di seguito sono riportate le istruzioni per scaricare i certificati CA root:
1. Sul generatore di immagini, crea un file denominato`/etc/sssd/pki/sssd_auth_ca_db.pem`.
1. Apri la [console AWS Private CA](https://console.aws.amazon.com/acm-pca/).
1. Scegli il certificato privato utilizzato con WorkSpaces Applications Directory Config.
1. Scegli la scheda del **certificato CA**.
1. Copia la catena di certificati e l'ente del certificato in `/etc/sssd/pki/sssd_auth_ca_db.pem` On Image Builder.
Se i certificati CA root utilizzati da KDCs sono diversi dal certificato CA radice utilizzato da WorkSpaces Applications Directory Config, segui questi passaggi di esempio per scaricarli:
1. Connect a un'istanza Windows aggiunta allo stesso dominio del generatore di immagini.
1. Aprire `certlm.msc`.
1. Nel riquadro di sinistra, scegli **Trusted Root Certificate Authorities**, quindi scegli **Certificati**.
1. Per ogni certificato CA principale, apri il menu contestuale (fai clic con il pulsante destro del mouse).
1. Scegli **Tutte le attività**, scegli **Esporta** per aprire la procedura guidata di esportazione dei certificati, quindi scegli **Avanti**.
1. **Scegliete **X.509 con codifica Base64 (.CER**) e scegliete Avanti.**
1. **Scegliete **Sfoglia**, immettete un nome di file e scegliete Avanti.**
1. Scegli **Fine**.
1. Apri il certificato esportato in un editor di testo.
1. Copia il contenuto del file nel generatore di immagini. `/etc/sssd/pki/sssd_auth_ca_db.pem`
# Abilitazione dell'autenticazione basata su certificati
Completa i seguenti passaggi per abilitare l'autenticazione basata su certificati.
**Per abilitare l'autenticazione basata su certificati**
1. Apri la console WorkSpaces delle applicazioni in [https://console.aws.amazon.com/appstream2.](https://console.aws.amazon.com/appstream2)
1. Nel riquadro di navigazione, scegli **Directory Configs**. Seleziona l'oggetto Directory Config che desideri configurare e scegli **Modifica**.
1. Seleziona **Abilita l'autenticazione basata su certificati**.
1. Verifica che l'ARN della CA privata sia associato nell'elenco. Per apparire nell'elenco, è necessario archiviare la CA privata nella stessa e. Account AWS Regione AWSÈ inoltre assegnare un tag alla CA privata con una chiave denominata `euc-private-ca`.
1. Configurazione dell'accesso alla directory nel fallback. Con il fallback gli utenti possono accedere utilizzando la password del dominio AD se l'autenticazione basata su certificati non riesce. Questa operazione è consigliata solo nei casi in cui gli utenti conoscono le password del dominio. Quando il fallback è disattivato, una sessione può disconnettere l'utente se si verifica una schermata di blocco o la disconnessione di Windows. Se il fallback è attivato, la sessione richiede all'utente la password del dominio AD.
1. Seleziona **Salva modifiche**.
1. L'autenticazione basata su certificati è ora abilitata. Quando gli utenti si autenticano con SAML 2.0 su uno stack di WorkSpaces applicazioni utilizzando la flotta aggiunta al dominio dal client Web WorkSpaces Applications o dal client per Windows (versione 1.1.1099 e successive), non riceveranno più una richiesta per la password del dominio. Gli utenti vedranno un messaggio "Connecting with certificate-based authentication…" durante la connessione a una sessione abilitata per l'autenticazione basata su certificati.
# Gestione dell'autenticazione basata su certificati
Dopo aver abilitato l'autenticazione basata su certificati, esamina le seguenti attività.
**Topics**
+ [Certificato della CA privata](certificate-based-authentication-manage-CA.md)
+ [Certificati per utenti finali](certificate-based-authentication-manage-certs.md)
+ [Report di audit](certificate-based-authentication-manage-audit.md)
+ [Registrazione di log e monitoraggio](certificate-based-authentication-manage-logging.md)
# Certificato della CA privata
In una configurazione tipica, il certificato di una CA privata ha un periodo di validità di 10 anni. Per ulteriori informazioni sulla sostituzione di una CA privata con un certificato scaduto o sulla riemissione della CA privata con un nuovo periodo di validità, consulta [Gestione del ciclo di vita della CA privata](https://docs.aws.amazon.com/privateca/latest/userguide/ca-lifecycle.html)
# Certificati per utenti finali
I certificati per gli utenti finali emessi da AWS Private CA for WorkSpaces Applications (autenticazione basata su certificati) non richiedono rinnovo o revoca. Questi certificati sono di breve durata. WorkSpaces Le applicazioni emettono automaticamente un nuovo certificato per ogni nuova sessione o ogni 24 ore per sessioni di lunga durata. La sessione WorkSpaces Applicazioni regola l'uso di questi certificati per gli utenti finali. Se si termina una sessione, WorkSpaces Applications smette di utilizzare quel certificato. Questi certificati per gli utenti finali hanno un periodo di validità più breve rispetto a una tipica distribuzione AWS privata di CA CRL. Di conseguenza, non vanno revocati e non verranno visualizzati in un CRL.
# Report di audit
È possibile creare un report di audit per elencare i certificati emessi o revocati dalla CA privata. Per ulteriori informazioni, consulta [Utilizzo di report di audit con la CA privata](https://docs.aws.amazon.com/privateca/latest/userguide/PcaAuditReport.html).
# Registrazione di log e monitoraggio
È possibile CloudTrail utilizzarlo per registrare le chiamate API verso una CA privata tramite WorkSpaces Applications. Per ulteriori informazioni, consulta [What Is AWS CloudTrail?](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) e [utilizzo CloudTrail](https://docs.aws.amazon.com/privateca/latest/userguide/PcaCtIntro.html). Nella Cronologia degli CloudTrail eventi puoi visualizzare **GetCertificate**i nomi **IssueCertificate**degli eventi tratti dalla fonte degli eventi **acm-pca.amazonaws.com** creati dal nome utente delle Applicazioni. WorkSpaces **EcmAssumeRoleSession** Questi eventi verranno registrati per ogni richiesta di autenticazione basata su certificati delle Applicazioni. WorkSpaces Per ulteriori informazioni, consulta [Visualizzazione degli eventi con CloudTrail la cronologia degli eventi](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html).
# Abilita la condivisione PCA tra account
La condivisione tra account CA privati (PCA) offre la possibilità di concedere ad altri account le autorizzazioni per l'utilizzo di una CA centralizzata. La CA può generare ed emettere certificati utilizzando [AWS Resource Access Manager](https://aws.amazon.com/ram/) (RAM) per gestire le autorizzazioni. Ciò elimina la necessità di una CA privata in ogni account. La condivisione tra account CA privati può essere utilizzata con WorkSpaces Applications Certificate-based Authentication (CBA) all'interno dello stesso. Regione AWS
Per utilizzare una risorsa CA privata condivisa con WorkSpaces Applications CBA, completa i seguenti passaggi:
1. Configura la CA privata per CBA in modo centralizzato. Account AWS Per ulteriori informazioni, consulta [Autenticazione basata su certificati](certificate-based-authentication.md).
1. Condividi la CA privata con la risorsa Account AWS in cui le risorse delle WorkSpaces applicazioni utilizzano CBA. A tale scopo, segui la procedura descritta in [Come usare la RAM AWS per condividere il tuo cross-account ACM Private CA](https://aws.amazon.com/blogs/security/how-to-use-aws-ram-to-share-your-acm-private-ca-cross-account/). Non è necessario completare la fase 3 per creare un certificato. Puoi condividere la CA privata con una persona Account AWS o condividerla tramite AWS Organizations. Se condividi con account individuali, devi accettare la CA privata condivisa nel tuo account di risorsa utilizzando la AWS Resource Access Manager console o APIs.
Durante la configurazione della condivisione, verifica che la condivisione di AWS Resource Access Manager risorse per la CA privata nell'account di risorsa utilizzi il modello di autorizzazione `AWSRAMBlankEndEntityCertificateAPICSRPassthroughIssuanceCertificateAuthority` gestita. Questo modello è in linea con il modello PCA utilizzato dal ruolo di servizio WorkSpaces Applicazioni per l'emissione dei certificati CBA.
1. Una volta completata la condivisione, visualizza la CA privata condivisa utilizzando la console Private CA nell'account della risorsa.
1. Utilizza l'API o la CLI per associare l'ARN CA privato a CBA nella configurazione della directory delle applicazioni. WorkSpaces Al momento, la console WorkSpaces Applicazioni non supporta la selezione di CA private condivise. ARNs Di seguito sono riportati alcuni esempi di comandi CLI:
`aws appstream update-directory-config --directory-name --certificate-based-auth-properties Status=,CertificateAuthorityArn=`