Vous débutez votre transition vers le cloud via Office 365 et/ou Azure ? Vous allez donc probablement avoir recourt à un composant appelé AAD Connect qui permet de synchroniser vos comptes depuis votre AD on-prem vers votre Azure Active Directory. Je ne vais pas rentrer dans les détails de cette solution car j’ai déjà réalisé plusieurs articles sur le sujet. En cas de besoin, je vous invite à consulter les liens suivants :
- Configuration de AAD Connect (Azure Active Directory Connect) et synchronisation avec Office 365
- Installer et configurer Azure AD Connect pour synchroniser votre AD avec Office 365
En revanche, je souhaite revenir sur une question fondamentale que vous allez certainement vous poser lors de l’installation de votre AAD Connect : quelle méthode d’authentification allez-vous choisir pour vos utilisateurs ?
Il existe en effet plusieurs choix possibles :
- Password Hash Synchronization (PhS)
- Active Directory Federation Services (ADFS)
- Pass-Through Authentication (PTA)
D’autres méthodes sont également possibles avec des outils non-Microsoft comme par exemple : PingFederate, Okta, etc. Mais nous nous intéresserons uniquement aux solutions Microsoft.
Méthode 1 – Password Hash Synchronization
Cette méthode d’authentification est l’une des plus anciennes avec l’ADFS. C’est également la plus simple à déployer puisque vous n’aurez besoin d’installer que 1 serveur AAD Connect. C’est en effet le même outil qui va s’occuper de la synchronisation des identités mais également des mots de passe. Mais attention, je vous vois arriver : Microsoft va connaître tous nos mots de passe, oh la la la… Non ce n’est pas le cas !
L’AAD Connect va simplement partager une version de votre mot de passe que l’on appelle “hash“. Contrairement, au chiffrement, le hash n’est pas réversible et on ne peut pas revenir à la chaîne de caractère initiale. De plus, Microsoft ne va pas se contenter de le faire 1 fois mais va l’appliquer 1 000 fois !
Malheureusement, cette méthode a mauvaise réputation simplement parce que les gens s’arrêtent au nom de la fonctionnalité sans entrer dans les détails. Si vous voulez voir exactement comment Microsoft protège votre mot de passe, je vous invite à consulter le lien suivant.
Comme Microsoft connaît le hash du mot de passe, il peut réaliser l’authentification directement dans le Cloud sans passer par l’infrastructure on-premises. J’insiste donc – dans ce scénario l’authentification est réalisée dans le Cloud – par l’infrastructure de Microsoft.
Méthode 2 – Fédération avec ADFS
L’ADFS est le scénario le plus utilisé au sein des entreprises. Vous aurez toujours besoin de l’AAD Connect mais l’authentification que vous utiliserez est dite fédérée. Cela signifie que lorsque vous accédez à vos services Office 365 et/ou Azure, Microsoft s’appuiera sur votre infrastructure on-prem ADFS pour authentifier vos collaborateurs.
Dans ce cas, nous avons toujours besoin d’un serveur AAD Connect. Mais nous aurons aussi besoin de déployer une ferme ADFS. Comme cette dernière sera responsable de toutes les authentifications de vos collaborateurs pour accéder aux services – ce service devient hautement critique.
De ce fait, votre ferme ADFS sera généralement composée comme suit :
- 2 serveurs ADFS (au moins) ;
- 2 serveurs proxy (au moins) – car on ne publie pas un serveur ADFS sur du réseau périmétrique ;
- 0 à 2 serveurs en fonction du choix que vous ferez pour la base de données ADFS : s’agira-t-il d’une base WID ou bien d’un Always-On/Cluster ?
Si votre infrastructure ou votre datacenter a un problème, aucune authentification n’est possible. Vous ajouterez donc probablement plus de serveurs que je ne l’ai précédemment mentionné et si votre entreprise est multi-sites il y en aura probablement sur chaque site.
On voit donc aisément que cette méthode est bien plus “lourde” en termes d’infrastructure. Vous devez disposer de compétences ADFS et vous devrez gérer tous les serveurs mentionnés ce qui veut dire qu’ils devront être monitorés, sauvegardés, etc. On arrive donc au mieux à 5 serveurs minimum (en comptant l’AAD Connect qui est nécessaire dans tous les cas de figure).
Méthode 3 – Pass-Through Authentication
Finalement, il nous reste une troisième méthode à voir : Pass-Trough Authentication. Dans ce dernier scénario, l’authentification est toujours réalisée par l’infrastructure On-prem mais on va déployer 1 agent spécifique qui sera responsable de l’authentification.
Cet agent sera déployé au sein de votre infrastructure on-prem. Et vue qu’il est nécessaire pour toute authentification, vous le doublerez probablement en l’installant sur 2 serveurs (au minimum). Très souvent, on l’installe 1 fois sur le serveur AAD Connect et sur un second serveur indépendant.
J’ai donc déployé 2 serveurs : l’AAD Connect qui dispose d’un agent PTA + un second agent PTA sur une autre VM.
Utilisation de PhS vs. ADFS
Au début d’Office 365, il y avait clairement une très forte proportion d’ADFS par rapport à PhS – sachant que la méthode PTA est arrivée plus tardivement. Pourquoi ? Probablement parce que les gens pensent (encore aujourd’hui) que Microsoft risque de connaître les mots de passe des utilisateurs. Donc en gros, il y avait environ 80% ou 85% d’ADFS par rapport à PhS.
Cela étant, depuis quelques années, la tendance est claire : beaucoup abandonnent l’ADFS au profit du PhS. Plusieurs raisons à cela : de plus en plus d’applications sont directement intégrées à l’Azure AD et n’ont plus besoin de l’infrastructure ADFS on-prem pour fonctionner. Mais surtout, l’infrastructure ADFS doit être disponible de manière permanente pour les authentifications et donc au moindre incident, plus aucune authentification n’est possible. A l’inverse, avec la méthode PhS, l’authentification ne s’appuie pas sur votre infra mais sur l’infra de Microsoft (alors bien sûr l’éditeur a également des indispos mais je vous laisse comparer par rapport à vos SLA).
Et surtout un type d’attaque est venue tout changer… Les attaques de ransomwares ! En effet, si votre infrastructure on-prem est touchée par un ransomware, vos serveurs ADFS, DC, … peuvent être tous indisponibles. En utilisant la méthode PhS, même si votre datacenter est down, les collaborateurs pourront toujours accéder à leurs services dans Office 365. C’est un argument très important que beaucoup d’entreprises ont bien compris en cas d’attaque. C’est pourquoi on voit que le pourcentage d’ADFS diminue régulièrement au profit de PhS. Aujourd’hui, on serait plutôt à 30 ou 35% de PhS selon les entreprises.
Mais alors alors comment choisir ? Quelles sont les bonnes questions à se poser ? 😀
Comment choisir votre méthode d’authentification
Ceux qui me connaissent savent que j’aime bien les “recettes de cuisine” pour se souvenir de quelque-chose. Alors voici comment j’aborde ce choix avec les personnes avec qui je travaille :
- Est-ce que je souhaite que être responsable de l’authentification ou est-ce que je préfère compter sur l’infrastructure de Microsoft ? Si vous préférez utiliser les infrastructures O365 et Azure, alors ne cherchez pas plus loin et choisissez la méthode PhS. Elle possède l’avantage d’avoir un très faible besoin en termes de serveurs/VM et en cas d’indisponibilité de votre datacenter, les collaborateurs continuent d’accéder aux services O365 avec le client-lourd et/ou les interfaces web.
- Si en revanche, vous souhaitez gérer l’authentification alors vous devrez choisir entre l’ADFS et le PTA. Pour ce choix, vous devez répondre aux questions suivantes : est-ce que je souhaite gérer une ferme ADFS ? Ai-je des compétences ADFS en interne ? Est-ce que j’en avais déjà une avant ? Si vous répondez oui à une de ces questions, vous pouvez partir sur le choix ADFS. En revanche, si vous n’avez jamais touché à l’ADFS et que vous vous préparez à le déployer spécifiquement pour l’AAD Connect – je vous encourage fortement à vous poser la question du PTA. En effet, cette méthode vous évite la gestion d’une ferme ADFS et ne nécessite que 2 VM.
Sur sa page officielle Microsoft propose l’organigramme ci-dessous que je vous invite à consulter (en anglais).
Combinaison de méthodes
Et là, vous allez me dire : mais Thibault, le diagramme semble plus compliqué que ce que tu nous as expliqué… Et vous aurez complètement raison. Il me reste en effet un dernier point à partager avec vous. 😀
Certaines méthodes d’authentification peuvent être combinées ! 😉
Les méthodes ADFS et PTA peuvent être activées en “principal” tout en activant en secondaire la méthode PhS. Un scénario que l’on retrouve de manière très importante au sein des entreprises afin de pouvoir continuer à offrir tous les services O365 en cas d’indisponibilité de l’infrastructure on-prem.
La question du SSO
Et enfin, je terminerai sur le SSO… Si comme beaucoup d’entreprises vous avez des besoins en termes de SSO, sachez qu’il n’y a pas que l’ADFS qui répondra à ce besoin. En effet, avec les méthodes PhS et PTA, vous pouvez activer une option que l’on appelle Seamless SSO. Cette fonctionnalité vous permettra d’apporter du SSO à vos utilisateurs – même sans ADFS. Attention toutefois, vérifiez bien la compatibilité de vos applications en interne car ce n’est évidemment pas aussi paramétrable qu’une ferme ADFS.
Voilà, c’est terminé. J’espère que c’est clair pour vous et que ça vous permettra de faire votre choix en ayant tout compris. Dans tous les cas, rien de grave, sachez que vous pouvez basculez d’une méthode à une autre très facilement en cas d’erreur. Pour ce faire, relancez simplement l’assistant AAD Connect et modifiez votre sélection.
Pour toute question, n’hésitez pas à utiliser la zone dédiée au commentaires ! 😀
