View a markdown version of this page

Conditions préalables - WorkSpaces Applications Amazon

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.

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_Subject NameID. Pour plus d’informations, consultez Etape 5 : Créer des assertions pour la réponse de l'authentification SAML.

    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.

  2. 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.

  3. Configurez l'attribut ObjectSid dans votre assertion SAML. Vous pouvez utiliser cet attribut pour effectuer un mappage robuste avec l'utilisateur Active Directory. Certificate-based l'authentification échoue si l'ObjectSidattribut ne correspond pas à l'identifiant de sécurité (SID) Active Directory de l'utilisateur spécifié dans le NameID SAML_Subject. Pour de plus amples informations, veuillez consulter Etape 5 : Créer des assertions pour la réponse de l'authentification SAML. ObjectSidIl est obligatoire pour l'authentification par certificat après le 10 septembre 2025. Pour plus d'informations, consultez KB5014754 : modifications Certificate-based d'authentification sur les contrôleurs de domaine Windows.

  4. 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. 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.

  5. Créez une autorité de certification (CA) AWS privée à l'aide de Private CA, si aucune autorité de certification n'est configurée avec votre Active Directory. AWS Une autorité de certification privée est requise pour utiliser l'authentification par certificat. Pour de plus amples informations, consultez Planification du déploiement de votre CA privée AWS. Les paramètres de CA AWS privée suivants sont courants dans de nombreux cas d'utilisation de l'authentification basée sur des certificats :

    • Options de type de CA

      • Short-lived mode d'utilisation de l'autorité de certification  : recommandé si l'autorité de certification émet uniquement des certificats d'utilisateur final pour l'authentification basée sur des certificats.

      • 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

      Certificate-based l'authentification nécessite un point de distribution CRL en ligne accessible à la fois depuis l'instance du parc d' WorkSpaces applications et depuis le contrôleur de domaine. Cela nécessite un accès non authentifié au compartiment Amazon S3 configuré pour les entrées AWS Private CA CRL, ou une CloudFront distribution ayant accès au compartiment Amazon S3 si celui-ci bloque l'accès public. Pour plus d’informations sur ces options, consultez Planification d’une liste de révocation de certificats (CRL).

  6. Marquez votre autorité de certification privée à l'aide d'une clé permettant euc-private-ca de 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. 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 Compte AWS, consultezAWS Politiques gérées requises pour accéder aux ressources WorkSpaces des applications.

  7. Certificate-based l'authentification utilise des cartes à puce virtuelles pour se connecter. 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. 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 émis par une autorité de certification tierce. AWS recommande aux autorités de certification d'entreprise Active Directory 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 Déploiement d'Active Directory sur un nouvel Amazon Virtual Private Cloud pour des exemples de déploiements de Microsoft AD AWS géré 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.

    2. Sur la console AWS Private CA, ou à l'aide du SDK ou de l'interface de ligne de commande, exportez le certificat CA privé. Pour plus d’informations, consultez Exportation d’un certificat privé.

    3. 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 <path>\<file> 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 l’autorité de certification. 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 du certificat de l’autorité de certification privée. En fonction de vos paramètres de réplication Active Directory, la publication par l'autorité de certification sur vos contrôleurs de domaine et les instances de votre parc d' WorkSpaces applications 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 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) se fait automatiquement. Toutefois, pour Rocky Linux et Red Hat Enterprise Linux, vous devez télécharger le ou les certificats d'autorité de certification racine à partir de l'autorité de certification utilisée par votre configuration d'annuaire 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 des 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 d'une région ou d'un compte à un autre, ou que vous réassociez une image à un nouvel Active Directory, ce fichier doit être reconfiguré avec les certificats appropriés sur un générateur d'images et une nouvelle capture d'écran avant d'être utilisé.

Vous trouverez ci-dessous les instructions pour télécharger les certificats CA racine :

  1. Dans le générateur d'images, créez un fichier nommé/etc/sssd/pki/sssd_auth_ca_db.pem.

  2. Ouvrez la console AWS Private CA.

  3. Choisissez le certificat privé utilisé avec la configuration de votre répertoire d' WorkSpaces applications.

  4. Choisissez l'onglet Certificat CA.

  5. 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 CA racine utilisés par les KDC sont différents du certificat CA racine utilisé par la configuration de votre répertoire d' WorkSpaces applications, suivez ces exemples pour les télécharger :

  1. Connectez-vous à une instance Windows associée au même domaine que votre générateur d'images.

  2. Ouvrir certlm.msc.

  3. Dans le volet de gauche, choisissez Autorités de certification racine fiables, puis choisissez Certificats.

  4. Pour chaque certificat CA racine, ouvrez le menu contextuel (clic droit).

  5. Choisissez Toutes les tâches, choisissez Exporter pour ouvrir l'assistant d'exportation de certificats, puis cliquez sur Suivant.

  6. Choisissez Base64-encoded X.509 (.CER), puis cliquez sur Suivant.

  7. Choisissez Parcourir, entrez un nom de fichier, puis cliquez sur Suivant.

  8. Choisissez Finish (Terminer).

  9. Ouvrez le certificat exporté dans un éditeur de texte.

  10. Copiez le contenu du fichier dans /etc/sssd/pki/sssd_auth_ca_db.pem le générateur d'images.