Azure AD Connect: Use a SAML 2.0 identity provider for single sign-on - Azure - Microsoft (2023)

This document provides information on how to use a SAML 2.0 compliant SP-Lite profile-based identity provider as your preferred identity provider/Security Token Service (STS). This scenario is useful when you already have a local 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 resources protected by Azure AD. The SAML 2.0 SP-Lite profile is based on the widely used Security Assertion Markup Language (SAML) federated identity standard to provide a login framework and attribute exchange.

Microsoft supports this sign-in experience as an integration of a Microsoft cloud service such as Microsoft 365 with its correctly configured SAML 2.0 profile-based IdP. SAML 2.0 identity providers are third-party products, and therefore Microsoft does not provide support for implementing, configuring, and troubleshooting best practices related to them. Once configured correctly, the integration with the SAML 2.0 identity provider can be tested for proper configuration using the Microsoft Connectivity Analyzer tool, described in more detail below. For more information on their SAML 2.0 SP-Lite profile-based identity provider, ask 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 with its SAML 2.0 identity provider configured for single sign-on.

Azure AD SAML 2.0 protocol requirements

This document details the protocol and message format requirements that your SAML 2.0 identity provider must implement to connect to 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.

We recommend ensuring that the output messages from the SAML 2.0 identity provider are as similar as possible to the provided sample traces. Also, use specific attribute values ​​from Azure AD metadata whenever possible. Once you are satisfied with your outgoing messages, you can test 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 federation endpoint should be used:https://nexus.partner.microsoftonline-p.cn/federationmetadata/saml20/federationmetadata.xml.

Requirements for the SAML protocol

This section describes how request and response message pairs are combined to help you 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. Using sample SAML request and response messages along with automated and manual tests, you can work toward interoperability with Azure AD.

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 claim node itself must be signed
2. The RSA-sha1 algorithm should be used as the DigestMethod. Other digital signature algorithms are not supported.
3. You can also sign the XML document.
4. The transformation algorithm must match the values ​​in the following example:
5. SignatureMethod The algorithm should match the following example:

compatible links

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

1. HTTPS is the required transport.
2. Azure AD will require HTTP POST to send the token during login.
3. Azure AD will use HTTP POST for the authentication request to the identity provider and REDIRECT for the logout message to the identity provider.

required attributes

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

Example SAML Request and Response Messages

A pair of request and response messages are displayed for the exchange of login messages. The following is an example of a request message sent from Azure AD to a sample SAML 2.0 identity provider. Example The 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.

 urn:federation:MicrosoftOnline="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"/>

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

 http://WS2012R2-0.contoso.com/adfs/services/trust     http://WS2012R2-0.contoso.com/adfs/services/trust   < ds:URI de referencia="#_7e3c1bcd-f180-4f78-83e1-7680920793aa">     CBn/5YqbheaJP425c0pHva9PhNY=        MIIC7jCCAdagAwIBAgIQRrjsbFPaXIlOG3GTv50fkjANBgkqhkiG9w0BAQsFADAzMTEwLwYDVQQDEyhBREZTIFNpZ25pbmcgLSBXUzIwMTJSMi0wLnN3aW5mb3JtZXIuY29tMB4XDTE0MDEyMDE 1 MTY0MFoX DTE1MDEyMDE1MTY0MFowMzExMC8GA1UEAxMoQURGUyBTaWduaW5nIC0gV1MyMDEyUjItMC5zd2luZm9ybWVyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKe+rLVmXy1QwCwZw qg bbp1/+3Z Wxd9T/jV0hpLIIWr+LCOHqq8n8beJvlivgLmDJo8f+EITnAxWcsJUvVai/35AhHCUq9tc9sqMp5PWtabAEMb2AU72/QlX/72D2/NbGQq1BWYbqUpgpCZ2nSgvWDlHlCiU o/ /UGsvfox0 1kjTFlmqQInsJVfRxF5AcCAweEAATANBgkqhkiG9w0BAQsFAAOCAQEAi8c6C4zaTEc7aQiUgvnGQgCbMZbhUXXLGRpjvFLKaQzkwa9eq7WLJibcSNyGXBa/Sft5wJgsm3TPKgSehGAOTirhcq H heZyvBObAS cY7GOT+u9pVYp6raFrc7ez3c+CGHeV/tNvy1hJNs12FYH4X+ZCNFIT9tprieR25NCdi5SWUbPZL0tVzJsHc1y92b2M2FxqRDohxQgJvyJOpcg2mSBzZZIkvDg7gfPSUXHVS1MQs0 RHSbwq/XdQoc UUhl9/e/YWCbNNxlM84BxFsBUok1dH /gzBySx +Fc8zYi7cOq9yaBT3RLT6cGmFGVYZJW4FyhPZOCLVNsLlnPQcX3dDg9A==  ABCDEG1234567890      urn:federation:MicrosoftOnline    IDPE Mail">administrador@contoso.com     urn : oasis : names : tc : SAML : 2.0 : ac : classes : PasswordProtectedTransport   

