Utiliser un fournisseur d’identité (IdP) SAML 2.0 pour l’authentification unique

Article
12/19/2024

Ce document contient des informations sur l’utilisation d’un profil SP-Lite compatible SAML 2.0 basé sur un fournisseur d’identité en tant que Service STS (Security Token Service) / fournisseur d’identité préféré. Ce scénario est utile lorsque vous avez déjà un répertoire d’utilisateurs et un Store de mots de passe local accessibles à l’aide de SAML 2.0. Ce répertoire d’utilisateurs existant peut être utilisé pour l’authentification auprès de Microsoft 365 et d’autres ressources sécurisées par Microsoft Entra ID. Le profil SP-Lite SAML 2.0 est basé sur la norme d’identité fédérée Security Assertion Markup Language (SAML) largement utilisée pour fournir une structure d’échange d’authentification et d’attribut.

Remarque

Pour obtenir la liste des IdP tiers testés pour une utilisation avec Microsoft Entra ID, consultez la liste de compatibilité de fédération Microsoft Entra

Microsoft prend en charge cette expérience d’authentification comme l’intégration d’un service cloud Microsoft, par exemple Microsoft 365, avec votre fournisseur d’identité basé sur le profil SAML 2.0 correctement configuré. Les fournisseurs d’identité SAML 2.0 sont des produits tiers, par conséquent, Microsoft n’offre aucun support technique sur les meilleures pratiques de déploiement, de configuration, de dépannage les concernant. Une fois correctement configurée, la configuration correcte de l’intégration au fournisseur d’identité SAML 2.0 peut être testée à l’aide de l’outil Analyseur de connectivité Microsoft décrit plus en détail ci-dessous. Pour plus d’informations sur votre fournisseur d’identité basé sur un profil SP-Lite SAML 2.0, demandez à l’organisation qui l’a fournie.

Important

Seul un ensemble limité de clients est disponible dans ce scénario d’authentification avec les fournisseurs d’identité SAML 2.0, cela inclut :

Clients basés sur le Web tels que Outlook Web Access et Sharepoint Online
Clients de messagerie riches qui utilisent l’authentification de base et une méthode d’accès Exchange prise en charge comme IMAP, POP, Active Sync, MAPI, etc. (le point de terminaison Enhanced Client Protocol est requis pour le déploiement), notamment :
- Microsoft Outlook 2010/Outlook 2013/Outlook 2016, Apple iPhone (différentes versions d’iOS)
- Différents appareils Google Android
- Windows Phone 7, Windows Phone 7.8 et Windows Phone 8.0
- Client de messagerie Windows 8 et client de messagerie Windows 8.1
- Client de messagerie Windows 10

Tous les autres clients ne sont pas disponibles dans ce scénario d’authentification avec votre fournisseur d’identité SAML 2.0. Par exemple, le client de bureau Lync 2010 n’est pas en mesure de vous connecter au service avec votre fournisseur d’identité SAML 2.0 configuré pour l’authentification unique.

Microsoft Entra configuration requise pour le protocole SAML 2.0

Ce document recense les exigences détaillées du protocole et de la mise en forme des messages que votre fournisseur d’identité SAML 2.0 doit mettre en œuvre pour établir la fédération avec Microsoft Entra ID et activer l’authentification auprès d’un ou plusieurs services cloud Microsoft (tels que Microsoft 365). La partie utilisatrice de SAML 2.0 (SP-STS) pour un service de cloud Microsoft utilisée dans ce scénario est Microsoft Entra ID.

Il est recommandé de vérifier que les messages de sortie de votre fournisseur d’identité SAML 2.0 sont aussi semblables que possible aux suivis d’exemples fournis. En outre, utilisez les valeurs d’attribut spécifiques à partir des métadonnées Microsoft Entra lorsque cela est possible. Une fois que vous êtes satisfait de vos messages de sortie, vous pouvez tester l’Analyseur de connectivité Microsoft comme décrit ci-dessous.

Les métadonnées Microsoft Entra peuvent être téléchargées à partir de cette URL : https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml. Pour les clients en Chine utilisant l’instance propre à la Chine de Microsoft 365, le point de terminaison de fédération suivant doit être utilisé : https://nexus.partner.microsoftonline-p.cn/federationmetadata/saml20/federationmetadata.xml.

Exigences du protocole SAML

