Azure AD Connect: Use a SAML 2.0 Identity Provider for Single Sign-On - Azure - Microsoft (2023)

This document provides information on using a SAML 2.0 compliant identity provider based on SP-Lite profiles as a preferred identity provider/Security Token Service (STS). This scenario is useful when you already have a user directory and password store that can be accessed through SAML 2.0. This existing user directory can be used to sign in to Microsoft 365 and other secure Azure AD resources. The SAML 2.0 SP-Lite profile is based on the widely used Security Assertion Markup Language (SAML) federated identity standard to provide a framework for connecting and exchanging attributes.

Microsoft supports this sign-in experience as an integration of a Microsoft cloud service such as Microsoft 365 with its properly configured SAML 2.0 profile-based IdP. SAML 2.0 identity providers are third-party products, and as such, Microsoft does not support best practices for implementing, configuring, and troubleshooting them. Once configured correctly, the SAML 2.0 identity provider integration can be tested for proper configuration using the Microsoft Connectivity Analyzer tool, described in more detail below. For more information on your profile-based SAML 2.0 SP-Lite identity provider, contact the organization that provided it.

All other clients are not available in this login scenario with their SAML 2.0 identity provider. For example, the Lync 2010 desktop client cannot sign in to the service if its SAML 2.0 identity provider is configured for single sign-on.

Azure AD SAML 2.0 protocol requirements

This document provides detailed message format and protocol requirements that your SAML 2.0 identity provider must implement to federate with Azure AD to enable sign-in to one or more Microsoft cloud services (such as Microsoft 365). The SAML 2.0 Relying Party (SP-STS) for a Microsoft cloud service used in this scenario is Azure AD.

It is recommended to ensure that the output messages from the SAML 2.0 identity provider are as similar as possible to the sample traces provided. Also, if possible, use specific attribute values ​​from the provided Azure AD metadata. Once you're happy with your outgoing messages, you can test them with Microsoft Connectivity Analyzer as described below.

Azure AD metadata can be downloaded from this URL:https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xmlFor customers in China using the China-specific instance of Microsoft 365, the following federated endpoint should be used:https://nexus.partner.microsoftonline-p.cn/federationmetadata/saml20/federationmetadata.xml.

SAML protocol requirements

This section describes how to compose request and response message pairs so that you can format your messages correctly.

Azure AD can be configured to work with identity providers using the SAML 2.0 SP Lite profile with some specific requirements listed below. Work toward interoperability with Azure AD using sample SAML request and response messages, as well as automated and manual tests.

Signature block requirements

In the SAML response message, the signature node contains information about the digital signature of the message itself. The signature block has the following requirements:

1. The assertion node itself must be signed
2. The RSA sha1 algorithm should be used as the DigestMethod. Other digital signature algorithms are not supported.<ds:DigestMethod-Algorithmus="https://www.w3.org/2000/09/xmldsig#sha1"/>
3. You can also sign the XML document.
4. The transformation algorithm must match the values ​​in the following example:<ds:Transformation algorithm="https://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <ds:Transformation algorithm="https://www.w3.org/2001/ 10/ xml-exc-c14n#"/>
5. The SignatureMethod algorithm should resemble the following example:<ds:SignatureMethod-Algorithmus="https://www.w3.org/2000/09/xmldsig#rsa-sha1"/>

supported links

The links are the transport related communication parameters that are required. The following requirements apply to bindings

1. HTTPS is the required transport.
2. Azure AD requires HTTP POST for token delivery during sign-in.
3. Azure AD uses HTTP POST for the authentication request to the identity provider and REDIRECT for the outgoing message to the identity provider.

mandatory attributes

This table shows the requirements for specific attributes in the SAML 2.0 message.

SAML Request and Response Message Examples

A pair of request and response messages is displayed for the login message exchange. Here is a sample request message sent from Azure AD to a sample SAML 2.0 identity provider. The sample SAML 2.0 identity provider is Active Directory Federation Services (AD FS) configured to use the SAML-P protocol. Interoperability testing with other SAML 2.0 identity providers was also performed.

<samlp:AuthnRequest xmlns:samlp="urna:oasis:nombres:tc:SAML:2.0:protocolo" xmlns:saml="urna:oasis:nombres:tc:SAML:2.0:afirmación" 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>

The following is an example of a response message sent to Azure AD/Microsoft 365 by the SAML 2.0 compliant identity provider.

