Office 365 : Activer le SSO sur Windows pour Edge, Chrome, Teams, etc.

I. Présentation

Dans ce tutoriel, nous allons voir comment activer le SSO (Single Sign-On) entre un environnement Active Directory local et Office 365, afin d’être automatiquement authentifié avec son compte lors de l’ouverture de Teams, de Word, d’Excel, ou encore du portail Office ou du SharePoint de l’entreprise, à partir du navigateur Microsoft Edge ou Google Chrome.

Grâce à la mise en place du SSO, lorsqu’un utilisateur se connecte sur une machine du domaine Active Directory avec son compte utilisateur, et qu’il accède au portail Office avec son navigateur, à Teams (en mode Web ou avec l’application), à Outlook, ou encore qu’il ouvre une application de la suite Microsoft 365 Apps sur sa session, il est automatiquement connecté avec son compte. Autrement dit, il est connecté dans les applications sans avoir à saisir son adresse e-mail et son mot de passe. Avec une configuration supplémentaire, on peut également appliquer le SSO au client OneDrive, ainsi qu’au navigateur Mozilla Firefox.

Pour suivre ce tutoriel, vous avez besoin des éléments suivants :

• Instance Azure AD Connect en place
• Contrôleur de domaine Active Directory pour créer une GPO
• Serveur membre du domaine Active Directory
• Compte utilisateur de l’Active Directory, synchronisé sur le tenant Office 365 via Azure AD Connect

II. Activer le SSO dans Azure AD Connect

Premièrement, nous devons configurer Azure AD Connect de manière à activer l’authentification unique (SSO) dans les paramètres. Pour cela, ouvrez Azure AD Connect sur le serveur où il est installé, et cliquez sur « Modifier la connexion utilisateur » dans la liste des tâches disponibles, puis sur « Suivant« .

Ensuite, vous allez devoir indiquer un compte pour vous authentifier sur l’environnement Cloud. Une fois que c’est fait, l’écran « Connexion utilisateur » s’affiche. A cet endroit, vous devez cocher l’option « Activer l’authentification unique » correspondante au SSO, et pour la méthode d’authentification, si vous utilisez « Synchronisation de hachage du mot de passe« , c’est bon. Une alternative consiste à utiliser le mode « Authentification directe« .

Dès que c’est fait, cliquez sur « Suivant » et il faudra s’authentifier une nouvelle fois, cette fois-ci avec un compte administrateur de l’Active Directory.

Patientez pendant quelques secondes le temps que la configuration est actualisée, puis fermez Azure AD Connect.

Si vous souhaitez vérifier que la nouvelle configuration est bien prise en charge, vous pouvez ouvrir le portail Azure, accéder à Azure Active Directory, puis cliquer sur « Azure AD Connect » dans le menu à gauche. Ici, il faudra vérifier que « Authentification unique fluide » est bien activé pour votre domaine.

Enfin, sachez que dans l’Active Directory, un nouvel objet de type « ordinateur » nommé « AZUREADSSOACC » a été créé et qu’il est indispensable au bon fonctionnement du SSO. Pour des raisons de sécurité, il est nécessaire de positionner cet objet dans une OU protégée contre les suppressions accidentelles et l’accès à cet objet doit être limité aux administrateurs. Puisque la partie Azure AD Connect terminée, nous pouvons passer à la suite de la configuration.

III. Créer la GPO pour le SSO Office 365

A. Paramètre « Liste des attributions de sites aux zones »

Deuxièmement, nous devons créer une stratégie de groupe à partir de la console de création de GPO. Pour ma part, je nomme cette GPO « O365 – SSO » et je la positionne directement sur l’OU « Personnel » puisqu’elle contient les comptes utilisateurs du personnel de mon entreprise fictive. Tout cela pour dire que cette GPO contient des paramètres utilisateurs.

Modifiez cette GPO et parcourez les paramètres de cette façon :

Configuration utilisateur > Stratégies > Modèles d'administration > Composants Windows > Internet Explorer > Panneau de configuration Internet Explorer > Onglet Sécurité

Ici, vous devez ouvrir le paramètre « Liste des attributions de sites aux zones« .

Afin de configurer ce paramètre, cliquez sur « Activé » (1), puis sur le bouton « Afficher » (2) et indiquez « https://autologon.microsoftazuread-sso.com » comme nom pour la valeur et indiquez la valeur « 1« , comme ceci :

En fait, cette configuration permet de dire à la machine que cette adresse appartient à la zone Intranet – d’où la valeur « 1 » – pour que Windows accepte de transmettre des informations d’identification à cette URL.

B. Paramètre « Autoriser les mises à jour de la barre d’état via le script »

Continuons la configuration en activant le paramètre « Autoriser les mises à jour de la barre d’état via le script » :

