View a markdown version of this page

Certificate-based Authentification et WorkSpaces personnalisation - Amazon WorkSpaces
Conditions préalablesActivation de l'authentification par certificatGestion de l'authentification par certificatActiver le partage PCA entre comptes

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.

Certificate-based Authentification et WorkSpaces personnalisation

Vous pouvez utiliser l'authentification par certificat pour supprimer l'invite de l'utilisateur WorkSpaces à saisir le mot de passe du domaine Active Directory. 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 les assertions SAML qui lui correspondent dans Active Directory ;

  • offrir une expérience d'authentification unique avec moins d'invites utilisateur ;

  • activer les flux d'authentification sans mot de passe via votre fournisseur d'identité SAML 2.0.

Certificate-based l'authentification utilise CA privée AWS les ressources de votre AWS compte. CA privée AWS permet la création de hiérarchies d'autorités de certification (CA) privées, y compris les autorités de certification racines et subordonnées. Avec CA privée AWS, vous pouvez créer votre propre hiérarchie CA et émettre des certificats avec celle-ci pour authentifier les utilisateurs internes. Pour plus d’informations, consultez le Guide de l’utilisateur Autorité de certification privée AWS.

Lors de l'utilisation CA privée AWS pour l'authentification basée sur des certificats, des certificats WorkSpaces seront automatiquement demandés pour vos utilisateurs lors de l'authentification de session. Les utilisateurs sont authentifiés auprès d'Active Directory à l'aide d'une carte à puce virtuelle allouée avec les certificats.

Certificate-based l'authentification est prise en charge avec les offres Windows WorkSpaces on DCV utilisant les dernières WorkSpaces applications clientes Web Access, Windows et macOS. Ouvrez les téléchargements WorkSpaces du client Amazon pour trouver les dernières versions :

  • Client Windows version 5.5.0 ou ultérieure

  • Client macOS version 5.6.0 ou ultérieure

Pour plus d'informations sur la configuration de l'authentification basée sur les certificats avec Amazon WorkSpaces, consultez Comment configurer l'authentification basée sur les certificats pour Amazon WorkSpaces et Considérations relatives à la conception dans des environnements hautement réglementés pour l'authentification basée sur les certificats avec les applications et. WorkSpaces WorkSpaces

Conditions préalables