Cette section présente en détail comment les paires de messages de requête et de réponse sont regroupées pour vous aider à mettre correctement en forme vos messages.

Microsoft Entra ID peut être configuré pour fonctionner avec les fournisseurs d’identité qui utilisent le profil SP-Lite SAML 2.0 avec certaines exigences spécifiques indiquées ci-dessous. En utilisant les exemples de messages de requête et de réponse SAML ainsi que les tests automatisés et manuels, vous pouvez atteindre l’interopérabilité avec Microsoft Entra ID.

Exigences des blocs de signature

Dans le message de réponse SAML, le nœud Signature contient des informations sur la signature numérique du message proprement dit. Ce bloc de signature comporte les exigences suivantes :

Le nœud d’assertion doit être signé
L’algorithme RSA-sha1 doit être utilisé comme DigestMethod. Les autres algorithmes de signature numérique ne sont pas acceptés. <ds:DigestMethod Algorithm="https://www.w3.org/2000/09/xmldsig#sha1"/>
Vous pouvez aussi signer le document XML.
L’algorithme Transform doit correspondre aux valeurs figurant dans l’exemple suivant : <ds:Transform Algorithm="https://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <ds:Transform Algorithm="https://www.w3.org/2001/10/xml-exc-c14n#"/>.
L’algorithme SignatureMethod doit correspondre à l’exemple suivant : <ds:SignatureMethod Algorithm="https://www.w3.org/2000/09/xmldsig#rsa-sha1"/>.

Notes

Afin d’améliorer la sécurité, l’algorithme SHA-1 est déprécié. Utilisez un algorithme plus sécurisé comme SHA-256. D’autres informations sont disponibles ici.

Liaisons prises en charge

Les liaisons représentent les paramètres des communications relatives au transport requises. Les exigences suivantes s’appliquent aux liaisons

HTTPS est le transport requis.
Microsoft Entra ID exige HTTP POST pour la soumission de jeton pendant la connexion.
Microsoft Entra ID utilise HTTP POST pour la demande d’authentification auprès du fournisseur d’identité et REDIRECT pour le message de déconnexion pour le fournisseur d’identité.

Attributs requis

Cette table présente les exigences des attributs spécifiques dans le message SAML 2.0.

Attribut	Description
NameID	La valeur de cette assertion doit être la même que ImmutableID de l’utilisateur Microsoft Entra. Elle peut avoir jusqu'à 64 caractères alphanumériques. Tous les caractères HTML non sécurisés doivent être encodés, par exemple un caractère « + » est affiché comme « .2B ».
IDPEmail	Le nom d’utilisateur principal (UPN) est listé dans la réponse SAML sous la forme d’un élément nommé IDPEmail. Il s’agit du UserPrincipalName (UPN) de l’utilisateur dans Microsoft Entra ID/Microsoft 365. L’UPN est au format de l’adresse de messagerie. Valeur UPN dans Windows Microsoft 365 (ID Microsoft Entra).
Émetteur	Nécessaire pour être un URI du fournisseur d’identité. Ne réutilisez pas l’émetteur à partir des exemples de messages. Si vous avez plusieurs domaines de premier niveau dans vos clients Microsoft Entra, l’émetteur doit correspondre au paramètre URI spécifié, configuré par domaine.

Important

Actuellement, Microsoft Entra ID prend en charge les URI au Format NameID suivant pour SAML 2.0:urn:oasis:names:tc:SAML:2.0:nameid-format:persistent.

Exemple de messages de requête et de réponse SAML

Une paire de messages de requête et de réponse est affichée pour l’échange de messages d’authentification. Vous trouverez ci-dessous un exemple de message de requête envoyé à partir de Microsoft Entra à un exemple de fournisseur d’identité SAML 2.0. L’exemple de fournisseur d’identité SAML 2.0 est Active Directory Federation Services (AD FS) configuré pour utiliser le protocole SAML-P. Les tests d’interopérabilité ont également été effectués avec d’autres fournisseurs d’identité SAML 2.0.

<samlp:AuthnRequest ID="_1e089e5c-a976-4881-af74-3b92c89e7e2c" Version="2.0" IssueInstant="2024-03-12T14:00:18.450Z" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"><Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">urn:federation:MicrosoftOnline</Issuer><samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"/></samlp:AuthnRequest>

