Deux nouveaux services hybrides de Microsoft simplifient considérablement la connexion de votre Active Directory à Azure

Microsoft a récemment annoncé la préversion publique de deux nouvelles fonctionnalités majeures qui faciliteront considérablement l'intégration de votre Active Directory sur site à Azure AD. L'authentification par transit (PTA) et l'authentification unique transparente (que je choisirai d'appeler 3SO) permettront à vos utilisateurs d'accéder facilement aux applications Azure AD telles qu'Office 365 sans avoir à installer une ferme complexe d'Active Directory Federation Services (AD FS) dans votre centre de données ni à synchroniser les hachages des mots de passe des utilisateurs avec Azure AD.

Ou, dans le cas de 3SO, en installant quoi que ce soit de plus.

Les choix d'authentification hybride jusqu'à présent (et leurs limites)

Aujourd’hui, la grande majorité des entreprises s’appuie sur Active Directory comme service d’identité de base, et celui-ci n’est pas près de disparaître. Ainsi, l’une des premières étapes fondamentales lorsque l’on envisage d’utiliser l’un des services en ligne de Microsoft consiste à intégrer votre Active Directory sur site à Azure AD afin de bénéficier de deux fonctionnalités. Tout d’abord, vous devez synchroniser les comptes et les groupes AD avec Azure AD à l’aide d’Azure AD Connect. Ensuite, une fois les comptes transférés dans Azure AD, vous devez choisir le mode d’authentification des utilisateurs sur cette plateforme. Dans cet article, je me concentre sur les aspects liés à l’authentification des utilisateurs.