Effectuez les étapes suivantes avant d'activer l'authentification par certificat.

  1. Configurez votre WorkSpaces annuaire avec l'intégration SAML 2.0 pour utiliser l'authentification basée sur des certificats. Pour plus d'informations, consultez la section WorkSpaces Intégration à SAML 2.0.

  2. Configurez l'attribut userPrincipalName dans votre assertion SAML. Pour plus d'informations, consultez Créer des assertions pour la réponse de l'authentification SAML.

  3. Configurez l'attribut ObjectSid dans votre assertion SAML. Cela est nécessaire pour effectuer un mappage robuste vers l'utilisateur Active Directory. Certificate-based l'authentification échouera si l'attribut ne correspond pas à l'identifiant de sécurité Active Directory (SID) de l'utilisateur spécifié dans le NameID SAML_Subject. Pour plus d'informations, consultez Créer des assertions pour la réponse de l'authentification SAML.

    Note

    Selon Microsoft KB5014754, l'ObjectSidattribut deviendra obligatoire pour l'authentification par certificat après le 10 septembre 2025.

  4. Ajoutez l'TagSessionautorisation sts : à votre politique de confiance des rôles IAM utilisée avec votre configuration SAML 2.0 si elle n'est pas déjà présente. Cette autorisation est requise pour utiliser l'authentification par certificat. Pour plus d'informations, consultez Créer un rôle IAM Fédération SAML 2.0.

  5. Créez une autorité de certification (CA) privée en utilisant CA privée AWS si vous n'en avez pas configurée avec votre Active Directory. CA privée AWS est nécessaire pour utiliser l'authentification basée sur des certificats. Pour plus d'informations, consultez la section Planification de votre CA privée AWS déploiement et suivez les instructions pour configurer une autorité de certification pour l'authentification basée sur des certificats. Les CA privée AWS paramètres suivants sont les plus courants pour les cas d'utilisation de l'authentification basée sur des certificats :

    1. Options de type de CA :

      1. Short-lived mode d'utilisation de l'autorité de certification (recommandé si vous utilisez l'autorité de certification uniquement pour émettre des certificats d'utilisateur final pour l'authentification basée sur des certificats)

      2. Hiérarchie de niveau unique avec CA racine (vous pouvez aussi choisir une CA subordonnée si vous souhaitez intégrer une hiérarchie de CA existante)

    2. Options d'algorithme principal : RSA 2048

    3. Options de nom unique du sujet : utilisez n'importe quelle combinaison d'options pour identifier la CA dans votre magasin d'autorités de certification racines de confiance Active Directory.

    4. Options de révocation des certificats : Distribution de CRL

      Note

      Certificate-based l'authentification nécessite un point de distribution CRL en ligne accessible depuis les ordinateurs de bureau et le contrôleur de domaine. Cela nécessite un accès non authentifié au compartiment Amazon S3 configuré pour les entrées Private CA CRL, ou une CloudFront distribution qui aura accès au compartiment S3 si celui-ci bloque l'accès public. Pour plus d'informations, consultez Planification d'une liste de révocation de certificats (CRL).

  6. Balisez votre autorité de certification privée avec une clé autorisée euc-private-ca pour désigner la CA à utiliser avec l'authentification par certificat EUC. La clé ne nécessite pas de valeur. Pour plus d'informations, consultez Gestion des balises pour votre CA privée.

  7. Certificate-based l'authentification utilise des cartes à puce virtuelles pour l'ouverture de session. En suivant les Recommandations pour l'activation de l'ouverture de session de carte à puce auprès d'autorités de certification tierces dans Active Directory, effectuez les opérations suivantes :

    • Configurez les contrôleurs de domaine avec un certificat de contrôleur de domaine pour authentifier les utilisateurs de cartes à puce. Si une CA d'entreprise provenant des services de certificats Active Directory est configurée dans Active Directory, les contrôleurs de domaine sont automatiquement inscrits avec des certificats pour permettre l'ouverture de session par carte à puce. Si vous ne disposez pas des services de certificats Active Directory, consultez Configuration requise pour les certificats de contrôleur de domaine provenant d'une autorité de certification tierce. Vous pouvez créer un certificat de contrôleur de domaine avec CA privée AWS. Dans ce cas, n'utilisez pas une CA privée configurée pour les certificats de courte durée.

      Note

      Si vous utilisez AWS Managed Microsoft AD, vous pouvez configurer les services de certificats sur une instance EC2 pour répondre aux exigences relatives aux certificats de contrôleur de domaine. Voir par AWS Launch Wizard exemple les déploiements AWS Managed Microsoft AD configurés avec les services de certificats Active Directory. AWS L'autorité de certification privée peut être configurée en tant que subordonnée à l'autorité de certification des services de certificats Active Directory, ou peut être configurée comme sa propre racine lors de l'utilisation AWS Managed Microsoft AD.

      Une tâche de configuration supplémentaire avec AWS Managed Microsoft AD les services de certificats Active Directory consiste à créer des règles sortantes depuis le groupe de sécurité VPC des contrôleurs vers l'instance EC2 exécutant les services de certificats, permettant aux ports TCP 135 et 49152-65535 d'activer l'inscription automatique des certificats. En outre, l'instance EC2 en cours d'exécution doit autoriser l'accès entrant sur les 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é, AWS Managed Microsoft AD consultez la section Configuration de vos sous-réseaux et groupes de sécurité VPC.

    • Sur la CA privée AWS console ou à l'aide du SDK ou de l'interface de ligne de commande, sélectionnez votre autorité de certification et, sous le certificat CA, exportez le certificat privé de l'autorité de certification. Pour plus d'informations, consultez Exportation d'un certificat privé.

    • Publiez la CA dans Active Directory. Connectez-vous à un contrôleur de domaine ou à un poste associé à un domaine. Copiez le certificat privé de la CA à l'emplacement (<path>\<file>) de votre choix et exécutez les commandes suivantes en tant qu'administrateur de domaine. Vous pouvez également utiliser la stratégie de groupe et l'outil Microsoft PKI Health Tool (PKIview) pour publier la CA. Pour plus d'informations, consultez Instructions de configuration.

      certutil -dspublish -f <path>\<file> RootCA
certutil -dspublish -f  <path>\<file> NTAuthCA

      Assurez-vous que les commandes s'exécutent correctement, puis supprimez le fichier de certificat privé. En fonction des paramètres de réplication Active Directory, la publication de la CA sur vos contrôleurs de domaine et instances de bureau peut prendre plusieurs minutes.

      Note

      • Active Directory doit distribuer l'autorité de certification aux autorités de certification racine de confiance et Enterprise NTAuth stocke automatiquement les WorkSpaces ordinateurs de bureau lorsqu'ils sont joints au domaine.

Activation de l'authentification par certificat

Procédez comme suit pour activer l’authentification par certificat.

  1. Ouvrez la WorkSpaces console à l'adresse https://console.aws.amazon.com/workspaces/v2/home.

  2. Dans le volet de navigation, choisissez Directories (Annuaires).

  3. Choisissez l'ID de répertoire pour votre WorkSpaces.

  4. Sous Authentification, cliquez sur Modifier.

  5. Cliquez sur Modifier Certificate-Based l'authentification.

  6. Cochez Activer Certificate-Based l'authentification.

  7. Vérifiez que l’ARN de votre autorité de certification privée est associé dans la liste. L'autorité de certification privée doit appartenir au même AWS compte et Région AWS doit être étiquetée avec une clé intitulée euc-private-ca pour apparaître dans la liste.

  8. Cliquez sur Enregistrer les modifications. Certificate-based l'authentification est désormais activée.

  9. Redémarrez vos packs Windows WorkSpaces on DCV pour que les modifications soient prises en compte. Pour plus d'informations, voir Redémarrer un WorkSpace.

  10. Après le redémarrage, lorsque les utilisateurs s'authentifient via SAML 2.0 à l'aide d'un client pris en charge, ils ne sont plus invités à saisir le mot de passe de domaine.

Note

Lorsque l'authentification basée sur les certificats est activée pour se connecter WorkSpaces, les utilisateurs ne sont pas invités à utiliser l'authentification multifacteur (MFA), même si elle est activée dans le Répertoire. Lorsque vous utilisez l'authentification par certificat, la MFA peut être activée via votre fournisseur d'identité SAML 2.0. Pour plus d'informations sur l' AWS Directory Service authentification multifacteur, consultez Multi-factor Authentification (connecteur AD) ou Activer l'authentification multifacteur pour. AWS Managed Microsoft AD

Gestion de l'authentification par certificat

Certificat d'une autorité de certification (CA)

Dans une configuration typique, le certificat d'une CA privée a une durée de validité de 10 ans. Consultez Gestion du cycle de vie des CA privées pour plus d'informations sur le remplacement d'une CA privée dont le certificat a expiré, ou la réémission de la CA avec une nouvelle période de validité.

Certificats utilisateur final

Les certificats d'utilisateur final émis par CA privée AWS pour l'authentification WorkSpaces basée sur les certificats ne nécessitent ni renouvellement ni révocation. Ces certificats sont de courte durée. WorkSpacesémet automatiquement un nouveau certificat toutes les 24 heures. Ces certificats d'utilisateur final ont une période de validité plus courte que celle d'une distribution CA privée AWS CRL 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.

Journalisation et surveillance

Vous pouvez l'utiliser AWS CloudTrail pour enregistrer les appels d'API à CA privée AWS by WorkSpaces. Pour plus d'informations, consultez la section Utilisation CloudTrail. Dans l'historique des CloudTrail événements, vous pouvez afficher GetCertificate les noms des IssueCertificate événements à partir de la source de l'acm-pca.amazonaws.comévénement créée par le nom WorkSpaces EcmAssumeRoleSession d'utilisateur. Ces événements seront enregistrés pour chaque demande d'authentification par certificat EUC.

Activer le partage PCA entre comptes

Lorsque vous utilisez le partage entre comptes d'une autorité de certification privée, vous pouvez accorder à d'autres comptes l'autorisation d'utiliser une autorité de certification centralisée, ce qui supprime la nécessité d'une autorité de certification privée pour chaque compte. L'autorité de certification peut générer et émettre des certificats en utilisant AWS Resource Access Manager pour gérer les autorisations. Le partage entre comptes CA privés peut être utilisé avec l'authentification WorkSpaces basée sur des certificats (CBA) au sein de la même région. AWS

Pour utiliser une ressource de CA privée partagée avec WorkSpaces CBA

  1. Configurez l'autorité de certification privée pour CBA dans un AWS compte centralisé. Pour plus d’informations, consultez Certificate-based Authentification et WorkSpaces personnalisation.

  2. Partagez la CA privée avec les AWS comptes de ressources où les WorkSpaces ressources utilisent le CBA en suivant les étapes décrites dans Comment utiliser la AWS RAM pour partager votre compte croisé ACM Private CA. Il n'est pas nécessaire de terminer l'étape 3 pour créer un certificat. Vous pouvez partager l'autorité de certification privée avec des AWS comptes individuels ou la partager via AWS des organisations. Pour partager avec des comptes individuels, vous devez accepter l'autorité de certification privée partagée dans votre compte de ressources à l'aide de la console Resource Access Manager (RAM) ou des API. Lors de la configuration du partage, vérifiez que le partage de ressources RAM pour l'autorité de certification privée dans le compte de ressources utilise le modèle d'autorisation AWS RAMBlankEndEntityCertificateAPICSRPassthroughIssuanceCertificateAuthority géré. Ce modèle s'aligne sur le modèle PCA utilisé par le rôle de WorkSpaces service lors de la délivrance de certificats CBA.

  3. Une fois le partage réussi, vous devriez pouvoir consulter l'autorité de certification privée partagée à l'aide de la console de certification privée du compte de ressource.

  4. Utilisez l'API ou l'interface de ligne de commande pour associer l'ARN CA privé au CBA dans les propriétés de votre WorkSpaces répertoire. À l'heure actuelle, la WorkSpaces console ne prend pas en charge la sélection d'ARN CA privés partagés. Exemples de commandes CLI :

    aws workspaces modify-certificate-based-auth-properties —resource-id <value> —certificate-based-auth-properties Status=<value>,CertificateAuthorityArn=<value>