Si isSignedAuthenticationRequestRequired est activé comme expliqué dans internaldomainfederation-update, la requête va se présenter comme cet exemple :

  <samlp:AuthnRequest ID="_1868c6f2-1fdd-40b9-818f-b4b44efb92c5" Version="2.0" IssueInstant="2024-03-11T16:51:17.120Z" Destination="https://fs.contoso.com/adfs/ls/" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"><Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">urn:federation:MicrosoftOnline</Issuer><Signature xmlns="http://www.w3.org/2000/09/xmldsig#"><SignedInfo><CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/><Reference URI="#_1868c6f2-1fdd-40b9-818f-b4b44efb92c5"><Transforms><Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></Transforms><DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><DigestValue>aB1cD2eF3gH4iJ5kL6-mN7oP8qR=</DigestValue></Reference></SignedInfo><SignatureValue>cD2eF3gH4iJ5k...L6mN7-oP8qR9sT==</SignatureValue><KeyInfo><ds:X509Data xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509SKI>eF3gH4iJ5kL6mN7oP8-qR9sT0uV=</ds:X509SKI></ds:X509Data><ds:KeyName xmlns:ds="http://www.w3.org/2000/09/xmldsig#">MicrosoftOnline</ds:KeyName></KeyInfo></Signature><samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"/></samlp:AuthnRequest>

Vous trouverez ci-dessous un exemple de message de réponse envoyé à partir de l’exemple de fournisseur d’identité SAML 2.0 vers Microsoft Entra ID / Microsoft 365.

    <samlp:Response ID="_592c022f-e85e-4d23-b55b-9141c95cd2a5" Version="2.0" IssueInstant="2014-01-31T15:36:31.357Z" Destination="https://login.microsoftonline.com/login.srf" Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" InResponseTo="_049917a6-1183-42fd-a190-1d2cbaf9b144" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://WS2012R2-0.contoso.com/adfs/services/trust</Issuer>
    <samlp:Status>
    <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
    </samlp:Status>
    <Assertion ID="_7e3c1bcd-f180-4f78-83e1-7680920793aa" IssueInstant="2014-01-31T15:36:31.279Z" Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
    <Issuer>http://WS2012R2-0.contoso.com/adfs/services/trust</Issuer>
    <ds:Signature xmlns:ds="https://www.w3.org/2000/09/xmldsig#">
      <ds:SignedInfo>
        <ds:CanonicalizationMethod Algorithm="https://www.w3.org/2001/10/xml-exc-c14n#" />
        <ds:SignatureMethod Algorithm="https://www.w3.org/2000/09/xmldsig#rsa-sha1" />
        <ds:Reference URI="#_7e3c1bcd-f180-4f78-83e1-7680920793aa">
          <ds:Transforms>
            <ds:Transform Algorithm="https://www.w3.org/2000/09/xmldsig#enveloped-signature" />
            <ds:Transform Algorithm="https://www.w3.org/2001/10/xml-exc-c14n#" />
          </ds:Transforms>
          <ds:DigestMethod Algorithm="https://www.w3.org/2000/09/xmldsig#sha1" />
          <ds:DigestValue>CBn/aB1cD2eF3gH4iJ5kL6-mN7oP8qR=</ds:DigestValue>
        </ds:Reference>
      </ds:SignedInfo>
      <ds:SignatureValue>cD2eF3gH4iJ5kL6mN7-oP8qR9sT==</ds:SignatureValue>
      <KeyInfo xmlns="https://www.w3.org/2000/09/xmldsig#">
        <ds:X509Data>
          <ds:X509Certificate>eF3gH4iJ5kL6mN7oP8-qR9sT0uV=</ds:X509Certificate>
        </ds:X509Data>
      </KeyInfo>
    </ds:Signature>
    <Subject>
      <NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">ABCDEG1234567890</NameID>
      <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
        <SubjectConfirmationData InResponseTo="_049917a6-1183-42fd-a190-1d2cbaf9b144" NotOnOrAfter="2014-01-31T15:41:31.357Z" Recipient="https://login.microsoftonline.com/login.srf" />
      </SubjectConfirmation>
    </Subject>
    <Conditions NotBefore="2014-01-31T15:36:31.263Z" NotOnOrAfter="2014-01-31T16:36:31.263Z">
      <AudienceRestriction>
        <Audience>urn:federation:MicrosoftOnline</Audience>
      </AudienceRestriction>
    </Conditions>
    <AttributeStatement>
      <Attribute Name="IDPEmail">
        <AttributeValue>administrator@contoso.com</AttributeValue>
      </Attribute>
    </AttributeStatement>
    <AuthnStatement AuthnInstant="2014-01-31T15:36:30.200Z" SessionIndex="_7e3c1bcd-f180-4f78-83e1-7680920793aa">
      <AuthnContext>
        <AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</AuthnContextClassRef>
      </AuthnContext>
    </AuthnStatement>
    </Assertion>
    </samlp:Response>

