• Créer un agent d'inscription
• SafeNet Authentication Client (SAC) - Présentation

10. Stratégies de groupes (GPOs) disponibles pour l'utilisation de cartes à puces

Lorsque vous implémentez des cartes à puces dans votre entreprise, vous pouvez rendre l'utilisation de celles-ci obligatoire et définir le comportement à adopter lorsque la carte à puce est retirée.
Pour cela, ouvrez la console "Gestion de stratégie de groupe" et utilisez l'objet GPO que vous souhaitez.
Dans notre cas, nous modifierons celui qui existe par défaut (Default Domain Policy), néanmoins cela signifie que cela s'appliquera à tous les serveurs et ordinateurs de l'entreprise.

Dans l'éditeur de gestion des stratégies de groupe qui apparait, allez dans : Configuration ordinateur -> Stratégies -> Paramètres Windows -> Paramètres de sécurité -> Stratégies locales -> Options de sécurité.

La 1ère stratégie s'appelle "Ouverture de session interactive : carte à puce nécessaire" et permet de définir si la connexion par carte à puce est obligatoire ou non.

Attention : si le compte Administrateur de votre domaine ne possède pas de carte à puce et que vous activez cette stratégie de groupe (GPO) sur tous les serveurs et ordinateurs de votre entreprise, vous allez vous retrouver bloqué.
En effet, vous ne pourrez plus vous connecter en tant qu'administrateur avec son mot de passe pour retirer cette stratégie de groupe (GPO).

Comme c'est indiqué dans l'onglet "Expliquer" :

