Connexion par carte à puce – Uwe Gradenegger

Attestation YubiKey Personal Identity Verification (PIV) - avec le module TameMyCerts Policy pour Microsoft Active Directory Certificate Services (ADCS)

Depuis la version 1.7 récemment publiée, le système de gestion de l'information de l'université de Zurich prend en charge la gestion de l'information. Module de politique TameMyCerts pour les services de certificats Microsoft Active Directory l'attestation de vérification de l'identité personnelle (PIV) pour YubiKeys.

Une YubiKey est un jeton de sécurité compact qui peut être utilisé, entre autres, comme une carte à puce pour le stockage et l'utilisation sécurisés de certificats et peut donc également être utilisé pour une connexion sans mot de passe à des environnements Active Directory.

Cette fonction cool a été créée par Oscar Virot et intégrée dans TameMyCerts. Elle permet d'apporter une preuve cryptographique lors de l'émission d'un certificat et de garantir ainsi qu'une paire de clés est effectivement sécurisée par une YubiKey et ne peut pas être exportée.

Cela peut notamment s'avérer utile pour se conformer à la directive NIS2, dans la mesure où les entreprises optent pour des certificats comme deuxième facteur de connexion avec des comptes critiques en termes de sécurité dans Active Directory.

Continuer la lecture

L'inscription par carte à puce échoue avec un message d'erreur "A certification chain processed correctly, but one of the CA certificates is not trusted by the policy provider. 0x800b0112 (-2146762478 CERT_E_UNTRUSTEDCA)".

Supposons le scénario suivant :

L'entreprise souhaite utiliser la connexion par carte à puce.
Les contrôleurs de domaine sont avec des certificats utilisables pour l'inscription par carte à puce équipée.
Les utilisateurs sont munis de certificats utilisables pour la connexion par carte à puce.
La connexion au domaine par carte à puce échoue avec le message d'erreur suivant :

A certification chain processed correctly, but one of the CA certificates is not trusted by the policy provider. 0x800b0112 (-2146762478 CERT_E_UNTRUSTEDCA)

Continuer la lecture

Signer des certificats en contournant l'autorité de certification - uniquement avec les moyens du bord

Dans l'article "Signer des certificats en contournant l'autorité de certificationJ'ai décrit dans l'article "Comment un attaquant en possession de droits administratifs sur l'autorité de certification peut générer un certificat d'inscription pour des comptes administratifs du domaine en contournant le logiciel de l'autorité de certification, c'est-à-dire en utilisant directement la clé privée de l'autorité de certification.

Dans l'article précédent, j'ai présenté le PSCertificateEnrollment Module Powershell pour illustrer la procédure. Microsoft fournit avec certreq et certutil Le système d'exploitation de l'entreprise est livré avec des outils de pentesting parfaitement adaptés.

Continuer la lecture

Modifications apportées à l'émission de certificats et à l'ouverture de session basée sur des certificats dans Active Directory par le correctif pour Windows Server du 10 mai 2022 (KB5014754)

Avec le correctif du 10 mai 2022, Microsoft tente de combler une faille de sécurité dans le Active Directory dans laquelle l'inscription basée sur un certificat (généralement connue sous le nom de PKINIT ou encore de Connexion par carte à puce).

La mise à jour modifie à la fois le comportement Autorité de certification que le comportement d'Active Directory lors du traitement des inscriptions basées sur des certificats.

Continuer la lecture

forcer les contrôleurs de domaine (ou autres participants) à utiliser un répondeur en ligne (OCSP)

Par défaut, les systèmes Windows, même si un répondeur en ligne (OCSP) est configuré, sont envoyés à l'adresse suivante d'un certain nombre de requêtes OCSP de retomber sur une liste de blocage (si elle existe), car cela est généralement plus efficace dans un tel cas. Mais ce comportement n'est pas toujours souhaité.

Par exemple, si vous utilisez des inscriptions par carte à puce, vous voudrez peut-être savoir si des inscriptions ont été effectuées avec des certificats délivrés sans autorisation. En relation avec le déterministe Good du répondeur en ligne il est possible d'établir un rapport (presque) complet Chemin d'audit pour toutes les inscriptions par carte à puce.

Continuer la lecture

Configurer un modèle de certificat pour les contrôleurs de domaine

Même dans le cas d'un modèle de certificat pour contrôleurs de domaine supposé simple à configurer, certains points doivent être pris en compte.

Continuer la lecture

Empêcher la connexion au réseau avec une carte à puce

Si vous installez les services de certificats Active Directory dans la configuration standard, l'environnement est automatiquement configuré pour que les connexions par carte à puce soient acceptées par les contrôleurs de domaine.

