- Article
This document contains information on using a SAML 2.0 compliant SP-Lite profile-based Identity Provider as the preferred Security Token Service (STS) / identity provider. This scenario is useful when you already have a user directory and password store on-premises that can be accessed using SAML 2.0. This existing user directory can be used for sign-on to Microsoft 365 and other Azure AD-secured 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 sign-on and attribute exchange framework.
Note
For a list of 3rd party Idps that have been tested for use with Azure AD see the Azure AD federation compatibility list
Microsoft supports this sign-on experience as the integration of a Microsoft cloud service, such as Microsoft 365, with your properly configured SAML 2.0 profile-based IdP. SAML 2.0 identity providers are third-party products and therefore Microsoft does not provide support for the deployment, configuration, troubleshooting best practices regarding them. Once properly configured, the integration with the SAML 2.0 identity provider can be tested for proper configuration by using the Microsoft Connectivity Analyzer Tool, which is described in more detail below. For more information about your SAML 2.0 SP-Lite profile-based identity provider, ask the organization that supplied it.
Important
Only a limited set of clients are available in this sign-on scenario with SAML 2.0 identity providers, this includes:
- Web-based clients such as Outlook Web Access and SharePoint Online
- Email-rich clients that use basic authentication and a supported Exchange access method such as IMAP, POP, Active Sync, MAPI, etc. (the Enhanced Client Protocol end point is required to be deployed), including:
- Microsoft Outlook 2010/Outlook 2013/Outlook 2016, Apple iPhone (various iOS versions)
- Various Google Android Devices
- Windows Phone 7, Windows Phone 7.8, and Windows Phone 8.0
- Windows 8 Mail Client and Windows 8.1 Mail Client
- Windows 10 Mail Client
All other clients are not available in this sign-on scenario with your SAML 2.0 Identity Provider. For example, the Lync 2010 desktop client is not able to sign in to the service with your SAML 2.0 Identity Provider configured for single sign-on.
Azure AD SAML 2.0 protocol requirements
This document contains detailed requirements on the protocol and message formatting that your SAML 2.0 identity provider must implement to federate with Azure AD to enable sign-on 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 that you ensure your SAML 2.0 identity provider output messages be as similar to the provided sample traces as possible. Also, use specific attribute values from the supplied Azure AD metadata where possible. Once you are happy with your output messages, you can test with the Microsoft Connectivity Analyzer as described below.
The Azure AD metadata can be downloaded from this URL: https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml.For 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.
SAML protocol requirements
This section details how the request and response message pairs are put together in order to help you to format your messages correctly.
Azure AD can be configured to work with identity providers that use the SAML 2.0 SP Lite profile with some specific requirements as listed below. Using the sample SAML request and response messages along with automated and manual testing, you can work to achieve interoperability with Azure AD.
Signature block requirements
Within the SAML Response message, the Signature node contains information about the digital signature for the message itself. The signature block has the following requirements:
- The assertion node itself must be signed
- The RSA-sha1 algorithm must be used as the DigestMethod. Other digital signature algorithms are not accepted.
<ds:DigestMethod Algorithm="https://www.w3.org/2000/09/xmldsig#sha1"/> - You may also sign the XML document.
- The Transform Algorithm must match the values in the following sample:
<ds:Transform Algorithm="https://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <ds:Transform Algorithm="https://www.w3.org/2001/10/xml-exc-c14n#"/> - The SignatureMethod Algorithm must match the following sample:
<ds:SignatureMethod Algorithm="https://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
Note
In order to improve the security SHA-1 algorithm is deprecated. Ensure to use a more secure algorithm like SHA-256. More information can be found.
Supported bindings
Bindings are the transport-related communications parameters that are required. The following requirements apply to the bindings
- HTTPS is the required transport.
- Azure AD will require HTTP POST for token submission during sign-in.
- Azure AD will use HTTP POST for the authentication request to the identity provider and REDIRECT for the sign out message to the identity provider.
Required attributes
This table shows requirements for specific attributes in the SAML 2.0 message.
| Attribute | Description |
|---|---|
| NameID | The value of this assertion must be the same as the Azure AD user’s ImmutableID. It can be up to 64 alpha numeric characters. Any non-html safe characters must be encoded, for example a “+” character is shown as “.2B”. |
| IDPEmail | The User Principal Name (UPN) is listed in the SAML response as an element with the name IDPEmail The user’s UserPrincipalName (UPN) in Azure AD/Microsoft 365. The UPN is in email address format. UPN value in Windows Microsoft 365 (Azure Active Directory). |
| Issuer | Required to be a URI of the identity provider. Do not reuse the Issuer from the sample messages. If you have multiple top-level domains in your Azure AD tenants the Issuer must match the specified URI setting configured per domain. |
Important
Azure AD currently supports the following NameID Format URI for SAML 2.0:urn:oasis:names:tc:SAML:2.0:nameid-format:persistent.
Sample SAML request and response messages
A request and response message pair is shown for the sign-on message exchange.The following is a sample request message that is 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 SAML-P protocol. Interoperability testing has also been completed with other SAML 2.0 identity providers.
<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>The following is a sample response message that is sent from the sample SAML 2.0 compliant identity provider to Azure AD / 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/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>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>Configure your SAML 2.0 compliant identity provider
This section contains guidelines 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 needs to adhere to information about the Azure AD relying party. Azure AD publishes metadata at https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml.
It is recommended that you always import the latest Azure AD metadata when configuring your SAML 2.0 identity provider.
Note
Azure AD does not read metadata from the identity provider.
Add Azure AD as a relying party
You must enable communication between your SAML 2.0 identity provider and Azure AD. This configuration will be dependent on your specific identity provider and you should refer to documentation for it. You would typically set the relying party ID to the same as the entityID from the Azure AD metadata.
Note
Verify the clock on your SAML 2.0 identity provider server is synchronized to an accurate time source. An inaccurate clock time can cause federated logins to fail.
Install Windows PowerShell for sign-on with SAML 2.0 identity provider
After you have configured your SAML 2.0 identity provider for use with Azure AD sign-on, the next step is to download and install the Azure Active Directory Module for Windows PowerShell. Once installed, you will 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 organizations data in Azure AD. This module installs a set of cmdlets to Windows PowerShell; you run those cmdlets to set up single sign-on access to Azure AD and in turn to all of the cloud services you are subscribed to. For instructions about how to download and install the cmdlets, see /previous-versions/azure/jj151815(v=azure.100)
Set up a trust between your SAML identity provider and Azure AD
Before configuring federation on an Azure AD domain, it must have a custom domain configured. You cannot federate the default domain that is provided by Microsoft. The default domain from Microsoft ends with “onmicrosoft.com”.You will run a series of cmdlets in the Windows PowerShell command-line interface to add or convert domains for single sign-on.
Each Azure Active Directory domain that you want to federate using your SAML 2.0 identity provider must either be added as a single sign-on domain or converted to be a single sign-on domain from a standard domain. Adding or converting a domain sets up a trust 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.
Note
Your domain may experience an outage that impacts users up to 2 hours after you take this step.
Configuring a domain in your Azure AD Directory for federation
- Connect to your Azure AD Directory as a tenant administrator:
Connect-MsolService- Configure your desired Microsoft 365 domain to use federation with 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 $BrandName ` -Authentication Federated ` -PassiveLogOnUri $LogOnUrl ` -ActiveLogOnUri $ecpUrl ` -SigningCertificate $MySigningCert ` -IssuerUri $MyURI ` -LogOffUri $LogOffUrl ` -PreferredAuthenticationProtocol $Protocol- You can obtain the signing certificate base64 encoded string from your IDP metadata file. An example of this location has been provided but may differ slightly based 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+LJ8reTgypEKspQIN0WvtPWmiq4zAwBp08hAacgv868c0MM4WbOYU0rzMIR6Q+ceGVRImlCwZ5b7XKp4mJZ9hlaRjeuyVrDuzBkzROSurX1OXoci08yJvhbtiBJLf3uPOJHrhjKRwIt2TnzS9ElgFZlJiDIA26Athe73n43CT0af2IG6yC7e6sK4L3NEXJrwwUZk=</X509Certificate> </X509Data> </KeyInfo> </KeyDescriptor></IDPSSODescriptor>For more information about “Set-MsolDomainAuthentication”, see: /previous-versions/azure/dn194112(v=azure.100).
Note
You must use $ecpUrl = "https://WS2012R2-0.contoso.com/PAOS" only if you set up an ECP extension for your identity provider. Exchange Online clients, excluding Outlook Web Application (OWA), rely on a POST based active end point. If your SAML 2.0 STS implements an active end point similar to Shibboleth’s ECP implementation of an active end point it may be possible for these rich clients to interact with the Exchange Online service.
Once federation has been configured you can switch back to “non-federated” (or “managed”), however this change takes up to two hours to complete and it requires assigning new random passwords for cloud-based sign-in to each user. Switching back to “managed” may be required in some scenarios to reset an error in your settings. For more information on Domain conversion see: /previous-versions/azure/dn194122(v=azure.100).
Provision user principals to Azure AD / Microsoft 365
Before you can authenticate your users to Microsoft 365, you must provision Azure AD with user principals that correspond to the assertion in the SAML 2.0 claim. If these user principals are not known to Azure AD in advance, then they cannot be used for federated sign-in. Either Azure AD Connect or Windows PowerShell can be used to provision user principals.
Azure AD Connect can be used to provision principals to your domains in your Azure AD Directory from the on-premises Active Directory. For more detailed information, see Integrate 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 changes from the on-premises directory. To use the Windows PowerShell cmdlets, you must download the Azure Active Directory Modules.
This procedure shows how to add a single user to Azure AD.
Connect to your Azure AD Directory as a tenant administrator: Connect-MsolService.
Create a new user principal:
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 about “New-MsolUser” checkout, /previous-versions/azure/dn194096(v=azure.100)
Note
The “UserPrincipalName” value must match the value that you will send for “IDPEmail” in your SAML 2.0 claim and the “ImmutableID” value must match the value sent in your “NameID” assertion.
Verify single sign-on with your SAML 2.0 IDP
As the administrator, before you verify and manage single sign-on (also called identity federation), review the information and perform the steps in the following articles to set up single sign-on with your SAML 2.0 SP-Lite based identity provider:
- You have reviewed the Azure AD SAML 2.0 Protocol Requirements
- You have configured your SAML 2.0 identity provider
- Install Windows PowerShell for single sign-on with SAML 2.0 identity provider
- Set up a trust between SAML 2.0 identity provider and Azure AD
- Provisioned a known test user principal to Azure Active Directory (Microsoft 365) either through Windows PowerShell or Azure AD Connect.
- Configure directory synchronization using Azure AD Connect.
After setting up single sign-on with your SAML 2.0 SP-Lite based identity Provider, you should verify that it is working correctly.
Note
If you converted a domain, rather than adding one, it may take up to 24 hours to set up single sign-on.Before you verify single sign-on, you should finish setting up Active Directory synchronization, synchronize your directories, and activate your synced users.
Use the tool to verify that single sign-on has been set up correctly
To verify that single sign-on has been set up correctly, you can perform the following procedure to confirm that you are able to 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.
Note
The Connectivity Analyzer requires Internet Explorer 10 or later.
Download the Connectivity Analyzer.
Click Install Now to begin downloading and installing the tool.
Select “I can’t set up federation with Office 365, Azure, or other services that use Azure Active Directory”.
Once the tool is downloaded and running, you will see the Connectivity Diagnostics window. The tool will step you through testing your federation connection.
The Connectivity Analyzer will open your SAML 2.0 IDP for you to sign-in, enter the credentials for the user principal you are testing:
At the Federation test sign-in window, you should enter an account name and password for the Azure AD tenant that is configured to be federated with your SAML 2.0 identity provider. The tool will attempt to sign-in using those credentials and detailed results of tests performed during the sign-in attempt will be provided as output.
This window shows a failed result of testing. Clicking on Review detailed results will show information about the results for each test that was performed. You can also save the results to disk in order to share them.
Note
The Connectivity analyzer also tests Active Federation using the WS*-based and ECP/PAOS protocols. If you are not using these you can disregard the following error: Testing the Active sign-in flow using your identity provider’s Active federation endpoint.
Manually verify that single sign-on has been set up correctly
Manual verification provides additional steps that you can take to ensure that your SAML 2.0 identity Provider is working properly in many scenarios.To verify that single sign-on has been set up correctly, complete the following steps:
- On a domain-joined computer, sign-in to your cloud service using the same sign-in name that you use for your corporate credentials.
- Click inside the password box. If single sign-on is set up, the password box will be shaded, and you will see the following message: “You are now required to sign-in at <your company>.”
- Click the Sign-in at <your company> link. If you are able to sign-in, then single sign-on has been set up.
Next Steps
- Active Directory Federation Services management and customization with Azure AD Connect
- Azure AD federation compatibility list
- Azure AD Connect Custom Installation
FAQs
How do I setup SAML 2.0 in Azure AD? ›
- Select Add provider for your website.
- For Login provider, select Other.
- For Protocol, select SAML 2.0.
- Enter a provider name.
- Select Next.
- Select Confirm.
- Select Close.
- Sign in to the Azure portal with the Hybrid Identity Administrator account credentials for your tenant.
- In the left menu, select Azure Active Directory.
- Select Azure AD Connect.
- Verify that Seamless single sign-on is set to Enabled.
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.
Which authentication protocol provides the single sign-on SSO functionality between Azure AD and SAP cloud platform? ›Azure Active Directory easily enables SSO across cloud and on-premise applications with the use of SAML 2.0 authentication.
How does SAML 2.0 authentication work? ›SAML works by exchanging user information, such as logins, authentication state, identifiers, and other relevant attributes between the identity and service provider. As a result, it simplifies and secures the authentication process as the user only needs to log in once with a single set of authentication credentials.
How to set up SSO with SAML v2? ›- Select Add IdP.
- Enter a nickname for your IdP.
- Obtain the IdP metadata; then, copy it. ...
- In the IdP Metadata text box, paste the IdP Metadata.
- Copy the SSO URL; then, paste it in your IdP.
- Select Save. ...
- To enable the IdP for use with Smartsheet, select Activate.
Azure AD decrypts the Kerberos key, using a key which is shared with Azure AD when Azure AD Seamless SSO is initially configured. If the ticket is valid, Azure AD grants access and returns an authentication token to the browser. The user can now log into the business application without re-entering a password.
How do I create a self signed user account in Azure AD? ›- Sign in to the Azure portal as an Azure AD administrator.
- Under Azure services, select Azure Active Directory.
- In the left menu, select External Identities.
- Under Self-service sign up, select User flows.
- Select the self-service sign-up user flow from the list.
SAML is the standard through which SPs and IdPs communicate with each other to verify credentials. SSO is an authentication process intended to simplify access to multiple applications with a single set of credentials. SAML improves security by unburdening SPs from having to store login credentials.
How do I use Azure AD as an identity provider? ›- In your Azure AD B2C tenant, select User flows.
- Click the user flow that you want to add the Azure AD identity provider.
- Under Settings, select Identity providers.
- Under Custom identity providers, select Contoso Azure AD.
- Select Save.
What is the difference between SAML and OpenID Connect in Azure AD? ›
SAML authentication is commonly used with identity providers such as Active Directory Federation Services (AD FS) federated to Azure AD, so it's often used in enterprise applications. OpenID Connect is commonly used for apps that are purely in the cloud, such as mobile apps, websites, and web APIs.
What is the difference between Azure SSO and AD? ›With password-based SSO, users sign in to the application with a username and password the first time they access it. After the first sign-on, Azure AD provides the username and password to the application.
What is the difference between ad authentication and SSO? ›AD and SSO are very different; one is an on-prem directory service — the authoritative source of identities, the other a cloud-based, web app identity extension point solution that federates the identities from a core directory to web applications.
Which technologies enable SSO with Azure AD? ›This means any Microsoft customer using a subscription of a commercial online service such as Azure, Office 365, Dynamics and Power Platform can enable SSO for all their cloud apps, even with Azure AD Free.
What is SAML 2.0 identity provider? ›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.
Is SAML 2.0 still used? ›SAML 2.0 was introduced in 2005 and remains the current version of the standard. The previous version, 1.1, is now largely deprecated.
What are the two models for users to authenticate using SAML select two? ›...
Following are the supported authentication methods:
- Passwords (Default)
- Kerberos.
- One-Time Link.
- One-Time Token.
- The user goes to the Bitbucket page to login.
- User clicks on Sign in with Google.
- The browser redirects the user to the Google login page.
- Google shows the credentials page for users to enter credentials.
- The user enters the google credentials and clicks submit.
- In the Admin Console, go to SecurityIdentity Providers.
- Click Add Identity Provider, and then select Add SAML 2.0 IdP.
- Configure the General Settings. ...
- Configure Authentication Settings. ...
- Configure JIT Settings. ...
- Configure SAML Protocol Settings. ...
- Optional. ...
- Click Add Identity Provider.
A Service Provider (SP) is the entity providing the service, typically in the form of an application. An Identity Provider (IdP) is the entity providing the identities, including the ability to authenticate a user.
What is the benefit of single sign-on Azure AD? ›
Azure AD's SSO feature enables users to login to multiple applications via a single pane, which includes both SaaS and on-premises applications. The SSO feature makes it easier for administrators to add new users and services without needing to set up credentials or security groups for each application or service.
How to check if single sign-on is enabled in Active Directory? ›Check status of feature
Ensure that the Seamless SSO feature is still Enabled on your tenant. You can check the status by going to the Azure Active Directory > Azure AD Connect pane in the Azure portal. Click through to see all the AD forests that have been enabled for Seamless SSO.
Single sign-on (SSO) is a technology which combines several different application login screens into one. With SSO, a user only has to enter their login credentials (username, password, etc.) one time on a single page to access all of their SaaS applications.
Which Azure AD Connect authentication method should you select? ›For most organizations that just want to enable user sign-in to Microsoft 365, SaaS applications, and other Azure AD-based resources, we recommend the default password hash synchronization option.
How do I manage Azure AD Connect? ›- Double-click on the Azure AD Connect desktop shortcut to start the wizard.
- Click Configure.
- On the tasks screen, select the Customize synchronization options and click Next.
- Enter your Azure AD credentials.
- Click Next.
Azure AD supports many standardized protocols for authentication and authorization, such as SAML 2.0, OpenID Connect, OAuth 2.0, and WS-Federation. Azure AD also supports password vaulting and automated sign-in capabilities for apps that only support forms-based authentication.
Can each user account in Azure AD be assigned only one license? ›User accounts in Azure Active Directory can be assigned multiple licenses for different Azure or Microsoft 365 services.
How do I create a runas account in Azure? ›Sign-in to the Azure portal. Go to your Automation account and select Run As Accounts in the account settings section. On the Run As Accounts properties page, select either Run As Account or Classic Run As Account depending on which account you need to renew the certificate for.
What is identity provider in Azure? ›An identity provider creates, maintains, and manages identity information while providing authentication services to applications. When sharing your apps and resources with external users, Azure AD is the default identity provider for sharing.
What is the difference between Active Directory and SAML? ›While SAML is an identity provider, ADFS is a service provider. A SAML 2.0 Identity Provider (IdP) can take multiple forms, one of which is a self hosted Active Directory Federation Services (ADFS) server.
What is the advantage of using SAML? ›
Benefits of SAML Authentication
Improved User Experience — Users only need to sign in one time to access multiple service providers. This allows for a faster authentication process and less expectation of the user to remember multiple login credentials for every application.
SAML is primarily used to enable web browser single sign-on (SSO). The user experience objective for SSO is to allow a user to authenticate once and gain access to separately secured systems without resubmitting credentials.
Which three authentication methods can Azure AD users use? ›- Microsoft Authenticator.
- Authenticator Lite (in Outlook)
- Windows Hello for Business.
- FIDO2 security key.
- OATH hardware token (preview)
- OATH software token.
- SMS.
- Voice call.
Azure AD returns a JSON Web Token (JWT) access token. Your code sends the access token on a call to a service that supports Azure AD authentication.
Does Azure AD Connect require a license? ›What about licensing? No licensing is needed to install AAD Connect and get all your AD users and groups syncing with AAD. If you include other connectors there is still no licensing required. But if you want to write anything back to AD from Azure AD that requires AAD Premium licensing.
What is the difference between SAML 2.0 and OpenID? ›OpenID lacks user authorization data (such as permissions) and focuses primarily on identity assertion. SAML is an identity data exchange and is very feature-rich. Authentication is decentralized with OpenID. SAML uses assertions versus the OpenID and OAuth architecture of ID tokens.
Which is better SAML or OpenID Connect? ›OIDC is lightweight and more performance-friendly than SAML. For large enterprises that require a higher level of security, SAML might be the better choice. SAML allows multi-factor authentication. It is a more mature standard with a proven track record and more feature-rich than OIDC.
What is the difference between identity provider and authorization server? ›In summary, an identity provider is the software component that authenticates and issues a token representing a user or other entity, while an authorization server is the server software component that validates and provides tokens that represent a user or other entity.
What are the different Azure AD identity types? ›- System-assigned. Some Azure resources, such as virtual machines allow you to enable a managed identity directly on the resource. When you enable a system-assigned managed identity: ...
- User-assigned. You may also create a managed identity as a standalone Azure resource.
- Active Directory (AD) Microsoft Active Directory (most often referred to as a domain controller) is the de facto directory system used today in most organizations. ...
- Azure Active Directory (AAD) ...
- Hybrid Azure AD (Hybrid AAD) ...
- Azure Active Directory Domain Services (AAD DS)
What is difference between LDAP and SAML? ›
LDAP: What's the Difference? The difference between SAML and LDAP is that SAML is designed for cloud-based connections using only an IdP and SP to communicate user data. LDAP, however, is typically used for accessing on-premises resources by installing a client on the user's device to connect with a directory service.
What is the difference between Windows authentication and AD authentication? ›Windows authentication enables the separation of duties. The Active Directory (AD) team manages the AD users. Whereas, the DBA adds AD users in the SQL instances and provides appropriate permissions. Active Directory helps to create Windows groups.
What is the difference between LDAP authentication and Active Directory authentication? ›Nevertheless, they are not the same thing. Whereas Active Directory is a directory server that stores user information such as usernames, phone numbers, and email addresses, LDAP is a protocol that allows reading and modifying that information. You can also use LDAP to authenticate users using the Bind operation.
How to setup SAML with Azure Active Directory? ›- Log in to Azure AD as a Global Admin in the Microsoft Azure portal.
- Go to the Azure Active Directory tab > Enterprise application.
- Click New application.
- Click Create your own application.
- Enter a name and then click Integrate any other application you don't find in the gallery (Non-gallery).
Sign in to the Azure portal with the Hybrid Identity Administrator account credentials for your tenant. In the left menu, select Azure Active Directory. Select Azure AD Connect. Verify that Seamless single sign-on is set to Enabled.
Does Azure AD free support SSO? ›Azure AD Free offers basic SSO functionality that's essential for organizations using AD to access Microsoft's portfolio of cloud services.
How to configure SAML in Active Directory? ›- Select Add Claim Description.
- Specify the claim: Display name: Persistent Identifier. Claim identifier: urn:oasis:names:tc:SAML:2.0:nameid-format:persistent. ...
- Select OK.
- Step 1: Download and extract package. ● ...
- Step 2: Add the module in your application. ● ...
- Step 3: Configure your Identity Provider. ...
- Step 4: Configure your Service Provider. ...
- Step 5: Test Configuration. ...
- Step 6:Attribute Mapping. ...
- Step 7: Integration Code. ...
- Step 8: Add following link in your application for Single Sign-On (SSO)
For the Azure AD SAML Toolkit application, the address is https://samltoolkit.azurewebsites.net . Select Register in the upper right corner of the page. For Email, enter the email address of the user that will access the application. Ensure that the user account is already assigned to the application.
How do I set up Azure AD authentication? ›- From the portal menu, select Azure Active Directory.
- From the left navigation, select App registrations > New registration.
- In the Register an application page, enter a Name for your app registration.
- Select Register.
How to configure Azure AD as identity provider? ›
- In your Azure AD B2C tenant, select User flows.
- Click the user flow that you want to add the Azure AD identity provider.
- Under Settings, select Identity providers.
- Under Custom identity providers, select Contoso Azure AD.
- Select Save.
- Select. ...
- Select Azure Active Directory, and then select Connect directory.
- Select a directory from the dropdown menu, and then select Connect. ...
- Select Sign out. ...
- Confirm that the process is complete.
- Step 1: Exchange of metadata information. ...
- Step 2: Identity provider configuration. ...
- Step 3: Enable SAML in Configuration. ...
- Step 4: Test the single sign-on connection. ...
- Step 5: Go live.
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.
What is SAML 2.0 name ID format? ›SAML 2.0 name identifier formats control how the users at identity providers are mapped to users at service providers during single sign-on. Use the email address name identifier format if you want a user to log in at the service provider as the same user that they use to log in at the identity provider.
What is the SAML format for Azure AD? ›Azure AD currently supports the following NameID Format URI for SAML 2.0:urn:oasis:names:tc:SAML:2.0:nameid-format:persistent.
What is the difference between SAML and LDAP in Azure AD? ›The difference between SAML and LDAP is that SAML is designed for cloud-based connections using only an IdP and SP to communicate user data. LDAP, however, is typically used for accessing on-premises resources by installing a client on the user's device to connect with a directory service.
How do I change authentication methods in Azure AD? ›Browse to Azure Active Directory > Users > All users. Choose the user for whom you wish to add an authentication method and select Authentication methods. At the top of the window, select + Add authentication method. Select a method (phone number or email).
What authentication method does Azure AD use? ›In Azure AD, a password is often one of the primary authentication methods. You can't disable the password authentication method. If you use a password as the primary authentication factor, increase the security of sign-in events using Azure AD Multi-Factor Authentication.