Aujourd'hui, Microsoft vous propose deux options d'authentification : AD FS, qui offre la fédération d'identités (ainsi que plusieurs autres fonctionnalités) pour l'authentification unique (SSO), et la synchronisation des mots de passe (« PHS » dans les graphiques ci-dessous). Cette deuxième option, connue des experts en informatique sous le nom de « synchronisation des hachages de mots de passe » (d'où le « H »), offre une fonctionnalité de « connexion unique » : l'utilisateur doit saisir ses identifiants une deuxième fois pour se connecter à Azure AD, mais il s'agit du même identifiant et du même mot de passe que ceux qu'il utilise pour Active Directory.

Ross Adams, responsable du programme d'authentification passthrough de Microsoft, présente les différences entre ces solutions dans ce graphique astucieux des avantages et des inconvénients (figure 1) :

Par ordre croissant de complexité et de valeur, nous avons

• Comptes exclusivement dans le cloud : les comptes utilisateur sont gérés et authentifiés dans Azure AD. Cet article portant sur les solutions hybrides, nous ne nous attarderons pas sur ce point.
• AAD Connect / Comptes cloud : vous pouvez utiliser Azure AD Connect pour synchroniser les comptes utilisateur vers Azure AD afin que l'identifiant de connexion (généralement l'adresse e-mail de l'utilisateur) reste le même, mais les utilisateurs doivent gérer eux-mêmes leurs mots de passe dans le service cloud. Je ne vois personne faire cela.
• AAD Connect + PHS : Lorsque vous activez la fonction optionnelle de synchronisation des hachages de mots de passe dans Azure AD Connect, les hachages de mots de passe des utilisateurs stockés dans votre Active Directory sur site seront synchronisés dans Azure AD, ce qui permettra une authentification identique.
• AAD Connect + AD FS : La solution la plus complète et la plus complexe, et de loin, cette combinaison fournit un SSO à Azure AD, en s'authentifiant par rapport aux comptes de votre Active Directory local.

Comme vous pouvez le constater, la mise en place d'un véritable SSO au sein de votre entreprise présente un niveau de complexité considérable. Les solutions tierces proposées par Okta, Ping Identity, OneLogin, Centrify, OptimalIDM et d'autres fournisseurs offrent des méthodes d'authentification plus simples qui comblent cette lacune, ce qui explique en partie leur popularité.

Windows joint au domaine...et tout le reste

Pour bien comprendre ce qu'apportent ces deux nouvelles solutions en préversion publique, il est utile de classer les cas d'utilisation de l'authentification en deux catégories : soit le client devant être authentifié par Azure AD dispose d'un ticket Kerberos, soit il n'en a pas.

Le premier est le scénario classique d’authentification d’entreprise sous Windows, connu sous le nom d’« authentification Windows intégrée » (IWA). Un utilisateur connecté à son poste de travail Windows affilié au domaine à l’aide d’un compte AD, sur le réseau d’entreprise (c’est-à-dire que le poste de travail peut trouver un contrôleur de domaine) et disposant donc d’un ticket Kerberos, bénéficie d’un accès transparent aux ressources compatibles avec AD sans qu’on lui demande de saisir son mot de passe. Ce scénario existe depuis la création d’Active Directory.

Le deuxième seau représente les autres scénarios d'authentification qui ont évolué depuis :

• Un poste de travail relié à un domaine qui tente de s'authentifier depuis l'extérieur du réseau (l'ordinateur portable).
• Un client basé sur un navigateur, qu'il s'agisse d'un ordinateur de bureau ou d'un appareil mobile (le navigateur Web)
• Un client basé sur une API, tel qu'une application Office (l'application mobile)

Examinons d'abord le cas d'un poste de travail affilié à un domaine, ainsi que la solution ingénieuse proposée par Microsoft via 3SO.

Qu'est-ce que l'authentification unique transparente ?

3SO est conçu pour fonctionner avec le premier bucket - le PC relié au domaine sur le réseau de l'entreprise. L'élégance de la solution 3SO peut être résumée en quelques mots : Azure AD peut désormais prendre en charge l'authentification Kerberos.

C'est tout. En résumé, l'objectif principal d'AD FS est de transformer un ticket Kerberos en un jeton de sécurité SAML ou OAuth moderne pouvant être utilisé par une partie de confiance telle qu'Azure AD. Si Azure AD est capable d'interpréter un ticket Kerberos – en particulier un ticket de service pour une ressource Azure –, vous n'avez pas besoin de l'intermédiaire AD FS pour effectuer cette conversion.

La figure 2 illustre cette procédure. Azure AD est représenté dans votre AD local comme n'importe quel autre ordinateur ; AD ne fait pas la différence. Un compte d’ordinateur (AZUREADSSOACCT) est ajouté à votre AD, ainsi que deux SPN (noms d’entité de service) contenant les URL nécessaires à l’authentification. La clé secrète Kerberos du compte de poste de travail est partagée de manière sécurisée avec Azure AD. À partir de ce moment, les clients utilisent IWA pour accéder aux ressources Azure, exactement comme ils accéderaient à un serveur IIS dans votre centre de données local.

1. Un utilisateur tente d'accéder à une ressource Azure AD telle qu'Office 365. Azure AD demande à l'utilisateur de fournir un ticket de service Kerberos.
2. Le client présente son TGT (ticket-granting ticket) et le SPN du serveur cible (une URL Azure AD dans ce cas) à son contrôleur de domaine.
3. Le service de délivrance de tickets (TGS) intégré au centre de distribution de clés (KDC) du contrôleur de domaine crée un ticket de service pour la ressource Azure AD et le renvoie au client.
4. Le client présente le ticket de service à Azure AD. Si le ticket est valide, l'utilisateur est authentifié.

Notez que ce processus ne signifie pas que l'utilisateur est autorisé à accéder à la ressource, mais simplement qu'il a prouvé son identité. Ainsi, un utilisateur Windows de l'entreprise se connectant depuis le réseau n'est pas invité à saisir un mot de passe pour accéder aux ressources Azure AD, et AD FS n'est pas nécessaire. Plutôt astucieux, non ?

L'installation de 3SO est on ne peut plus simple : il suffit de cocher la case « Activer l'authentification unique » dans la configuration personnalisée de la dernière version d'AD Connect.

Clients soutenus

Il existe plusieurs configurations prises en charge pour 3SO. Tout d’abord, il doit s’agir d’un client prenant en charge Kerberos, tel que Windows. Ensuite, cette fonctionnalité permet d’accéder aux ressources Azure AD via un navigateur (par exemple https://outlook.office.com) ou à partir d’un client Office prenant en charge l’authentification moderne. Vous pouvez consulter la liste des clients pris en charge, mais en substance, cette fonctionnalité est prise en charge par tous les principaux navigateurs (IE, Chrome, Firefox) à l'exception d'Edge, ainsi que par tous les systèmes d'exploitation clients Microsoft pris en charge. Microsoft recommande d'activer 3SO pour tous les clients ; si l'utilisateur se trouve dans une configuration non prise en charge, le pire qui puisse arriver est qu'il soit invité à saisir son mot de passe.

Qu'est-ce que l'authentification par transparence ?

Le protocole PTA est conçu pour les cas où le client ne dispose pas de ticket Kerberos, soit parce que le client Kerberos ne parvient pas à se connecter à un contrôleur de domaine (par exemple, lorsqu'un employé travaille depuis son domicile sur son ordinateur portable d'entreprise), soit parce que le client ne prend pas en charge Kerberos (par exemple, un navigateur mobile ou une application qui ne prend pas en charge l'authentification moderne).

Je ne vais pas aborder ici la procédure d'installation de PTA, mais en substance, vous déployez un ou plusieurs connecteurs légers sur site, à l'instar du connecteur Azure AD Application Proxy, sur des serveurs membres d'un domaine où ils peuvent communiquer avec un contrôleur de domaine.

À un niveau élevé, le processus d'authentification PTA ressemble beaucoup au processus d'authentification AD FS : Azure AD reconnaît que la demande d'authentification est déléguée à un Active Directory sur site via un proxy. Pour AD FS, il agit en tant que proxy. Pour PTA, ce sont les connecteurs qui jouent le rôle de proxy (Figure 3).

1. Azure AD invite l'utilisateur à s'authentifier et celui-ci saisit son adresse électronique et son mot de passe.
2. Azure AD détecte que le domaine de l'utilisateur est configuré pour le PTA ; Azure AD en informe le connecteur, qui récupère alors les informations d'identification.
3. Le connecteur authentifie l'utilisateur auprès d'AD à l'aide de la même API Windows que celle utilisée par AD FS.
4. La réponse est renvoyée au connecteur.
5. Le connecteur transmet la réponse à Azure AD.
6. Azure AD délivre un jeton à l'utilisateur.

Vous pouvez constater que cette méthode présente de nombreux avantages par rapport à AD FS :

• Les connecteurs peuvent être installés sur des serveurs ou des DC existants, reliés à un domaine.
• Lorsque plusieurs connecteurs sont installés (ce qui est recommandé), PTA répartit automatiquement la charge entre eux.
• Toutes les connexions Azure sont sortantes et aucun point d'extrémité non authentifié n'est exposé à l'internet.
• La gestion est très simple depuis le portail Azure, et il n'y a aucun certificat à gérer

Quand voudriez-vous encore utiliser AD FS ?

Ne vous y trompez pas, AD FS n'a en aucun cas été mis de côté. PTA est une flèche très spécialisée pour une cible unique : elle permet à Azure AD d'authentifier les utilisateurs d'Active Directory par rapport à l'AD de leur entreprise, un point c'est tout. Vous avez toujours besoin d'AD FS si

• Vous souhaitez utiliser des cartes à puce pour l'authentification
• Vous souhaitez utiliser des fournisseurs d'AMF tiers
• Votre politique de sécurité d'entreprise exige que les mots de passe restent toujours sur site (contrairement à AD FS, dans PTA, le mot de passe de l'utilisateur est saisi dans Azure AD avant d'être transféré sur site)
• Vous utilisez les règles d'authentification supplémentaires d'AD FS pour appliquer l'accès conditionnel.
• Vous utilisez l'accès conditionnel à Windows 10 sur site en fonction de l'appareil.

Et bien sûr, vous devez disposer d'AD FS si vous avez des entités de confiance configurées localement pour fournir une authentification unique (SSO) que vous ne souhaitez pas migrer vers Azure AD.

AD FS 2016 offre également de nouvelles fonctionnalités telles que la prise en charge intégrée d'Azure MFA ; si vous avez un déploiement AD FS existant, examinez très attentivement vos besoins futurs et ce qu'AD FS peut faire avant d'envisager de le supprimer par mesure d'économie.

Choix de l'authentification hybride maintenant

Microsoft propose désormais un ensemble beaucoup plus complet d'options d'authentification hybride (figure 4) :

Les options d'origine sont toujours disponibles, mais vous pouvez désormais bénéficier d'un excellent rapport qualité-prix sans grande complexité supplémentaire. Si vous utilisez la synchronisation des mots de passe, l'ajout de 3SO éliminera les problèmes liés aux mots de passe pour vos utilisateurs d'entreprise sur le réseau. Si, à la place, vous activez PTA en même temps que 3SO, vous bénéficiez pratiquement des mêmes avantages qu'avec AD FS pour ce cas d'utilisation spécifique de l'authentification Azure AD.

Avec la préversion publique de 3SO et de l'authentification par relais, Microsoft a considérablement réduit les obstacles à l'adoption d'une stratégie d'identité hybride utilisant les outils natifs de l'entreprise. En effet, ces outils sont encore plus simples à utiliser que les solutions tierces qui tiraient parti de la complexité d'AD FS.

Et au cas où cela ne serait pas clair, tout cela est gratuit. Microsoft a misé son avenir sur ses services cloud Azure. L’entreprise souhaite faciliter au maximum l’adoption de ces services, et dans le monde actuel centré sur Active Directory, cela implique de rendre l’intégration d’AD avec Azure AD rapide et sans difficulté. Il a fallu une éternité pour que ces fonctionnalités voient le jour, mais je prédis qu’elles deviendront rapidement le pont d’identité le plus populaire entre l’identité Microsoft sur site et l’identité Microsoft dans le cloud.