Utiliser des cartes à puce pour l'authentification dans WorkSpaces Personal - Amazon WorkSpaces
ExigencesLimitationsConfiguration Active DirectoryActiver les cartes à puce pour Windows WorkSpacesActivez les cartes à puce pour Ubuntu, Rocky Linux et Red Hat Enterprise Linux WorkSpacesActiver les cartes à puce pour Amazon Linux 2 WorkSpaces

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.

Utiliser des cartes à puce pour l'authentification dans WorkSpaces Personal

Les offres Windows et Linux WorkSpaces on DCV autorisent l'utilisation de cartes à puce CAC (Common Access Card) et de vérification d'identité personnelle (PIV) pour l'authentification.

Amazon WorkSpaces prend en charge l'utilisation de cartes à puce à la fois pour l'authentification pré-session et pour l'authentification en cours de session. L'authentification de pré-session fait référence à l'authentification par carte à puce effectuée pendant que les utilisateurs se connectent à leur WorkSpaces. L'authentification en cours de session fait référence à l'authentification effectuée après la connexion.

Par exemple, les utilisateurs peuvent utiliser des cartes à puce pour l'authentification en cours de session lorsqu'ils travaillent avec des applications et des navigateurs Web. Ou encore, pour les actions nécessitant des autorisations d'administration. Par exemple, si l'utilisateur dispose d'autorisations administratives sur son système Linux WorkSpace, il peut utiliser des cartes à puce pour s'authentifier lors de l'exécution sudo et des sudo -i commandes.

Exigences

  • Un annuaire Connecteur Active Directory (AD Connector) est requis pour l'authentification pré-session. AD Connector utilise l'authentification mutuelle par certificat (protocole TLS mutuel) pour authentifier les utilisateurs auprès d'Active Directory à l'aide de certificats de carte à puce matériels ou logiciels. Pour plus d'informations sur la façon de configurer AD Connector et l'annuaire sur site, consultez Configuration Active Directory.

  • Pour utiliser une carte à puce sous Windows ou Linux WorkSpace, l'utilisateur doit utiliser le client Amazon WorkSpaces Windows version 3.1.1 ou ultérieure, le client WorkSpaces macOS version 3.1.5 ou ultérieure, ou le client WorkSpaces Ubuntu 22.04 version 2024.1 ou ultérieure (l'authentification par carte à puce n'est pas prise en charge avec WorkSpaces le client Ubuntu 20.04). Pour plus d'informations sur l'utilisation des cartes à puce avec les clients Windows et macOS, consultez la section Support des cartes à puce dans le guide de WorkSpaces l'utilisateur Amazon.

  • L'autorité de certification (CA) racine et les certificats de carte à puce doivent répondre à certaines exigences. Pour plus d'informations, consultez Activer l'authentification mTLS dans AD Connector pour une utilisation avec des cartes à puce dans le Guide d'administration AWS Directory Service et Exigences de certificat dans la documentation Microsoft.

    Outre ces exigences, les certificats utilisateur utilisés pour l'authentification par carte à puce auprès d'Amazon WorkSpaces doivent inclure les attributs suivants :

    • Le nom de l'utilisateur AD userPrincipalName (UPN) dans le champ subjectAltName (SAN) du certificat. Nous recommandons d'émettre des certificats de carte à puce pour l'UPN par défaut de l'utilisateur.

      Note

      Amazon Linux 2 WorkSpaces s'appuie sur UPN pour le certificate-to-user mappage. Les nouveaux systèmes Linux WorkSpaces, tels qu'Ubuntu, Rocky Linux et Red Hat Enterprise Linux WorkSpaces, prennent en charge des méthodes de mappage plus sécurisées.

    • L'attribut EKU (Extended Key Usage) de l'authentification client (1.3.6.1.5.5.7.3.2).

    • L'attribut EKU d'ouverture de session par carte à puce (1.3.6.1.4.1.311.20.2.2).

  • Pour l'authentification pré-session, l'OCSP (Online Certificate Status Protocol) est requis pour vérifier la révocation des certificats. Pour l'authentification en cours de session, l'OCSP est recommandé, mais pas obligatoire.

    Note

    Ubuntu WorkSpaces, Rocky Linux WorkSpaces et Red Hat Enterprise Linux WorkSpaces nécessitent l'OCSP pour l'authentification en session par défaut, et la vérification OCSP dans ces systèmes nécessite que l'extension NONCE soit activée sur le répondeur OCSP pour empêcher les attaques par rediffusion. Pour désactiver l'extension NONCE, la vérification OCSP en session doit être complètement désactivée. Pour désactiver la vérification OCSP dans Ubuntu, Rocky Linux et Red Hat Enterprise Linux WorkSpaces, créez un nouveau fichier /etc/sssd/conf.d/disable-ocsp.conf avec le contenu suivant : 

    [sssd]
certificate_verification = no_ocsp