Configuration utilisateur > Stratégies > Modèles d'administration > Composants Windows > Internet Explorer > Panneau de configuration Internet Explorer > Onglet Sécurité > Zone Intranet

Comme ceci :

Une fois que c’est fait, nous devons configurer un dernier paramètre pour déployer une valeur de Registre Windows.

C. Clé de Registre « https »

Pour déployer ce troisième paramètre dans le Registre, rendez-vous dans la section suivante (toujours dans la partie utilisateur) :

Préférences > Paramètres Windows > Registre

Ensuite, effectuez un clic droit et sous « Nouveau« , cliquez sur « Élément Registre« . Créez un nouvel élément avec la configuration suivante :

• Action : Mettre à jour
• Ruche : HKEY_CURRENT_USER
• Chemin d’accès à la clé : Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\microsoftazuread-sso.com\autologon
• Nom de la valeur : https
• Type de valeur : REG_DWORD
• Données de la valeur : 00000001

Ce qui donne :

La GPO est prête, nous obtenons la configuration suivante :

Avec cette configuration, le SSO pourra fonctionner au sein de plusieurs applications : Microsoft Edge, Google Chrome, Microsoft Teams, et la suite Office. En revanche, pour que le SSO fonctionne dans Firefox et OneDrive, une configuration supplémentaire doit être apportée.

IV. Tester le SSO sur un poste Windows

Suite à la configuration que l’on vient d’effectuer, le SSO devrait fonctionner ! Afin de le vérifier, il n’y a qu’une seule solution : tester depuis un poste client intégré au domaine, en se connectant avec un compte utilisateur concerné par la GPO « O365 – SSO« .

A. Visualiser les paramètres intranet

Tout d’abord, une fois que la session est ouverte, on peut s’assurer que le paramètre de zone Intranet est bien appliqué. Ce n’est pas obligatoire, mais pour vérifier cela, il faut ouvrir le panneau de configuration, cliquer sur « Options Internet » puis l’onglet « Sécurité« . Une fois dans cet onglet, il faut sélectionner « Intranet local » (1), cliquer sur « Sites » (2) puis le bouton « Avancé » (3) et enfin s’assurer que l’URL « autologon » est bien dans la liste des sites (4). Comme ceci :

B. Connexion aux différentes applications

Concernant le SSO en lui-même, il y a plusieurs façons de le tester… Pour Teams, c’est tout simple, il suffit d’ouvrir Teams et de voir ce qu’il se passe : normalement l’utilisateur est authentifié directement. À partir d’un navigateur, en l’occurrence Chrome ou Edge, si vous accédez à « portal.office.com », cela ne fonctionnera pas. En effet, vous devez utiliser une URL spécifique qui contient votre domaine (format classique ou format onmicrosoft.com).

Pour le domaine « it-connect.tech« , cela donne :

https://portal.office.com/?domain_hint=it-connect.tech
https://portal.office.com/?domain_hint=itconnect.onmicrosoft.com

Avec les deux URL ci-dessus, le SSO fonctionne bien. C’est également le cas avec cette adresse :

https://myapps.microsoft.com/tuto.cm.onmicrosoft.com

Mais aussi avec un accès sur le SharePoint de l’entreprise, par exemple :

https://tuto.sharepoint.com/

En fait, pour que le SSO fonctionne dans le navigateur, il faut utiliser des URL personnalisées qui permettent d’identifier votre environnement Cloud. À mon avis, il est intéressant de déployer des favoris dans les navigateurs ou des raccourcis sur le Bureau des sessions avec les bons liens.

Enfin, sachez que si vous utilisez le SSO couplé avec le MFA, cela fonctionne tout de même. Néanmoins, le nom d’utilisateur et le mot de passe sont automatiquement « saisit », mais la fenêtre MFA s’affiche : ce qui permet d’optimiser le processus d’authentification malgré tout, surtout si l’on approuve l’appareil, cela ne reviendra pas systématiquement.

C. Debug du SSO Office 365

Si cela ne fonctionne pas, il y a plusieurs raisons possibles : GPO pas appliquée, Azure AD Connect mal configuré, etc… Ou encore, un poste de travail qui n’est pas à l’heure. Pour analyser le problème, vous pouvez ouvrir une console dans la session de l’utilisateur et exécuter la commande ci-dessous pour lister les tickets Kerberos.

klist

Normalement, vous devez voir un ticket avec l’URL autologon, comme ceci :

Si ce n’est pas le cas, vous pouvez essayer de purger vos tickets Kerberos, redémarrer la machine puis rouvrir la session. Pour supprimer les différents tickets, utilisez cette commande :

klist purge

Afin d’avoir des informations supplémentaires sur le dépannage du SSO, vous pouvez consulter la documentation de Microsoft.

Le SSO Office 365 est en place au sein de votre environnement : ce sont les utilisateurs qui vont apprécier !