Set up your SAML 2.0 compliant identity provider

This section provides guidance on how to configure your SAML 2.0 identity provider to connect 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 will depend on your specific identity provider and you should refer to its documentation. Typically, you'll set the relying party ID to the same as the entity ID from the Azure AD metadata.

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

After configuring 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. Once installed, you'll 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 for Windows PowerShell; You run these cmdlets to configure single sign-on access to Azure AD and, in turn, to all cloud services you subscribe 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 you can configure federation to an Azure AD domain, you must have a custom domain configured. You cannot federate the default domain provided by Microsoft. Microsoft's default domain ends in "onmicrosoft.com". You'll run a series of cmdlets in the Windows PowerShell command-line interface to add or convert domains to single sign-on.

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

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

Configuring 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 = "Ejemplo 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 =" miic7jcadagawibagiqrrjsbfpaxilog3gtv50fkjanbgkQhkig9 wydvqqdeyh breztifnpz25pbmcg lsbxuziwmtjsmi0wlnnn3aw5mb3jtzxiuy29tmb4xdte0mDeyDe1MTy0mfoxdt e1mdeyMDe1mty0mfowmzexmc8ga1UeaxmoqUruGuy5BtuBeUlu5BtuTHAWLuEwiWaWaWaWaWaWiWaWaWaWiLu5 Gv1Mymdeyujit mc 5zd2luzM9YB wvylmnvbtccasiwdqyjKoziHvcnaqebbqadggepAdccaqocggebake+rlvmxy1qwcwzwqgbbp1/kupq vcjkUKlitvdbSfyqbdtjp7wqgbbp1/kupq vcjkUKlitvdbSfyqbdtjp7wlvmlvmwhthbiH bliThbi7 OE362GF2WMJFF1B0HCRSGLIN7DARXPQ4QI6OA57 SW1YFMJ3SQYUTP0EZV3S4+ZBDVOB6AMSZIDIWXALP9ZFYWG2BLSGNVLDB0+XKEDZWDBCLCVG+ 3Z WXD9 T/JV0HPIIWR+LCOHQQ8N8BEJVLIVGLMDJO8F+EITNAXWCSJUVVAI/35AHHCUQ9TC9SQMP5PWTABAEM B 2AU72/QLX/72D2/NBGQQ1BWYBQUPGPCZ2NSGVLVL FOX01KJTFLMQQINSJVFRXF5ACC AWEAATANBGKQHKIG9W0 BAQSFAAOCAQEAI8C6C4ZATEC7AQIUGVNGQGCBMZBHUXXLGRPJVFLKAQZKWA9 EQ7WLJIBCSNYGXBA /SFT5WJGSM3TPKGL CQHHEZYVBOBASCY7GOT+U9PVYP6RAFRC7EZ3C+CGHEV/TNVY1HJNS12FYH4X+ZCNFIT9TPRIER25NCDI5 SWUBPZL0TVZJSHC1Y92B2M2FXQRDOHXQGJVY JOPCG2MSBZZZInK MQS0RHSBW Q/XDQOCUUHL9/E/YWCBNNXLM84BXFSBUOK1DH/ Gzby sx+fc8zyi7coq9yabt3rlt6cgmfgvyzjw4fyhpzoclvnsllnpqcx3ddg9a = = "$ uri =" http://ws2012r2-0.contoso.com/adfs/services/trus AME $ DOM `-FederationBrandName $ BrandName` - Autenticación federada ` -PassiveLogOnUri $LogOnUrl On `UriActiveLogOnUrl ecpUrl ` -SigningCertificate $MySigningCert ` -IssuerUri $MyURI ` -LogOffUri $LogOffUrl ` -Preferred AuthenticationProtocol $Protocol