<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:protocolo"> <Issuer xmlns="urn:oasis:names:tc:SAML:2.0:asertion">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:asertion"> <Austeller>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 /xml dsig#r sa-sha1" /> <ds:Referencia URI="#_7e3c1bcd-f180-4f78-83e1-7680920793aa"> <ds:Transformaciones> <ds:Algoritmo de transformación="https://www.w3. org/ 2000/09 /xmldsig#firma-envuelta" /> <ds:Algoritmo de transformación="https://www.w3.org/2001/10/xml-exc-c14n#" /> </ds:Transformaciones> <ds :DigestMethod-Algorithmus ="https://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="https:// www.w3 .org/ 2000/09/xmldsig#"> <ds:X509Data> <ds:X509Certificate>MIIC7jCCAdagAwIBAgIQRrjsbFPaXIlOG3GTv50fkjANBgkqhkiG9w0BAQsFADAzMTEwLwYDVQQDEyhBREZTIFNpZ25pbmcgLSBXUz I0BAQsFADAz MTEwLwYDVQQDEyhBREZTIFNpZ25pbmcgLSBXUzI0BAQsFADAzMTEwLwYDVQQDEyhBREZTIFNpZ25pbmcgLSBXUzIzI5wMTNJtnJtnJTJ ZXIuY29tMB4XDTE0MDEyMDE1MTY0MFoXDTE1MDEyMDE1MTY0MFowMzExMC8GA1UEAxMoQURGUyBTaWduaW5nIC0gV1MyMDEyUjItMC5zd2luZm9ybWVyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKe+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">ABCDEG12 34567890</Nam eID> <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> <SubjectConfirmationData InRespo nseTo="_049917a6-1183-42fd-a190-1d2cbaf9b144" NotOnOrAfter="2014-01 -31T15:41 :31.357Z" Destinatario="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>Administrador @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>

Set up your SAML 2.0 compliant identity provider

This section provides guidance on how to configure your SAML 2.0 identity provider to federate with Azure AD to enable single sign-on access to one or more Microsoft cloud services (such as Microsoft 365) using the SAML 2.0 protocol. The SAML 2.0 relying party for a Microsoft cloud service used in this scenario is Azure AD.

Your SAML 2.0 identity provider must comply with Azure AD relying party information. Azure AD publishes metadata tohttps://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml.

It is recommended to always import the latest metadata from Azure AD when configuring your SAML 2.0 identity provider.

Add Azure AD as a relying party

You must enable communication between your SAML 2.0 identity provider and Azure AD. This setting depends on your specific identity provider and you should refer to the documentation for this. Typically, you would configure the relying party ID to be the same as the entity ID in the Azure AD metadata.

Install Windows PowerShell to sign in with the SAML 2.0 identity provider

Once you've configured your SAML 2.0 identity provider for use with Azure AD sign-in, the next step is to download and install the Azure Active Directory Module for Windows PowerShell. After installation, use these cmdlets to configure your Azure AD domains as federated domains.

The Azure Active Directory Module for Windows PowerShell is a download for managing your organization's data in Azure AD. This module installs a set of cmdlets in Windows PowerShell; Run these cmdlets to configure single sign-on access to Azure AD, and therefore to all cloud services you're subscribed to. For instructions on how to download and install the cmdlets, see/versiones-anteriores/azure/jj151815(v=azure.100)

Establish a trust relationship between your SAML identity provider and Azure AD

Before configuring federation in an Azure AD domain, a custom domain must be configured. You cannot federate the default domain provided by Microsoft. Microsoft's default domain ends in "onmicrosoft.com". Runs a series of cmdlets in the Windows PowerShell command-line interface to add domains or convert to single sign-on.

Each Azure Active Directory domain that you want to federate with your SAML 2.0 identity provider must be added as a single sign-on domain or converted from a standard domain to a single sign-on domain. Adding or converting a domain establishes a trust relationship between your SAML 2.0 identity provider and Azure AD.

The following procedure walks you through converting an existing standard domain to a federated domain using SAML 2.0 SP-Lite.

Set up a domain in your Azure AD directory for federation

1. Connect to your Azure AD directory as a tenant administrator:

Connect-MsolService

2. Configure the desired Microsoft 365 domain to use federation with SAML 2.0:

