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

  • Article

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.


For a list of third-party Idps that have been tested for use with Azure AD, seeAzure AD federation compatibility list

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.


Only a limited set of clients are available in this login scenario with SAML 2.0 identity providers, including:

  • Web-based clients like Outlook Web Access and SharePoint Online
  • Rich email clients that use basic authentication and an Exchange-compatible access method, such as IMAP, POP, Active Sync, MAPI, etc. (The Enhanced Client Protocol endpoint must be implemented), which includes:
    • Microsoft Outlook 2010/Outlook 2013/Outlook 2016, Apple iPhone (various iOS versions)
    • Multiple Google Android devices
    • Windows Phone 7, Windows Phone 7.8 y Windows Phone 8.0
    • Windows 8 Mail Client and Windows 8.1 Mail Client
    • Windows 10 email client

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: customers in China using the China-specific instance of Microsoft 365, the following federation endpoint should be used:

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.

(Video) How to Enable Azure AD Single Sign-On in your Application using SAML

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:


To improve security, the SHA-1 algorithm is deprecated. Be sure to use a more secure algorithm like SHA-256. More informationIt can be found.

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.

name idThe value of this claim must be the same as the ImmutableID of the Azure AD user. It can be up to 64 alphanumeric characters. All non-HTML-compliant characters must be encoded, for example, a "+" sign will appear as ".2B".
IDPE mailThe User Principal Name (UPN) is specified in the SAML response as an element named IDPEmail. The UserPrincipalName (UPN) of the user in Azure AD/Microsoft 365. The UPN is in email address format. UPN value in Windows Microsoft 365 (Azure Active Directory).
editorMust be a URI for the identity provider. Do not reuse the sender of the sample messages. If you have multiple top-level domains in your Azure AD tenants, the issuer must match the specified URI settings configured per domain.


Azure AD currently supports the following NameID URI format for SAML 2.0: urn:oasis:names:tc:SAML:2.0:nameid-format:persistent.

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.


The following is an example of a response message sent from the sample SAML 2.0 compliant identity provider to Azure AD/Microsoft 365.   < 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">     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 to

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


(Video) SAML & Azure AD | Demo with Drop Box | Azure AD Gallery Application | Setup SAML authentication

Azure AD doesn't read the identity provider metadata.

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.


Verify that the SAML 2.0 identity provider's server clock is synchronized with an accurate time source. An inaccurate time can cause federated logins to fail.

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 "". 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.


Your domain may experience an outage affecting users for up to 2 hours after performing this step.

Configuring a domain in your Azure AD Directory for federation

  1. Connect to your Azure AD Directory as a tenant administrator:
  1. Configure the desired Microsoft 365 domain to use federation with SAML 2.0:
$dom = "" $BrandName = "Ejemplo SAML 2.0 IDP" $LogOnUrl = "" $LogOffUrl = " /passivelogoff "$ ecpurl =" "$ 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 =" AME $ DOM `-FederationBrandName $ BrandName` - Autenticación federada ` -PassiveLogOnUri $LogOnUrl On `UriActiveLogOnUrl ecpUrl ` -SigningCertificate $MySigningCert ` -IssuerUri $MyURI ` -LogOffUri $LogOffUrl ` -Preferred AuthenticationProtocol $Protocol
  1. 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).


(Video) Azure Active Directory Single Sign-On Configuration Demo

you should use$ecpUrl = ""only if you configure an ECP extension for your identity provider. Exchange Online clients, except Outlook Web Application (OWA), rely on a POST-based active endpoint. If SAML 2.0 STS implements a live endpoint similar to Shibboleth's ECP implementation of a live endpoint, it is possible for these rich clients to interact with the Exchange Online service.

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 ` -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)


The "UserPrincipalName" value must match the value you want to send for "IDPEmail" in your SAML 2.0 assertion, and the "ImmutableID" value must match the value you send in your "NameID" assertion.

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.


(Video) Using AzureAD as Identity Provider for Google Workspace

If you converted a domain instead of adding one, it can take up to 24 hours to set up single sign-on. Before confirming single sign-on, you must complete Active Directory synchronization setup, sync your folders, and enable your sync users.

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.


Connectivity Analyzer requires Internet Explorer 10 or later.

  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:

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

  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.

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

  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.


Connection Analyzer also tests Active Federation using WS* and ECP/PAOS based protocols. If you don't use them, you can ignore the following errors: Test the active login flow using the active federation endpoint of your identity provider.

(Video) How to configure SAML single sign-on for your help center with Microsoft Azure AD | Zoho Desk

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


Azure AD Connect: Use a SAML 2.0 identity provider for single sign-on - Azure - Microsoft? ›

SAML 2.0 (Security Assertion Markup Language) is an open standard created to provide cross-domain single sign-on (SSO). In other words, it allows a user to authenticate in a system and gain access to another system by providing proof of their authentication.

How do I enable single sign-on in Azure AD Connect? ›

To verify that you have enabled Seamless SSO correctly:
  1. Sign in to the Azure portal with the Hybrid Identity Administrator account credentials for your tenant.
  2. In the left menu, select Azure Active Directory.
  3. Select Azure AD Connect.
  4. Verify that Seamless single sign-on is set to Enabled.
May 4, 2023

Is SAML 2.0 based on single sign-on? ›

SAML 2.0 (Security Assertion Markup Language) is an open standard created to provide cross-domain single sign-on (SSO). In other words, it allows a user to authenticate in a system and gain access to another system by providing proof of their authentication.

How do I setup SAML 2.0 in Azure AD? ›

To configure Azure AD as the SAML 2.0 provider
  1. Select Add provider for your website.
  2. For Login provider, select Other.
  3. For Protocol, select SAML 2.0.
  4. Enter a provider name.
  5. Select Next.
  6. Select Confirm.
  7. Select Close.
Mar 30, 2023

Does Azure AD SSO use SAML? ›

Azure AD: Enterprise cloud IdP that provides SSO and Multi-factor authentication for SAML apps. It synchronizes, maintains, and manages identity information for users while providing authentication services to relying applications.


1. How to add Microsoft Azure AD as a SAML Identity Provider in AWS Cognito?
(Security in Action 101)
2. 45. How to configure Azure Active Directory Seamless Single Sign On
(MSFT WebCast)
3. SAML Azure SSO
(Creative Cloud IT Tools)
4. Setting up Azure SSO (SAML 2.0) in Clockify
5. Configuring an Enterprise Application for Single Sign-on
(Microsoft Security)
6. Authentication fundamentals: Web single sign-on | Azure Active Directory
(Microsoft Azure)


Top Articles
Latest Posts
Article information

Author: Kareem Mueller DO

Last Updated: 02/08/2023

Views: 5750

Rating: 4.6 / 5 (46 voted)

Reviews: 93% of readers found this page helpful

Author information

Name: Kareem Mueller DO

Birthday: 1997-01-04

Address: Apt. 156 12935 Runolfsdottir Mission, Greenfort, MN 74384-6749

Phone: +16704982844747

Job: Corporate Administration Planner

Hobby: Mountain biking, Jewelry making, Stone skipping, Lacemaking, Knife making, Scrapbooking, Letterboxing

Introduction: My name is Kareem Mueller DO, I am a vivacious, super, thoughtful, excited, handsome, beautiful, combative person who loves writing and wants to share my knowledge and understanding with you.