Limitations

  • Seules l'application cliente WorkSpaces Windows version 3.1.1 ou ultérieure, l'application cliente WorkSpaces macOS version 3.1.5 ou ultérieure et l'application client WorkSpaces Ubuntu 22.04 version 2024.1 ou ultérieure sont actuellement prises en charge pour l'authentification par carte à puce. WorkSpaces L'application cliente Ubuntu 20.04 ou antérieure n'est pas prise en charge pour l'authentification par carte à puce.

  • L'application cliente WorkSpaces Windows 3.1.1 ou version ultérieure prend en charge les cartes à puce uniquement lorsque le client est exécuté sur une version 64 bits de Windows.

  • Seuls les annuaires AD Connector sont aujourd'hui pris en charge pour l'authentification par carte à puce.

  • L'authentification en cours de session est disponible dans toutes les régions où le DCV est pris en charge. L'authentification pré-session est disponible dans les régions suivantes :

    • Région Asie-Pacifique (Sydney)

    • Région Asie-Pacifique (Tokyo)

    • Région Europe (Irlande)

    • AWS GovCloud Région (USA Est)

    • AWS GovCloud Région (USA Ouest)

    • Région USA Est (Virginie du Nord)

    • Région USA Ouest (Oregon)

  • Pour l'authentification en cours de session et l'authentification de présession sous Linux ou Windows WorkSpaces, une seule carte à puce est actuellement autorisée à la fois. L'utilisation simultanée de plusieurs cartes peut fonctionner, mais elle n'est pas prise en charge.

  • Pour l'authentification pré-session, l'activation de l'authentification par carte à puce et de l'authentification par connexion dans le même annuaire n'est actuellement pas prise en charge.

  • Seules les cartes CAC et PIV sont prises en charge pour le moment. D'autres types de cartes à puce matérielles ou logicielles peuvent également fonctionner, mais leur utilisation avec le DCV n'a pas encore été entièrement testée.

Configuration Active Directory

Pour activer l'authentification par carte à puce, vous devez configurer votre annuaire AD Connector et votre annuaire sur site de la façon suivante.

Configuration de l'annuaire AD Connector

Avant de commencer, assurez-vous que l'annuaire AD Connector a été configuré conformément aux instructions de la page Conditions préalables requises pour AD Connector du Guide d'administration AWS Directory Service . En particulier, assurez-vous d'avoir ouvert les ports nécessaires au niveau du pare-feu.

Pour terminer la configuration de votre répertoire AD Connector, suivez les instructions de la page Activer l'authentification mTLS dans AD Connector pour une utilisation avec des cartes à puce dans le Guide d'administration AWS Directory Service .

Note

L'authentification par carte à puce nécessite une délégation Kerberos contrainte (KCD) pour fonctionner correctement. KCD exige que la partie nom d'utilisateur du compte de service AD Connector corresponde au AMAccount nom s du même utilisateur. Un AMAccount nom ne peut pas dépasser 20 caractères.

Configuration d'annuaire sur site

Outre la configuration de votre répertoire AD Connector :

  • Assurez-vous que l'utilisation étendue des clés (EKU) est définie sur les certificats délivrés aux contrôleurs de domaine pour votre annuaire local. Pour ce faire, utilisez le modèle de certificat d'authentification Kerberos par défaut des services de domaine Active Directory (AD DS). N'utilisez pas de modèle de certificat de contrôleur de domaine ni de modèle de certificat d'authentification de contrôleur de domaine, car ces modèles ne contiennent pas les paramètres nécessaires à l'authentification par carte à puce.

  • Pour Linux WorkSpaces, assurez-vous que l'extension NONCE est activée sur le répondeur OCSP de l'autorité de certification délivrant les certificats de carte à puce. Si elle ne peut pas être activée, la vérification OCSP en session devra être désactivée dans Ubuntu, Rocky Linux et Red Hat Enterprise Linux. WorkSpaces Pour désactiver la vérification OCSP, créez un nouveau fichier /etc/sssd/conf.d/disable-ocsp.conf avec le contenu suivant : 

    [sssd]
certificate_verification = no_ocsp

Activer les cartes à puce pour Windows WorkSpaces

Pour obtenir des instructions générales sur la manière d'activer l'authentification par carte à puce dans Windows, consultez Recommandations pour l'activation de l'ouverture de session de carte à puce auprès d'autorités de certification tierces dans la documentation Microsoft.

Pour détecter l'écran de verrouillage Windows et déconnecter la session

Pour permettre aux utilisateurs de déverrouiller WorkSpaces les fenêtres activées pour l'authentification pré-session par carte à puce lorsque l'écran est verrouillé, vous pouvez activer la détection de l'écran de verrouillage Windows dans les sessions des utilisateurs. Lorsque l'écran de verrouillage Windows est détecté, la WorkSpace session est déconnectée et l'utilisateur peut se reconnecter au WorkSpaces client à l'aide de sa carte à puce.

Vous pouvez utiliser les paramètres de stratégie de groupe pour activer la déconnexion de session lorsque l'écran de verrouillage Windows est détecté dans les instances WorkSpaces Windows. Pour plus d'informations, consultez Configurer la session de déconnexion lors du verrouillage de l'écran pour DCV.

Pour activer l'authentification pré-session ou en cours de session

