Utiliser un fournisseur d’identité SAML 2.0 pour implémenter l’authentification unique

S’applique à : Azure, Office 365, Power BI, Windows Intune

Cette rubrique contient des instructions à l'attention des responsables de l'implémentation d'un service cloud Microsoft qui souhaitent fournir à leurs utilisateurs Azure Active Directory (AD) une solution de validation d'authentification en faisant appel à un fournisseur d'identité basé sur un profil SP-Lite compatible SAML 2.0 comme service d'émission de jeton de sécurité/fournisseur d'identité préféré. Cette approche est utile lorsque le responsable de l'implémentation de solution dispose déjà d'un annuaire d'utilisateurs et d'un magasin de mots de passe accessibles via SAML 2.0 au niveau local. Ce répertoire d’utilisateurs existant peut être utilisé pour l’authentification à Office 365 et d’autres ressources sécurisées par AD Azure. 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.

Pour prendre en charge ce processus d'authentification, un fournisseur d'identité basé sur un profil SAML 2.0 correctement configuré (que nous allons désormais désigner sous le nom de « fournisseur d'identité SAML 2.0 ») est intégré à un service cloud Microsoft, par exemple Office 365. 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, configuration, 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.

Exigences du protocole SAML 2.0 Azure AD

Cette rubrique 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 Azure AD et activer l’authentification à un ou plusieurs services de cloud de Microsoft (par exemple, Office 365). La partie utilisatrice de SAML 2.0 (SP-STS) pour un service de cloud Microsoft utilisée dans ce scénario est Azure AD.

Il est recommandé que les messages de sortie de votre fournisseur d'identité SAML 2.0 s'apparentent le plus possible aux exemples fournis. En outre, utilisez les valeurs d’attribut spécifiques à partir des métadonnées Azure AD 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 Azure AD 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 d’Office 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.

Azure AD 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 Azure AD.

Exigences concernant le bloc 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 :

1. Le nœud d’assertion doit être signé

2. L’algorithme RSA-sha1 doit être utilisé comme DigestMethod. Les autres algorithmes de signature numérique ne sont pas acceptés.

   <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
   

3. Vous pouvez aussi signer le document XML.

4. Les valeurs de l'algorithme Transform doivent correspondre à celles de l'exemple suivant :

   <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
     <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
   

5. L'algorithme SignatureMethod doit correspondre à l'exemple suivant :

   <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
   

Liaisons prises en charge

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

1. HTTPS est le transport requis.

2. Azure AD exige HTTP POST pour la soumission de jeton au cours de la connexion

3. Azure AD utilise HTTP POST pour la demande d’authentification auprès du fournisseur d’identité et REDIRECT pour le message de fermeture de session pour le fournisseur d’identité.

Attributs requis

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

Exemples de messages de demande 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.

Il s’agit d’un exemple de message de requête envoyé à partir d’Azure AD à 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 xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_7171b0b2-19f2-4ba2-8f94-24b5e56b7f1e" IssueInstant="2014-01-30T16:18:35Z" Version="2.0" AssertionConsumerServiceIndex="0" >
  <saml:Issuer>urn:federation:MicrosoftOnline</saml:Issuer>
  <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"/>
</samlp:AuthnRequest>

Il s’agit d’un exemple de message de réponse envoyé depuis l’exemple de fournisseur d’identité SAML 2.0 vers Azure AD / Office 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="http://www.w3.org/2000/09/xmldsig#">
      <ds:SignedInfo>
        <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
        <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
        <ds:Reference URI="#_7e3c1bcd-f180-4f78-83e1-7680920793aa">
          <ds:Transforms>
            <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
            <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
          </ds:Transforms>
          <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
          <ds:DigestValue>CBn/5YqbheaJP425c0pHva9PhNY=</ds:DigestValue>
        </ds:Reference>
      </ds:SignedInfo>
      <ds:SignatureValue>TciWMyHW2ZODrh/2xrvp5ggmcHBFEd9vrp6DYXp+hZWJzmXMmzwmwS8KNRJKy8H7XqBsdELA1Msqi8I3TmWdnoIRfM/ZAyUppo8suMu6Zw+boE32hoQRnX9EWN/f0vH6zA/YKTzrjca6JQ8gAV1ErwvRWDpyMcwdYCiWALv9ScbkAcebOE1s1JctZ5RBXggdZWrYi72X+I4i6WgyZcIGai/rZ4v2otoWAEHS0y1yh1qT7NDPpl/McDaTGkNU6C+8VfjD78DrUXEcAfKvPgKlKrOMZnD1lCGsViimGY+LSuIdY45MLmyaa5UT4KWph6dA==</ds:SignatureValue>
      <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
        <ds:X509Data>
          <ds:X509Certificate>MIIC7jCCAdagAwIBAgIQRrjsbFPaXIlOG3GTv50fkjANBgkqhkiG9w0BAQsFADAzMTEwLwYDVQQDEyhBREZTIFNpZ25pbmcgLSBXUzIwMTJSMi0wLnN3aW5mb3JtZXIuY29tMB4XDTE0MDEyMDE1MTY0MFoXDTE1MDEyMDE1MTY0MFowMzExMC8GA1UEAxMoQURGUyBTaWduaW5nIC0gV1MyMDEyUjItMC5zd2luZm9ybWVyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKe+rLVmXy1QwCwZwqgbbp1/+3ZWxd9T/jV0hpLIIWr+LCOHqq8n8beJvlivgLmDJo8f+EITnAxWcsJUvVai/35AhHCUq9tc9sqMp5PWtabAEMb2AU72/QlX/72D2/NbGQq1BWYbqUpgpCZ2nSgvlWDHlCiUo//UGsvfox01kjTFlmqQInsJVfRxF5AcCAwEAATANBgkqhkiG9w0BAQsFAAOCAQEAi8c6C4zaTEc7aQiUgvnGQgCbMZbhUXXLGRpjvFLKaQzkwa9eq7WLJibcSNyGXBa/SfT5wJgsm3TPKgSehGAOTirhcqHheZyvBObAScY7GOT+u9pVYp6raFrc7ez3c+CGHeV/tNvy1hJNs12FYH4X+ZCNFIT9tprieR25NCdi5SWUbPZL0tVzJsHc1y92b2M2FxqRDohxQgJvyJOpcg2mSBzZZIkvDg7gfPSUXHVS1MQs0RHSbwq/XdQocUUhl9/e/YWCbNNxlM84BxFsBUok1dH/gzBySx+Fc8zYi7cOq9yaBT3RLT6cGmFGVYZJW4FyhPZOCLVNsLlnPQcX3dDg9A==</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 rubrique contient des instructions sur comment configurer votre fournisseur d’identité SAML 2.0 pour établir la fédération avec Azure AD et permettre l’accès d’authentification unique à un ou plusieurs services cloud Microsoft (par exemple, Office 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 Azure AD.

Ajouter les métadonnées Azure AD

Votre fournisseur d’identité SAML 2.0 doit se conformer aux informations sur la partie utilisatrice AD Azure. Azure AD publie des métadonnées dans https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml.

Il est recommandé de toujours importer les dernières métadonnées Azure AD lors de la configuration de votre fournisseur d’identité SAML 2.0. Notez qu’Azure AD ne lit pas les métadonnées du fournisseur d’identité.

Ajouter Azure AD en tant que partie utilisatrice

Vous devez activer la communication entre votre fournisseur d’identité SAML 2.0 et Azure AD. 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 Azure AD.

Installez Windows PowerShell pour l’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 Azure AD, l’étape suivante consiste à télécharger et installer le Module Azure Active Directory pour Windows PowerShell. Une fois installé, utilisez ces applets de commande pour configurer vos domaines Azure AD en tant que domaines fédérés.

Le Module Azure Active Directory pour Windows PowerShell est téléchargé pour la gestion des données de votre organisation dans Azure AD. Ce module installe un ensemble d’applets de commande Windows PowerShell ; exécutez ces applets de commande pour configurer l’accès d’authentification unique à Azure AD et à tous les services cloud auxquels vous êtes abonné. Pour obtenir des instructions sur le téléchargement et l'installation de ces applets de commande, consultez https://technet.microsoft.com/library/jj151815.aspx.

Configurer une approbation entre votre fournisseur d’identité SAML et Azure AD

Avant de configurer la fédération sur un domaine Azure AD, 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 dans l’interface de ligne de commandes de Windows PowerShell pour ajouter ou convertir des domaines pour l’authentification unique.

Chaque domaine Azure Active Directory 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 Azure AD.

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. Notez que 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 locataire Office 365 à des fins de fédération

1. Connecter à votre locataire Office 365 en tant qu’administrateur de locataire : Connect-MsolService .

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

   $dom = "contoso.com" $BrandName - "Sample SAML 2.0 IDP" $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" $MySigningCert = @" MIIC7jCCAdagAwIBAgIQRrjsbFPaXIlOG3GTv50fkjANBgkqhkiG9w0BAQsFADAzMTEwLwYDVQQDEyh BREZTIFNpZ25pbmcgLSBXUzIwMTJSMi0wLnN3aW5mb3JtZXIuY29tMB4XDTE0MDEyMDE1MTY0MFoXDT E1MDEyMDE1MTY0MFowMzExMC8GA1UEAxMoQURGUyBTaWduaW5nIC0gV1MyMDEyUjItMC5zd2luZm9yb WVyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKe+rLVmXy1QwCwZwqgbbp1/kupQ VcjKuKLitVDbssFyqbDTjP7WRjlVMWAHBI3kgNT7oE362Gf2WMJFf1b0HcrsgLin7daRXpq4Qi6OA57 sW1YFMj3sqyuTP0eZV3S4+ZbDVob6amsZIdIwxaLP9Zfywg2bLsGnVldB0+XKedZwDbCLCVg+3ZWxd9 T/jV0hpLIIWr+LCOHqq8n8beJvlivgLmDJo8f+EITnAxWcsJUvVai/35AhHCUq9tc9sqMp5PWtabAEM b2AU72/QlX/72D2/NbGQq1BWYbqUpgpCZ2nSgvlWDHlCiUo//UGsvfox01kjTFlmqQInsJVfRxF5AcC AwEAATANBgkqhkiG9w0BAQsFAAOCAQEAi8c6C4zaTEc7aQiUgvnGQgCbMZbhUXXLGRpjvFLKaQzkwa9 eq7WLJibcSNyGXBa/SfT5wJgsm3TPKgSehGAOTirhcqHheZyvBObAScY7GOT+u9pVYp6raFrc7ez3c+ CGHeV/tNvy1hJNs12FYH4X+ZCNFIT9tprieR25NCdi5SWUbPZL0tVzJsHc1y92b2M2FxqRDohxQgJvy JOpcg2mSBzZZIkvDg7gfPSUXHVS1MQs0RHSbwq/XdQocUUhl9/e/YWCbNNxlM84BxFsBUok1dH/gzBy Sx+Fc8zYi7cOq9yaBT3RLT6cGmFGVYZJW4FyhPZOCLVNsLlnPQcX3dDg9A==" "@ $uri = "http://WS2012R2-0.contoso.com/adfs/services/trust" $Protocol = "SAMLP" Set-MsolDomainAuthentication ` -DomainName $dom -FederationBrandName $dom -Authentication Federated -PassiveLogOnUri $MyURI -ActiveLogOnUri $ecpUrl -SigningCertificate $MySigningCert -IssuerUri $uri -LogOffUri $url -PreferredAuthenticationProtocol $Protocol 
   

   REMARQUE : Vous pouvez obtenir la chaîne codée en base64 du certificat de signature à partir de votre fichier de métadonnées IDP. Un exemple de cet emplacement est fourni, mais il peut varier légèrement selon votre implémentation.

   <IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"> <KeyDescriptor use="signing"> <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"> <X509Data> <X509Certificate>MIIC5jCCAc6gAwIBAgIQLnaxUPzay6ZJsC8HVv/QfTANBgkqhkiG9w0BAQsFADAvMS0wKwYDVQQDEyRBREZTIFNpZ25pbmcgLSBmcy50ZWNobGFiY2VudHJhbC5vcmcwHhcNMTMxMTA0MTgxMzMyWhcNMTQxMTA0MTgxMzMyWjAvMS0wKwYDVQQDEyRBREZTIFNpZ25pbmcgLSBmcy50ZWNobGFiY2VudHJhbC5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwMdVLTr5YTSRp+ccbSpuuFeXMfABD9mVCi2wtkRwC30TIyPdORz642MkurdxdPCWjwgJ0HW6TvXwcO9afH3OC5V//wEGDoNcI8PV4enCzTYFe/h//w51uqyv48Fbb3lEXs+aVl8155OAj2sO9IX64OJWKey82GQWK3g7LfhWWpp17j5bKpSd9DBH5pvrV+Q1ESU3mx71TEOvikHGCZYitEPywNeVMLRKrevdWI3FAhFjcCSO6nWDiMqCqiTDYOURXIcHVYTSof1YotkJ4tG6mP5Kpjzd4VQvnR7Pjb47nhIYG6iZ3mR1F85Ns9+hBWukQWNN2hcD/uGdPXhpdMVpBAgMBAAEwDQYJKoZIhvcNAQELBQADggEBAK7h7jF7wPzhZ1dPl4e+XMAr8I7TNbhgEU3+oxKyW/IioQbvZVw1mYVCbGq9Rsw4KE06eSMybqHln3w5EeBbLS0MEkApqHY+p68iRpguqa+W7UHKXXQVgPMCpqxMFKonX6VlSQOR64FgpBme2uG+LJ8reTgypEKspQIN0WvtPWmiq4zAwBp08hAacgv868c0MM4WbOYU0rzMIR6Q+ceGVRImlCwZ5b7XKp4mJZ9hlaRjeuyVrDuzBkzROSurX1OXoci08yJvhbtiBJLf3uPOJHrhjKRwIt2TnzS9ElgFZlJiDIA26Athe73n43CT0af2IG6yC7e6sK4L3NEXJrwwUZk=</X509Certificate> </X509Data> </KeyInfo> </KeyDescriptor> 
   

   Pour plus d’informations sur « Set-MsolDomainAuthentication », consultez : https://technet.microsoft.com/library/dn194112.aspx.

   Notes

   Vous devez exécutez 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 : https://msdn.microsoft.com/library/windowsazure/dn194122.aspx.

Déploiement de principaux d'utilisateur vers Azure AD/Office 365

Avant d’authentifier vos utilisateurs à Office 365, vous devez approvisionner Azure AD avec des principaux d’utilisateur qui correspondent à l’assertion de la revendication SAML 2.0. Si ces principaux d’utilisateur ne sont pas connus dans Azure AD à l’avance, ils ne peuvent pas être utilisés pour la connexion fédérée. DirSync ou Windows PowerShell peuvent être utilisés pour approvisionner des principaux d’utilisateur.

L'outil DirSync permet de déployer des principaux vers vos domaines dans votre locataire Office 365 depuis le service Active Directory local. Pour plus d’informations, consultez : https://technet.microsoft.com/library/hh967642.aspx.

Windows PowerShell peut également être utilisé pour automatiser l’ajout de nouveaux utilisateurs à Azure AD et synchroniser les modifications apportées à partir du répertoire local. Pour utiliser les applets de commande Windows PowerShell, vous devez télécharger les modules Azure Active Directory qui peuvent être obtenus ici : https://technet.microsoft.com/library/jj151815.aspx.

Cette procédure indique comment ajouter un utilisateur unique à Azure AD.

1. Connecter à votre locataire Office 365 en tant qu’administrateur de locataire : Connect-MsolService.

2. Créer un principal d’utilisateur :

   New-MsolUser ` 
   -UserPrincipalName elwoodf1@contoso.com
   -ImmutableId ABCDEFG1234567890
   -DisplayName "Elwood Folk"
   -FirstName Elwood 
   -LastName Folk 
   -AlternateEmailAddresses "Elwood.Folk@contoso.com" 
   -LicenseAssignment "samlp2test:ENTERPRISEPACK" 
   -UsageLocation "US" 
   

   Pour plus d’informations sur « New-MsolUser », consultez https://technet.microsoft.com/en-us/library/dn194096.aspx.

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 :

1. Vous avez consulté les exigences du protocole SAML 2.0 Azure AD

2. Vous avez configuré votre fournisseur d’identité SAML 2.0

3. Installez Windows PowerShell pour l’authentification unique avec le fournisseur d’identité SAML 2.0

4. Configurez une approbation entre votre fournisseur d’identité SAML 2.0 et Azure AD

5. Déployez un principal d'utilisateur test vers Azure Active Directory (Office 365) par le biais de Windows PowerShell ou de DirSync.

6. Suivez les instructions détaillées de la feuille de route de synchronisation d’annuaires pour préparer, activer, installer un outil et vérifier la synchronisation d’annuaires.

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.

Utilisez l’outil pour vérifier que l’authentification unique a été correctement configurée

Afin de vérifier la configuration correcte de l’authentification unique, vous pouvez exécuter la procédure suivante pour confirmer la possible connexion au service clous avec vos informations d’identification. Vous trouverez sur Microsoft TechNet de l'aide pour tester l'authentification unique à l'aide des services AD FS dans différents cas de figure.

Microsoft propose un outil que vous pouvez utiliser pour tester votre fournisseur d’identité basé sur SAML 2.0. Avant d’exécuter l’outil de test, vous devez avoir configuré un client Azure AD pour procéder à une fédération avec votre fournisseur d’identité.

1. Téléchargez l’Analyseur de connectivité à partir de https://testconnectivity.microsoft.com/?tabid=Client.

2. Cliquez sur Installer maintenant pour télécharger et installer l'outil. Voici une capture d'écran de l'outil une fois-celui téléchargé et démarré.

   

   Sélectionnez Je ne peux pas configurer la fédération avec Office 365, Azure ou d'autres services utilisant Azure Active Directory.

3. Une fois l’outil téléchargé et en cours d’exécution, la fenêtre Diagnostics de connectivité s’affiche. L’outil vous guide pour tester votre connexion de fédération.

   

4. L'analyseur de connectivité ouvre votre fournisseur d'identité SAML 2.0 pour vous permettre de vous connecter. Entrez les informations d'identification du principal d'utilisateur que vous testez :

   

5. Dans la fenêtre de connexion des tests de la fédération, entrez un nom de compte et un mot de passe pour le client Azure AD configuré pour être fédéré avec votre fournisseur d’identité SAML 2.0. L’outil tente de se connecter à l’aide de ces informations d’identification et les résultats détaillés de tests effectués lors de la tentative de connexion sont fournis en tant que sortie.

   

6. Cette fenêtre affiche un résultat d’échec du test. Cliquez sur Vérifier les résultats détaillés pour afficher des informations sur les résultats de chaque test effectué. Vous pouvez également enregistrer les résultats sur le disque afin de les partager.

   Notes

   L’analyseur de connectivité teste également la fédération active à l’aide des protocoles WS*et ECP/PAOS si vous n’utilisez pas ces protocoles, vous pouvez ignorer l’erreur suivante : Tester le flux de connexion active à l’aide du point de terminaison de fédération Active de votre fournisseur d’identité.

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

La vérification manuelle comprend des étapes supplémentaires que vous pouvez suivre pour vous assurer que votre fournisseur d’identité SAML 2.0 fonctionne correctement dans de nombreux scénarios.

Pour vérifier que l’authentification unique a été correctement configurée, procédez comme suit :

1. Sur un ordinateur joint au domaine, connectez-vous à votre service cloud à l’aide du même nom d’ouverture de session que vous utilisez pour vos informations d’identification d’entreprise.

2. Cliquez dans la zone de mot de passe. Si l’authentification unique est configurée, la zone de mot de passe est ombrée et vous verrez le message suivant : « Vous êtes maintenant obligé de vous connecter à <votre entreprise> ».

3. Cliquez sur le lien de connexion à <votre entreprise> . Si vous êtes en mesure de vous connecter, l’authentification unique a été configurée.

Voir aussi

Concepts

DirSync avec authentification unique