Notes de configuration pour Windows Hello for Business

Windows Hello for Business est une fonctionnalité de sécurité destinée à simplifier la vie de l’utilisateur pour l’authentification et d’aller progressivement vers le « passwordless ». En effet, l’utilisateur peut ouvrir sa session Windows avec un PIN, une empreinte digitale ou la reconnaissance faciale (si l’ordinateur dispose du matériel adapté).

Cette technologie utilise un certificat utilisateur (un peu comme une smart card) qui est stocké dans le module TPM de l’ordinateur (s’il y en a un et dans le cas contraire, seulement si c’est autorisé sans module TPM).

Il y a plusieurs liens intéressants sur le site de Microsoft pour en apprendre plus et configurer:.

1. Windows Hello for Business Overview
2. Windows Hello for Business Frequently Asked Questions (FAQ)
3. Windows Hello for Business Deployment Overview (toute la section concerne la configuration, c’est le point sur lequel je vais revenir dans cet article)
4. Et de la documentation plus technique sur les étapes de Provisioning et d’Authentification pour mieux comprendre comment ça fonctionne

Au niveau de la configuration, comme on peut le voir dans le lien 3, il y a plusieurs possibilités de configuration. Je vais me pencher sur le modèle « certificate-trust » qui peut paraitre plus complexe à configurer que le modèle « key-trust » (et c’est vrai) mais qui permet de se connecter depuis son poste de travail configuré pour Windows Hello for Business à d’autres machines distantes en RDP en utilisateur l’authentification PIN/empreinte/figure, ce qui va jusqu’au bout de l’utilisation de cette technologie. Dans le mode « key-trust », l’utilisateur ne pourra pas utiliser l’authentification Windows Hello for Business pour se connecter en RDP sur des machines distantes et devra continuer à saisir son mot de passe.

Dans la continuité du précédent article où je parlais de Hybrid Azure AD Join, je vais donc parler en toute logique du scénario Hybrid Azure AD Joined Certificate Trust Deployment. Voici les points importants selon moi, dans l’ordre de la documentation. Je ne couvre pas tous les points de la documentation, seulement ceux qui méritent une attention particulière.

1 – Prérequis

• Le schéma AD doit être en Windows Server 2016. Mais cela ne veut pas dire qu’il faut avoir les DC en 2016, ils peuvent encore être en 2012 R2 par exemple – mais il serait temps de les migrer dans une version ultérieur, la fin de support de Windows Server 2012 R2 est en Octobre 2023)
• Il faut disposer d’une PKI « Enterprise » (c’est-à-dire intégrée à Active Directory) basée sur Windows Server
• Il faut Azure AD Connect. C’est en général déjà là puisqu’on parle de configuration hybride
• Il faut utiliser AD FS pour l’authentification (2016 ou 2019). Il n’est pas possible d’utiliser PTA ou PHS. Il faut aussi avoir configuré le MFA avec AD FS. Soit le MFA Azure, soit un autre, mais il en faut un
• Avoir Azure AD Premium P1 pour utiliser le Device Writeback d’Azure AD Connect

2 – PKI

La documentation Microsoft explique comment installer une PKI très rapidement, c’est OK pour un lab mais surtout pas en production ! Une infrastructure PKI n’est pas à prendre à la légère, il faut la concevoir et la paramétrer correctement. Le mieux est de déléguer ce travail à un consultant spécialisé pour que toutes les bonnes questions soient posées et que les bonnes pratiques soient suivies (sans oublier les étapes cruciales de renouvellement des certificats des autorités de certificats, le disaster recovery…).

3 – Azure AD Device Registration

Dans le cas où Hybrid Azure AD Join est configuré, la quasi totalité de la configuration est faite, il suffit de vérifier ce qui est déjà configuré notamment dans Active Directory. A ce jour, la documentation donne des informations pour Azure AD Connect 1.0 mais certaines opérations ne sont plus nécessaires lorsqu’on utilise Azure AD Connect 2.0 qui le fait lui-même (par exemple le module AdSyncPrep.psm1 n’est plus disponible dans Azure AD Connect 2.0, c’est fait directement dans l’assistant Azure AD Connect).

4 – Azure AD Device Write Back

Chaque ordinateur enregistré dans Azure AD (y compris les PC du domaine en Hybrid AAD Join) aura un nouvel objet dans Active Directory. La commande PowerShell Initialize-ADSyncDeviceWriteBack va positionner les bonnes permissions et l’assistant Azure AD Connect va configuer des nouvelles règles de synchronisation dans le moteur de synchronisation entre AD et Azure AD.

A noter : si vous ne voulez pas synchroniser dans AD tous les périphériques enregistrés dans Azure AD, mais uniquement les PC Hybrid AAD Join, il faut juste après cette configuration ouvrir le Synchronization Rules Editor d’Azure AD Connect et désactiver la règle « In from AAD – Device Join SOAInAAD ». Par défaut activée une fois le Device Write Back configuré, cette règle crée les objets dans AD pour ceux qui sont Azure AD Join (et pas Hybrid Azure AD Join). Pour résumer, la règle dit « si l’objet a été créé dans Azure AD et que c’est le maître, alors crée le dans AD ». Dans le cas d’un PC Hybrid Join, l’objet correspondant au PC dans Azure AD est créé par la synchro Azure AD Connect (depuis AD vers AAD) et donc cette règle ne s’applique pas dans tous les cas. Ici, il s’agit de la règle 234.

5 – AD FS

La documentation mentionne plein de claims à configurer. Ils sont tous déjà configurés par Azure AD Connect (des fois avec une syntaxe légèrement différente mais avec le même résultat). La seule règle non existante dans AD FS par défaut est la suivante, qui n’est à mettre que lorsqu’on utilise un Alternate Login ID pour les utilisateurs :

6 – Certificate Templates

Si la règle 224 a été désactivée plus haut pour ne pas synchroniser les objects Azure AD Join dans AD, il n’est pas nécessaire de faire l’étape de configuration « Domain Controller certificate template » car celle-ci n’est pas nécessaire pour les périphériques Hybrid AAD Join.

7 – Federation Services

Avec AD FS 2019, vérifiez que vous avez bien la permission « ugs » sinon il faut suivre cette partie de la procédure. Dans le cas contraire, il y aura plein d’erreurs dans l’Event Log AD FS et Windows Hello for Business ne fonctionnera pas complètement.

En résumé, lorsque les périphériques sont configurés pour Hybrid Azure AD Join avant la configuration de Windows Hello, la configuration de Windows Hello est relativement simple, si une PKI est déjà disponible et fonctionnelle. Le reste n’est que configuration à faire en prenant son temps, en comprenant l’état avant de faire une action et vérifier l’état après avoir effectué chaque action.

— Stefan