Par défaut, Windows WorkSpaces n'est pas activé pour prendre en charge l'utilisation de cartes à puce pour l'authentification avant ou pendant la session. Si nécessaire, vous pouvez activer l'authentification en session et en présession pour Windows à l'aide des WorkSpaces paramètres de stratégie de groupe. Pour de plus amples informations, veuillez consulter Configurer la redirection par carte à puce pour DCV.

Pour utiliser l'authentification pré-session, outre la mise à jour des paramètres de stratégie de groupe, vous devez également activer l'authentification pré-session via les paramètres de l'annuaire AD Connector. Pour plus d'informations, suivez les instructions de la page Activer l'authentification mTLS dans AD Connector pour une utilisation avec des cartes à puce dans le Guide d'administration AWS Directory Service .

Pour permettre aux utilisateurs d'utiliser des cartes à puce dans un navigateur

Si les utilisateurs se servent de Chrome comme navigateur, aucune configuration particulière n'est requise pour l'emploi des cartes à puce.

S'ils se servent de Firefox comme navigateur, vous pouvez leur permettre d'utiliser des cartes à puce dans Firefox via une stratégie de groupe. Vous pouvez utiliser ces modèles de politique de groupe Firefox dans GitHub.

Par exemple, vous pouvez installer la version 64 bits d'OpenSC pour Windows pour prendre en charge PKCS #11, puis utiliser le paramètre de stratégie de groupe suivant, où NAME_OF_DEVICE représente la valeur souhaitée pour identifier PKCS #11 (comme OpenSC), et PATH_TO_LIBRARY_FOR_DEVICE le chemin d'accès au module PKCS #11. Ce chemin doit pointer vers une bibliothèque avec une extension .DLL, comme C:\Program Files\OpenSC Project\OpenSC\pkcs11\onepin-opensc-pkcs11.dll.

Software\Policies\Mozilla\Firefox\SecurityDevices\NAME_OF_DEVICE = PATH_TO_LIBRARY_FOR_DEVICE
Astuce

Si vous utilisez OpenSC, vous pouvez également charger le module pkcs11 OpenSC dans Firefox en exécutant le programme pkcs11-register.exe. Pour exécuter ce programme, double-cliquez sur le fichier C:\Program Files\OpenSC Project\OpenSC\tools\pkcs11-register.exe, ou ouvrez une fenêtre d'invite de commandes et exécutez la commande suivante :

"C:\Program Files\OpenSC Project\OpenSC\tools\pkcs11-register.exe"

Pour vérifier que le module pkcs11 OpenSC a été chargé dans Firefox, procédez comme suit :

  1. Si Firefox est déjà en cours d'exécution, fermez-le.

  2. Ouvrez Firefox. Cliquez sur le bouton de menu Firefox menu button dans l'angle supérieur droit, puis choisissez Paramètres.

  3. Sur la page about:preferences, dans le volet de navigation de gauche, sélectionnez Vie privée et sécurité.

  4. Sous Certificats, choisissez Périphériques de sécurité.

  5. Dans la boîte de dialogue Gestionnaire de périphériques, le cadre de cartes à puce OpenSC (0.21) doit être disponible dans le volet de navigation de gauche, et afficher les valeurs suivantes quand vous le sélectionnez :

    Module : OpenSC smartcard framework (0.21)

    Chemin : C:\Program Files\OpenSC Project\OpenSC\pkcs11\onepin-opensc-pkcs11.dll

Résolution des problèmes

Pour plus d'informations sur la résolution des problèmes liés aux cartes à puce, consultez Problèmes de certificat et de configuration dans la documentation Microsoft.

Voici quelques exemples de problèmes courants :

  • Mappage incorrect des emplacements aux certificats

  • Plusieurs certificats sur la carte à puce qui peuvent correspondre à l'utilisateur Les certificats sont mis en correspondance selon les critères suivants :

    • Autorité de certification racine du certificat

    • Champs <KU> et <EKU> du certificat

    • UPN dans l'objet du certificat

  • Plusieurs certificats avec <EKU>msScLogin dans l'utilisation de la clé

Pour l'authentification par carte à puce, il est en général préférable de n'avoir qu'un seul certificat, mappé au tout premier emplacement de la carte.

Les outils de gestion des certificats et des clés de carte à puce (comme la suppression ou le remappage des certificats et des clés) peuvent être spécifiques au fabricant. Pour plus d'informations, consultez la documentation du fabricant de la carte à puce.

Activez les cartes à puce pour Ubuntu, Rocky Linux et Red Hat Enterprise Linux WorkSpaces

Pour permettre l'utilisation de cartes à puce sur Ubuntu, Rocky Linux et Red Hat Enterprise Linux WorkSpaces, vous devez inclure le certificat racine et tous les certificats CA intermédiaires dans l' WorkSpace image pour toutes les cartes à puce CAs émettrices et pour toutes les CAs émissions de certificats de contrôleur de domaine.

