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

Microsoft a récemment annoncé la prévisualisation publique de deux nouvelles fonctionnalités majeures qui faciliteront grandement l'intégration de votre Active Directory sur site à Azure AD. L'authentification passive (PTA) et l'authentification unique transparente (j'ai choisi de l'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 ou à synchroniser les hachages de 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)

La grande majorité des entreprises ont aujourd'hui Active Directory comme service d'identité de base, et ce n'est pas près de disparaître. Par conséquent, la première tâche fondamentale à accomplir lorsque l'on prévoit d'utiliser l'un des services en ligne de Microsoft est d'intégrer son Active Directory sur site avec Azure AD, et ce pour deux raisons. Tout d'abord, vous devez synchroniser les comptes et les groupes AD avec Azure AD à l'aide d'Azure AD Connect. Ensuite, une fois que les comptes sont dans Azure AD, vous devez choisir comment authentifier les utilisateurs. Dans cet article, je me concentre sur les aspects liés à l'authentification des utilisateurs.

Aujourd'hui, Microsoft propose deux options d'authentification : AD FS, qui assure la fédération des identités (et un certain nombre d'autres fonctionnalités) pour le SSO, et la synchronisation des mots de passe ("PHS" dans les graphiques ci-dessous). Ce second choix, connu des "digerati" sous le nom de synchronisation du hachage des mots de passe (d'où le "H"), offre une capacité de "même connexion" où l'utilisateur doit entrer ses informations d'identification une seconde fois pour se connecter à Azure AD, mais il s'agit des mêmes nom d'utilisateur et 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 dans le nuage uniquement : Les comptes d'utilisateurs sont gérés et authentifiés dans Azure AD. Comme nous parlons de solutions hybrides dans ce billet, nous ne nous attarderons pas sur ce point.
• AAD Connect / Comptes dans le nuage : Vous pouvez utiliser Azure AD Connect pour synchroniser les comptes d'utilisateurs dans Azure AD afin que l'identifiant de connexion (généralement l'adresse électronique de l'utilisateur) soit le même, mais les utilisateurs doivent conserver leurs propres mots de passe dans le service en nuage. 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, il y a un écart important dans la complexité du déploiement pour obtenir un véritable SSO dans votre organisation. Les solutions tierces telles que Okta, Ping Identity, OneLogin, Centrify, OptimalIDM et d'autres proposent des méthodes d'authentification plus simples qui s'adaptent à cet écart, et c'est l'une des raisons de leur popularité.

Windows joint au domaine...et tout le reste

Pour comprendre ce que ces deux nouvelles solutions en avant-première publique apportent, il est utile de regrouper les cas d'utilisation de l'authentification en deux catégories : le client à authentifier par Azure AD dispose d'un ticket Kerberos ou il n'en a pas.

Le premier est le scénario classique d'authentification d'entreprise Windows, connu sous le nom d'authentification Windows intégrée (IWA). Un utilisateur connecté à son poste de travail Windows relié au domaine avec un compte AD, sur le réseau de l'entreprise (c'est-à-dire que le poste de travail peut trouver un contrôleur de domaine) et qui dispose donc d'un ticket Kerberos, obtient un accès transparent aux ressources AD sans être invité à saisir son mot de passe. Ce scénario existe depuis l'invention 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 client mobile (le navigateur web)
• Un client basé sur une API, tel qu'une application Office (l'application mobile)

Examinons tout d'abord le scénario du poste de travail rattaché à un domaine et la solution élégante de Microsoft utilisant 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 qu'une partie se fiant à l'authentification, telle qu'Azure AD, peut utiliser. Si Azure AD peut comprendre 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 la traduction.

