Exigences Limitations Configuration Active Directory Activer les cartes à puce pour Windows WorkSpaces Activer les cartes à puce pour Linux WorkSpaces Activer les cartes à puce pour Amazon Linux 2 WorkSpaces (obsolète)

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

Les offres groupées Windows et Linux WorkSpaces sur DCV permettent l'utilisation de cartes à puce Common Access Card (CAC) et de Personal Identity Verification (PIV) pour l'authentification.

Amazon WorkSpaces prend en charge l'utilisation de cartes à puce à la fois pour l'authentification de pré-session et pour l'authentification de session. Pre-session l'authentification fait référence à l'authentification par carte à puce qui est effectuée lorsque les utilisateurs se connectent à leur WorkSpaces. In-session l'authentification 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 des sudo -i commandes.

Table des matières

Exigences
Limitations
Configuration Active Directory
Activer les cartes à puce pour Windows WorkSpaces
Activer les cartes à puce pour Linux WorkSpaces
Activer les cartes à puce pour Amazon Linux 2 WorkSpaces (obsolète)

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 avec 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 :
- L'utilisateur de l'utilisateur AD PrincipalName (UPN) dans le champ objet AltName (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 mappage entre le certificat et l'utilisateur. 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 sur 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 cliente 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 une version 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 s'exécute sur une version 64 bits de Windows.
Seuls les annuaires AD Connector sont aujourd'hui pris en charge pour l'authentification par carte à puce.
In-session l'authentification est disponible dans toutes les régions où le DCV est pris en charge. Pre-session l'authentification est disponible dans les régions suivantes :
- Région Asie-Pacifique (Sydney)
- Région Asie-Pacifique (Tokyo)
- Région Europe (Irlande)
- AWS GovCloud (US-East) Région
- AWS GovCloud (US-West) Région
- Région USA Est (Virginie du Nord)
- Région USA Ouest (Oregon)
Pour l'authentification en cours de session et l'authentification avant 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 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 é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 s AMAccountName du même utilisateur. Un s ne AMAccountName peut pas dépasser 20 caractères.

On-premises configuration du répertoire

Outre la configuration de votre répertoire AD Connector :

Assurez-vous que l'utilisation étendue des clés (EKU) « Authentification KDC » est définie sur les certificats émis 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 émettrice des 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 les fenêtres WorkSpaces qui sont activées pour l'authentification de 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 de Windows est détecté, la WorkSpace session est déconnectée et l'utilisateur peut se reconnecter depuis le 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 pendant et avant la session pour Windows à l'aide des paramètres WorkSpaces de stratégie de groupe. Pour plus d’informations, consultez 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 stratégie 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 :

Si Firefox est déjà en cours d'exécution, fermez-le.
Ouvrez Firefox. Cliquez sur le bouton de menu dans l'angle supérieur droit, puis choisissez Paramètres.
Sur la page about:preferences, dans le volet de navigation de gauche, sélectionnez Vie privée et sécurité.
Sous Certificats, choisissez Périphériques de sécurité.
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.

Activer les cartes à puce pour Linux WorkSpaces

Tous les systèmes Linux WorkSpaces utilisent SSSD pour l'intégration d'Active Directory et partagent la même implémentation d'authentification par carte à puce basée sur PKINIT et OpenSC.

Pour activer l'utilisation de cartes à puce sous Linux WorkSpaces, vous devez inclure la racine et tous les certificats d'autorité de certification intermédiaires dans l' WorkSpace image pour toutes les autorités de certification émettant des cartes à puce et pour toutes les autorités de certification émettant des 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 d'une autorité de certification tierce.
Vous pouvez exporter votre propre certificat CA en utilisant le site Web d'inscription, qui http://ip_address/certsrv contient http://fqdn/certsrv soit l'adresse IP et le nom de domaine complet (FQDN) du serveur CA. ip_address fqdn 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ù se rootca.cer trouve 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, où se rootca trouve 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 offres 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, notamment 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.

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.
Sur le fichier nouvellement créé WorkSpace, assurez-vous que /etc/skylight.conf le fichier contient 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 vers des méthodes de mappage renforcées dès que possible.
Sur le WorkSpace, exécutez la commande suivante en tant qu'utilisateur root, où pem-path1pem-path2, etc., se trouvent 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 motifs 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épendances supplémentaires sont installés sur le WorkSpace avant d'exécuter la commande ci-dessus, en utilisant les commandes suivantes en tant que 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
```
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 Prise en charge des cartes à puce dans le Guide de WorkSpaces l'utilisateur Amazon.)
Créez une WorkSpace image et un bundle personnalisés à partir du WorkSpace.
Utilisez le nouveau pack personnalisé à lancer WorkSpaces 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

Sur celui WorkSpace que vous utilisez pour créer votre WorkSpace image, créez un nouveau fichier nommé policies.json inPREFIX/firefox/distribution/, where PREFIX is /usr/lib64 on Fedora-based systems (Amazon Linux 2, Red Hat Enterprise Linux et Rocky Linux WorkSpaces) et /usr/lib on Debian-based systems (Ubuntu WorkSpaces).
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 plus facile lorsque la pré-session est configurée pour utiliser l'authentification par mot de passe. Pendant le provisionnement de la session, Linux bascule WorkSpaces automatiquement la préférence du mode d'authentification de l'hôte sur le mode par mot de passe ou par 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 d'une 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 PIV ou les certificats sur chaque jeton de carte à puce.

Un outil en 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 touches), en particulier en combinaison avec pkcs15-tool la capacité à extraire des certificats publics d'une carte à puce.

Options de dépannage courantes :

Extrayez le premier certificat (généralement l'emplacement PIV 9A) de la carte à puce et enregistrez-le sous le nom : 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 de 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'authentification KDC EKU (utilisation étendue des clés) :. openssl s_client -connect DC_HOSTNAME:636 -showcerts | openssl x509 -noout -text
Essayez manuellement PKINIT pour voir s'il existe des codes d'erreur qui peuvent ê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ù se 01 trouve le numéro de l'un des quatre emplacements PIV principaux de la carte - 01 pour9A, 02 pour, etc. 9C La plupart des cartes seront dotées d'un certificat destiné à l'authentification des utilisateurs dans l'emplacement 9A.
Vérifiez si le système est capable de mapper un certificat de carte à puce à un utilisateur AD (exécutez 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é à 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 CA racine et intermédiaire doit être fournie. L'enable_smartcardoutil affiche une erreur si tous les certificats importés ne sont pas approuvés parce qu'il manque un certificat CA racine dans la liste, mais il ne peut pas détecter si une chaîne de confiance complète ou le certificat CA intermédiaire le plus interne de l'une des chaînes de confiance est absent. Dans ce cas, les certificats seront importés 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 qui émet les certificats CA.
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 manquants KDC Authentication EKU (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'authentification KDC EKU.
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 rester à jour.
Les certificats de cartes à puce sont mappés aux utilisateurs dans AD à l'aide de méthodes de mappage faibles. Traditionnellement, le champ UPN de AltName l'attribut sujet était utilisé pour mapper un certificat à un utilisateur dans AD, étant censé correspondre à l'attribut de l'utilisateurPrincipalName . Cette méthode n'est plus considérée comme une méthode de mappage sécurisée et n'est pas autorisée 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 efficaces. 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 trouve le niveau de verbosité souhaité, de 1 à 10. Les journaux de chaque section correspondante se trouvent alors dans le /var/log/sssd/ répertoire. Pour plus de détails, consultez la section Résolution des problèmes SSSD et journaux de débogage SSSD dans la documentation SSSD.

Activer les cartes à puce pour Amazon Linux 2 WorkSpaces (obsolète)

Important

Amazon Linux 2 arrivera en fin de vie le 30 juin 2026. Cette section s'applique uniquement à l'ancienne version d'Amazon Linux 2 WorkSpaces. Pour la version actuelle de Linux WorkSpaces, consultezActiver les cartes à puce pour Linux 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 activer 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 CA racine : Vous pouvez obtenir votre certificat CA 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, où se rootca trouve 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.

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.
Sur le nouveau WorkSpace, exécutez la commande suivante en tant qu'utilisateur root, où se pem-path trouve le chemin vers le fichier de certificat CA racine au format PEM.
```
/usr/lib/skylight/enable_smartcard --ca-cert pem-path
```
Note
Amazon Linux 2 part du WorkSpaces principe que les certificats des 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 pour chaque utilisateur WorkSpace.
(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.
Effectuez toutes les personnalisations supplémentaires 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 Prise en charge des cartes à puce dans le Guide de WorkSpaces l'utilisateur Amazon.)
Créez une WorkSpace image et un bundle personnalisés à partir du WorkSpace.
Utilisez le nouveau pack personnalisé à lancer WorkSpaces 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

Sur celui WorkSpace que vous utilisez pour créer votre WorkSpace image, créez un nouveau fichier nommé policies.json dans/usr/lib64/firefox/distribution/.
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.

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.

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.
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).
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 est probablement lié au 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.

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Accès à Microsoft Entra ID

Accès Internet