Pour obtenir votre certificat CA : Vous pouvez obtenir votre certificat CA de plusieurs manières :

  • Vous pouvez utiliser un ensemble de certificats CA provenant d'une autorité de certification tierce.

  • Vous pouvez exporter votre propre certificat CA à l'aide du site Web d'inscription, qui contient http://ip_address/certsrv soit http://fqdn/certsrv l'adresse IP ip_address et le nom de domaine complet (FQDN) du serveur CA, soit où se fqdn trouvent. Pour plus d'informations sur l'utilisation du site d'inscription Web, consultez Comment exporter un certificat d'autorité de certification racine dans la documentation Microsoft.

  • Vous pouvez utiliser la procédure suivante pour exporter le certificat CA depuis un serveur CA qui exécute les services de certificats Active Directory (AD CS). Pour plus d'informations sur l'installation d'AD CS, consultez Installer l'autorité de certification dans la documentation Microsoft.

    1. Connectez-vous au serveur CA à l'aide d'un compte administrateur.

    2. Dans le menu Démarrer Windows, ouvrez une fenêtre d'invite de commandes (Démarrer > Système Windows > Invite de commandes).

    3. Utilisez la commande suivante pour exporter le certificat CA vers un nouveau fichier, où rootca.cer figure le nom du nouveau fichier :

      certutil -ca.cert rootca.cer

      Pour plus d'informations sur l'exécution de certutil, consultez la page certutil dans la documentation Microsoft.

    4. Utilisez la commande OpenSSL suivante pour convertir le certificat CA exporté du format DER au format PEM, rootca où est le nom du certificat. Pour plus d'informations sur OpenSSL, consultez le site http://www.openssl.org/.

      openssl x509 -inform der -in rootca.cer -out /tmp/rootca.pem
Pour ajouter vos certificats CA à votre système Linux WorkSpaces

Pour vous aider à activer les cartes à puce, nous avons ajouté le enable_smartcard script à nos packs Linux WorkSpaces DCV. Ce script effectue les actions suivantes :

  • Importe vos certificats CA dans un bundle PEM privé qui définit la racine de confiance pour SSSD (sous Linux WorkSpaces).

  • Met à jour la configuration SSSD, PAM et Kerberos, qui inclut l'activation PKINIT (authentification Kerberos à l'aide d'un certificat au lieu d'un mot de passe) lors du provisionnement. WorkSpace

La procédure suivante explique comment utiliser le enable_smartcard script pour importer vos certificats CA et activer l'authentification par carte à puce pour votre système Linux WorkSpaces.

  1. Créez un nouveau Linux WorkSpace avec le protocole DCV activé. Lorsque vous lancez le WorkSpace dans la WorkSpaces console Amazon, sur la page Select Bundles, assurez-vous de sélectionner DCV pour le protocole, puis sélectionnez l'un des bundles WorkSpaces publics Linux.

  2. Sur le /etc/skylight.conf fichier nouvellement créé WorkSpace, assurez-vous qu'il y a une pam_smartcard = true ligne dans [features] la section : 

    [features]
pam_smartcard = true
    Note

    Si tous vos utilisateurs ne sont pas encore configurés pour utiliser altSecurityIdentities un mappage de certificats renforcé, vous pouvez également ajouter une smartcard_weak_mapping = true ligne dans la même [features] section /etc/skylight.conf pour prendre en charge les anciennes méthodes de mappage, mais nous vous recommandons de migrer ces utilisateurs pour utiliser des méthodes de mappage robustes dès que possible.

  3. Sur le WorkSpace, exécutez la commande suivante en tant qu'utilisateur rootpem-path1, où se trouventpem-path2, etc., les chemins d'accès aux fichiers, chacun contenant l'un des certificats CA de la chaîne de confiance pour les certificats de carte à puce et de contrôleur de domaine. Tous ces fichiers doivent être au format PEM et contenir un certificat par fichier. Des modèles globulaires peuvent être utilisés (par exemple,*.pem)

    /usr/lib/skylight/enable_smartcard --ca-cert pem-path1 pem-path2 pem-path3 ...
    Note

    Assurez-vous que des packages de dépendance supplémentaires sont installés sur le WorkSpace avant d'exécuter la commande ci-dessus, en utilisant les commandes suivantes en tant qu'utilisateur root.

    Pour Rocky Linux et Red Hat Enterprise Linux WorkSpaces : 

    dnf install sssd-dbus libsss_simpleifp sssd-tools krb5-pkinit opensc

    Pour Ubuntu WorkSpaces : 

    apt install krb5-pkinit opensc

  4. Effectuez toute personnalisation supplémentaire sur le WorkSpace. Par exemple, vous souhaiterez peut-être ajouter une politique à l'échelle du système pour permettre aux utilisateurs d'utiliser des cartes à puce dans Firefox. (Les utilisateurs de Chrome doivent activer eux-mêmes les cartes à puce sur leurs clients. Pour plus d'informations, consultez la section Support des cartes à puce dans le guide de WorkSpaces l'utilisateur Amazon.)

  5. Créez une WorkSpace image personnalisée et un bundle à partir du WorkSpace.

  6. Utilisez le nouveau pack personnalisé WorkSpaces pour le lancer pour vos utilisateurs.

Vous pouvez autoriser vos utilisateurs à utiliser des cartes à puce dans Firefox en ajoutant une SecurityDevices politique à votre WorkSpace image Linux. Pour plus d'informations sur l'ajout de politiques à l'échelle du système à Firefox, consultez les modèles de politiques de Mozilla sur GitHub.

