Pour aborder l’année 2017, voici le troisième article de la série dédiée à la suite EMS (Enterprise Mobility + Security). Les articles précédents étaient dédiés à la procédure de mise en place d’un abonnement d’évaluation et à la mise en place de l’outil AZURE AD Connect, permettant de faire le lien entre les identités d’entreprise et les identités cloud. Nous allons maintenant aborder l’expérience utilisateur apportée par les différents scénarios AZURE AD Connect (Simple Sign on vs Single Sign On avec ADFS).
Nous aborderons « Pass Through Authentication » et « Single Sign On » sans ADFS dans un prochain article, de même que la jonction des ordinateurs à AZURE AD.
Simple Sign On
Dans son mode de déploiement Simple Sign on, AZURE AD Connect projette les identités d’entreprise dans le cloud de même que les Hash de mots de passe. Il s’agit d’un mode de déploiement le plus simple pour lequel chaque utilisateur dispose de deux identités distinctes mais synchronisées : l’identité On-Premise et l’identité Cloud. D’un point de vue technique, il s’agit d’une double authentification et aucunement de SSO car l’authentification est traitée par deux fournisseurs d’identité distincts :
|
Authentification On-Premise par les contrôleurs de domaine Active Directory pour l’accès en SSO à l’ensemble des ressources de la forêt. |
Cette authentification permet d’accéder aux ressources du périmètre d’entreprise mais pas au-delà. |
|
Authentification Cloud pour l’accès aux ressources SaaS |
Cette authentification permet d’obtenir un jeton de sécurité utilisé pour accéder aux applications SaaS comme Office 365 ou toute autre application fédérée avec AZURE AD |
AZURE AD Connect en mode Simple Sign On rend ce scénario acceptable grâce à la synchronisation des comptes d’utilisateurs et des Hash de mots de passe, c’est en effet simple mais cela reste techniquement une double authentification.
En Simple Sign On, l’accès au portail SaaS Office 365 (https://portal.office.com) nécessitera que vous identifiez et ce dans toutes les situations :
- Machine jointe à un domaine Active Directory connectée à l’Intranet ou à l’Internet
- Machine en WorkGroup connectée à l’Intranet ou à l’Internet
Il existe bien une case à cocher Maintenir la connexion mais celle-ci ne permet que de conserver en cache les identifiants de session dans le navigateur (après une authentification réussie). Si vous cochez cette case, les cookies de session seront conservés à la fermeture du navigateur et réutilisables par la suite jusqu’à expiration de leur durée de vie (6 heures par défaut).
En revanche, la fonctionnalité Password Synchronization permettra bien d’utiliser ses identifiants d’entreprise pour accéder au portail ce qui nous donnera dans tous les cas une expérience utilisateur simplifiée, d’où le Simple Sign On.
Single Sign On avec ADFS
Avec le service ADFS, on va pouvoir mettre en place une véritable plateforme de SSO. Il s’agit là d’une fonctionnalité SSO « classique » reposant sur des protocoles très largement adoptés et donc potentiellement candidate à de nombreuses situations. ADFS existe depuis longtemps, avec les versions suivantes :
- ADFS 1.0 – Windows Server 2003 R2
- ADFS 1.1 – Windows Server 2008 et Windows Server 2008 R2
- ADFS 2.0 – Windows Server 2008 et Windows Server 2008 R2
- ADFS 2.1 – Windows Server 2012
- ADFS 3.0 – Windows Server 2012 R2
- ADFS 4.0 – Windows Server 2016
ADFS est le service de fédération de l’annuaire Active Directory, service permettant aux identités d’entreprise d’être utilisées par une application tierce, située sur l’Intranet ou non. Cette méthode offre l’avantage de reposer sur l’utilisation de SAML, Oauth et OpenID Connect, très largement diffusés et adoptés dans le monde du SaaS. En contrepartie, la mise en œuvre d’une plateforme SSO avec ADFS réclame une certaine expertise technique, tant par les contraintes techniques qu’elle impose que les exigences de disponibilité qu’elle implique. Pour utiliser ADFS il va falloir :
- Manipuler des certificats SSL
- Publier le service ADFS par un service de Proxy adéquat
- Créer des relations de confiance
- Prendre en compte la haute disponibilité
L’installation d’une ferme ADFS sort du contexte de cet article, mais j’ai écrit une série d’articles sur ce sujet qui vous permettra si besoin de trouver vos repères.
Typiquement une ferme ADFS se présente sous la forme suivante :
- Des contrôleurs de domaine
- Des serveurs ADFS joints au domaine
- Des serveurs de publication (reverse proxy) situés dans une DMZ
- Un pare feu redirigeant les flux HTTPS sur le serveur de publication
En voici une illustration simple (sans haute disponibilité) :
L’activation du SSO entre AZURE AD et une ferme ADFS déjà existante pourra se faire en utilisant l’assistant AZURE AD Connect. Lors du lancement, un message vous avertira que les opérations de synchronisation seront interrompues durant le paramétrage :
L’option qui nous intéresse pour activer le SSO avec ADFS est Change user sign-in :
La modification nécessite d’être authentifié sur AZURE AD avec un compte de type Global Administrator :
Nous choisirons l’option Federation with AD-FS :
L’assistant nous permet de créer une ferme de serveurs ADFS ou d’en utiliser une existante. Nous choisirons cette deuxième option.
L’assistant nous demandera une authentification sur le serveur ADFS
Il reste à préciser le domaine AZURE AD pour lequel nous souhaitons activer la fédération :
Puis à valider ce choix
L’activation du mode fédéré prend quelques minutes durant lesquelles les paramètres du tenant Office 365 sont modifiés et les relations de confiance établies
A l’issue du paramétrage, l’assistant propose de vérifier les enregistrements DNS internes et externes de votre ferme ADFS :
La fédération ne pouvant fonctionner que par le biais du nom DNS associé au service, il est important de s’assurer que les 2 tests retournent un résultat positif.
Pour terminer la partie configuration, il reste un point important à traiter à défaut lequel l’objectif SSO ne sera pas atteint : le site web du service de fédération doit faire partie des sites de confiance de la zone Intranet local des postes clients. Cela peut être effectué manuellement ou de façon massive par GPO.
A ce stade, il ne reste plus qu’à tester le SSO.
Depuis un PC joint au domaine d’entreprise et connecté à l’intranet (authentification par un contrôleur de domaine), l’accès à une application SaaS gérée par AZURE AD, comme par exemple le portail Office 365, devra se faire sans demande d’authentification supplémentaire : l’identifiant de la session en cours doit permettre d’obtenir un jeton SAML valide pour les applications assignées à l’utilisateur.
L’URL du portail Office 365 devra être saisie
sous la forme https://login.microsoftonline.com/login.srf?wa=wsignin1.0&whr=xxxx (en remplaçant xxxx par votre nom de domaine Office 365)
Dans notre cas, cela donne https://login.microsoftonline.com/login.srf?wa=wsignin1.0&whr=antoinedentan.ovh
Une fois l’URL tapée dans la barre d’adresse du navigateur, nous sommes redirigés quelques instants de façon transparente vers notre service de fédération, l’authentification se fait alors en tache de fond et utilise la session Windows en cours pour obtenir un jeton SAML valide pour Office 365 par le biais du serveur ADFS.
Une fois le jeton obtenu, nous sommes redirigés vers le portail Office 365. Aucune demande d’authentification n’a eu lieu hormis l’ouverture de session Windows. C’est bien du Single Sign On.
Depuis un PC joint au domaine d’entreprise et non connecté à l’intranet (authentification par le cache local), l’accès à une application SaaS gérée par AZURE AD, comme par exemple le portail Office 365, se fera cette fois ci avec une demande d’authentification supplémentaire : l’identifiant de la session en cours ne permet pas d’obtenir un jeton SAML valide pour les applications assignées à l’utilisateur.
L’URL du portail Office 365 devra être saisie
sous la forme https://login.microsoftonline.com/login.srf?wa=wsignin1.0&whr=xxxx (en remplaçant xxxx par votre nom de domaine Office 365)
Dans notre cas, cela donne https://login.microsoftonline.com/login.srf?wa=wsignin1.0&whr=antoinedentan.ovh
Une fois l’URL tapée dans la barre d’adresse du navigateur, nous sommes redirigés vers notre service de fédération ADFS ou nous devons nous authentifier (formulaire web), l’authentification nous donne un jeton SAML valide pour Office 365 par le biais du serveur ADFS.
Une fois le jeton obtenu, nous sommes redirigés vers le portail Office 365. Nous avons dû nous authentifier sur notre serveur ADFS car nous n’avions pas de session en cours authentifiée par un contrôleur de domaine, c’est encore du Single Sign On car d’un point de vue Active Directory, nous ne sommes authentifiés qu’une seule fois.
Pour les machines en Workgroup, la même expérience utilisateur est à attendre : il faudra s’authentifier une fois à l’Active directory, et cela passera par le serveur ADFS. La différence tient au fait que ce scénario se produira aussi bien à l’intérieur de l’entreprise qu’à l’extérieur.
Voilà pour ce petit aperçu de l’expérience utilisateur en ce qui concerne les accès au monde SaaS en mode Simple Sign On et Single Sign On. Le prochain article sera consacré à l’expérience utilisateur améliorée avec les fonctionnalités de jonction au domaine Azure AD.
Merci de votre lecture.
Une réflexion au sujet de « Evaluation de Enterprise Mobility + Security. Troisième partie : l’expérience utilisateur en SSO »