• Activé : signifie que vos utilisateurs pourront se connecter uniquement avec une carte à puce.
• Désactivé : comportement par défaut. Permet à vos utilisateurs de se connecter avec une carte à puce ou avec leurs identifiants habituels (nom d'utilisateur / mot de passe).

La 2ème stratégie s'appelle "Ouverture de session interactive : comportement lorsque la carte à puce est retirée" et permet de définir le comportement à adopter lorsque la carte à puce est retirée de votre lecteur de cartes.

Comme indiqué dans l'onglet "Expliquer" :

• Aucune action : comportement par défaut. Rien ne se passe lors du retrait de la carte à puce du lecteur.
  En effet, par défaut, la carte à puce est seulement requise lors de l'ouverture de session.
• Verrouiller la station de travail : pour des raisons de sécurité, votre session sera verrouillée (PAS fermée) lors du retrait de la carte à puce.
  Ainsi, vous pouvez partir de votre poste avec votre carte à puce (par mesure de sécurité) et conserver votre session ouverte, mais verrouillée.
• Forcer la fermeture de session : pour des raisons de sécurité, votre session sera fermée lors du retrait de la carte à puce.
• Déconnecter en cas de session Bureau à distance : si l'utilisateur est connecté via une connexion Bureau à distance (RDS), l'utilisateur sera déconnecté lors du retrait de la carte à puce.
  La session restera donc ouverte, mais verrouillée sur le serveur ou l'ordinateur distant et l'utilisateur pourra se reconnecter à cette session ultérieurement en réutilisant sa carte à puce.
  Si l'utilisateur est connecté localement, le comportement adopté sera le même que l'option "Verrouiller la station de travail".

Dans notre cas, nous n'avons activé aucune de ces stratégies dans notre environnement de test.
Ces stratégies étant à utiliser uniquement en fonction des besoins de votre entreprise.

Pour finir, sachez qu'il est également possible de rendre la connexion par carte à puce obligatoire pour un utilisateur spécifique si vous le souhaitez.
Pour cela, il suffit de modifier l'utilisateur souhaité sur votre contrôleur de domaine et d'aller dans l'onglet "Compte".
Dans la liste des options de compte disponibles pour chaque utilisateur, vous trouverez l'option "Une carte à puce est nécessaire pour ouvrir une session interactive".

Important : si vous cochez cette case pour cet utilisateur, cet utilisateur pourra se connecter uniquement en utilisant sa carte à puce.
Ce qui signifie que cet utilisateur ne pourra se connecter que sur les serveurs et/ou ordinateurs possédant un lecteur de carte à puce compatible.
Dans le cas contraire, cet utilisateur ne sera pas en mesure de se connecter étant donné qu'il ne pourra plus utiliser sa combinaison "nom d'utilisateur / mot de passe".

11. Mettre à jour le certificat utilisé par votre contrôleur de domaine

Pour que vous puissiez vous connecter avec une carte à puce sur un serveur ou un ordinateur de votre entreprise, il faut que ceux-ci puissent faire confiance à votre contrôleur de domaine Active Directory.
Pour que cela soit possible, vous devez mettre à jour le certificat que votre contrôleur de domaine Active Directory.

Dans le cas contraire, vous recevrez surement cette erreur sur le PC client.

Plain Text

La connexion par carte à puce n'est pas prise en charge pour votre compte. Pour plus d'informations, contactez votre administrateur.

En effet, par défaut, votre contrôleur de domaine utilise un certificat basé sur le modèle de certificat "Contrôleur de domaine".

Or, ce type de certificat n'est conçu que pour 2 rôles :

• Garantit votre identité auprès d'un ordinateur distant : ce qui correspond à la stratégie d'application "Authentification du client".
• Garantit l'identité d'un ordinateur distant : ce qui correspond à la stratégie d'application "Authentification du serveur".

Si vous regardez les modèles de certificats que votre autorité de certification peut délivrer par défaut, vous verrez que les contrôleurs de domaine peuvent obtenir différents modèles de certificats :

• Contrôleur de domaine : le modèle de certificat utilisé par défaut par vos contrôleurs de domaine.
  Comme vous venez de le voir, ce type de certificat n'est conçu que pour l'authentification du client et du serveur.
• Réplication de la messagerie de l'annuaire : modèle de certificat qui peut être obtenu par un contrôleur de domaine si vous avez activé l'inscription automatique de certificat (côté ordinateur) pour vos contrôleurs de domaine.
• Authentification du contrôleur de domaine : possède les mêmes stratégies d'application que le modèle de certificat "Contrôleur de domaine" qu'il remplace.
  Mais, ce modèle de certificat est aussi conçu pour la connexion par carte à puce.
• Authentification Kerberos : modèle de certificat plus récent qui possède les mêmes stratégies d'application que le précédent (Authentification du contrôleur de domaine).
  Mais, ce modèle possède une 4ème stratégie d'application supplémentaire permettant l'authentification KDC (Key Distribution Center).

Pour que la connexion grâce à une carte à puce fonctionne correctement sur vos serveurs et vos ordinateurs (qui sont membres de votre domaine Active Directory), vous devrez donc utiliser un certificat basé sur le modèle de certificat "Authentification du contrôleur de domaine" ou "Authentification Kerberos".

Source : Valider et configurer l’infrastructure à clé publique - Modèle d’autorisation de certificat - Microsoft Docs.

Pour vérifier ce que nous venons de vous expliquer, vous pouvez faire un clic droit "Gérer" sur "Modèles de certificats".
Ensuite, faites un double clic sur "Authentification du contrôleur de domaine".

Comme vous pouvez le voir dans l'onglet "Extension" de ce modèle de certificat "Authentification du contrôleur de domaine", les stratégies d'application sont :

• Authentification du client
• Authentification du serveur
• Ouverture de session par carte à puce

Si vous allez dans l'onglet "Modèles obsolètes" de ce modèle de certificat, vous verrez qu'il rend le modèle de certificat "Contrôleur de domaine" obsolète.
En effet, ce modèle de certificat "Authentification du contrôleur de domaine" est plus récent que son prédécesseur (Contrôleur de domaine).

Cela signifie aussi qu'en activant l'inscription automatique de certificats, l'inscription d'un certificat basé sur le modèle de certificat "Authentification du contrôleur de domaine" fera disparaitre l'ancien certificat basé sur le modèle "Contrôleur de domaine".

L'autre possibilité est d'utiliser un certificat basé sur le modèle : Authentification Kerberos.
Faites un double clic sur ce modèle.

Comme vous pouvez le voir, les 3 stratégies citées précédemment sont aussi présentes.
Mais, une stratégie d'application supplémentaire a apparu (si vous avez une version récente de Windows Server) : Authentification KDC.

Par contre, ce modèle de certificat ne rend pas le modèle de certificat "Contrôleur de domaine".

Pour mettre à jour le certificat de votre contrôleur de domaine, enlevez le modèle de certificat "Contrôleur de domaine" de la liste de modèles de certificats que votre autorité de certification peut délivrer.
Notez que cela ne supprime pas le modèle de certificat concerné, mais cela empêche uniquement votre autorité de certification de délivrer ce type de certificat.

Confirmez la désactivation de ce modèle de certificat en cliquant sur Oui.

Le modèle de certificat "Contrôleur de domaine" disparait de la liste.

Pour que le certificat actuel de votre contrôleur de domaine soit remplacé par un modèle de certificat plus récent (via la gestion des modèles de certificats obsolètes que vous avez vue précédemment), vous devrez activer l'inscription automatique des certificats pour vos contrôleurs de domaine.
Pour cela, sur votre contrôleur de domaine, ouvrez la console "Gestion de stratégie de groupe" et modifiez l'objet GPO "Default Domain Controllers Policy" qui existe par défaut et qui concerne tous vos contrôleurs de domaine.

Dans l'éditeur de gestion des stratégies de groupe qui apparait, allez dans "Configuration ordinateur -> Stratégies -> Paramètres Windows -> Paramètres de sécurité -> Stratégies de clé publique" et faites un double clic sur la stratégie "Clients des services de certificats - Inscription automatique".

Activez cette stratégie et cochez les 2 cases pour activer le renouvellement automatique des certificats que votre contrôleur de domaine peut inscrire automatiquement et la mise à jour des anciens certificats en utilisant les nouveaux modèles de certificats qui les remplacent (le cas échéant).
Ensuite, cliquez sur OK.

Sur votre contrôleur de domaine, forcez la mise à jour de la stratégie de groupe en exécutant la commande.
Cela provoquera aussi l'inscription automatique des certificats, si nécessaire.

Batch

gpupdate /force

Si besoin, vous pouvez forcer l'inscription automatique des certificats en exécutant la commande :

Batch

certreq -autoenroll -q

Si vous allez dans le magasin de certificats "Personnel" de votre contrôleur de domaine, vous remarquerez que vos certificats ont changé.
En effet, votre certificat basé sur le modèle de certificat "Contrôleur de domaine" (étant donné qu'il est rendu obsolète par le modèle de certificat "Authentification du contrôleur de domaine" qui a été détecté lors de l'inscription automatique des certificats).
Maintenant, votre contrôleur de domaine possède normalement 3 certificats :

• 1 certificat basé sur le modèle de certificat "Authentification Kerberos".
• 1 certificat basé sur le modèle de certificat "Authentification du contrôleur de domaine".
• 1 certificat basé sur le modèle de certificat "Réplication de la messagerie de l'annuaire".

Important : le seul certificat réellement nécessaire pour le bon fonctionnement de la connexion par carte à puce est celui basé sur le modèle de certificat "Authentification du contrôleur de domaine".
Comme expliqué précédemment, si votre contrôleur de domaine possède au moins un certificat basé sur le modèle de certificat "Authentification du contrôleur de domaine" ou "Authentification Kerberos", cela fonctionnera correctement étant donné que ces 2 modèles sont conçus pour la connexion par carte à puce.

Note : dans votre cas, le modèle de certificat est affiché tout à droite de la liste.
Mais, pour ce tutoriel, je l'ai volontairement déplacée vers la gauche pour que cela soit plus lisible.

Si vous faites un double clic sur le certificat basé sur le modèle de certificat "Authentification du contrôleur de domaine", vous verrez que ce certificat est conçu notamment pour l'ouverture de session par carte à puce.

Dans l'onglet "Détails", si vous sélectionnez le champ "Informations du modèle de certificat", vous verrez que le modèle utilisé est : Authentification du contrôleur de domaine.

Faites un double clic sur le certificat basé sur le modèle de certificat "Authentification Kerberos".

Comme vous pouvez le voir, le certificat basé sur le modèle de certificat "Authentification Kerberos" est aussi conçu pour l'ouverture de session par carte à puce, mais également pour l'authentification KDC.
Dans notre cas, cela n'est pas requis, mais sachez juste que ce modèle de certificat est plus récent que le modèle "Authentification du contrôleur de domaine".

Dans l'onglet "Détails", si vous sélectionnez le champ "Informations du modèle de certificat", vous verrez que le modèle utilisé est : Authentification Kerberos.