Pour permettre aux utilisateurs d'utiliser des cartes à puce dans Firefox

  1. Sur le fichier WorkSpace que vous utilisez pour créer votre WorkSpace image, créez un nouveau fichier nommé policies.json inPREFIX/firefox/distribution/, qui se PREFIX trouve /usr/lib64 sur les systèmes basés sur Fedora (Amazon Linux 2, Red Hat Enterprise Linux et Rocky Linux WorkSpaces) et sur les systèmes basés /usr/lib sur Debian (Ubuntu). WorkSpaces

  2. Dans le fichier JSON, ajoutez la SecurityDevices politique suivante, où se NAME_OF_DEVICE trouve la valeur que vous souhaitez utiliser pour identifier le pkcs module. Par exemple, il se peut que vous souhaitiez utiliser une valeur comme "OpenSC" :

    {
    "policies": {
        "SecurityDevices": {
            "NAME_OF_DEVICE": "PREFIX/opensc-pkcs11.so"
        }
    }
}
Résolution des problèmes

Le dépannage de l'authentification par carte à puce est facilité lorsque la pré-session est configurée pour utiliser l'authentification par mot de passe. Pendant le provisionnement des sessions, Linux fait WorkSpaces automatiquement passer le mode d'authentification sur l'hôte à un mode basé sur un mot de passe ou à un mode basé sur une carte à puce en fonction de la méthode d'authentification de présession utilisée. En cas de problème d'authentification par carte à puce, la déconnexion et la reconnexion à l'aide de l'authentification de présession par mot de passe réinitialisent l'espace de travail à l'authentification par mot de passe sur l'hôte. Pour passer manuellement de l' WorkSpaces instance Linux à l'authentification par carte à puce, exécutez /usr/lib/skylight/resume_smartcard la commande en tant qu'utilisateur root.

Linux WorkSpaces utilise le logiciel OpenSC pour travailler avec des cartes à puce. Ce logiciel est livré avec des outils tels que pkcs11-tool et pkcs15-tool qui peuvent être utiles pour résoudre les problèmes liés aux cartes à puce. Ces outils peuvent être utilisés pour inspecter les lecteurs de cartes à puce, les jetons individuels et les emplacements ou certificats PIV sur chaque jeton de carte à puce.

Un outil de openssl ligne de commande peut être utile pour résoudre les problèmes liés aux chaînes de confiance, aux répondeurs OCSP ou aux indicateurs manquants KUs/EKUs (utilisation des usage/extended clés), en particulier lorsqu'ils sont associés pkcs15-tool à la capacité d'extraire des certificats publics d'une carte à puce.

Options de dépannage courantes :

  • Extrayez le premier certificat (généralement le slot PIV 9A) de la carte à puce et enregistrez-le sous le nom suivant : card-cert.pem pkcs15-tool --read-certificate 1 > card-cert.pem

  • Validez le certificat extrait par rapport à la base de données de confiance sur WorkSpace : openssl verify -verbose -CAfile /etc/sssd/pki/sssd_auth_ca_db.pem -cert card-cert.pem

  • Obtenez l'URL OCSP à partir du certificat de carte à puce extrait : openssl x509 -noout -ocsp_uri -in card-cert.pem

  • Vérifiez que la réponse OCSP indique que le certificat est valide et inclut NONCE :openssl ocsp -issuer /etc/sssd/pki/sssd_auth_ca_db.pem -CAfile /etc/sssd/pki/sssd_auth_ca_db.pem -cert card-cert.pem -text -url OCSP_URI, où se OCSP_URI trouve l'URL OCSP ci-dessus.

  • Vérifiez si le certificat du contrôleur de domaine est considéré comme fiable :openssl s_client -connect DC_HOSTNAME:636 -showcerts | openssl verify -verbose -CAfile /etc/sssd/pki/sssd_auth_ca_db.pem, où DC_HOSTNAME est le nom d'hôte de l'un des contrôleurs de domaine de votre domaine Active Directory.

  • Vérifiez que le certificat du contrôleur de domaine a défini l'EKU d'authentification KDC (utilisation étendue des clés) :. openssl s_client -connect DC_HOSTNAME:636 -showcerts | openssl x509 -noout -text

  • Essayez le PKINIT manuel pour voir s'il existe des codes d'erreur susceptibles d'être utilisés pour affiner le problème : KRB5_TRACE=/dev/stdout kinit -X X509_user_identity=PKCS11:opensc-pkcs11.so:certid=01 -V où 01 est le numéro de l'un des quatre emplacements PIV principaux de la carte : 01 pour9A, 02 pour, etc. 9C La plupart des cartes comportent un certificat destiné à l'authentification de l'utilisateur dans l'emplacement 9A.

  • Vérifiez si le système est capable de mapper le certificat de carte à puce à un utilisateur AD (exécuter en tant que root) :dbus-send --print-reply --system --dest=org.freedesktop.sssd.infopipe /org/freedesktop/sssd/infopipe/Users org.freedesktop.sssd.infopipe.Users.FindByCertificate string:"$(<card-cert.pem)". Cela peut être combiné avec l'activation de la journalisation du débogage pour SSSD.

