Voici le second article de la série « Windows Hello for Business » (WHFB), consacré au déploiement du mode « Key Trust ». Le premier article a décrit les pré requis techniques visant essentiellement à disposer d’une infrastructure hybride AD / Azure AD nécessaire à WHFB ( jonction hybride des comptes d’ordinateurs en tant que « devices »). Sur la base de ces pré requis, nous allons aborder les premiers cas d’usages WHFB avec le déploiement du mode « Key Trust »

Ce dernier est resté longtemps le plus simple à mettre en place, jusqu’à l’apparition récente de son successeur reposant sur des clés « Cloud » (Cloud Trust – qui est toujours en preview et qui fera l’objet d’un prochain article). Key Trust reste malgré tout un mode de déploiement pertinent qui ne demande que peu d’investissements techniques :

• Azure AD MFA
• La jonction hybride et le « Device Writeback » opérationnels
• Des postes Windows 10
• Des contrôleurs de domaine fonctionnant sous Windows Server 2016, 2019 ou 2022
• Une autorité de certification intégrée à l’annuaire Active Directory et la CRL accessible en http
• Des certificats « KDC » sur les contrôleurs de domaine : https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-pki#domain-controller-certificate-template

Une fois cet ensemble de préparatifs opérationnels, le reste du déploiement est très simple mais ça n’est que la partie visible : des actions beaucoup plus complexes se déroulent en tâche de fond.

Commençons par la simplicité : si vous voulez activer Windows Hello pour vos utilisateurs, il vous suffira d’activer le paramètre de stratégie de groupe « Use Windows Hello For Business », c’est tout ! Ce paramètre existe dans le contexte ordinateur et utilisateur, à vous de choisir votre périmètre, et il suffira de le mettre sur « Enabled » et de choisir si vous voulez on non forcer l’enrôlement à l’ouverture de session :

Si l’enrôlement est forcé à l’ouverture de session, l’expérience utilisateur est celle qui est décrite dans le précédent article https://www.adviseit.fr/2022/06/01/presentation-de-windows-hello-for-business/ , dans ce cas l’utilisateur n’a pas d’autre choix que de dérouler le processus d’enrôlement (simple et rapide mais… forcé).

Dans le cas contraire, aucune action d’enrôlement n’est déclenchée de façon automatique, l’utilisateur va procéder lui-même à l’enrôlement de façon volontaire en utilisant la procédure ci-après.

Dans l’application « Paramètres », trouver les « Options de connexion » (Paramètres / Accueil / Options de connexion)

A cet endroit, vous trouverez entre autres les options de connexion disponibles pour Windows Hello. Certaines ne seront peut-être pas disponibles si :

• Votre ordinateur ne dispose pas d’une caméra infrarouge permettant la reconnaissance faciale
• Votre ordinateur ne dispose pas d’un lecteur d’empreinte digitale
• Votre organisation n’a pas activé les options biométriques

En revanche, l’option pour le code PIN est bien présente (elle est du reste obligatoire) et c’est elle qui va nous intéresser en premier lieu :

En choisissant cette option, nous allons définir un code PIN qui sera utilisé pour « ouvrir » le magasin de clés Windows Hello, il faut pour cela cliquer sur le bouton « Ajouter »

Une petite explication sur le processus est présentée

Puis l’authentification Azure MFA est initiée à destination du compte utilisateur à l’origine de la demande, la suite du processus est liée à la réussite du challenge Azure MFA :

Après l’authentification Azure MFA, l’utilisateur doit choisir son code PIN :

Et c’est (presque) terminé !

Plutôt simple non ? Regardons à présent ce qui se passe en coulisse, ça va se compliquer un peu. Nous allons utiliser les composants suivants :

• Un certificat Ordinateur
• Un certificat Utilisateur
• La clé publique du certificat Utilisateur (propagée du compte Azure AD vers le compte Active Directory)

Certificat Ordinateur (Device)

Lorsqu’un ordinateur Windows 10 est joint à Azure AD, un certificat est généré puis stocké dans le magasin de certificats « Ordinateur » . Ce certificat porte un GUID que l’on retrouvera ensuite sur le « device » correspondant.

En regardant attentivement, on constate que ce certificat dispose du même GUID que celui du Device Azure AD :