Configurer votre fournisseur d’identité compatible SAML 2.0

Cette section contient des instructions sur la manière de configurer votre fournisseur d’identité SAML 2.0 pour établir la fédération avec Microsoft Entra ID et permettre l’accès d’authentification unique à un ou plusieurs services cloud Microsoft (tels que Microsoft 365) à l’aide du protocole SAML 2.0. La partie utilisatrice de SAML 2.0 pour un service de cloud Microsoft utilisée dans ce scénario est Microsoft Entra ID.

Ajouter des métadonnées Microsoft Entra

Votre fournisseur d’identité SAML 2.0 doit se conformer aux informations sur la partie utilisatrice Microsoft Entra ID. Microsoft Entra ID publie les métadonnées à l’adresse https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml.

Il est recommandé de toujours importer les dernières métadonnées Microsoft Entra lors de la configuration de votre fournisseur d’identité SAML 2.0.

Remarque

Microsoft Entra ID ne lit pas les métadonnées du fournisseur d’identité.

Ajouter Microsoft Entra ID en tant que partie de confiance

Vous devez activer la communication entre votre fournisseur d’identité SAML 2.0 et Microsoft Entra ID. Cette configuration dépend de votre fournisseur d’identité spécifique, vous devez vous référer à la documentation correspondante. Vous pouvez généralement définir l’ID de la partie utilisatrice identique à l’entityID à partir des métadonnées Microsoft Entra.

Remarque

Vérifiez que l’horloge du serveur de votre fournisseur d’identité SAML 2.0 est synchronisée à une heure source précise. Une heure inexacte peut entraîner l’échec des connexions fédérées.

Installez PowerShell pour une authentification avec le fournisseur d’identité SAML 2.0

Après avoir configuré votre fournisseur d’identité SAML 2.0 pour une utilisation avec l’authentification Microsoft Entra, l’étape suivante consiste à télécharger et installer le module PowerShell Microsoft Graph. Une fois installé, vous allez utiliser ces applets de commande pour configurer vos domaines Microsoft Entra en tant que domaines fédérés.

Le module PowerShell Microsoft Graph est un téléchargement pour la gestion des données de votre organisation dans Microsoft Entra ID. Ce module installe un ensemble d’applets de commande sur PowerShell. Exécutez ces applets de commande pour configurer un accès par authentification unique à Microsoft Entra ID et à tous les services cloud auxquels vous êtes abonné. Pour obtenir des instructions sur le téléchargement et l’installation des applets de commande, consultez Installer le kit de développement logiciel (SDK) PowerShell Microsoft Graph.

Configurer une approbation entre votre fournisseur d’identité SAML et Microsoft Entra ID

Avant de configurer la fédération sur un domaine Microsoft Entra, un domaine personnalisé doit être configuré. Vous ne pouvez pas fédérer le domaine par défaut fourni par Microsoft. Le domaine par défaut de Microsoft se termine par onmicrosoft.com. Exécutez une série d’applets de commande PowerShell pour ajouter ou convertir des domaines pour une authentification unique.

Chaque domaine Microsoft Entra que vous souhaitez fédérer à l’aide de votre fournisseur d’identité SAML 2.0 doit être ajouté en tant que domaine d’authentification unique ou converti en un seul domaine d’authentification d’un domaine standard. L’ajout ou la conversion d’un domaine configure une approbation entre votre fournisseur d’identité SAML 2.0 et Microsoft Entra ID.

La procédure suivante vous guide tout au long de la conversion d’un domaine standard existant en domaine fédéré à l’aide de SP-Lite SAML 2.0.

Notes

Votre domaine peut rencontrer une indisponibilité qui impacte les utilisateurs pendant au moins 2 heures après avoir effectué cette étape.

Configuration d’un domaine dans votre répertoire Microsoft Entra pour la fédération

Connectez-vous à votre répertoire Microsoft Entra en tant qu'administrateur client :
```
Connect-MgGraph -Scopes "Domain.ReadWrite.All"
```