Les problèmes connus les plus courants sont les suivants :

  • Chaîne de confiance incomplète pour le certificat de carte à puce : lors de l'importation de certificats à l'aide d'un enable_smartcard script, la liste complète de tous les certificats d'autorité de certification racine et intermédiaire doit être fournie. L'enable_smartcardoutil affiche une erreur si tous les certificats importés ne sont pas fiables parce qu'ils ne figurent pas dans la liste des certificats d'autorité de certification racine, mais il ne peut pas détecter l'absence d'une chaîne de confiance complète ou du certificat d'autorité de certification intermédiaire le plus interne de l'une des chaînes de confiance. Dans ce cas, il importera les certificats sans erreur, mais un certificat de carte à puce ou un certificat de contrôleur de domaine peuvent toujours être considérés comme non fiables.

  • Chaîne de confiance manquante pour les certificats de contrôleur de domaine : si les certificats de contrôleur de domaine sont émis par une autorité de certification différente de celle des cartes à puce (par exemple, dans le cas d'une carte d'accès commune (CAC)), cette chaîne de confiance doit être importée avec la carte à puce émettrice des certificats d'autorité de certification.

  • Absence de prise en charge de l'extension NONCE dans le répondeur OCSP - Linux WorkSpaces exige que l'extension NONCE soit activée sur le répondeur OCSP de l'émetteur de la carte à puce. Si elle ne peut pas être activée, la validation OCSP devra être complètement désactivée.

  • Les certificats de contrôleur de domaine sont absents (OID 1.3.6.1.5.2.3.1). Pour que l'authentification par carte à puce fonctionne, les certificats de contrôleur de domaine doivent être réémis pour inclure l'KDC AuthenticationEKU d'authentification KDC.

  • Les certificats de contrôleur de domaine ont expiré. Pour que l'authentification par carte à puce fonctionne, les certificats de contrôleur de domaine doivent être conservés up-to-date.

  • Les certificats de carte à puce sont mappés aux utilisateurs dans AD à l'aide de méthodes de mappage faibles. Traditionnellement, le champ UPN dans subjectAltName l'attribut était utilisé pour mapper un certificat à un utilisateur dans AD, étant censé correspondre userPrincipalName à l'attribut. Cette méthode n'est plus considérée comme une méthode de mappage sécurisée et est interdite par défaut. Il est possible de le réactiver en passant un --allow-weak-mapping argument à la enable_smartcard commande et en ajoutant une smartcard_weak_mapping = true ligne à la [features] section du /etc/skylight.conf fichier, mais une meilleure solution consiste à utiliser l'une des méthodes de mappage les plus puissantes. Consultez la documentation relative à l'association de comptes pour plus de détails.

Les outils de gestion des certificats et des clés de carte à puce (comme la suppression ou le remappage des certificats et des clés) peuvent être spécifiques au fabricant. Voici des outils supplémentaires que vous pouvez utiliser pour travailler avec des cartes à puce :

  • opensc-explorer

  • opensc-tool

  • pkcs11_inspect

  • pkcs11_listcerts

  • pkcs15-tool

Pour activer la journalisation du débogage

  • Ajoutez une debug_level = LEVEL ligne /etc/sssd/sssd.conf pour chaque section individuelle, où se LEVEL situe le niveau de verbosité souhaité, de 1 à 10. Les journaux de chaque section correspondante peuvent ensuite être trouvés dans le /var/log/sssd/ répertoire. Consultez la documentation SSSD ici et ici pour plus de détails.

Activer les cartes à puce pour Amazon Linux 2 WorkSpaces

Note

Amazon Linux 2 WorkSpaces sur DCV présente actuellement les limites suivantes :

  • La redirection du presse-papiers, d'entrée audio, d'entrée vidéo et de fuseau horaire n'est pas prise en charge.

  • L'utilisation de plusieurs moniteurs n'est pas prise en charge.

Pour permettre l'utilisation de cartes à puce sur Amazon Linux 2 WorkSpaces, vous devez inclure un fichier de certificat CA racine au format PEM dans l' WorkSpace image.

Pour obtenir votre certificat d'autorité de certification racine : vous pouvez obtenir votre certificat d'autorité de certification racine de plusieurs manières :

  • Vous pouvez utiliser un certificat de CA racine géré par une autorité de certification tierce.

  • Vous pouvez exporter votre propre certificat de CA racine via le site Web d'inscription, qui est http://ip_address/certsrv ou http://fqdn/certsrv, où ip_address et fqdn représentent l'adresse IP et le nom de domaine complet (FQDN) du serveur de certification de la CA racine. Pour plus d'informations sur l'utilisation du site d'inscription Web, consultez Comment exporter un certificat d'autorité de certification racine dans la documentation Microsoft.

  • Vous pouvez utiliser la procédure suivante pour exporter le certificat de CA racine depuis un serveur de certification de CA racine qui exécute les services de certificats Active Directory (AD CS). Pour plus d'informations sur l'installation d'AD CS, consultez Installer l'autorité de certification dans la documentation Microsoft.

    1. Connectez-vous au serveur de CA racine via un compte administrateur.

    2. Dans le menu Démarrer Windows, ouvrez une fenêtre d'invite de commandes (Démarrer > Système Windows > Invite de commandes).

    3. Utilisez la commande suivante pour exporter le certificat de CA racine vers un nouveau fichier, où rootca.cer est le nom du nouveau fichier :

      certutil -ca.cert rootca.cer

      Pour plus d'informations sur l'exécution de certutil, consultez la page certutil dans la documentation Microsoft.

    4. Utilisez la commande OpenSSL suivante pour convertir le certificat CA racine exporté du format DER au format PEM, rootca où est le nom du certificat. Pour plus d'informations sur OpenSSL, consultez le site http://www.openssl.org/.

      openssl x509 -inform der -in rootca.cer -out /tmp/rootca.pem
