Use a SAML Identity Provider to provide sign-on validation ...



Office 365 SAML 2.0 Federation Implementer’s GuideMicrosoft CorporationPublished: March 6, 2014, Rev 1.0Applies To: Office 365, Windows Azure, and other Windows Azure Active Directory secured resourcesUse a SAML Identity Provider to provide sign-on validation for Office 365 or other Azure AD secured resourcesThe topics in this section contain instructions for solution implementers of a Microsoft cloud service who want to provide their Azure Active Directory users with sign-on validation using a SAML 2.0 compliant SP-Lite profile based Identity Provider as their preferred Security Token Service (STS) / Identity Provider (IDP). This is useful where the solution implementer already has 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 Office 365 and other Azure Active Directory 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.Microsoft supports this sign-on experience as the integration of a Microsoft cloud service, such as Office 365, with your properly configured SAML 2.0 profile based Identity Provider which we will henceforth refer to as the SAML 2.0 Identity Provider and/or 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.19459-3476ImportantOnly a limited set of clients are available in this sign-on scenario with SAML 2.0 Identity Providers, as follows:Web-based clients such as Outlook Web Access and SharePoint OnlineEmail-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 / Microsoft Outlook 2013, Apple iPhone (various iOS versions)Various Google Android DevicesWindows Phone 7, Windows Phone 7.8, and Windows Phone 8.0Windows 8 Mail Client, and Windows 8.1 Mail ClientAll 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 login into the service with your SAML 2.0 Identity Provider configured for single sign-on.19459-3475ImportantAs a pre-requisite to starting the steps below, please review the benefits, user experiences, and requirements of single sign-on in Prepare for single sign-on.Windows Azure AD SAML 2.0 Protocol RequirementsThis topic contains detailed requirements on the protocol and message formatting that your SAML 2.0 Identity Provider must implement to federate with Windows Azure AD to enable sign-on to one or more Microsoft cloud services (such as Office 365). The SAML 2.0 relying party (SP-STS) for a Microsoft cloud service used in this scenario is Windows Azure AD.We recommend ensuring that 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: customers in China using the China-specific instance of Office 365, the following federation endpoint should be used: Protocol RequirementsThis 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 RequirementsWithin 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 signedThe RSA-sha1 algorithm must be used as the DigestMethod. Other digital signature algorithms are not accepted. <ds:DigestMethod Algorithm=""/> <ds:DigestMethod Algorithm=""/>You may also sign the XML document. The Transform Algorithm must match the values in the sample <ds:Transform Algorithm=""/> <ds:Transform Algorithm=""/> <ds:Transform Algorithm=""/> <ds:Transform Algorithm=""/>The SignatureMethod Algorithm must match the sample <ds:SignatureMethod Algorithm=""/> <ds:SignatureMethod Algorithm=""/>Supported BindingsBindings are the transport related communications parameters that are required. The following requirements apply to the bindingsHTTPS is the required transport.Azure AD will require HTTP POST for token submission during logonAzure AD will use HTTP POST for the authentication request to the Identity Provider and REDIRECT for the Logoff message to the Identity Provider.Required AttributesThis table shows requirements for specific attributes in the SAML 2.0 message.NameIDThe 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” IDPEmailThe User Principal Name (UPN) is listed in the SAML response as an element with the name IDPEmail This is the user’s UserPrincipalName (UPN) in Windows Azure AD/Office 365. The UPN is in email address format. UPN value in Windows Office 365 (Windows Azure Active Directory)IssuerThis is required to be a URI of the Identity Provider. You should 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.19459-3476NoteWindows Azure Active Directory currently supports the following NameID Format URI for SAML 2.0:urn:oasis:names:tc:SAML:2.0:nameid-format:persistentSample SAML Request and Response MessagesA request and response message pair is shown for the sign-on message exchange. This is a sample request message that is sent from Azure AD to a sample SAML 2.0 IDP. The sample SAML 2.0 IDP is ADFS configured to use SAML-P protocol. Interoperability testing has also been completed with other SAML 2.0 IDPs.<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><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>This is a sample response message that is sent from the sample SAML 2.0 compliant IDP to Azure AD / Office 365. <samlp:Response ID="_592c022f-e85e-4d23-b55b-9141c95cd2a5" Version="2.0" IssueInstant="2014-01-31T15:36:31.357Z" Destination="" 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">; <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>; <ds:Signature xmlns:ds=""> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="" /> <ds:SignatureMethod Algorithm="" /> <ds:Reference URI="#_7e3c1bcd-f180-4f78-83e1-7680920793aa"> <ds:Transforms> <ds:Transform Algorithm="" /> <ds:Transform Algorithm="" /> </ds:Transforms> <ds:DigestMethod Algorithm="" /> <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=""> <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="" /> </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@</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><samlp:Response ID="_592c022f-e85e-4d23-b55b-9141c95cd2a5" Version="2.0" IssueInstant="2014-01-31T15:36:31.357Z" Destination="" 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">; <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>; <ds:Signature xmlns:ds=""> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="" /> <ds:SignatureMethod Algorithm="" /> <ds:Reference URI="#_7e3c1bcd-f180-4f78-83e1-7680920793aa"> <ds:Transforms> <ds:Transform Algorithm="" /> <ds:Transform Algorithm="" /> </ds:Transforms> <ds:DigestMethod Algorithm="" /> <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=""> <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="" /> </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@</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 ProviderThis topic contains guidelines on how to configure your SAML 2.0 Identity Provider to federate with Windows Azure AD to enable single sign-on access to one or more Microsoft cloud services (such as Office 365) using the SAML 2.0 protocol. The SAML 2.0 relying party for a Microsoft cloud service used in this scenario is Windows Azure AD.Add Windows Azure AD metadataYour SAML 2.0 Identity Provider needs to adhere to information about the Windows Azure AD relying party. Windows Azure AD publishes metadata at: is recommended that you always import the latest Windows Azure AD metadata when configuring your SAML 2.0 Identity Provider. Note that Azure AD does not read metadata from the identity provider.Add Windows Azure AD as a relying partyYou have to 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 Windows Azure AD metadata.19459-3476NoteVerify 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 ProviderAfter 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 Windows Azure Active Directory Module for Windows PowerShell. Once installed, you will use these cmdlets to configure your Windows Azure AD domains as federated domains.Download and install the Windows PowerShell cmdletsThe Windows Azure Active Directory Module for Windows PowerShell is a download for managing your organizations data in Windows Azure AD. This module installs a set of cmdlets to Windows PowerShell; you run those cmdlets to set up single sign-on access to Windows 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 Set up a trust between your SAML Identity Provider and Windows Azure ADBefore 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 “”.Windows Azure AD domains configured and managed using the Windows Azure Active Directory Module for Windows PowerShell You will use this topic to run a series of cmdlets in the Windows PowerShell command-line interface to add or convert domains for single sign-on.Each Windows 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 Windows Azure AD.The following procedure walks you through how to convert an existing standard domain to a federated domain using SAML 2.0 SP-Lite. Note that your domain may experience an outage that impacts users up to 2 Hours after you take this step.Configuring a Domain in your Office 365 Tenant for FederationThis PowerShell script uses the custom domain configured of . You will need to replace that in the script with your own custom domain. Connect to your Office 365 tenant as a tenant administrator :Connect-MsolService Connect-MsolService Configure your desired Office 365 domain to use Federation with SAML 2.0$dom = ""$BrandName - "Sample SAML 2.0 IDP"$LogOnUrl = ""$LogOffUrl = ""$ecpUrl = ""$MyURI = "urn:uri:MySamlp2IDP"$MySigningCert = @"MIIC7jCCAdagAwIBAgIQRrjsbFPaXIlOG3GTv50fkjANBgkqhkiG9w0BAQsFADAzMTEwLwYDVQQDEyhBREZTIFNpZ25pbmcgLSBXUzIwMTJSMi0wLnN3aW5mb3JtZXIuY29tMB4XDTE0MDEyMDE1MTY0MFoXDTE1MDEyMDE1MTY0MFowMzExMC8GA1UEAxMoQURGUyBTaWduaW5nIC0gV1MyMDEyUjItMC5zd2luZm9ybWVyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKe+rLVmXy1QwCwZwqgbbp1/kupQVcjKuKLitVDbssFyqbDTjP7WRjlVMWAHBI3kgNT7oE362Gf2WMJFf1b0HcrsgLin7daRXpq4Qi6OA57sW1YFMj3sqyuTP0eZV3S4+ZbDVob6amsZIdIwxaLP9Zfywg2bLsGnVldB0+XKedZwDbCLCVg+3ZWxd9T/jV0hpLIIWr+LCOHqq8n8beJvlivgLmDJo8f+EITnAxWcsJUvVai/35AhHCUq9tc9sqMp5PWtabAEMb2AU72/QlX/72D2/NbGQq1BWYbqUpgpCZ2nSgvlWDHlCiUo//UGsvfox01kjTFlmqQInsJVfRxF5AcCAwEAATANBgkqhkiG9w0BAQsFAAOCAQEAi8c6C4zaTEc7aQiUgvnGQgCbMZbhUXXLGRpjvFLKaQzkwa9eq7WLJibcSNyGXBa/SfT5wJgsm3TPKgSehGAOTirhcqHheZyvBObAScY7GOT+u9pVYp6raFrc7ez3c+CGHeV/tNvy1hJNs12FYH4X+ZCNFIT9tprieR25NCdi5SWUbPZL0tVzJsHc1y92b2M2FxqRDohxQgJvyJOpcg2mSBzZZIkvDg7gfPSUXHVS1MQs0RHSbwq/XdQocUUhl9/e/YWCbNNxlM84BxFsBUok1dH/gzBySx+Fc8zYi7cOq9yaBT3RLT6cGmFGVYZJW4FyhPZOCLVNsLlnPQcX3dDg9A==""@$uri = ""$Protocol = "SAMLP"Set-MsolDomainAuthentication `-DomainName $dom -FederationBrandName $dom-Authentication Federated -PassiveLogOnUri $MyURI -ActiveLogOnUri $ecpUrl-SigningCertificate $MySigningCert -IssuerUri $uri -LogOffUri $url -PreferredAuthenticationProtocol $Protocol $dom = ""$BrandName - "Sample SAML 2.0 IDP"$LogOnUrl = ""$LogOffUrl = ""$ecpUrl = ""$MyURI = "urn:uri:MySamlp2IDP"$MySigningCert = @"MIIC7jCCAdagAwIBAgIQRrjsbFPaXIlOG3GTv50fkjANBgkqhkiG9w0BAQsFADAzMTEwLwYDVQQDEyhBREZTIFNpZ25pbmcgLSBXUzIwMTJSMi0wLnN3aW5mb3JtZXIuY29tMB4XDTE0MDEyMDE1MTY0MFoXDTE1MDEyMDE1MTY0MFowMzExMC8GA1UEAxMoQURGUyBTaWduaW5nIC0gV1MyMDEyUjItMC5zd2luZm9ybWVyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKe+rLVmXy1QwCwZwqgbbp1/kupQVcjKuKLitVDbssFyqbDTjP7WRjlVMWAHBI3kgNT7oE362Gf2WMJFf1b0HcrsgLin7daRXpq4Qi6OA57sW1YFMj3sqyuTP0eZV3S4+ZbDVob6amsZIdIwxaLP9Zfywg2bLsGnVldB0+XKedZwDbCLCVg+3ZWxd9T/jV0hpLIIWr+LCOHqq8n8beJvlivgLmDJo8f+EITnAxWcsJUvVai/35AhHCUq9tc9sqMp5PWtabAEMb2AU72/QlX/72D2/NbGQq1BWYbqUpgpCZ2nSgvlWDHlCiUo//UGsvfox01kjTFlmqQInsJVfRxF5AcCAwEAATANBgkqhkiG9w0BAQsFAAOCAQEAi8c6C4zaTEc7aQiUgvnGQgCbMZbhUXXLGRpjvFLKaQzkwa9eq7WLJibcSNyGXBa/SfT5wJgsm3TPKgSehGAOTirhcqHheZyvBObAScY7GOT+u9pVYp6raFrc7ez3c+CGHeV/tNvy1hJNs12FYH4X+ZCNFIT9tprieR25NCdi5SWUbPZL0tVzJsHc1y92b2M2FxqRDohxQgJvyJOpcg2mSBzZZIkvDg7gfPSUXHVS1MQs0RHSbwq/XdQocUUhl9/e/YWCbNNxlM84BxFsBUok1dH/gzBySx+Fc8zYi7cOq9yaBT3RLT6cGmFGVYZJW4FyhPZOCLVNsLlnPQcX3dDg9A==""@$uri = ""$Protocol = "SAMLP"Set-MsolDomainAuthentication `-DomainName $dom -FederationBrandName $dom-Authentication Federated -PassiveLogOnUri $MyURI -ActiveLogOnUri $ecpUrl-SigningCertificate $MySigningCert -IssuerUri $uri -LogOffUri $url -PreferredAuthenticationProtocol $Protocol 17078-8078Note54610546100<IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"> <KeyDescriptor use="signing"> <KeyInfo xmlns=""> <X509Data> <X509Certificate>MIIC5jCCAc6gAwIBAgIQLnaxUPzay6ZJsC8HVv/QfTANBgkqhkiG9w0BAQsFADAvMS0wKwYDVQQDEyRBREZTIFNpZ25pbmcgLSBmcy50ZWNobGFiY2VudHJhbC5vcmcwHhcNMTMxMTA0MTgxMzMyWhcNMTQxMTA0MTgxMzMyWjAvMS0wKwYDVQQDEyRBREZTIFNpZ25pbmcgLSBmcy50ZWNobGFiY2VudHJhbC5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwMdVLTr5YTSRp+ccbSpuuFeXMfABD9mVCi2wtkRwC30TIyPdORz642MkurdxdPCWjwgJ0HW6TvXwcO9afH3OC5V//wEGDoNcI8PV4enCzTYFe/h//w51uqyv48Fbb3lEXs+aVl8155OAj2sO9IX64OJWKey82GQWK3g7LfhWWpp17j5bKpSd9DBH5pvrV+Q1ESU3mx71TEOvikHGCZYitEPywNeVMLRKrevdWI3FAhFjcCSO6nWDiMqCqiTDYOURXIcHVYTSof1YotkJ4tG6mP5Kpjzd4VQvnR7Pjb47nhIYG6iZ3mR1F85Ns9+hBWukQWNN2hcD/uGdPXhpdMVpBAgMBAAEwDQYJKoZIhvcNAQELBQADggEBAK7h7jF7wPzhZ1dPl4e+XMAr8I7TNbhgEU3+oxKyW/IioQbvZVw1mYVCbGq9Rsw4KE06eSMybqHln3w5EeBbLS0MEkApqHY+p68iRpguqa+W7UHKXXQVgPMCpqxMFKonX6VlSQOR64FgpBme2uG+LJ8reTgypEKspQIN0WvtPWmiq4zAwBp08hAacgv868c0MM4WbOYU0rzMIR6Q+ceGVRImlCwZ5b7XKp4mJZ9hlaRjeuyVrDuzBkzROSurX1OXoci08yJvhbtiBJLf3uPOJHrhjKRwIt2TnzS9ElgFZlJiDIA26Athe73n43CT0af2IG6yC7e6sK4L3NEXJrwwUZk=</X509Certificate> </X509Data> </KeyInfo> </KeyDescriptor>00<IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"> <KeyDescriptor use="signing"> <KeyInfo xmlns=""> <X509Data> <X509Certificate>MIIC5jCCAc6gAwIBAgIQLnaxUPzay6ZJsC8HVv/QfTANBgkqhkiG9w0BAQsFADAvMS0wKwYDVQQDEyRBREZTIFNpZ25pbmcgLSBmcy50ZWNobGFiY2VudHJhbC5vcmcwHhcNMTMxMTA0MTgxMzMyWhcNMTQxMTA0MTgxMzMyWjAvMS0wKwYDVQQDEyRBREZTIFNpZ25pbmcgLSBmcy50ZWNobGFiY2VudHJhbC5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwMdVLTr5YTSRp+ccbSpuuFeXMfABD9mVCi2wtkRwC30TIyPdORz642MkurdxdPCWjwgJ0HW6TvXwcO9afH3OC5V//wEGDoNcI8PV4enCzTYFe/h//w51uqyv48Fbb3lEXs+aVl8155OAj2sO9IX64OJWKey82GQWK3g7LfhWWpp17j5bKpSd9DBH5pvrV+Q1ESU3mx71TEOvikHGCZYitEPywNeVMLRKrevdWI3FAhFjcCSO6nWDiMqCqiTDYOURXIcHVYTSof1YotkJ4tG6mP5Kpjzd4VQvnR7Pjb47nhIYG6iZ3mR1F85Ns9+hBWukQWNN2hcD/uGdPXhpdMVpBAgMBAAEwDQYJKoZIhvcNAQELBQADggEBAK7h7jF7wPzhZ1dPl4e+XMAr8I7TNbhgEU3+oxKyW/IioQbvZVw1mYVCbGq9Rsw4KE06eSMybqHln3w5EeBbLS0MEkApqHY+p68iRpguqa+W7UHKXXQVgPMCpqxMFKonX6VlSQOR64FgpBme2uG+LJ8reTgypEKspQIN0WvtPWmiq4zAwBp08hAacgv868c0MM4WbOYU0rzMIR6Q+ceGVRImlCwZ5b7XKp4mJZ9hlaRjeuyVrDuzBkzROSurX1OXoci08yJvhbtiBJLf3uPOJHrhjKRwIt2TnzS9ElgFZlJiDIA26Athe73n43CT0af2IG6yC7e6sK4L3NEXJrwwUZk=</X509Certificate> </X509Data> </KeyInfo> </KeyDescriptor> You can obtain the signing certificate base64 encoded string from your IDP metadata file. An example of this location has been provided but mat differ slightly based on your implementation.For more information about “Set-MsolDomainAuthentication”, see: 17078-8078NoteYou must run use “$ecpUrl = ““” 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: Provision User Principals to Azure AD / Office 365Before you can authenticate your users to Office 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 DirSync or PowerShell can be used to provision user principals. The DirSync ToolThe DirSync Tool can be used to provision principals to your domains in your Office 365 tenant from Microsoft Active Directory located on-premises. For more detailed information, check out: Using PowerShellPowerShell can also be used to automate adding new users to Azure AD and to synchronize changes from the on-premises directory. To use the PowerShell cmdlets you must download the Windows Azure Active Directory Modules which can be obtained here: This PowerShell script shows how to add a single user to Azure AD. Connect to your Office 365 tenant as a tenant administrator:Connect-MsolService Connect-MsolService Create a new user principal:New-MsolUser ` -UserPrincipalName elwoodf1@-ImmutableId ABCDEFG1234567890-DisplayName "Elwood Folk"-FirstName Elwood -LastName Folk -AlternateEmailAddresses "Elwood.Folk@" -LicenseAssignment "samlp2test:ENTERPRISEPACK" -UsageLocation "US" New-MsolUser ` -UserPrincipalName elwoodf1@-ImmutableId ABCDEFG1234567890-DisplayName "Elwood Folk"-FirstName Elwood -LastName Folk -AlternateEmailAddresses "Elwood.Folk@" -LicenseAssignment "samlp2test:ENTERPRISEPACK" -UsageLocation "US" For more information about “New-MsolUser” check out, 17078-8078NoteThe “UserPrinciplName” 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 IDPAs 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 Windows Azure AD SAML 2.0 Protocol RequirementsYou have configured your SAML 2.0 Identity ProviderInstall Windows PowerShell for single sign-on with SAML 2.0 Identity ProviderSet up a trust between SAML 2.0 Identity Provider and Windows Azure ADProvisioned a known test user principal to Windows Azure Active Directory (Office 365) either through PowerShell or DirSyncFollow the detailed instructions in Directory synchronization roadmap to prepare for, activate, install a tool, and verify directory synchronization.After setting up single sign-on with your SAML 2.0 SP-Lite based Identity Provider, you should verify that it is working correctly.0-8079NoteIf 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. If you are using DirSync, see Directory synchronization roadmap.Use the tool to verify that single sign-on has been set up correctlyTo 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 provides guidance on TechNet for testing ADFS at Test single sign-on for different usage scenarios.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 a Windows Azure AD tenant to federate with your Identity Provider. 0-8079NoteThe Connectivity Analyzer requires Internet Explorer 10 or later.Download the Connectivity Analyzer from, Install Now to begin downloading and installing the tool. Here is a screenshot of the tool after it has been downloaded and started.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 logon, 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.0-8079NoteThe 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:Manually verify that single sign-on has been set up correctlyManual 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 logon 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. ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download