Si l'utilisation des connexions par carte à puce n'est pas souhaitée, il est donc judicieux de désactiver cette fonctionnalité afin d'éviter, en cas de compromission de l'autorité de certification, Ne pas compromettre Active Directory.

Continuer la lecture

Modification automatique des mots de passe pour les comptes qui nécessitent une connexion via une carte à puce ou Windows Hello for Business

Une nouvelle fonctionnalité de Windows Server 2016 est que les mots de passe pour les comptes qui utilisent uniquement Connexion avec des cartes à puce doivent être renouvelés automatiquement conformément aux directives relatives aux mots de passe.

Si l'option „ Smart card is required for interactive logon “ (Une carte à puce est requise pour la connexion interactive) est activée pour un compte utilisateur, le mot de passe du compte utilisateur est défini une seule fois sur une valeur aléatoire. Cependant, le mot de passe ne change plus par la suite, ce qui rend le compte plus vulnérable aux attaques de type « pass-the-hash ».

La nouvelle fonctionnalité résout ce problème en générant régulièrement de nouveaux mots de passe aléatoires pour les comptes concernés (en fonction de la politique de mot de passe configurée pour le compte).

Continuer la lecture

Utiliser l'assurance du mécanisme d'authentification (AMA) pour sécuriser la connexion des comptes administratifs

L'assurance du mécanisme d'authentification (AMA) est une fonction qui doit garantir qu'un utilisateur n'est membre d'un groupe de sécurité que s'il s'est connecté avec une méthode d'authentification forte (c'est-à-dire une carte à puce). Si l'utilisateur se connecte à l'aide d'un nom d'utilisateur et d'un mot de passe, il ne peut pas accéder aux ressources demandées.

Conçu à l'origine pour l'accès aux serveurs de fichiers, l'AMA peut toutefois être utilisé (avec quelques restrictions) pour la connexion administrative. Ainsi, il serait par exemple envisageable qu'un utilisateur soit non privilégié s'il se connecte avec un nom d'utilisateur et un mot de passe, et qu'il dispose de droits administratifs s'il se connecte avec un certificat.

Continuer la lecture

La connexion via carte à puce échoue avec le message d'erreur "Signing in with a security device isn't supported for your account".

Supposons le scénario suivant :

Un utilisateur dispose d'un Connexion par carte à puce et se connecte au domaine Active Directory avec ce certificat.
La connexion échoue. Le message d'erreur suivant est renvoyé à l'utilisateur sur son ordinateur :

Signing in with a security device isn't supported for your account. For more info, contact your administrator.

Continuer la lecture

Configurer un modèle de certificat pour Authentication Mechanism Assurance (AMA)

L'assurance du mécanisme d'authentification (AMA) offre la possibilité de lier l'adhésion à un groupe de sécurité à l'inscription avec un certificat de carte à puce contenant un identifiant d'objet (OID) spécifique.

Si l'utilisateur ne se connecte pas avec son certificat de carte à puce, mais avec son nom d'utilisateur et son mot de passe, il n'est pas non plus membre du groupe de sécurité.

Ci-dessous, nous décrivons comment générer un modèle de certificat à utiliser avec l'assurance du mécanisme d'authentification.

Continuer la lecture

La connexion via carte à puce échoue avec le message d'erreur "The revocation status of the authentication certificate could not be determined".

Supposons le scénario suivant :

Un utilisateur dispose d'un Connexion par carte à puce et se connecte au domaine Active Directory avec ce certificat.
La connexion échoue. Le message d'erreur suivant est renvoyé à l'utilisateur sur son ordinateur :

The revocation status of the authentication certificate could not be determined.

Continuer la lecture

Création d'une carte à puce virtuelle dans un système invité Hyper-V

Pour les environnements de test, il est souvent utile de pouvoir travailler avec des cartes à puce. Voici un petit guide sur la manière de mettre en place une carte à puce virtuelle dans un invité Hyper-V à l'aide d'un module de plate-forme de confiance (TPM) virtualisé.

Continuer la lecture

Modèles de certificats de contrôleur de domaine et inscription par carte à puce

Pour que les contrôleurs de domaine puissent traiter les inscriptions par carte à puce, ils ont besoin de certificats qui fournissent cette fonction.

Continuer la lecture

Modifier l'objet NTAuthCertificates dans Active Directory

Dans la configuration standard, tous les certificats d'autorité de certification des autorités de certification intégrées dans Active Directory (Enterprise Certification Authority) se trouvent dans un objet de type CertificationAuthority appelé NTAuthCertificates au sein de la partition Configuration de l'arborescence globale d'Active Directory.

Continuer la lecture

Français