Pour ajouter votre certificat CA racine à votre Amazon Linux 2 WorkSpaces

Pour vous aider à activer les cartes à puce, nous avons ajouté le enable_smartcard script à nos offres Amazon Linux DCV. Ce script effectue les actions suivantes :

  • Importation du certificat CA racine dans la base de données des services de sécurité réseau (NSS).

  • Installation du module pam_pkcs11 pour l'authentification PAM (Pluggable Authentication Module).

  • Exécute une configuration par défaut, qui inclut l'activation pkinit lors du WorkSpace provisionnement.

La procédure suivante explique comment utiliser le enable_smartcard script pour ajouter votre certificat CA racine à votre Amazon Linux 2 WorkSpaces et pour activer les cartes à puce pour votre Amazon Linux 2 WorkSpaces.

  1. Créez un nouvel Amazon Linux 2 WorkSpace avec le protocole DCV activé. Lorsque vous lancez le WorkSpace dans la WorkSpaces console Amazon, sur la page Select Bundles, assurez-vous de sélectionner DCV pour le protocole, puis sélectionnez l'un des bundles publics Amazon Linux 2.

  2. Sur le nouveau WorkSpace, exécutez la commande suivante en tant qu'utilisateur root, où se pem-path trouve le chemin d'accès au fichier de certificat de l'autorité de certification racine au format PEM.

    /usr/lib/skylight/enable_smartcard --ca-cert pem-path
    Note

    Amazon Linux 2 part du WorkSpaces principe que les certificats figurant sur les cartes à puce sont émis pour le nom d'utilisateur principal (UPN) par défaut de l'utilisateur, par exemplesAMAccountName@domain, où se domain trouve un nom de domaine complet (FQDN).

    Pour utiliser d'autres suffixes UPN, run /usr/lib/skylight/enable_smartcard --help pour plus d'informations. Le mappage d'autres suffixes UPN est propre à chaque utilisateur. Par conséquent, ce mappage doit être effectué individuellement sur celui de chaque utilisateur WorkSpace.

  3. (Facultatif) Par défaut, tous les services sont activés pour utiliser l'authentification par carte à puce sur Amazon Linux 2 WorkSpaces. Pour limiter l'authentification par carte à puce uniquement à des services spécifiques, vous devez modifier /etc/pam.d/system-auth. Supprimer la mise en commentaire de la ligne auth pour pam_succeed_if.so, et modifiez la liste des services selon les besoins.

    Une fois la mise en commentaire supprimée pour la ligne auth, vous devez ajouter à la liste le service pour lequel vous souhaitez autoriser l'authentification par carte à puce. Pour qu'un service utilise uniquement l'authentification par mot de passe, vous devez le supprimer de la liste.

  4. Procédez à toute personnalisation supplémentaire du WorkSpace. Par exemple, vous souhaiterez peut-être ajouter une politique à l'échelle du système pour permettre aux utilisateurs d'utiliser des cartes à puce dans Firefox. (Les utilisateurs de Chrome doivent activer eux-mêmes les cartes à puce sur leurs clients. Pour plus d'informations, consultez la section Support des cartes à puce dans le guide de WorkSpaces l'utilisateur Amazon.)

  5. Créez une WorkSpace image personnalisée et un bundle à partir du WorkSpace.

  6. Utilisez le nouveau pack personnalisé WorkSpaces pour le lancer pour vos utilisateurs.

Vous pouvez autoriser vos utilisateurs à utiliser des cartes à puce dans Firefox en ajoutant une SecurityDevices politique à votre WorkSpace image Amazon Linux 2. Pour plus d'informations sur l'ajout de politiques à l'échelle du système à Firefox, consultez les modèles de politiques de Mozilla sur GitHub.

Pour permettre aux utilisateurs d'utiliser des cartes à puce dans Firefox

  1. Sur le fichier WorkSpace que vous utilisez pour créer votre WorkSpace image, créez un nouveau fichier nommé policies.json dans/usr/lib64/firefox/distribution/.

  2. Dans le fichier JSON, ajoutez la SecurityDevices politique suivante, où se NAME_OF_DEVICE trouve la valeur que vous souhaitez utiliser pour identifier le pkcs module. Par exemple, il se peut que vous souhaitiez utiliser une valeur comme "OpenSC" :

    {
    "policies": {
        "SecurityDevices": {
            "NAME_OF_DEVICE": "/usr/lib64/opensc-pkcs11.so"
        }
    }
}

