À l'heure où les entreprises intègrent le cloud computing à leur modèle économique, une grande partie d'entre elles choisissent de connecter leur environnement Active Directory sur site à son équivalent dans le cloud, Azure Active Directory de Microsoft. Lorsque vous étendez votre AD sur site à Azure AD, deux options s’offrent à vous pour l’authentification des utilisateurs sur site auprès du service cloud : la fédération d’identités et l’authentification directe avec Azure AD. Bien que l’authentification directe soit techniquement la méthode la plus simple des deux, elle nécessite l’activation d’une fonctionnalité appelée « synchronisation des mots de passe ». Or, je pense que la synchronisation des mots de passe est une fonctionnalité assez mal comprise qui mérite d’être mieux expliquée.
Microsoft propose deux méthodes pour gérer l'authentification vers Azure AD : la fédération d'identités ou l'authentification directe via Azure AD lui-même. La fédération d'identités avec un service de fédération tel qu'AD FS ou PingFederate permet une authentification unique (Single Sign-On) sur Azure AD en redirigeant les utilisateurs depuis le service cloud vers leur Active Directory local pour l'authentification. L'autre option, l'authentification directe dans Azure AD, nécessite que l'identifiant et le mot de passe de l'utilisateur soient stockés localement dans le service cloud. Pour les entreprises, cela doit être effectué à l'aide de la fonctionnalité de synchronisation des mots de passe du service AD Connect de Microsoft ; aucun fournisseur tiers ne propose de fonctionnalité équivalente.
Qu'est-ce que la synchronisation des hachages de mots de passe et pourquoi l'utiliser ?
À son niveau le plus simple, celui d’un croquis griffonné sur une serviette de cocktail, la synchronisation des hachages de mots de passe (une description plus précise, que j’expliquerai ci-dessous) copie le mot de passe de l’utilisateur depuis AD vers Azure AD toutes les deux minutes. Cela permet aux utilisateurs de se connecter à Azure AD avec le même identifiant et le même mot de passe que ceux qu’ils utilisent pour se connecter à AD. Microsoft appelle ce modèle « same sign-on ». Il se distingue de l’authentification unique (« single sign-on ») car, avec la synchronisation des hachages de mot de passe, les utilisateurs sont invités à se connecter à Azure AD en plus de toute connexion d’entreprise qu’ils ont déjà effectuée.
Pourquoi utiliser la synchronisation des hachages de mots de passe ? Principalement parce qu'elle est plus simple à mettre en œuvre qu'un service de fédération. Microsoft devait proposer un moyen simple d'intégrer les utilisateurs d'Active Directory sur site à Azure AD, et la synchronisation des hachages de mots de passe permet d'y parvenir sans avoir recours à un service de fédération hautement disponible reposant sur plusieurs serveurs.
Et la solution la plus simple s'est avérée populaire ; environ 50 % des organisations qui synchronisent avec Azure AD utilisent la synchronisation par hachage de mot de passe. Sur ces 50 %, la moitié sont des petites et moyennes entreprises. La synchronisation par hachage de mot de passe permet à ces organisations de passer en douceur à une infrastructure informatique "cloud-first" ou "cloud-only", car les utilisateurs s'authentifient déjà directement auprès du service Azure AD.
Un autre avantage de la synchronisation des hachages de mots de passe est que, contrairement à la fédération, elle ne dépend pas d'un service de fédération externe pour traiter les authentifications. En effet, Microsoft propose la synchronisation des hachages de mots de passe en complément de la fédération, afin qu'elle puisse servir de solution de secours en cas de panne de votre service de fédération.
Quel est le degré de sécurité de la synchronisation par hachage des mots de passe ?
Notez que je parle ici de « synchronisation des hachages de mots de passe » et non de « synchronisation des mots de passe ». C'est une distinction importante. Les mots de passe en clair ne sont pas synchronisés entre AD DS et Azure AD. Non seulement ce n’est pas une bonne idée, mais cela n’est même pas techniquement possible, car Active Directory ne dispose pas des mots de passe en clair. Lorsqu’un utilisateur crée ou met à jour son mot de passe dans AD, celui-ci est stocké sous la forme d’un hachage MD5 à sens unique sur les contrôleurs de domaine (DC) du domaine. C’est ce hachage qui est synchronisé vers Azure AD et stocké dans le magasin d’identifiants du service.
Comment cela fonctionne-t-il exactement ? J'ai rassemblé les étapes suivantes à partir de l'article d'Alex Simon intitulé « AAD Password Sync, Encryption, and FIPS Compliance » ( Synchronisation des mots de passe AAD , chiffrement et conformité FIPS) et de quelques autres sources :
- Les mots de passe des utilisateurs sont stockés sous la forme d'un hachage non réversible dans les contrôleurs de domaine (DC) Windows Server Active Directory. Lorsque l'agent de synchronisation des mots de passe d'AD Connect tente de synchroniser le hachage du mot de passe, le DC chiffre le hachage. Le chiffrement est effectué avec une clé dérivée de la clé de session RPC par salage. La dérivation de la clé est la suivante [où SaltedEncryptionKey = MD5 (RPC session Key, 128 bit random salt)]. Le DC transmet également le sel à l'agent de synchronisation en utilisant le protocole de réplication.
- Le hachage du mot de passe original est répliqué (à l'aide du protocole de réplication du DC) du DC vers l'agent Password Sync.
- L'agent de synchronisation des mots de passe déchiffre le hachage chiffré en dérivant la clé comme décrit ci-dessus. L'agent de synchronisation du mot de passe utilise MD5 pour dériver la clé, car la dérivation doit être identique à celle effectuée par le DC (lorsqu'il a crypté les données). De plus, MD5 est le niveau le plus élevé disponible pour cette action dans le protocole de réplication du DC des déploiements existants de Windows Server Active directory.
- Une fois le décryptage effectué, l'agent de synchronisation prend le hachage du mot de passe original résultant et le recompose en un hachage SHA256 en utilisant l'algorithme de dérivation de clé PKDF2 tel que défini dans la RFC 2898.
- L'agent Password Sync synchronise ensuite le hachage SHA256 du mot de passe sur le câble (un relais Service Bus crypté dédié au locataire Azure AD) vers Azure AD.
- Une fois que la copie du hachage SHA256 du mot de passe original atteint Azure AD, Azure AD chiffre le hachage avec l'algorithme AES avant de le stocker dans la base de données en nuage.
La seule chose qui traverse le câble sur le chemin d'Azure AD est une copie hachée SHA256 du hachage du mot de passe original. L'utilisation de MD5 par l'agent de synchronisation des mots de passe est strictement destinée à assurer la compatibilité du protocole de réplication avec le DC et n'est utilisée, sur site, qu'entre le DC et l'agent de synchronisation des mots de passe.
Inconvénients de la synchronisation par hachage du mot de passe
Du point de vue de l'utilisateur, l'inconvénient le plus évident est qu'il doit saisir ses identifiants d'entreprise une deuxième fois, qu'il soit connecté à son réseau d'entreprise ou qu'il se trouve à l'extérieur sur un réseau public. Il est toutefois possible de limiter ces connexions en cochant la case « Rester connecté » (KMSI). Cochez cette case pour créer un cookie de session qui contourne l’authentification pendant une courte période. Votre équipe de sécurité devra se prononcer à ce sujet, et le comportement KMSI peut être activé ou désactivé par l’administrateur Azure AD.
Du point de vue d'un professionnel de la gestion des identités, le problème lié à la synchronisation des hachages de mots de passe réside dans le fait que le mot de passe est diffusé à plusieurs endroits à des fins d'authentification. À l'inverse, la fédération redirige toutes les demandes d'authentification vers le fournisseur d'identité. Microsoft a déployé des efforts considérables pour garantir la sécurité du processus, mais il est légitime de s'interroger sur le cycle de vie du mot de passe.
Quand faut-il utiliser la synchronisation des hachages de mots de passe ?
Il existe un cas d'utilisation pour lequel vous devez utiliser la synchronisation du hachage des mots de passe : si vous choisissez d'implémenter les services de domaine Azure AD. Cette fonctionnalité crée un contrôleur de domaine en tant que service que les applications Azure (telles que les machines virtuelles exécutant des applications dépendantes d'AD) peuvent utiliser. Cependant, pour que ces DC soient fonctionnellement équivalents aux DC sur site, ils doivent avoir des hachages de mots de passe d'utilisateur et nécessitent donc une synchronisation de hachage de mots de passe pour les intégrer dans Azure.
La synchronisation des hachages de mots de passe est une solution couramment utilisée pour intégrer vos identités sur site à Azure AD. Elle n'est pas aussi élégante que la fédération d'identités, mais elle est plus simple. Comme pour tout choix de conception, assurez-vous d'avoir bien pesé les avantages et les inconvénients de cette solution, ainsi que leur impact sur votre situation.
