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
DCVLes offres groupées Windows et Linux WorkSpaces autorisent l'utilisation de cartes à puce Common Access Card (CAC)
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.
Table des matières
Prérequis
-
Un annuaire Connecteur Active Directory (AD Connector) est requis pour l'authentification pré-session. AD Connector utilise l'authentification mutuelle basée sur des certificats pour authentifier les utilisateurs auprès d'Active Directory à l'aide d'un certificat de carte à puce matériel ou logiciel. TLS 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 ou le client WorkSpaces macOS version 3.1.5 ou ultérieure. 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 TLS l'authentification m dans AD Connector pour une utilisation avec des cartes à puce dans le Guide d'AWS Directory Service administration et Exigences relatives aux certificats
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 par défaut pour l'utilisateurUPN.
-
L'attribut Extended Key Usage () de l'authentification du client (1.3.6.1.5.5.7.3.2). EKU
-
L'attribut Smart Card Logon (1.3.6.1.4.1.311.20.2.2). EKU
-
-
Pour l'authentification préalable à la session, le protocole d'état des certificats en ligne (OCSP) est requis pour vérifier la révocation des certificats. Pour l'authentification en cours de session, OCSP c'est recommandé, mais pas obligatoire.
Limites
-
Seules l'application cliente WorkSpaces Windows version 3.1.1 ou ultérieure et l'application cliente macOS version 3.1.5 ou ultérieure sont actuellement prises 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.
-
Ubuntu WorkSpaces ne prend actuellement pas en charge l'authentification par carte à puce.
-
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ù elle DCV est prise 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 (US-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.
-
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.
-
Seulement CAC et les PIV cartes sont prises en charge pour le moment. D'autres types de cartes à puce matérielles ou logicielles peuvent également fonctionner, mais leur utilisation n'a pas encore été entièrement testée. DCV
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 section Activer TLS l'authentification m dans AD Connector pour une utilisation avec des cartes à puce dans le Guide d'AWS Directory Service administration.
Note
L'authentification par carte à puce nécessite Kerberos Constrained Delegation (KCD) pour fonctionner correctement. KCDexige que la partie nom d'utilisateur du compte de service AD Connector corresponde au sAMAccount nom du même utilisateur. Un sAMAccount nom ne peut pas dépasser 20 caractères.
Configuration d'annuaire sur site
Outre la configuration de votre annuaire AD Connector, vous devez également vous assurer que l'utilisation de la clé étendue « KDC Authentication » (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.
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
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 Activer ou désactiver 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 Activer ou désactiver 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 section Activer TLS l'authentification m dans AD Connector pour une utilisation dans les cartes à puce du Guide d'AWS Directory Service administration.
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
Par exemple, vous pouvez installer la version 64 bits d'OpenSC
où est la valeur que vous souhaitez utiliser pour PKCS identifier #11, telle NAME_OF_DEVICE
OpenSC
que, et
où se trouve le chemin d'accès au PKCS module #11. Ce chemin doit pointer vers une bibliothèque avec un. DLLextension, telle quePATH_TO_LIBRARY_FOR_DEVICE
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
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 -
Le UPN dans le sujet 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
Note
Linux WorkSpaces sur Linux présente DCV 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.
-
Vous devez utiliser l'application cliente WorkSpaces Windows pour vous connecter à Linux WorkSpaces surDCV.
Pour permettre l'utilisation de cartes à puce sous Linux WorkSpaces, vous devez inclure un fichier de certificat CA racine au PEM format indiqué dans l' WorkSpace image.
Pour obtenir votre certificat de CA racine
Vous pouvez obtenir votre certificat de CA racine de plusieurs façon :
-
Vous pouvez utiliser un certificat de CA racine géré par une autorité de certification tierce.
-
Vous pouvez exporter votre propre certificat d'autorité de certification racine à l'aide du site d'inscription Web, qui contient
http://
soit l'adresse IPip_address
/certsrv
etip_address
le nom de domaine complet () du serveur de certification racinefqdn
http://
, soit l'adresse IP et le nom de domaine complet (FQDN). Pour plus d'informations sur l'utilisation du site d'inscription Web, consultez Comment exporter un certificat d'autorité de certification racinefqdn
/certsrvdans 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. -
Connectez-vous au serveur de CA racine via un compte administrateur.
-
Dans le menu Démarrer Windows, ouvrez une fenêtre d'invite de commandes (Démarrer > Système Windows > Invite de commandes).
-
Utilisez la commande suivante pour exporter le certificat de CA racine vers un nouveau fichier, où
est le nom du nouveau fichier :rootca
.cercertutil -ca.cert
rootca
.cerPour plus d'informations sur l'exécution de certutil, consultez la page certutil
dans la documentation Microsoft. -
Utilisez la SSL commande Open suivante pour convertir le certificat CA racine exporté du DER format au PEM format, où
rootca
est le nom du certificat. Pour plus d'informations sur OpenSSL, consultez le site www.openssl.org. openssl x509 -inform der -in
rootca
.cer -out /tmp/rootca
.pem
-
Pour ajouter votre certificat CA racine à votre système Linux WorkSpaces
Pour vous aider à activer DCV les cartes à puce, nous avons ajouté le enable_smartcard
script à nos offres Amazon Linux. Ce script effectue les actions suivantes :
-
Importe votre certificat CA racine dans la base de données Network Security Services (NSS)
. -
Installe le
pam_pkcs11
module pour l'authentification par le module d'authentification enfichable ()PAM. -
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 d'autorité de certification racine à votre système Linux WorkSpaces et pour activer les cartes à puce pour votre système Linux WorkSpaces.
-
Créez un nouveau Linux WorkSpace avec le DCV protocole activé. Lorsque vous lancez le WorkSpace dans la WorkSpaces console Amazon, sur la page Select Bundles, assurez-vous DCVde sélectionner 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
trouve le chemin d'accès au PEM format du fichier de certificat de l'autorité de certification racine.pem-path
/usr/lib/skylight/enable_smartcard --ca-cert
pem-path
Note
Linux WorkSpaces suppose que les certificats des cartes à puce sont émis pour le nom d'utilisateur principal par défaut de l'utilisateur (UPN), par exemple
, wheresAMAccountName
@domain
is a full qualified domain name (FQDN).domain
Pour utiliser d'autres UPN suffixes,
run /usr/lib/skylight/enable_smartcard --help
pour plus d'informations. Le mappage des UPN suffixes alternatifs est propre à chaque utilisateur. Par conséquent, ce mappage doit être effectué individuellement sur celui de chaque utilisateur WorkSpace. -
(Facultatif) Par défaut, tous les services sont activés pour utiliser l'authentification par carte à puce sous Linux 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 ligneauth
pourpam_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. -
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.)
-
Créez une WorkSpace image personnalisée et un bundle à partir du WorkSpace.
-
Utilisez le nouveau pack personnalisé WorkSpaces pour le lancer pour vos utilisateurs.
Pour permettre aux utilisateurs d'utiliser des cartes à puce dans Firefox
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 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/
. -
Dans le JSON fichier, ajoutez la SecurityDevices politique suivante, où se
trouve la valeur que vous souhaitez utiliser pour identifier leNAME_OF_DEVICE
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 la résolution des problèmes, nous vous recommandons d'ajouter l'utilitaire pkcs11-tools
. 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 -
Le UPN dans le sujet 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.
-
Dans le fichier
/etc/pam.d/system-auth-ac
, modifiez l'actionauth
et faites passer le paramètrenodebug
depam_pksc11.so
àdebug
. -
Dans le fichier
/etc/pam_pkcs11/pam_pkcs11.conf
, remplacezdebug = false;
pardebug = true;
. L'optiondebug
s'applique séparément à chaque module de mappeur, vous devrez donc peut-être la modifier à la fois sous la sectionpam_pkcs11
directement, et aussi sous la section de mappeur appropriée (par défaut, ceci estmapper generic
). -
Dans le fichier
/etc/pam.d/system-auth-ac
, modifiez l'actionauth
et ajoutez le paramètredebug
oudebug_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é, entrez la carte à pucePIN. pklogin_finder
affiche stdout
le nom d'utilisateur figurant sur le certificat de carte à puce dans le formulaire
. Ce nom d'utilisateur doit correspondre au WorkSpace nom d'utilisateur.NETBIOS
\username
Dans les services de domaine Active Directory (AD DS), le nom de BIOS domaine réseau est le nom de domaine antérieur à Windows 2000. Généralement (mais pas toujours), le nom de BIOS domaine Net est le sous-domaine du nom de domaine Domain Name System (DNS). Par exemple, si le nom de DNS domaine estexample.com
, le nom de BIOS domaine Net l'est généralementEXAMPLE
. Si le nom DNS de domaine estcorp.example.com
, le nom de BIOS domaine Net l'est généralementCORP
.
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 Kerberos octroyant un ticket ()TGT. 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
.