Résolution des problèmes : pour résoudre les problèmes, nous vous recommandons d'ajouter l'pkcs11-toolsutilitaire. Il vous permet d'effectuer les actions suivantes :

  • Répertorier chaque carte à puce

  • Répertorier les emplacements de chaque carte à puce

  • Répertorier les certificats sur chaque carte à puce

Voici quelques exemples de problèmes courants :

  • Mappage incorrect des emplacements aux certificats

  • Plusieurs certificats sur la carte à puce qui peuvent correspondre à l'utilisateur Les certificats sont mis en correspondance selon les critères suivants :

    • Autorité de certification racine du certificat

    • Champs <KU> et <EKU> du certificat

    • UPN dans l'objet du certificat

  • Plusieurs certificats avec <EKU>msScLogin dans l'utilisation de la clé

Pour l'authentification par carte à puce, il est en général préférable de n'avoir qu'un seul certificat, mappé au tout premier emplacement de la carte.

Les outils de gestion des certificats et des clés de carte à puce (comme la suppression ou le remappage des certificats et des clés) peuvent être spécifiques au fabricant. Voici des outils supplémentaires que vous pouvez utiliser pour travailler avec des cartes à puce :

  • opensc-explorer

  • opensc-tool

  • pkcs11_inspect

  • pkcs11_listcerts

  • pkcs15-tool

Pour activer la journalisation du débogage

Pour résoudre les problèmes liés à la configuration de pam_pkcs11 et pam-krb5, vous pouvez activer la journalisation du débogage.

  1. Dans le fichier /etc/pam.d/system-auth-ac, modifiez l'action auth et faites passer le paramètre nodebug de pam_pksc11.so à debug.

  2. Dans le fichier /etc/pam_pkcs11/pam_pkcs11.conf, remplacez debug = false; par debug = true;. L'option debug s'applique séparément à chaque module de mappeur, vous devrez donc peut-être la modifier à la fois sous la section pam_pkcs11 directement, et aussi sous la section de mappeur appropriée (par défaut, ceci est mapper generic).

  3. Dans le fichier /etc/pam.d/system-auth-ac, modifiez l'action auth et ajoutez le paramètre debug ou debug_sensitive à pam_krb5.so.

Une fois que vous avez activé la journalisation du débogage, le système imprime les messages de débogage pam_pkcs11 directement dans le terminal actif. Les messages de pam_krb5 sont consignés dans /var/log/secure.

Pour vérifier à quel nom d'utilisateur correspond un certificat de carte à puce, utilisez la commande pklogin_finder suivante :

sudo pklogin_finder debug config_file=/etc/pam_pkcs11/pam_pkcs11.conf

Lorsque vous y êtes invité, saisissez le code PIN de la carte à puce. pklogin_finder sort sur stdout le nom d'utilisateur figurant sur le certificat de carte à puce sous la forme NETBIOS\username. Ce nom d'utilisateur doit correspondre au WorkSpace nom d'utilisateur.

Dans les services de domaine Active Directory (AD DS), le nom de domaine NetBIOS est le nom de domaine antérieur à Windows 2000. Généralement (mais pas toujours), le nom de domaine NetBIOS est le sous-domaine du nom de domaine DNS (Domain Name System). Par exemple, si le nom de domaine DNS est example.com, le domaine NetBIOS est généralement EXAMPLE. Si le nom de domaine DNS est corp.example.com, le domaine NetBIOS est généralement CORP.

Par exemple, pour l'utilisateur mmajor du domaine corp.example.com, le résultat de pklogin_finder est CORP\mmajor.

Note

Si vous recevez le message "ERROR:pam_pkcs11.c:504: verify_certificate() failed", ceci indique que pam_pkcs11 a trouvé sur la carte à puce un certificat qui correspond aux critères du nom d'utilisateur, mais qui n'est pas lié à un certificat de CA racine reconnu par la machine. Lorsque cela se produit, pam_pkcs11 génère le message ci-dessus, puis essaie le certificat suivant. L'authentification n'est autorisée que si un certificat correspondant au nom d'utilisateur et lié à un certificat de CA racine reconnue est trouvé.

Pour résoudre les problèmes de configuration pam_krb5, vous pouvez invoquer manuellement kinit en mode débogage à l'aide de la commande suivante :

KRB5_TRACE=/dev/stdout kinit -V

Cette commande devrait réussir à obtenir un ticket d'octroi de tickets (TGT) Kerberos. En cas d'échec, essayez d'ajouter explicitement le nom principal Kerberos approprié à la commande. Par exemple, pour l'utilisateur mmajor du domaine corp.example.com, utilisez cette commande : 

KRB5_TRACE=/dev/stdout kinit -V mmajor

Si cette commande aboutit, le problème provient probablement du mappage entre le WorkSpace nom d'utilisateur et le nom principal Kerberos. Consultez la section [appdefaults]/pam/mappings du fichier /etc/krb5.conf.

Si cette commande échoue, mais qu'une commande kinit basée sur un mot de passe réussit, vérifiez les configurations associées à pkinit_ dans le fichier /etc/krb5.conf. Par exemple, si la carte à puce contient plusieurs certificats, vous devrez peut-être modifier pkinit_cert_match.