Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Authentification par certificat
Vous pouvez utiliser l'authentification basée sur des certificats avec des flottes d' WorkSpaces applications jointes à Microsoft Active Directory. Cela supprime l’invite utilisateur à saisir le mot de passe du domaine Active Directory lorsqu’un utilisateur se connecte. En utilisant l’authentification par certificat avec votre domaine Active Directory, vous pouvez :
+ vous fier à votre fournisseur d’identité SAML 2.0 pour authentifier l’utilisateur et fournir des assertions SAML correspondant à l’utilisateur dans Active Directory ;
+ créer une expérience de connexion et d’authentification unique avec moins d’invites utilisateur ;
+ activer les flux d’authentification sans mot de passe à l’aide de votre fournisseur d’identité SAML 2.0.
L'authentification basée sur les certificats utilise les AWS ressources de l'autorité de certification AWS privée (Private CA) de votre. Compte AWS Avec l'autorité de certification AWS privée, vous pouvez créer des hiérarchies d'autorités de certification (CA) privées, y compris les autorités racine et subordonnées CAs. Vous pouvez également créer votre propre hiérarchie d’autorités de certification et émettre des certificats à partir de celle-ci pour authentifier les utilisateurs internes. Pour plus d'informations, reportez-vous à la section [Qu'est-ce que c'est AWS CA privée](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html).
Lorsque vous utilisez AWS Private CA pour l'authentification basée sur des certificats, WorkSpaces Applications demande automatiquement des certificats pour vos utilisateurs lors de la réservation de session pour chaque instance du parc d' WorkSpaces applications. Il authentifie les utilisateurs auprès d’Active Directory à l’aide d’une carte à puce virtuelle dotée des certificats.
L'authentification basée sur les certificats (CBA) est prise en charge sur les flottes jointes au domaine WorkSpaces des applications (flottes mono-session ou multisession) qui exécutent des instances Windows. Pour activer le CBA sur les flottes multisessions, vous devez utiliser une image d'applications qui utilise un agent d' WorkSpaces applications publié le WorkSpaces 02-07-2025 ou après cette date. Ou bien, votre image doit utiliser les mises à jour d'image WorkSpaces des applications gérées publiées le 02-11-2025 ou après cette date.
**Topics**
+ [Conditions préalables](certificate-based-authentication-prereq.md)
+ [Activer l’authentification par certificat](certificate-based-authentication-enable.md)
+ [Gérer l’authentification par certificat](certificate-based-authentication-manage.md)
+ [Activer le partage PCA entre comptes](pca-sharing.md)
# Conditions préalables
Effectuez les étapes suivantes avant d’utiliser l’authentification par certificat.
1. Configurez une flotte jointe à un domaine et configurez SAML 2.0. Assurez-vous d’utiliser le format `username@domain.com` `userPrincipalName` pour la valeur SAML\$1Subject `NameID`. Pour plus d’informations, consultez [Etape 5 : Créer des assertions pour la réponse de l'authentification SAML](external-identity-providers-setting-up-saml.md#external-identity-providers-create-assertions).
**Note**
N’activez pas la **connexion par carte à puce pour Active Directory** dans votre pile si vous souhaitez utiliser l’authentification par certificat. Pour de plus amples informations, veuillez consulter [Cartes à puce](feature-support-USB-devices-qualified.md#feature-support-USB-devices-qualified-smart-cards).
1. Utilisez la version 10-13-2022 ou ultérieure de l'agent WorkSpaces Applications avec votre image. Pour de plus amples informations, veuillez consulter [Conservez l'image de vos WorkSpaces applications Amazon Up-to-Date](keep-image-updated.md).
1. Configurez l'attribut `ObjectSid` dans votre assertion SAML. Vous pouvez utiliser cet attribut pour effectuer un mappage fort avec l’utilisateur Active Directory. L’authentification par certificat échoue si l’attribut `ObjectSid` ne correspond pas à l’identifiant de sécurité (SID) Active Directory de l’utilisateur spécifié dans la valeur SAML\$1Subject `NameID`. Pour de plus amples informations, veuillez consulter [Etape 5 : Créer des assertions pour la réponse de l'authentification SAML](external-identity-providers-setting-up-saml.md#external-identity-providers-create-assertions). `ObjectSid`Il est obligatoire pour l'authentification basée sur des certificats après le 10 septembre 2025. Pour plus d'informations, voir [KB5014754: Modifications de l'authentification basée sur les certificats sur les contrôleurs de domaine Windows](https://support.microsoft.com/en-us/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16).
1. Ajoutez l’autorisation `sts:TagSession` à la politique de confiance des rôles IAM que vous utilisez avec votre configuration SAML 2.0. Pour plus d’informations, consultez [Transmission des balises de session dans AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html.html). Cette autorisation est requise pour utiliser l’authentification par certificat. Pour de plus amples informations, veuillez consulter [Étape 2 : créer un rôle IAM Fédération SAML 2.0](external-identity-providers-setting-up-saml.md#external-identity-providers-grantperms).
1. Créez une autorité de certification (CA) AWS privée à l'aide de l'autorité de certification privée, si aucune n'est configurée avec votre Active Directory. AWS Une autorité de certification privée est requise pour utiliser l'authentification basée sur des certificats. Pour de plus amples informations, consultez [Planification du déploiement de votre AWS CA privée](https://docs.aws.amazon.com/privateca/latest/userguide/PcaPlanning.html). Les paramètres AWS Private CA suivants sont courants dans de nombreux cas d'utilisation de l'authentification basée sur des certificats :
+ **Options de type de CA**
+ **Mode d’utilisation de l’autorité de certification de courte durée** : recommandé si l’autorité de certification émet uniquement des certificats d’utilisateur final pour l’authentification par certificat.
+ **Hiérarchie à un seul niveau avec une autorité de certification racine** : choisissez une autorité de certification subordonnée pour l’intégrer à une hiérarchie d’autorités de certification existante.
+ **Options de l’algorithme de clé** : RSA 2048
+ **Options de nom unique de l’objet** : utilisez les options les plus appropriées pour identifier cette autorité de certification dans votre magasin Active Directory Autorités de certification racine de confiance.
+ **Options de révocation des certificats :** distribution de CRL
**Note**
L'authentification basée sur des certificats nécessite un point de distribution CRL en ligne accessible à la fois depuis l'instance du parc d' WorkSpaces applications et le contrôleur de domaine. Cela nécessite un accès non authentifié au compartiment Amazon S3 configuré pour les entrées AWS privées de la CA CRL, ou une CloudFront distribution avec accès au compartiment Amazon S3 s'il bloque l'accès public. Pour plus d’informations sur ces options, consultez [Planification d’une liste de révocation de certificats (CRL)](https://docs.aws.amazon.com/privateca/latest/userguide/crl-planning.html).
1. Marquez votre autorité de certification privée avec une clé habilitée `euc-private-ca` à désigner l'autorité de certification à utiliser avec l'authentification basée sur WorkSpaces les certificats des applications. Cette clé ne nécessite aucune valeur. Pour plus d’informations, consultez [Gestion des balises pour votre autorité de certification privée](https://docs.aws.amazon.com/privateca/latest/userguide/PcaCaTagging.html). Pour plus d'informations sur les politiques AWS gérées utilisées avec WorkSpaces les applications pour accorder des autorisations aux ressources de votre ordinateur Compte AWS, consultez[AWS Politiques gérées requises pour accéder aux ressources WorkSpaces des applications](managed-policies-required-to-access-appstream-resources.md).
1. L’authentification par certificat utilise des cartes à puce virtuelles pour la connexion. Pour plus d’informations, consultez [Recommandations pour l’activation de l’ouverture de session par carte à puce auprès d’autorités de certification tierces](https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/enabling-smart-card-logon-third-party-certification-authorities). Procédez comme suit :
1. Configurez les contrôleurs de domaine avec un certificat de contrôleur de domaine pour authentifier les utilisateurs de carte à puce. Si une autorité de certification d’entreprise des services de certificats Active Directory est configurée dans votre Active Directory, elle inscrit automatiquement les contrôleurs de domaine avec des certificats qui permettent l’ouverture de session par carte à puce. Si vous ne disposez pas des services de certificats Active Directory, consultez la section [Exigences relatives aux certificats de contrôleur de domaine délivrés par une autorité de certification tierce](https://learn.microsoft.com/en-US/troubleshoot/windows-server/windows-security/requirements-domain-controller). AWS recommande aux autorités de certification Active Directory d'entreprise de gérer automatiquement l'inscription aux certificats de contrôleur de domaine.
**Note**
Si vous utilisez AWS Managed Microsoft AD, vous pouvez configurer les services de certificats sur une instance Amazon EC2 qui répond aux exigences relatives aux certificats de contrôleur de domaine. Consultez la section [Déployer Active Directory sur un nouvel Amazon Virtual Private Cloud](https://docs.aws.amazon.com/launchwizard/latest/userguide/launch-wizard-ad-deploying-new-vpc.html) pour des exemples de déploiements de Microsoft AD AWS gérés configurés avec les services de certificats Active Directory.
Avec AWS Managed Microsoft AD et Active Directory Certificate Services, vous devez également créer des règles sortantes depuis le groupe de sécurité VPC du contrôleur vers l'instance Amazon EC2 exécutant les services de certificats. Vous devez fournir au groupe de sécurité l’accès au port TCP 135 et aux ports 49152 à 65535 pour permettre l’inscription automatique aux certificats. L’instance Amazon EC2 doit également autoriser l’accès entrant sur ces mêmes ports depuis les instances de domaine, y compris les contrôleurs de domaine. Pour plus d'informations sur la localisation du groupe de sécurité pour AWS Managed Microsoft AD, voir [Configurer vos sous-réseaux et groupes de sécurité VPC](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_tutorial_setup_trust_prepare_mad.html#tutorial_setup_trust_open_vpc).
1. Sur la console de l'autorité de certification AWS privée, ou à l'aide du SDK ou de la CLI, exportez le certificat de l'autorité de certification privée. Pour plus d’informations, consultez [Exportation d’un certificat privé](https://docs.aws.amazon.com/acm/latest/userguide/export-private.html).
1. Publiez l’autorité de certification privée dans Active Directory. Connectez-vous à un contrôleur de domaine ou à une machine jointe à un domaine. Copiez le certificat de l’autorité de certification privée dans n’importe quel `\` et exécutez les commandes suivantes en tant qu’administrateur de domaine. Vous pouvez également utiliser la stratégie de groupe et le Microsoft PKI Health Tool (PKIView) pour publier l'autorité de certification. Pour plus d’informations, consultez [Instructions de configuration](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
```
Assurez-vous que les commandes s’exécutent correctement, puis supprimez le fichier du certificat de l’autorité de certification privée. En fonction de vos paramètres de réplication Active Directory, la publication sur vos contrôleurs de domaine et instances de parc d' WorkSpaces applications par l'autorité de certification peut prendre plusieurs minutes.
**Note**
Active Directory doit distribuer automatiquement l'autorité de certification aux autorités de certification racine fiables et aux NTAuth magasins d'entreprise pour les instances du parc d' WorkSpaces applications lorsqu'elles rejoignent le domaine.
Pour les systèmes d'exploitation Windows, la distribution de l'autorité de certification (CA) s'effectue automatiquement. Toutefois, pour Rocky Linux et Red Hat Enterprise Linux, vous devez télécharger le ou les certificats de l'autorité de certification racine depuis l'autorité de certification utilisée par votre Configuration du répertoire d' WorkSpaces applications. Si vos certificats d'autorité de certification racine KDC sont différents, vous devez également les télécharger. Avant d'utiliser l'authentification basée sur les certificats, il est nécessaire d'importer ces certificats sur une image ou un instantané.
Sur l'image, il doit y avoir un fichier nommé/`etc/sssd/pki/sssd_auth_ca_db.pem`. Il devrait se présenter comme suit :
```
-----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-----
```
**Note**
Lorsque vous copiez une image entre des régions ou des comptes, ou que vous associez à nouveau une image à un nouvel Active Directory, ce fichier doit être reconfiguré avec les certificats appropriés sur un générateur d'images et capturé à nouveau avant utilisation.
Vous trouverez ci-dessous des instructions pour télécharger les certificats de l'autorité de certification racine :
1. Dans le générateur d'images, créez un fichier nommé`/etc/sssd/pki/sssd_auth_ca_db.pem`.
1. Ouvrez la [console AWS Private CA](https://console.aws.amazon.com/acm-pca/).
1. Choisissez le certificat privé utilisé avec votre Configuration du répertoire d' WorkSpaces applications.
1. Choisissez l'onglet **Certificat CA**.
1. Copiez la chaîne de certificats et le corps du certificat dans `/etc/sssd/pki/sssd_auth_ca_db.pem` le générateur d'images.
Si les certificats de l'autorité de certification racine utilisés par le KDCs sont différents du certificat de l'autorité de certification racine utilisé par votre configuration du répertoire d' WorkSpaces applications, suivez ces exemples d'étapes pour les télécharger :
1. Connectez-vous à une instance Windows associée au même domaine que votre générateur d'images.
1. Ouvrir `certlm.msc`.
1. Dans le volet de gauche, choisissez **Trusted Root Certificate Authorities**, puis sélectionnez **Certificates**.
1. Pour chaque certificat CA racine, ouvrez le menu contextuel (clic droit).
1. Choisissez **Toutes les tâches**, sélectionnez **Exporter** pour ouvrir l'assistant d'exportation de certificats, puis cliquez sur **Suivant**.
1. **Choisissez **X.509 (.CER) codé en Base64**, puis Next.**
1. Choisissez **Parcourir**, entrez un nom de fichier, puis cliquez sur **Suivant**.
1. Choisissez **Finish** (Terminer).
1. Ouvrez le certificat exporté dans un éditeur de texte.
1. Copiez le contenu du fichier dans `/etc/sssd/pki/sssd_auth_ca_db.pem` le générateur d'images.
# Activer l’authentification par certificat
Procédez comme suit pour activer l’authentification par certificat.
**Pour activer l’authentification par certificat**
1. Ouvrez la console WorkSpaces Applications à l'adresse [https://console.aws.amazon.com/appstream2](https://console.aws.amazon.com/appstream2).
1. Dans le volet de navigation, choisissez **Directory Configs**. Sélectionnez la configuration de répertoire que vous souhaitez configurer, puis choisissez **Modifier**.
1. Choisissez **Activer l’authentification par certificat**.
1. Vérifiez que l’ARN de votre autorité de certification privée est associé dans la liste. Pour apparaître dans la liste, vous devez enregistrer l'autorité de certification privée dans le même Compte AWS et Région AWS. Vous devez également identifier l’autorité de certification privée avec une clé nommée `euc-private-ca`.
1. Configurez la solution de secours de connexion au répertoire. La solution de secours permet aux utilisateurs de se connecter à l’aide du mot de passe de leur domaine AD en cas d’échec de l’authentification par certificat. Cette solution n’est recommandée que dans les cas où les utilisateurs connaissent le mot de passe de leur domaine. Lorsque la solution de secours est désactivée, une session peut déconnecter l’utilisateur en cas d’écran de verrouillage ou de déconnexion de Windows. Si la solution de secours est activée, la session invite l’utilisateur à saisir le mot de passe de son domaine AD.
1. Choisissez **Save Changes (Enregistrer les modifications)**.
1. L’authentification par certificat est désormais activée. Lorsque les utilisateurs s'authentifient avec SAML 2.0 auprès d'une pile d' WorkSpaces applications à l'aide de la flotte jointe au domaine depuis le client Web WorkSpaces Applications ou le client pour Windows (version 1.1.1099 et versions ultérieures), ils ne sont plus invités à saisir le mot de passe du domaine. Les utilisateurs voient le message « Connexion avec authentification par certificat… » lors de la connexion à une session activée pour l’authentification par certificat.
# Gérer l’authentification par certificat
Après avoir activé l’authentification par certificat, passez en revue les tâches suivantes.
**Topics**
+ [Certificat d’autorité de certification privée](certificate-based-authentication-manage-CA.md)
+ [Certificats d’utilisateur final](certificate-based-authentication-manage-certs.md)
+ [Rapports d’audit](certificate-based-authentication-manage-audit.md)
+ [Journalisation et surveillance](certificate-based-authentication-manage-logging.md)
# Certificat d’autorité de certification privée
Dans une configuration classique, le certificat d’autorité de certification privée a une durée de validité de 10 ans. Pour plus d’informations sur le remplacement d’une autorité de certification privée dont le certificat a expiré ou sur la réémission de l’autorité de certification privée avec une nouvelle période de validité, consultez [Gestion du cycle de vie de l’autorité de certification privée](https://docs.aws.amazon.com/privateca/latest/userguide/ca-lifecycle.html).
# Certificats d’utilisateur final
Les certificats d'utilisateur final émis par l'authentification basée sur les certificats de AWS Private CA for WorkSpaces Applications ne nécessitent ni renouvellement ni révocation. Ces certificats sont de courte durée. WorkSpaces Les applications délivrent automatiquement un nouveau certificat pour chaque nouvelle session, ou toutes les 24 heures pour les sessions de longue durée. La session WorkSpaces Applications régit l'utilisation de ces certificats d'utilisateur final. Si vous mettez fin à une session, WorkSpaces Applications cesse d'utiliser ce certificat. Ces certificats d'utilisateur final ont une période de validité plus courte que celle d'une distribution CRL AWS privée classique. Par conséquent, les certificats d’utilisateur final n’ont pas besoin d’être révoqués et n’apparaîtront pas dans une CRL.
# Rapports d’audit
Vous pouvez créer un rapport d'audit pour répertorier tous les certificats émis ou révoqués par votre autorité de certification privée. Pour plus d’informations, consultez [Utilisation de rapports d’audit avec votre autorité de certification privée](https://docs.aws.amazon.com/privateca/latest/userguide/PcaAuditReport.html).
# Journalisation et surveillance
Vous pouvez l'utiliser CloudTrail pour enregistrer les appels d'API adressés à une autorité de certification privée par WorkSpaces Applications. Pour plus d'informations, voir [Qu'est-ce que c'est AWS CloudTrail ?](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) et [en utilisant CloudTrail](https://docs.aws.amazon.com/privateca/latest/userguide/PcaCtIntro.html). Dans l'historique des CloudTrail événements, vous pouvez consulter les noms **GetCertificate**des **IssueCertificate**événements provenant de la source d'événements **acm-pca.amazonaws.com** créés par le nom d'utilisateur des applications. WorkSpaces **EcmAssumeRoleSession** Ces événements seront enregistrés pour chaque WorkSpaces demande d'authentification basée sur un certificat d'application. Pour plus d'informations, consultez la section [Affichage des événements à l'aide de l'historique des CloudTrail événements](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html).
# Activer le partage PCA entre comptes
Le partage entre comptes d'une autorité de certification privée (PCA) permet d'autoriser d'autres comptes à utiliser une autorité de certification centralisée. L'autorité de certification peut générer et émettre des certificats en utilisant [AWS Resource Access Manager](https://aws.amazon.com/ram/) (RAM) pour gérer les autorisations. Cela élimine le besoin d'une autorité de certification privée pour chaque compte. Le partage entre comptes CA privés peut être utilisé avec l'authentification basée sur WorkSpaces les certificats (CBA) des applications dans le même cadre. Région AWS
Pour utiliser une ressource CA privée partagée avec WorkSpaces Applications CBA, procédez comme suit :
1. Configurez l'autorité de certification privée pour CBA de manière centralisée Compte AWS. Pour de plus amples informations, veuillez consulter [Authentification par certificat](certificate-based-authentication.md).
1. Partagez l'autorité de certification privée avec la ressource Comptes AWS où les ressources WorkSpaces des applications utilisent le CBA. Pour ce faire, suivez les étapes décrites dans [Comment utiliser la RAM AWS pour partager votre compte ACM Private CA entre plusieurs comptes.](https://aws.amazon.com/blogs/security/how-to-use-aws-ram-to-share-your-acm-private-ca-cross-account/) Il n'est pas nécessaire de suivre l'étape 3 pour créer un certificat. Vous pouvez soit partager l'autorité de certification privée avec un individu Comptes AWS, soit la partager via AWS Organizations. Si vous partagez avec des comptes individuels, vous devez accepter l'autorité de certification privée partagée dans votre compte de ressources à l'aide de la AWS Resource Access Manager console ou APIs.
Lors de la configuration du partage, vérifiez que le partage de AWS Resource Access Manager ressources pour l'autorité de certification privée dans le compte de ressources utilise le modèle d'autorisation `AWSRAMBlankEndEntityCertificateAPICSRPassthroughIssuanceCertificateAuthority` gérée. Ce modèle s'aligne sur le modèle PCA utilisé par le rôle de service WorkSpaces Applications lors de l'émission de certificats CBA.
1. Une fois le partage réussi, consultez l'autorité de certification privée partagée à l'aide de la console d'autorité de certification privée du compte de ressources.
1. Utilisez l'API ou la CLI pour associer l'ARN CA privé au CBA dans la configuration de votre répertoire WorkSpaces d'applications. À l'heure actuelle, la console WorkSpaces Applications ne prend pas en charge la sélection d'une autorité de certification privée partagée ARNs. Voici des exemples de commandes CLI :
`aws appstream update-directory-config --directory-name --certificate-based-auth-properties Status=,CertificateAuthorityArn=`