3. You can retrieve the base64-encoded string of the signing certificate from your IDP metadata file. An example of this location is provided, but it may differ slightly depending on your implementation.

    MIIC5jCCAc6gAwIBAgIQLnaxUPzay6ZJsC8HVv/QfTANBgkqhkiG9w0BAQsFADAvMS0wKwYDVQDEyRBREZTIFNpZ25pbmcgLSBmcy50ZWNobGFiY2VudHJhbC5vcmcwHhcNMTMxMTA0MTgxMzMyWhcN MTQx MTA0MTgxMzMyWjAvMS0wKwYDVQQDEyRBREZTIFNpZ25pbmcgLSBmcy50ZWNobGFiY2VudHJhbC5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwMdVLTr5YTSRp+ccbSpuufeXMfABD 9mVCi 2wtkRwC30TIyPdORz642MkurdxdPCWjwgJ0HW6TvXwco9afH3OC5V//wEGDoNcI8PV4enCzTYFe/h//w51uqyv48Fbb3lexs+aVl8155OAj2sO9IX64OJWKey82GQWK3g7LfhWWpp17 j5bK pSd9DBH5pvrV+Q1ESU3mx71TEOvikHGCZYitEPywNeVMLRKrevdWI3FAhFjcCSO6nWDiMqCqiTDYOURXIcHVYTSof1YotkJ4tG6mP5Kpjzd4VQvnR7Pjb47nhIYG6iZ3mR1F85Ns9+h BWukQWNN2h cD/ugdPXhpdMVpBAgMBAAEwDQYJKoZIhvcNAQELBQADggEBAK7h7jF7wPzhZ1dPl4e+XMAr8I7TNbhgEU3+oxKyW/IioQbvZVw1mYVCbGq9Rsw4KE06eSMybqHln3w5EeBbLS0 MEkApqHY+p68 iRpguqa+W7UHKXXQVgPMCpqxMFKonX6VlSQOR64FgpBme2uG+LJ8reTgypEKspQIN0WvtPWmiq4zAwBp08hAacgv868c0MM4WbOYU0rzMIR6Q+ceGVRImlCwZ5b7XKp4mJ Z9hlaRjeuyVrDuz BkzROSurX1OXoci08yJvhbtiBJLf3uPOJHrhjKRwIt2TnzS9ElgFZlJiDIA26Athe73n43CT0af2IG6yC7e6sK4L3NEXJrwwUZk=   

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

Once federation is set up, you can switch back to "unfederated" (or "managed"), but this change takes up to two hours to complete and requires assigning new random cloud login passwords to each user. In some scenarios, it may be necessary to go back to "managed" to reset a bug in your configuration. For more information on domain conversion, see:/versiones-anteriores/azure/dn194122(v=azure.100).

Provide user policies for Azure AD/Microsoft 365

Before you can authenticate your users to Microsoft 365, you must provide Azure AD with user policies that match the claim in the SAML 2.0 requirement. If Azure AD doesn't know about these user policies in advance, they can't be used for federated sign-in. Azure AD Connect or Windows PowerShell can be used to provision user policies.

Azure AD Connect can be used to provision entities for your domains in your on-premises Azure AD Directory. For more detailed 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 to synchronize local directory changes. To use the Windows PowerShell cmdlets, you must download theAzure Active Directory Modulator.

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

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

2. Create a new user policy:

   New-MsolUser ` -UserPrincipalName elwoodf1@contoso.com ` -ImmutableId ABCDEFG1234567890 ` -DisplayName "Elwood Folk" ` -FirstName Elwood ` -Efternavn Folk ` -AlternateEmailAddresses "Elwood.Folk"@contoso.comLocation

For more information about the "New-MsolUser" payment,/versiones-anteriores/azure/dn194096(v=azure.100)

Verify single sign-on with your SAML 2.0 IDP

As an administrator, before you authenticate and manage single sign-on (also known as identity federation), review the information and follow the steps in the following articles to configure single sign-on with your SAML 2.0 SP-based identity provider- Lite:

1. You have reviewed the Azure AD SAML 2.0 protocol 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. Create a trust relationship between the SAML 2.0 identity provider and Azure AD
5. You provided a known test user principal for Azure Active Directory (Microsoft 365) via Windows PowerShell or Azure AD Connect.
6. Configure library synchronization usingAzure AD connection.

After you configure single sign-on with your SAML 2.0 SP-Lite-based identity provider, you need to 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 configured correctly, you can perform the following procedure to verify that you can sign in to the cloud service with your company 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 set up an Azure AD tenant to connect to your identity provider.

1. DescargarConnectivity Analyzer.

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

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

4. Once the tool has been downloaded and run, you will see the Connectivity Diagnostics window. The tool will guide you through testing your federation connection.

5. Connectivity Analyzer opens your SAML 2.0 IDP so that you can log in, enter the credentials of the primary user you are testing:

   

6. In the test federation login window, enter an account name and password for the Azure AD tenant configured to associate with your SAML 2.0 identity provider. The tool will attempt to log in using these credentials and detailed results of the tests performed during the login attempt will be output.

   

7. This window shows a failed test result. Clicking View 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 you can take to ensure that your SAML 2.0 identity provider works correctly in many scenarios. To verify that single sign-on is configured correctly, complete the following steps:

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 inside the password field. If 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."
3. Click the Sign In link. If you can log in, single sign-on has been configured.

Next step

• Managing and customizing Active Directory federation services with Azure AD Connect
• Azure AD federation compatibility list
• Custom installation of Azure AD Connect