L’authentification unique (SSO) via Azure AD (désormais appelé Microsoft Entra ID) permet aux utilisateurs de se connecter une seule fois avec leurs identifiants Azure AD pour accéder aux applications internes et métier (LOB). Ils n’ont donc plus besoin de mémoriser plusieurs noms d’utilisateur ni de répéter les connexions. Résultat : une meilleure UX (expérience utilisateur), une sécurité renforcée et un contrôle d’accès plus efficace dans les environnements hybrides et cloud.
Le SSO Azure prend en charge un large éventail de types d’applications, aussi bien modernes qu’anciennes. Voici les scénarios d’applications métier les plus courants :
- Applications web internes (hébergées sur IIS, basées sur .NET)
- Applications SaaS personnalisées
- Applications sur site exposées via Azure AD Application Proxy
- Applications héritées nécessitant une authentification unique basée sur les en-têtes ou sur un formulaire
Ce guide vous accompagne pas à pas dans la configuration du SSO Azure pour ces applications.
Les étapes pour gérer l’authentification unique (SSO) avec Azure AD pour les applications métier (LOB)
Pour éviter les problèmes de configuration et garantir un déploiement sans accroc, assurez-vous que les prérequis suivants sont réunis avant de commencer :
📌 Prérequis généraux :
- Un tenant Azure AD avec une licence Premium P1 (nécessaire pour Application Proxy ou l’accès conditionnel)
- Une application métier hébergée sur site ou dans Azure
- Des terminaux joints au domaine ou joints à Azure AD
- Un accès administrateur au portail Azure et au serveur d’applications
Étape 1 : enregistrer l’application métier dans Azure AD
Cette étape crée une identité pour votre application dans Azure AD afin qu’elle puisse être gérée de façon sécurisée. Une fois l’enregistrement effectué, Azure AD reconnaît l’application et peut lui délivrer des jetons.
- Ouvrez le portail Azure.
- Allez dans Azure Active Directory > App registrations > New registration.
- Saisissez un nom pour l’application.
- Définissez l’URI de redirection (par exemple https://app.domain.com/auth/callback) (voir le point n° 1 de la section ⚠️ Points de vigilance.)
- Cliquez sur Register.
- Après l’enregistrement :
- Copiez l’Application (client) ID.
- Dans Authentication, choisissez la plateforme et saisissez votre URI de redirection.
- Dans API permissions, ajoutez les autorisations Microsoft Graph suivantes : openid, profile et email.
💡 Qu’est-ce qu’une application LOB dans Azure ?
Une application métier (LOB, Line-of-Business) est une application personnalisée ou interne, conçue spécifiquement pour les besoins d’une entreprise. Elle est souvent développée en interne et n’est pas rendue publique.
Étape 2 : configurer les options SSO selon le type d’application
Chaque application prend en charge une méthode d’authentification différente (SAML, OAuth2 ou OIDC). Cette étape indique à Azure AD laquelle utiliser pour que les utilisateurs puissent se connecter sans problème.
Pour les applications modernes (OIDC ou SAML)
- Allez dans Azure Active Directory > Enterprise Applications > [Votre application] > Single sign-on.
- Choisissez :
- SAML pour les applications compatibles SAML 2.0
- OIDC (OpenID Connect) pour les applications conçues avec des fournisseurs d’identité modernes
- Renseignez les champs requis :
- Identifier (Entity ID)
- Reply URL (Assertion Consumer Service)
- Sign-on URL
(Voir le point n° 2 de la section ⚠️ Points de vigilance.)
- Attribuez des utilisateurs ou des groupes dans l’onglet Users and Groups.
Pour les applications héritées ou basées sur les en-têtes
Utilisez Azure AD Application Proxy avec préauthentification (voir l’étape 3).
💡 Qu’est-ce que le SSO dans Azure ?
L’authentification unique (SSO) dans Azure est une fonction qui permet aux utilisateurs d’accéder à plusieurs applications avec une seule connexion. Elle simplifie l’authentification et renforce la sécurité en centralisant la gestion des identités.
Étape 3 : mettre en place Azure AD Application Proxy (pour les applications sur site)
Si votre application est hébergée sur site, Azure AD ne peut pas l’atteindre directement. Application Proxy fait office de tunnel sécurisé entre Azure et votre réseau interne. (Voir le point n° 3 de la section ⚠️ Points de vigilance.)
📌 Prérequis :
- Un Windows Server 2016 ou version ultérieure à l’intérieur du réseau
- Application Proxy Connector installé sur ce serveur
Instructions :
- Téléchargez ou installez l’Application Proxy Connector depuis Azure.
- Connectez-vous avec un compte Azure AD Global Admin.
- Dans le portail Azure, allez dans Azure AD > Enterprise Applications > + Add > On-premises application.
- Saisissez :
- Internal URL – http://internalapp.local
- External URL – https://app-tenant.msappproxy.net
- Activez la préauthentification via Azure AD
Vérifier la connexion
- Appuyez sur Win + R, tapez cmd et appuyez sur Entrée pour ouvrir l’invite de commande.
- Exécutez : netstat -ano | findstr :443
Étape 4 : configurer le comportement des jetons SSO sur les appareils clients
Les appareils clients doivent savoir comment gérer les jetons SSO : comment les demander, les stocker et les actualiser lorsque c’est nécessaire. Cette étape vous explique comment configurer le comportement des jetons SSO sur les appareils clients.
Activer le SSO fluide et l’authentification directe
- Configurez Azure AD Connect, activez le SSO fluide (Seamless SSO) et, si vous le souhaitez, l’authentification directe (Pass-through Authentication, PTA).
- Vérifiez la configuration dans PowerShell : Get-AzureADSSOStatus
Vérification du registre (mise en cache des jetons SSO côté client)
- Vérifiez les paramètres des jetons dans :
HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Identity
Des clés comme EnableADAL ou Version peuvent influer sur le comportement de l’authentification moderne dans les applications intégrées à Office.
Vérification via CMD (invite de commande) (présence du jeton)
- Pour inspecter ou réinitialiser les tickets Kerberos, exécutez : klist
Utilisez klist purge pour supprimer les anciens tickets Kerberos en cas de problème.
Étape 5 : appliquer les politiques via GPO
Pour garantir la cohérence sur l’ensemble de vos appareils, utilisez la stratégie de groupe afin de contrôler le comportement de Kerberos, la durée de vie des jetons et la compatibilité des navigateurs. (Voir le point n° 4 de la section ⚠️ Points de vigilance.)
Configurer les politiques Kerberos
- Appuyez sur Win + R, tapez gpedit.msc et appuyez sur Entrée pour ouvrir l’éditeur d’objets de stratégie de groupe.
- Accédez à :
Configuration ordinateur > Modèles d’administration > Système > Kerberos
📌 Assurez-vous que la synchronisation horaire et les paramètres Kerberos sont cohérents avec vos politiques d’authentification.
Pour les applications web (SSO via le navigateur)
- Accédez à :
Configuration utilisateur > Modèles d’administration > Composants Windows > Internet Explorer > Panneau de configuration Internet > Page Sécurité > Zone Intranet local
- Ajoutez l’URL de l’application aux sites de confiance avec PowerShell :
Set-ItemProperty -Path "HKCU:\Software\Microsoft\Windows\
CurrentVersion\Internet Settings\ZoneMap\Domains\app.domain.com" -Name https -Value 1
- Utilisez les modèles de politique de navigateur pour imposer le SSO dans Edge ou Chrome.
Étape 6 : automatiser l’accès et la validation des jetons avec PowerShell
PowerShell est votre boîte à outils pour valider les jetons, automatiser les accès et vérifier que votre configuration fonctionne comme prévu.
📌 Prérequis :
- PowerShell installé
- Accès à l’API Microsoft Graph (facultatif pour l’automatisation)
Instructions :
- Appuyez sur Win + S, recherchez PowerShell et sélectionnez Windows PowerShell dans les résultats.
- Exécutez ce script pour demander un jeton manuellement : (voir le point n° 5 de la section ⚠️ Points de vigilance.)
$tenantId = "your-tenant-id"
|
Cela confirme que la communication entre applications et l’accès des comptes de service fonctionnent correctement.
⚠️ Points de vigilance
| Risques | Conséquences possibles | Correctifs |
| 1. Enregistrer l’application avec un URI de redirection ou un type de plateforme erroné | Les utilisateurs ne pourront pas s’authentifier et les demandes de jetons échoueront. | Modifiez l’enregistrement de l’application : Azure AD > App registrations > [App] > Authentication |
| 2. Attribuer des métadonnées SAML/OIDC incorrectes ou incomplètes | La négociation SSO échoue, ce qui entraîne des échecs de connexion. | Mettez à jour ou téléversez de nouveau les métadonnées correctes dans Enterprise Applications > Single sign-on. |
| 3. Omettre la configuration d’Application Proxy pour les applications sur site | Azure AD ne peut pas atteindre l’application et le SSO ne fonctionne pas depuis l’extérieur. | Installez Application Proxy Connector et configurez la publication de l’application. |
| 4. Écraser des paramètres GPO existants lors de l’application des politiques | Perturbe le comportement des navigateurs ou de l’authentification déjà en place sur les terminaux | Exportez les GPO existants avant toute modification ; revenez en arrière grâce à la sauvegarde ou au contrôle de version des GPO. |
| 5. Utiliser une syntaxe PowerShell ou des identifiants incorrects pour tester les jetons | Le test du jeton échoue ou renvoie des erreurs trompeuses. | Vérifiez les paramètres et les secrets avant d’exécuter le script ; testez d’abord dans l’environnement de développement. |
Points complémentaires à envisager
Voici quelques recommandations pour renforcer, sécuriser et maintenir votre configuration SSO avec Azure AD pour les applications métier :
Imposer la MFA (authentification forte) et la confiance des appareils (accès conditionnel)
Utilisez l’accès conditionnel pour exiger la MFA (authentification forte) et n’autoriser l’accès qu’à partir d’appareils approuvés ou conformes. Cela ajoute une couche de sécurité supplémentaire et aide à empêcher les accès non autorisés, même si des identifiants ou des jetons sont dérobés.
💡 Conseil : lisez Comment configurer les politiques d’accès conditionnel dans Azure AD.
Contrôler les autorisations avec les rôles d’application
Plutôt que d’accorder le même niveau d’accès à tout le monde, utilisez les rôles d’application (App roles) pour définir ce que les utilisateurs peuvent faire dans l’application métier. Attribuez des rôles tels qu’Admin, Éditeur ou Lecteur afin d’appliquer le principe du moindre privilège et de réduire les risques de sécurité.
Surveiller la santé du SSO
Utilisez les journaux de connexion Azure AD pour savoir qui a accédé à quelle application et quand, suivre les taux de réussite et d’échec des connexions et de la MFA (authentification forte), et repérer les problèmes de sécurité potentiels. C’est un atout pour les audits, le dépannage et le respect des exigences de conformité.
Assurer la compatibilité SSO via Intune
Si vous utilisez Microsoft Intune pour gérer vos appareils, déployez des profils de configuration afin d’appliquer les paramètres de navigateur, les politiques propres aux applications et les règles de conformité des appareils. Vous garantissez ainsi une expérience SSO fluide et homogène sur tous les appareils inscrits.
Dépannage
Voici les problèmes les plus fréquents lors de la configuration du SSO avec Azure AD pour les applications métier, leurs causes et les solutions à appliquer :
| Problème | Cause | Solution |
| Le SSO échoue côté client | L’horloge de l’appareil est désynchronisée, ou les tickets Kerberos ont expiré ou sont corrompus. | Synchronisez l’heure système et utilisez klist purge pour supprimer et actualiser les tickets Kerberos. |
| L’application renvoie une erreur 403 | L’utilisateur n’a pas été affecté à l’application dans Azure AD. | Allez dans Enterprise Applications > [Votre application] > Users and Groups, puis attribuez l’utilisateur ou le groupe. |
| Aucun jeton n’est délivré | URI de redirection ou secret client incorrect dans l’enregistrement de l’application. | Vérifiez l’URI de redirection et le secret client dans App registrations > Authentication / Certificates & secrets. |
| L’application ne prend pas en charge SAML ni OIDC | Il s’agit d’une application héritée qui ne gère pas les protocoles d’authentification modernes. | Utilisez Azure AD Application Proxy avec un SSO basé sur les en-têtes pour permettre un accès sécurisé via la préauthentification Azure AD. |
Les services NinjaOne
NinjaOne accompagne les déploiements et la surveillance du SSO dans les environnements clients :
Validation à distance
Exécution à distance de scripts PowerShell pour vérifier la présence du cache de jetons, les clés de registre et l’accès réseau.
Déploiement de politiques
Diffusion de configurations équivalentes aux GPO pour imposer la compatibilité des navigateurs et les paramètres d’authentification Kerberos.
Alertes SSO
Alertes en cas de changement d’état d’un appareil ou d’une application lié au SSO ou à l’expiration d’un jeton.
Étiquetage SSO
Étiquetage des appareils et des utilisateurs selon leur statut de configuration SSO, pour faciliter les audits, le suivi de la conformité et la visibilité sur la santé de l’environnement.
Remédiation automatique
Automatisation de la remédiation des politiques sur les terminaux qui échouent aux contrôles préalables au SSO.
Ces outils permettent aux MSP d’offrir des expériences SSO sécurisées et homogènes sur l’ensemble des parcs clients, tout en réduisant la charge opérationnelle.
💡 Conseil : lisez également Activer le SSO.
Configurer le SSO avec Azure AD pour les applications métier : accès simplifié et sécurité renforcée
Le SSO avec Azure AD aide les entreprises à moderniser leur contrôle d’accès tout en simplifiant l’expérience utilisateur pour les applications internes et métier. Azure AD prend en charge aussi bien les applications cloud modernes que les anciens services web sur site, ce qui vous laisse la souplesse nécessaire pour sécuriser tout ce dont votre environnement a besoin.
Ce guide a couvert tout ce qu’il faut pour démarrer : l’enregistrement de votre application dans Azure AD, la mise en place de l’authentification SAML, OIDC ou via proxy, ainsi que le durcissement des paramètres clients grâce à la stratégie de groupe, à PowerShell et aux modifications du registre. Il a également montré comment NinjaOne renforce et surveille les environnements SSO pour les MSP.
Sujets connexes :
- SAML et SSO : quelle différence ?
- Azure AD Connect : qu’est-ce que c’est et comment le configurer
- Intégrer le sur site et le cloud avec la jointure hybride Microsoft Entra
- Intégrer le sur site et le cloud avec la jointure hybride Azure AD
- L’authentification Active Directory : tour d’horizon complet
- Intégration du SSO et de SCIM dans NinjaOne
- Combien coûte un logiciel SSO ? Tarification du SSO
Guide de démarrage rapide
NinjaOne prend en charge la configuration du SSO avec Azure AD pour les applications métier. Plus précisément :
- NinjaOne propose une configuration SAML/SSO avec Azure AD
- Le processus consiste à créer une Enterprise Application dans Azure AD
- Vous pouvez mettre en place l’authentification unique (SSO) avec Azure Active Directory
- Cette configuration permet de :
- mapper les attributs utilisateur
- configurer les correspondances de groupes
- activer le contournement conditionnel de la MFA (authentification forte)
- prendre en charge les comptes de techniciens et d’utilisateurs finaux
Les étapes clés sont les suivantes :
- Créer une Enterprise Application dans Azure AD
- Configurer les paramètres SAML
- Mapper les attributs et les rôles utilisateur
- Définir les correspondances de groupes
- Configurer, si besoin, le contournement de la MFA (authentification forte)
La documentation fournit des instructions détaillées pour mettre en place le SSO, y compris des consignes spécifiques à l’intégration avec Azure AD. Les administrateurs peuvent activer le SSO pour les techniciens comme pour les utilisateurs finaux, avec un contrôle précis sur les accès et l’authentification.