La figure 2 montre comment cela se passe. Azure AD est représenté dans votre AD local comme un simple ordinateur ; AD ne fait pas la différence. Un compte d'ordinateur (AZUREADSSOACCT) est ajouté à votre AD, ainsi que deux SPN (noms de principaux services) contenant les URL nécessaires à l'authentification. La clé secrète Kerberos du compte du poste de travail est partagée en toute sécurité avec Azure AD. À partir de ce moment, les clients utilisent IWA pour accéder aux ressources Azure, tout comme ils pourraient accéder à 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 d'octroi de tickets (TGS) au sein du 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 authentifié son identité. Il en résulte qu'un utilisateur Windows d'entreprise sur le réseau n'est pas invité à saisir un mot de passe pour accéder aux ressources Azure AD, et qu'AD FS n'est pas nécessaire. Pas mal, non ?

L'installation de 3SO est on ne peut plus simple : il suffit de cocher la case "Enable single sign on" dans la configuration personnalisée de la dernière version d'AD Connect.

Clients soutenus

Il existe plusieurs configurations possibles pour 3SO. Tout d'abord, il doit s'agir d'un client qui prend en charge Kerberos, comme Windows. Deuxièmement, il fonctionne pour accéder aux ressources Azure AD via un navigateur (par exemple https://outlook.office.com) ou à partir d'un client Office qui prend en charge l'authentification moderne. Vous pouvez consulter la liste des clients pris en charge, mais pour l'essentiel, il est pris en charge par tous les principaux navigateurs (IE, Chrome, Firefox), à l'exception de Edge, et 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, la pire chose qui puisse arriver est qu'il reçoive une demande de mot de passe.

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

PTA est conçu pour les cas d'utilisation où le client n'a pas de ticket Kerberos, soit parce que le client Kerberos ne peut pas atteindre un DC (par exemple lorsqu'un employé travaille à domicile sur son ordinateur portable d'entreprise), soit parce que le client ne supporte pas Kerberos (par exemple un navigateur mobile ou une application qui ne supporte pas l'authentification moderne).

Je n'expliquerai pas ici comment installer PTA, mais il s'agit essentiellement de déployer un ou plusieurs connecteurs légers sur site, un peu comme le connecteur Azure AD Application Proxy, sur des serveurs reliés à un domaine où ils peuvent communiquer avec un DC.

À 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étermine que le domaine de l'utilisateur est configuré pour l'ATP ; Azure AD en informe le connecteur qui récupère 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.
• Il est très simple à gérer à partir du portail Azure, et il n'y a pas de certificats à 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
• La politique de sécurité de votre entreprise exige que les mots de passe restent toujours sur place (contrairement à AD FS, dans PTA le mot de passe de l'utilisateur est saisi dans Azure AD avant d'être transféré sur place).
• 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 avoir AD FS si vous avez des parties dépendantes configurées localement pour fournir un SSO que vous ne souhaitez pas transférer à 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 maintenant obtenir une grande valeur avec très peu de complexité supplémentaire. Si vous utilisez la synchronisation des mots de passe, l'ajout de 3SO éliminera les défis liés aux mots de passe pour les utilisateurs de l'entreprise sur le réseau. Si, au contraire, vous activez PTA avec 3SO, vous obtenez pratiquement la même valeur qu'AD FS pour le cas d'utilisation spécifique de l'authentification Azure AD.

Avec l'aperçu public de 3SO et de l'authentification passthrough, Microsoft a considérablement réduit la barrière à l'adoption d'une stratégie d'identité hybride en utilisant les outils natifs de l'entreprise. En fait, ces outils sont même plus simples à utiliser que les offres de tiers qui ont tiré parti de la complexité d'AD FS.

Et au cas où ce ne serait pas clair, tout cela est gratuit. Microsoft a misé son avenir sur ses services en nuage Azure. La société veut rendre l'adoption de ces services aussi facile que possible, et dans le monde actuel centré sur l'Active Directory, cela signifie rendre l'intégration AD avec Azure AD rapide et sans douleur. Il a fallu une éternité pour que ces capacités apparaissent au grand jour, mais je prédis qu'elles deviendront rapidement la passerelle d'identité la plus populaire entre l'identité Microsoft sur site et l'identité Microsoft dans le nuage.