Maintenant que les entreprises adoptent l'informatique en nuage dans le cadre de leur modèle d'entreprise, un grand nombre d'entre elles choisissent de connecter leur environnement Active Directory sur site à son équivalent dans le nuage, Azure Active Directory de Microsoft. Lorsque vous étendez votre AD sur site à Azure AD, vous avez le choix entre deux méthodes d'authentification des utilisateurs sur site au service en nuage : la fédération d'identités et l'authentification directe à l'aide d'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é connue sous le nom de synchronisation des mots de passe. Et je pense que la synchronisation des mots de passe est une fonctionnalité assez mal comprise qui mérite plus d'explications.
Microsoft propose deux façons de gérer l'authentification à Azure AD : la fédération d'identité ou l'authentification directe à l'aide d'Azure AD lui-même. La fédération d'identité avec un service de fédération tel qu'AD FS ou PingFederate permet une authentification unique à Azure AD en redirigeant les utilisateurs du service en nuage vers leur AD local pour l'authentification. L'autre option, l'authentification directe dans Azure AD, exige que l'identifiant et le mot de passe de l'utilisateur soient stockés localement dans le service en nuage. Pour les entreprises, cela doit être fait avec la fonction de synchronisation des mots de passe du service AD Connect de Microsoft ; aucune tierce partie ne fournit une capacité équivalente.
Qu'est-ce que la synchronisation des hachages de mots de passe et pourquoi l'utiliser ?
À son niveau le plus simple, celui d'une esquisse de cocktail-party, la synchronisation du hachage du mot de passe (une description plus précise, que j'expliquerai ci-dessous) copie le mot de passe de l'utilisateur d'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 car, avec la synchronisation du hachage du mot de passe, les utilisateurs sont invités à se connecter à Azure AD en plus de toute autre connexion d'entreprise qu'ils ont effectuée.
Pourquoi voudriez-vous 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 avait besoin de fournir un moyen facile d'intégrer les utilisateurs AD sur site avec Azure AD, et Password hash sync le fait sans avoir besoin d'un service de fédération à plusieurs serveurs et à haute disponibilité.
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 du hachage des 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 fait, Microsoft propose la synchronisation du hachage des mots de passe en plus de la fédération, de sorte qu'elle peut être utilisée comme solution de repli si votre service de fédération subit une panne.
Quel est le degré de sécurité de la synchronisation par hachage des mots de passe ?
Notez que je décris cette fonctionnalité comme la synchronisation des hachages de mots de passe, et non comme la synchronisation des mots de passe. Il s'agit d'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 ce 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 DC du domaine. C'est ce hachage qui est synchronisé avec Azure AD et stocké dans le magasin d'informations d'identification du service.
Comment cela fonctionne-t-il exactement ? J'ai compilé les étapes suivantes à partir de l'article du blog d'Alex Simon intitulé AAD Password Sync, Encryption, and FIPS Compliance (Synchronisation des mots de passe, 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 une deuxième fois ses données d'identification, qu'il soit connecté au réseau de son entreprise ou à un réseau public. Il est toutefois possible de réduire le nombre de ces connexions en cochant la case "Keep me signed in" (KMSI). Cette case définit un cookie de session qui contourne l'authentification pendant une courte période. Votre équipe de sécurité devra se prononcer sur ce point, et l'administrateur Azure AD peut activer ou désactiver le comportement KMSI.
Du point de vue du professionnel de l'identité, le problème de la synchronisation du hachage du mot de passe est que vous distribuez le mot de passe à plus d'un endroit pour l'authentification. En revanche, la fédération redirige toutes les demandes d'authentification vers le fournisseur d'identité. Microsoft s'est donné beaucoup de mal pour garantir la sécurité du processus, mais il est légitime de se poser des questions 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 du hachage des mots de passe est une solution très répandue pour intégrer vos identités sur site à Azure AD. Cette solution n'est pas aussi élégante que la fédération d'identité, mais elle est plus simple. Comme pour toute décision de conception, assurez-vous d'avoir examiné les forces et les faiblesses de cette solution et de savoir comment elles s'appliquent à votre situation.
