Bienvenue dans une nouvelle série d’articles dédiée à la fonctionnalité Windows Hello For Business (aka WHFB). Il s’agit là d’une fonctionnalité « Poste de travail » qui sort un peu de mon terrain de jeu habituel mais vous comprendrez au fil des articles pourquoi je m’y intéresse et de quelle façon son usage initial a évolué de la simple fonctionnalité de confort à un élément de sécurité du S.I.
Les articles de la série traiteront de :
- La présentation générale et mise en œuvre des prérequis (cet article)
- Déploiement du scénario « KeyTrust »
- Déploiement du scénario « Cloud Trust »
- Utilisation du « Dual Enrolment » pour l’élévation de privilèges
- Ouverture de session Windows par clé FIDO2
Avant toute chose, je ne peux que regretter que cette fonctionnalité soit si peu connue et encore moins déployée en entreprise et vais donc commencer par une présentation générale et les différents modes de déploiement proposés.
Windows Hello For Business est l’implémentation de la technologie Windows Hello adaptées aux organisations disposant d’un annuaire d’entreprise (Active directory et / ou Azure AD).
Cette fonctionnalité est présente nativement dans les clients Windows 10 / Windows 11 (les premières versions s’appelaient « Microsoft Passport ») et permet aux utilisateurs d’ouvrir leur session Windows au travers d’une expérience simplifiée :
- Code PIN
- Empreinte digitale
- Reconnaissance faciale
L’utilisateur gagne ainsi en confort d’utilisation et ce de façon plus large que ce que l’on pourrait imaginer en première intention, nous le verrons plus loin.
Le fonctionnement de WHFB repose sur des clés d’authentification permettant d’authentifier un utilisateur en lieu et place de son mot de passe. Le principe est assez proche de l’authentification par carte à puce (SmartCard Logon) mais n’impose pas de disposer de cartes à puce / lecteurs de carte à puce : c’est la puce TPM des postes Windows 10 qui stocke et protège les « clés » et c’est l’utilisateur qui procède lui-même à son enrôlement.
Pour les usages les plus simples, WHFB permettra aux utilisateurs récalcitrants aux mots de passe compliqués d’ouvrir leur session Windows facilement. Dans ce cas de figure, si la solution est bien intégrée à l’écosystème applicatif de l’entreprise (applications « modernes » utilisant le SSO de Windows et / ou applications Cloud reposant sur l’annuaire Azure AD) WHFB pourra être la méthode d’authentification principale et dans le meilleur des cas, les utilisateurs pourront oublier leur mot de passe et même être affranchis de le changer.
Attention cependant, il existe de nombreux cas d’usage incompatibles avec WHFB pour lesquels le mot de passe a hélas encore de beaux jours devant lui :
- L’accès à une application reposant sur une authentification LDAP
- L’ouverture d’une session RDP (bien que… mais je le garde pour les prochains articles)
- Toute application ne prenant pas en compte l’authentification intégrée Windows
Expérience utilisateur attendue
Un des objectifs affichés est de favoriser l’expérience utilisateur, et en effet les utilisateurs WHFB seront soumis à deux nouvelles expériences : l’enrôlement et l’utilisation
L’enrôlement est nécessaire pour inscrire une clé d’authentification sur l’ordinateur (puce TPM), il a lieu à l’ouverture de session Windows depuis un poste sur lequel l’utilisateur n’est pas enrôlé (il ne dispose pas de clé d’authentification sur la puce TPM).
Dans ce cas de figure, après avoir saisi le login / mot de passe, l’assistant d’enrôlement est initié :
Si l’utilisateur dispose déjà d’une méthode de MFA déjà inscrite sur Azure AD (Microsoft Authenticator, clé de sécurité…) cette méthode de vérification est déclenchée (push Authenticator, PIN de la clé de sécurité …) puis l’utilisateur doit choisir le code PIN associé à son « device » (puce TPM) et l’enrôlement est terminé, difficile de faire plus simple.
Par la suite, l’utilisateur peut alors ouvrir sa session Windows en saisissant le code PIN choisi ou bien, si aucune restriction n’a été définie, choisir l’option de connexion par mot de passe :
Le reste se déroule alors normalement (accès en SSO à tout l’écosystème Microsoft : services de fichiers, services d’impression, ressources M365 et applications SaaS rattachées à Azure AD).
Sur le plan de la sécurité, WHFB joue également un rôle important : les clés d’authentification sont stockées sur les postes clients et protégés par une puce TPM elle-même protégée par les mécanismes préalablement décrits (code PIN, camera, empreinte…).
Si j’utilise un code PIN et quelqu’un arrive à voir ce que je saisis au clavier, il ne pourra rien en faire tant qu’il ne dispose pas du facteur de possession associé (mon ordinateur). Cet argument est parfaitement décrit par Microsoft et je ne vais pas m’attarder plus dessus : https://docs.microsoft.com/fr-fr/windows/security/identity-protection/hello-for-business/hello-why-pin-is-better-than-password .
Par ailleurs, si vous utilisez le Azure AD et son MFA pour accéder à des applications d’entreprise (ExchangeOnline, SharepointOnline ou toute application SaaS / OnPrem reposant sur Azure AD), il est intéressant de savoir que les demandes d’accès provenant d’une session WHFB seront nativement traitées comme satisfaisant le MFA (le MFA est fait par WHFB à l’ouverture de session et donc plus besoin d’embêter l’utilisateur avec un push Authenticator ou un SMS, on est sur du MFA transparent )
Scénarios de déploiement
WHFB peut être déployé selon 4 scénarios différents :
| Cloud uniquement | Destiné aux organisations rattachées à Azure AD mais sans Active Directory |
| Hybride reposant sur des certificats | Destiné aux organisations rattachées à Azure AD par l’intermédiaire d’Active Directory et disposant d’un fournisseur d’identités (généralement ADFS) |
| Hybride reposant sur des clés AD (Key Trust) | Destiné aux organisations rattachées à Azure AD par l’intermédiaire d’Active Directory et disposant ou non d’un fournisseur d’identités (généralement ADFS) |
| Hybride reposant sur des clés Cloud (Cloud Trust) | Destiné aux organisations rattachées à Azure AD par l’intermédiaire d’Active Directory et disposant ou non d’un fournisseur d’identités (généralement ADFS) |
Je travaille très majoritairement pour des organisations disposant d’un annuaire Active Directory et d’un tenant Azure AD et vais m’intéresser aux modes « hybride reposant sur des clés » (Key Trust et Cloud Trust) qui sont à mon sens plus aboutis que les deux précédents.
- Le mode Cloud uniquement s’adresse aux entreprises ne disposant pas d’un annuaire Active Directory.
- Le mode hybride reposant sur des certificats est complexe à mettre en œuvre et couteux à maintenir (nécessite une ferme ADFS et une autorité de certification parfaitement maitrisée). Il me semble également en voie d’obsolescence compte tenu de l’absence d’évolutions d’ADFS depuis la version 2016 et de la volonté à peine masquée de Microsoft de pousser les déploiements ADFS à migrer vers du « Pass-Through Authentication ».
- Le mode hybride reposant sur des clés offre toutes les possibilités de son prédécesseur et s’avère beaucoup plus simple à déployer.
- Le mode « hybride reposant sur des clés Cloud » est encore plus simple à déployer que son prédécesseur
Prérequis
- Un annuaire Active Directory
- Une souscription Azure AD Premium P1 ou P2 (nécessaire pour l’enrôlement MFA et le « Device Writeback »)
- Le périmètre de synchronisation Azure AD Connect doit inclure les postes de travail qui devront être joints au tenant Azure AD en mode hybride
- Le paramétrage du tenant doit être effectué en mode de jonction hybride : https://docs.microsoft.com/en-us/azure/active-directory/devices/howto-hybrid-azure-ad-join
- La fonctionnalité « Device Writeback » doit être configurée : https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-device-writeback
- Seul Windows 10 est supporté, les OS Serveurs sont donc exclus sauf lorsqu’on y accède en RDP depuis des machines Windows 10 configurées en dual enrolment : https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-feature-dual-enrollment
- Les contrôleurs de domaine doivent être en version 2016, 2019 ou 2022 (bonne occasion pour moderniser votre AD)
- Une PKI d’entreprise est nécessaire sauf dans le fonctionnement par clés Cloud ou elle n’est que recommandée
Préparation – Synchronisation des comptes d’ordinateur
La jonction hybride consiste à synchroniser les comptes d’ordinateur sur le tenant Azure AD. Dans Active Directory on parle d’objets de type « computer », dans Azure AD ces mêmes objets seront synchronisés en tant que « devices »
Il faut en premier lieu s’assurer que les comptes d’ordinateurs soient bien synchronisés car un « device » ne pourra être joint que si l’objet de destination est préalablement créé. Pour cela, direction l’assistant de configuration Azure AD Connect et les options de synchronisation :
Les unités organisationnelles hébergeant les postes de travail doivent être sélectionnées de sorte que les objets « computer » soient projetés sur le tenant Azure AD comme « devices » :
Une fois cette tâche effectuée, les objets « ordinateur » de l’annuaire Active Directory apparaitront comme objets de type « device » dans l’annuaire Azure AD avec un statut d’enregistrement « Pending » qui indique qu’aucune opération de jonction n’a été faite et pour laquelle une étape de configuration supplémentaire doit être faite :
Préparation – Configuration du SCP
Pour que les opérations de jonction débutent, il faut configurer les options de « devices » de sorte que les ordinateurs puissent identifier le tenant Azure AD et s’y inscrire ».
Cette opération consiste à créer un objet de configuration dans l’annuaire AD :
La fonctionnalité « Hybrid Azure AD Join » va créer un objet de découverte du tenant dans la forêt Active Directory (Service Connection Point – aka : SCP)
La fonctionnalité « Device Writeback » permettra de créer les « devices » dans la forêt Active Directory, ces objets sont un prérequis à l’utilisation de WHFB
Vous aurez surement compris que lorsque tout ça fonctionnera, nous aurons 3 objets distincts pour un ordinateur : le « computer » AD è Le « device » Azure AD è Le « device » AD. C’est sur cette chaine de confiance que reposera la fonctionnalité WHFB
On commencera par créer le SCP :
Et comme nous sommes en 2022, il semble pertinent d’ignorer délibérément les versions d’OS antérieures à Windows 10 / Windows Server 2016.
N.B : Je parle ici des versions « Server » que l’on peut joindre à Azure AD mais sur lesquels on ne pourra pas faire de WHFB (réservé à Windows 10)
Le SCP est un objet stocké dans la partition de configuration, sa création nécessite de renseigner un compte membre du groupe « Enterprise Admins »
Une fois cette opération terminée, l’objet SCP sera créé dans la partition de configuration sous le chemin LDAP : CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=<MyDomain>,DC=<Local>
Le GUID de cet objet est toujours le même : 62a0ff2e-97b9-4513-943f-0d221bd30080
L’objet créé détient les indications du tenant Azure AD dans l’attribut « Keywords », information permettant aux ordinateurs du domaine de localiser le tenant Azure AD pour s’y enregistrer :
Les ordinateurs du domaine sont alors capables d’identifier le tenant AzureAD et de voir s’il est possible de s’y rattacher. Cette opération se fait à l’ouverture de session par une tâche planifiée présente « Out of the box » sur les machines Windows 10 et Windows Server 2016/2019/2022.
Cette tâche est automatiquement activée lorsque ces ordinateurs joignent un domaine AD (elle est donc désactivée pour les machines en WorkGroup) :
Cette tâche s’exécute à chaque ouverture de session, elle a la particularité de s’exécuter en tant que SYSTEM :
Lors de son exécution, les services web du tenant Azure AD sont contactés nécessitant que les URLs ci-dessous soient accessibles dans le contexte « SYSTEM » des ordinateurs (attention aux proxys web nécessitant une authentification) :
- https://enterpriseregistration.windows.net
- https://login.microsoftonline.com
- https://device.login.microsoftonline.com
- https://autologon.microsoftazuread-sso.com
Lorsque la tâche aboutit (trouver le tenant Azure AD, s’y connecter, identifier si un « device » de même nom est en statut « Pending », s’y rattacher) le statut passe de « Pending » à la date de l’opération de jonction.
L’indicateur « Activity » permet de voir à quelle date le « device » a été vu pour la dernière fois :
Préparation – Activation de la fonctionnalité « Device WriteBack »
La fonctionnalité « Device Writeback » permet de créer des objets de type « device » dans le domaine AD.
Pour cela, il faut se rendre à nouveau dans l’assistant de configuration, et choisir « Device Options » :
L’assistant de configuration va créer un conteneur dans la forêt / domaine choisis :
La création du container nécessite de fournir les identifiants d’un compte membre du groupe « Enterprise Admins » :
Plusieurs tâches sont traitées par l’assistant (création du conteneur, modification des connecteurs Azure AD Connect :
Et si tout se passe bien :
Vous devriez voir rapidement le conteneur se peupler de « devices » :
Préparation – Certificats « Kerberos » pour les contrôleurs de domaine
WHFB nécessite que les contrôleurs de domaine disposent d’un certificat particulier permettant l’authentification des utilisateurs avec des clés.
Cette procédure est bien décrite sur le site de Microsoft : https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-pki#domain-controller-certificate-template
Si vous suivez la procédure, vous obtiendrez des certificats Kerberos permettant un usage plus large que le certificat de base « Domain Controller », et notamment l’utilisation de WHFB :
Il y a juste un point avec lequel je ne suis pas d’accord sur la procédure de création du modèle de certificat lorsqu’il est dit de choisir « None » sur le « Subject Name Format ». Je sélectionne systématiquement « Common Name » en plus du SAN (DNS Name) car j’ai eu des cas de figure ou malgré la présence du champ SAN, cette absence posait souci :
A ce stade, nous avons tous les éléments de base nécessaires à l’activation de WHFB :
- La jonction hybride
- Le « Device Writeback »
- Des contrôleurs de domaine avec certificat KDC
Dans le prochain article, nous déploierons le scénario « Key Trust » et analyserons l’expérience utilisateur offerte ainsi que le gain obtenu sur le plan de la sécurité.
Merci de votre lecture !