‎La clé privée de ce certificat est conservée localement (magasin de certificats « ordinateur » et la clé publique est synchronisée avec Azure AD. Azure AD Connect réécrit ensuite cette information dans l’attribut « UserCertificate » du compte ordinateur dans Active Directory :

Si vous voulez être certain que la valeur « UserCertificate » correspond au certificat de la machine, vous pouvez utiliser la procédure décrite ici : https://docs.microsoft.com/fr-fr/archive/blogs/kenben/how-to-easily-decode-the-usercertificate-or-cacertificate-attribute-in-active-directory-with-only-the-tools-built-into-windows. Pour ma part je n’ai obtenu qu’un texte incompréhensible mais en redirigeant la commande vers un fichier « .CER », je retrouve à nouveau le GUID correspondant :

Et si vous êtes attentifs, vous aurez surement remarqué que le GUID du certificat correspond également au GUID du « device » correspondant dans l’annuaire Active Directory, la boucle est bouclée  :

Nous disposons à ce stade d’un ordinateur « hybride » disposant de son certificat Azure AD lui permettant d’être reconnu en tant que « Device »

Certificat Utilisateur (Windows Hello For Business)

Durant la phase d’enrôlement, un certificat de type « SmartCard Logon » est distribué à l’utilisateur (Ouverture de session par carte à puce). Ce certificat détient la paire de clés asymétriques permettant l’ouverture de session, il est protégé par la puce TPM de l’ordinateur et le code PIN qui lui a été associé. La clé privée du certificat sera par la suite utilisée pour signer les pré-authentifications Kerberos à l’ouverture de session, accessible seulement après avoir saisi le code PIN  :

Il s’agit d’un certificat autosigné (l’émetteur et le sujet sont identiques) dont la durée de validité est de 30 ans :

Le certificat est associé au compte Azure de l’utilisateur, rien ne permet à ce stade d’ouvrir une session validée par un contrôleur de domaine. En fin d’enrôlement nous avons simplement un certificat autosigné stocké sur la puce TPM de l’ordinateur :

Et également une copie de la clé publique de ce certificat sur le compte Azure AD de l’utilisateur :

Ces clés sont uniques et non itinérantes : chacune d’entre elle représente un utilisateur particulier sur un « Device » particulier. Si vous utilisez Windows Hello sur plusieurs ordinateurs, vous aurez un certificat autosigné sur chacun (et si vous avez bien suivi, une copie de la clé publique de chaque certificat autosigné sur votre compte Azure AD) :

Pour permettre l’ouverture de session Windows Hello, une étape supplémentaire est nécessaire : la recopie de la clé publique sur les comptes Active Directory. Cette opération est effectuée par Azure AD Connect qui va réécrire la (ou les) clés publique(s) des utilisateurs dans l’attribut « MSDS-KeyCredentialLink » :

Le contenu de cet attribut est assez obscur, on ne peut que difficilement y accéder et encore moins le modifier :

On peut y accéder en PowerShell avec le module Active Directory (commande Get-ADUser), mais ça n’est pas très convivial:

On obtiendra un meilleur résultat avec le module WHfbTools (https://www.powershellgallery.com/packages/WHfBTools/1.0.3):

Coté Azure AD, l’interrogation au travers de l’API Graph permet de visualiser les « Devices » sur lesquels un utilisateur s’est enrôlé, et pour chaque « Device » le « DeviceID » (Identifiant du Device) et le keyMaterial (la clé publique du certificat). On retrouvera de cette façon les mêmes informations que ce qui est observé sur Active Directory :

Dans cet exemple, John DOE s’est enrôlé sur 3 ordinateurs, il dispose sur chacun d’un certificat dont une copie de la clé publique est copiée sur le compte utilisateur Azure AD.

Si on analyse le premier Device :

La valeur stockée dans l’attribut keyMaterial est la clé publique du certificat généré lors de l’enrôlement (codé en base 64). Une conversion en Hexadécimal permet de faire la comparaison avec le certificat obtenu sur le Device. Une fois les en têtes passées, le contenu est identique (comparaison des 10 premiers octets) :

L’enrôlement ayant lieu sur le tenant Azure AD et la propagation de ces informations vers le domaine Active Directory se faisant par Azure AD Connect toutes les 30 minutes, il faudra attendre l’exécution de ce cycle pour que la clé publique arrive à bon port et pouvoir enfin ouvrir une session Windows Hello.

Complexité du code PIN

De la même façon que les mots de passe, les codes PIN peuvent être soumis à des règles de complexité en ce qui concerne :

• Leur contenu (chiffres, lettres, caractères spéciaux…)
• La longueur (minimale et maximale)
• L’expiration

Source : https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-manage-in-organization

Ouverture de session et usage de Windows Hello

L’ouverture de session Windows Hello a déjà été décrite dans le précédent article (https://www.adviseit.fr/2022/06/01/presentation-de-windows-hello-for-business/)

Je dois juste rajouter qu’il existe des méthodes biométriques qui permettent d’obtenir le même résultat que le code PIN (permettre de signer la pré authentification Kerberos avec la clé privée du certificat utilisateur). Ce dernier reste néanmoins obligatoire pour le cas où les méthodes biométriques échoueraient. Les méthodes biométriques nécessitent des équipements compatibles mais offrent un confort accru (plus besoin de taper au clavier) :

• Reconnaissance d’empreinte digitale
• Reconnaissance faciale

Conclusion

Ce deuxième article de la série décrit un usage « bureautique » normal. Toutes les fonctionnalités de SSO de Windows dans un environnement Active Directory sont présentes et offrent une expérience fluide à l’utilisateur. Il y a cependant certains cas de figure ou le mot de passe peut être encore nécessaire et ou Windows Hello montrera ses limites :

• Applications reposant sur Active Directory mais ne prenant pas en charge l’authentification intégrée Windows
• Applications reposant sur LDAP
• Connexion à des serveurs RDP avec Windows Hello (mais … ce point sera traité et solutionné dans un prochain article)

Dans le prochain article, nous verrons de quelle façon il est possible d’enrichir l’utilisation de Windows Hello dans un contexte « Administrateur » et ce que cela est susceptible d’amener sur le plan de la sécurité du S.I.

Merci de votre lecture, n’hésitez pas à me laisser des commentaires !