$dom = "contoso.com" $BrandName = "IDP SAML 2.0 de Amostra" $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 e q7 WLJibc SNyGXBa/SfT5wJgsm3TPKgSehGAOTirhcqHheZyvBObAScY7GOT+u9pVYp6raFrc7ez3c+ CGHeV/tNvy1hJNs12FYH4X+ZCNFIT9tprieR25NCdi5SWUbPZL0tVzJsHc1y92b2M2FxqRDohxQgJvy JOpcg2mSBzZZIkvDg7gfPSUXHVS1MQs0RHSbwq/XdQocUUhl9/e/YWCbNNxlM84BxFsBUok1dH/gzBy Sx+Fc8zYi7cOq9yaBT3RLT6cGmFGVYZJW4FyhPZOCLVNsLlnPQcX3dDg9A==" $uri = "http://WS2012R2-0.contoso.com/adfs/services/trust" $ Protocolo = "SAMLP".

3. You can get the base64-encoded signing certificate chain from your IDP metadata file. An example of this location has been provided, but it may vary slightly depending on your implementation.

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

For more information on Set-MsolDomainAuthentication, see:/versiones-anteriores/azure/dn194112(v=azure.100).

Once the federation is configured, you can switch back to non-federated (or managed). However, this change takes up to two hours and requires assigning new random cloud-based login passwords for each user. In some scenarios, it may be necessary to re-manage to reset an error in your configuration. For more information on domain conversion, see:/versiones-anteriores/azure/dn194122(v=azure.100).

Provision user principals for Azure AD/Microsoft 365

Before you can authenticate your users to Microsoft 365, you must provision Azure AD with user principals that match the claim in the SAML 2.0 assertion. If these user principals are not known to Azure AD in advance, they cannot be used for federated login. Azure AD Connect or Windows PowerShell can be used to provision user principals.

Azure AD Connect can be used to provision entities for your domains in your local Azure AD directory. For more information, seeIntegrate your on-premises directories with Azure Active Directory.

Windows PowerShell can also be used to automate adding new users to Azure AD and syncing local directory changes. To use the Windows PowerShell cmdlets, you must use theMódulo Azure Active Directory.

This procedure shows how to add a single user to Azure AD.

1. As a tenant administrator, connect to your Azure AD directory: Connect-MsolService.

2. Create a new main user:

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

For more information on checking New-MsolUser, see/versiones-anteriores/azure/dn194096(v=azure.100)

Verify single sign-on with your SAML 2.0 IDP

As an administrator, before reviewing and managing single sign-on (also called federated identity), review the information and follow the steps in the following articles to enable single sign-on with your SAML 2.0 SP-based identity provider configuration. -Lite:

1. You have read the Azure AD SAML 2.0 registration requirements
2. You have configured your SAML 2.0 identity provider
3. Install Windows PowerShell for single sign-on with the SAML 2.0 identity provider
4. Configure a trust relationship between the SAML 2.0 identity provider and Azure AD
5. Deploy a known test user principal to Azure Active Directory (Microsoft 365) via Windows PowerShell or Azure AD Connect.
6. Configure directory synchronization withAzure AD connection.

After you configure single sign-on with your SAML 2.0 SP-Lite-based identity provider, verify that it works correctly.

Use the tool to verify that single sign-on is set up correctly

To verify that single sign-on is set up correctly, you can perform the following procedure to confirm that you can sign in to the cloud service with your corporate credentials.

Microsoft has provided a tool that you can use to test your SAML 2.0-based identity provider. Before running the test tool, you must have configured an Azure AD tenant to federate with your identity provider.

1. download theconnectivity analyzer.

2. Click Install Now to begin downloading and installing the tool.

3. Select "I can't federate with Office 365, Azure, or other services that use Azure Active Directory."

4. After the tool has been downloaded and run, the Connection Diagnostics window will appear. The tool guides you through testing your federation connection.

5. Connectivity Analyzer will open your SAML 2.0 IDP for you to log in, enter the credentials of the main user you are testing:

   

6. In the federation test input window, you must enter an account name and password for the Azure AD tenant that is configured to federate with your SAML 2.0 identity provider. The tool attempts to log in with these credentials, and the output provides detailed results of the tests performed during the login attempt.

   

7. This window shows a failed test result. Clicking Review Detailed Results will display information about the results of each test performed. You can also save the results to disk for sharing.

Manually verify that single sign-on is set up correctly

Manual verification provides additional steps to ensure that your SAML 2.0 identity provider works correctly in many scenarios. Follow these steps to verify that single sign-on is set up correctly:

1. On a domain-joined computer, sign in to your cloud service with the same login name you use for your corporate credentials.
2. Click on the password field. When single sign-on is configured, the password field will be grayed out and you will see the following message: "You must now sign in to <your company>".
3. Click the Register for <your company> link. If you can log in, single sign-on has been configured.

Next steps

• Manage and customize Active Directory federation services with Azure AD Connect
• Azure AD federation compatibility list
• Custom installation of Azure AD Connect