Configurez le domaine Microsoft 365 de votre choix pour utiliser la fédération avec SAML 2.0 :

$Domain = "contoso.com"  
$LogOnUrl = "https://WS2012R2-0.contoso.com/passiveLogon" 
$LogOffUrl = "https://WS2012R2-0.contoso.com/passiveLogOff" 
$ecpUrl = "https://WS2012R2-0.contoso.com/PAOS" 
$MyUri = "urn:uri:MySamlp2IDP"
$idptokensigningcert = [System.Security.Cryptography.X509Certificates.X509Certificate2]("C:\temp\contosoidptokensign.cer")  
$MySigningCert = [system.convert]::tobase64string($idptokensigningcert.rawdata) 
$Protocol = "saml"

New-MgDomainFederationConfiguration `
  -DomainId $Domain `
  -ActiveSignInUri $ecpUrl `
  -IssuerUri $MyUri `
  -PassiveSignInUri $LogOnUrl `
  -PreferredAuthenticationProtocol $Protocol `
  -SignOutUri $LogOffUrl `
  -SigningCertificate $MySigningCert

Vous pouvez obtenir la chaîne codée en base 64 du certificat de signature à partir de votre fichier de métadonnées IDP. Un exemple de cet emplacement est fourni ci-dessous, mais peut légèrement varier en fonction de votre implémentation.

<IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
  <KeyDescriptor use="signing">
    <KeyInfo xmlns="https://www.w3.org/2000/09/xmldsig#">
     <X509Data>
       <X509Certificate> eF3gH4iJ5kL6mN7oP8-qR9sT0uV=</X509Certificate>
      </X509Data>
    </KeyInfo>
  </KeyDescriptor>
</IDPSSODescriptor>

Pour plus d’informations, consultez New-MgDomainFederationConfiguration.

Remarque

Vous devez utiliser $ecpUrl = "https://WS2012R2-0.contoso.com/PAOS" uniquement si vous définissez une extension ECP pour votre fournisseur d’identité. Les clients Exchange Online, à l’exception d’Outlook Web Application (OWA), s’appuient sur un point de terminaison actif basé sur POST. Si votre STS SAML 2.0 met en œuvre un point de terminaison actif similaire à la mise en œuvre d’ECP de Shibboleth, il est possible pour ces clients riches d’interagir avec le service Exchange Online.

Une fois la fédération configurée, vous pouvez basculer vers « non fédéré » (ou « géré »). Toutefois, ce changement peut prendre jusqu’à deux heures et nécessite l’attribution de nouveaux mots de passe aléatoires pour l’authentification basée sur le cloud pour chaque utilisateur. Basculer vers « géré » peut être nécessaire dans certains scénarios pour réinitialiser une erreur dans vos paramètres. Pour plus d’informations sur la conversion de domaine, consultez Remove-MgDomainFederationConfiguration.

Approvisionner les principaux d’utilisateur sur Microsoft Entra ID / Microsoft 365

Avant d’authentifier vos utilisateurs auprès de Microsoft 365, vous devez provisionner Microsoft Entra ID avec des principaux d’utilisateur qui correspondent à l’assertion contenue dans la revendication SAML 2.0. Si ces principaux d’utilisateur ne sont pas connus dans Microsoft Entra ID à l’avance, ils ne peuvent pas être utilisés pour la connexion fédérée. Microsoft Entra Connect ou PowerShell peut être utilisé pour approvisionner les principaux d’utilisateur.

Microsoft Entra Connect peut être utilisé pour approvisionner les principaux vers vos domaines dans votre répertoire Microsoft Entra à partir d’Active Directory local. Pour obtenir plus d’informations, consultez Intégrer vos répertoires locaux avec Microsoft Entra ID.

PowerShell peut également être utilisé pour automatiser l’ajout de nouveaux utilisateurs à Microsoft Entra ID et synchroniser les modifications apportées à partir du répertoire local. Pour utiliser les applets de commande PowerShell, vous devez télécharger les modules PowerShell Microsoft Graph.

Cette procédure indique comment ajouter un utilisateur unique à Microsoft Entra ID.

Connectez-vous à votre répertoire Microsoft Entra en tant qu’administrateur client en utilisant Connect-MgGraph.

Créer un principal d’utilisateur :

$Password =  -join ((48..57) + (97..122) | Get-Random -Count 12 | % {[char]$_})
$PasswordProfile = @{ Password = "$Password" }

New-MgUser `
  -UserPrincipalName "elwoodf1@contoso.com" `
  -DisplayName "Elwood Folk" `
  -GivenName "Elwood" `
  -Surname "Folk" `
  -AccountEnabled `
  -MailNickName 'ElwoodFolk' `
  -OnPremisesImmutableId ABCDEFG1234567890 `
  -OtherMails "Elwood.Folk@contoso.com" `
  -PasswordProfile $PasswordProfile `
  -UsageLocation "US"

Pour plus d’informations, consultez New-MgUser.

Remarque

La valeur « UserPrincipalName » doit correspondre à la valeur que vous envoyez pour « IDPEmail » dans votre revendication SAML 2.0 et la valeur « OnPremisesImmutableId » doit correspondre à la valeur envoyée dans votre assertion « NameID ».

Vérifiez l’authentification unique avec votre fournisseur d’identité SAML 2.0

En tant qu’administrateur, avant de vérifier et gérer l’authentification unique (également appelée fédération des identités), passez en revue les informations et suivez les étapes dans les articles ci-dessous pour configurer l’authentification unique avec votre fournisseur d’identité basé sur SP-Lite SAML 2.0 :

Vous avez consulté les exigences du protocole SAML 2.0 Microsoft Entra
Vous avez configuré votre fournisseur d’identité SAML 2.0
Installez PowerShell pour une authentification unique (SSO) avec le fournisseur d’identité SAML 2.0
Configurer une approbation entre le fournisseur d’identité SAML 2.0 et Microsoft Entra ID
Configurez un principal d’utilisateur test connu sur Microsoft Entra ID (Microsoft 365) par le biais de PowerShell ou de Microsoft Entra Connect.
Configurez la synchronisation d’annuaires à l’aide de Microsoft Entra Connect.

Après avoir configuré l’authentification unique avec votre fournisseur d’identité basé sur SP-Lite SAML 2.0, vous devez vérifier qu’elle fonctionne correctement. Pour plus d’informations sur le test de l’authentification unique basée sur SAML, consultez test de l’authentification unique basée sur SAML.

Remarque

Si vous avez converti un domaine, plutôt que d’en ajouter un, l’authentification unique peut prendre jusqu'à 24 heures. Avant de vérifier l’authentification unique, vous devez terminer la configuration de la synchronisation Active Directory, synchroniser vos répertoires et activer vos utilisateurs synchronisés.

Vérifiez manuellement que l’authentification unique a été correctement configurée

La vérification manuelle comprend davantage d’étapes que vous pouvez suivre pour vous assurer que votre fournisseur d’identité SAML 2.0 fonctionne correctement dans de nombreux scénarios. Pour vous assurer que l’authentification unique est correctement configurée, procédez comme suit :

Sur un ordinateur joint au domaine, connectez-vous à votre service cloud à l’aide du nom de connexion que vous utilisez pour vos informations d’identification d’entreprise.
Sélectionnez la zone du mot de passe. Si l’authentification unique est configurée, la zone du mot de passe est grisée et le message suivant s’affiche : « Vous devez maintenant vous connecter à <votre entreprise>. »
Sélectionnez le lien Connexion à <votre entreprise>. Si vous êtes en mesure de vous connecter, l’authentification unique a été configurée.

Partager via

Utiliser un fournisseur d’identité (IdP) SAML 2.0 pour l’authentification unique

Microsoft Entra configuration requise pour le protocole SAML 2.0

Exigences du protocole SAML

Exigences des blocs de signature

Liaisons prises en charge

Attributs requis

Exemple de messages de requête et de réponse SAML

Configurer votre fournisseur d’identité compatible SAML 2.0

Ajouter des métadonnées Microsoft Entra

Ajouter Microsoft Entra ID en tant que partie de confiance

Installez PowerShell pour une authentification avec le fournisseur d’identité SAML 2.0

Configurer une approbation entre votre fournisseur d’identité SAML et Microsoft Entra ID

Configuration d’un domaine dans votre répertoire Microsoft Entra pour la fédération

Approvisionner les principaux d’utilisateur sur Microsoft Entra ID / Microsoft 365

Vérifiez l’authentification unique avec votre fournisseur d’identité SAML 2.0

Vérifiez manuellement que l’authentification unique a été correctement configurée

Étapes suivantes

Commentaires

Ressources supplémentaires