Overview

In this guide, we demonstrate the Azure and Office 365 integration with the RCDevs Identity Provider through SAML.
Refer to Microsoft documentation for all information about SAML configuration.

In this documentation, we provide two setups:

  • Azure/Office 365 users synced from an Active Directory domain and WebADM framework is configured with the AD domain infrastructure.
  • Azure/Office 365 users not synced from an Active Directory domain. This secondary setup involves a few additional steps. WebADM framework is configured with RCDevs Directory Server (OpenLDAP), and identities used for logging into the IdP are sourced from OpenLDAP.

Setting up an external SAML Identity Provider (IdP) for Office 365 involves configuring Azure Active Directory (Azure AD) as the IdP for your Office 365 tenant. Here are the steps to accomplish this:

  1. Configure Office 365 and setup the external IdP;
  2. Configure the Azure/Office 365 Client Policy through the WebADM Administrator portal;
  3. Verify and test your configuration

Active Directory Domain Identities

For this setup we assume the identities coming from Active Directory domains are already synced to your Azure/Office 365 tenant.

IdP configuration on Azure/Office 365

You will need to configure Office 365 to trust your external IdP. This involves using PowerShell commands since the Office 365 admin center does not provide a graphical interface for configuring third-party IdPs.

Connect to Exchange Online PowerShell using the following command:

$UserCredential = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection
Import-PSSession $Session -DisableNameChecking

Run the command to add the external IdP metadata:

Set-OrganizationConfig -SamlProviderMetadataUri "<metadata_uri>"

Replace <metadata_uri> with the URL of your IdP's metadata XML file.

On my side it is https://sso.rcdevsdocs.com/ws/saml/:

Set-OrganizationConfig -SamlProviderMetadataUri "https://sso.rcdevsdocs.com/ws/saml/"

After adding the metadata, configure the SAML settings for Office 365 to use your IdP:

Set-MsolDomainAuthentication -DomainName "<your_domain>" -Authentication Federated -IssuerUri "<issuer_uri>" -PassiveLogOnUri "<logon_uri> -LogOffUri "<logout_uri>" -PreferredAuthenticationProtocol SAMLP

Replace <your_domain>, <issuer_uri>, <logon_uri> and <logout_uri> with your domain name, IdP's issuer URI, and logon/logout URLs respectively.

Set-MsolDomainAuthentication -DomainName "rcdevsdocs" -Authentication Federated -IssuerUri "https://sso.rcdevsdocs.com/ -PassiveLogOnUri "https://sso.rcdevsdocs.com/openid/index.php" -LogOffUri "https://sso.rcdevsdocs.com/openid/index.php" -PreferredAuthenticationProtocol SAMLP

The IdP information can be retrieved from your SAML metadata page.
On my side, it is accessible through https://sso.rcdevsdocs.com/ws/saml URL.

Providing the following output:

<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" entityID="https://sso.rcdevsdocs.com">
<IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<KeyDescriptor use="signing">
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate>MIIGfzCCBGegAwIBAgIRAM9/TyvDiZAahDgzYkWGRdIwDQYJKoZIhvcNAQELBQAwUjEXMBUGA1UEAwwOUkNEZXZzIERvY3MgQ0ExCzAJBgNVBAsMAkNBMR0wGwYDVQQKDBRSQ0RldnMgRG9jdW1lbnRhdGlvbjELMAkGA1UEBhMCTFUwHhcNMjQwNzE1MTM0OTA3WhcNMzQwNzEzMTM0OTA3WjBgMRswGQYDVQQDDBJXZWJBRE0gQ2VydGlmaWNhdGUxDzANBgNVBA0MBlNFUlZFUjEXMBUGA1UECgwOUkNEZXZzIFN1cHBvcnQxFzAVBgNVBGEMDlZBVExVLTAwMDAwMDAwMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA1w3PR1Q+78jdD12g4Di3ljcthoZwvpQuwmuOm/+fBthQjrHR1UIY3HDkulCOYpBRiNNj6ED49eyF9jIeO/zVO5QXnzX4gmasZPd06ZYAD8pkDc7fnnxZD4aSHDKQcF1xwUnHESUCPzWR1Wy3t6ifwl85uRuC+QlskMv4t82LqeMQeSBdeBqNpADm9Hmg8AO5BK4Oz/NNooB46P5RYDEerY1D/qOfLkuzEDr2C2Z1rGvtG7+7EpaS+b9Ipnz/fT71QACPxJym98YWEp/1Fb/clC6QLKQuQ+AzheTVZyyeOhOYFxsoGEu+wDFAERXWWAr5sPnayDJiZdXbH+712ri35y9oFWOxZC1diATOS/MRc05bAzgAbyiQe1PrhDfwRiL4YF0EtLvuZJGBH031DZS3THdYSeONDhsImbNYFYLPpzRqb5iXssN+KBPAdCfYJ2IMfjAV4li0s1WSC40iZ5MAkwovE0HD++DVO2HHBJ9hYl6aqa35lGm/QSjkUYvw2xX3kvc3utPQcqUkYDWzF7tLIMpTzO6FtD1pR/FR6DKkqmx9NhLMdIi9eNGK4MG+MgKwCXhE1I6aJxVoRCbAihb0wgnR+Y38P4bJUYzvDCC4upE3DLc+ct5VJ/rtCo9UDyVQGsLDD9cDoywdr6feM/Pou+LpccVNAHul1FJ9CPKxyVECAwEAAaOCAUAwggE8MAsGA1UdDwQEAwIF4DATBgNVHSUEDDAKBggrBgEFBQcDATCBygYIKwYBBQUHAQEEgb0wgbowJgYIKwYBBQUHMAGGGmh0dHA6Ly8xOTIuMTY4LjQuMTYwL29jc3AvMCYGCCsGAQUFBzABhhpodHRwOi8vMTkyLjE2OC40LjE2MS9vY3NwLzAzBggrBgEFBQcwAoYnaHR0cDovLzE5Mi4xNjguNC4xNjAvY2FjZXJ0Lz9mb3JtYXQ9ZGVyMDMGCCsGAQUFBzAChidodHRwOi8vMTkyLjE2OC40LjE2MS9jYWNlcnQvP2Zvcm1hdD1kZXIwSwYDVR0fBEQwQjAfoB2gG4YZaHR0cDovLzE5Mi4xNjguNC4xNjAvY3JsLzAfoB2gG4YZaHR0cDovLzE5Mi4xNjguNC4xNjEvY3JsLzANBgkqhkiG9w0BAQsFAAOCAgEACy/zl7IPSaOn2wEZ66xQNxm9FW408jMrQS2Y6hFvfzRMNhbOh+ZwNFSgCijUJ4ASZVQeZIiYN8f/quH80Y7AJE3kcTpXvJE2LozDbUMsXe0GpkNuzDojbp3K2ZcgUitL0q/rDHPBXXExl1AEhPgpwN1I7ZyHPfZpU92XxcsoSrUi8AMmzoVwlna30RMkkCDDBsf+an1uxdrdwMQLeQddOFddAUI80NWvh0drnv1epkT34K+RpvEAU514a3suErDMIqp+h7BqTdPrdiRkIhTutgSsPquhGIDzv+WvGBzFGWPAfudQHE5jMn3lPgN3r75HrdNfMkVEv0jclpp3VhiUnwQzNQn2UzVe7LQh8ixjEg1kwtIQ8UuwX6LOZ7a51WuKkRfS1iw1yDCM1UmGNuoMGqI6bxwFbBZ1C3brgJKjXBciEpXrSpcJ+ulhDYYUrCmGnpg6xyJ6veWfT2tVExLcffv4edT0KCJuKsyTztLFtT9A9ihyV/lPBsVUtIipe2CaCXupP84812s0cgo6XkcAr99pvtPNLZg9aBLuVt7GmyJSQeLJ6z+QWlkKnsEh7HlSrV2RC/wsTYlTeTRZFmiNa1RGx4UsNyTf9Igp+EG4Nh/UBhGO1Jkn1dIRZyb/qgcF/DWCSdbwFIKxuaKA12KFJMFS4aMV1e0QLDhLfpZ1/10=</X509Certificate>
<!--  Cert Fingerprint (SHA1): 32774463a2e892150f46852b3fdcac7f5be924dc  -->
<!--  Cert Fingerprint (SHA256): e0bd10584f5c3a554e279b9241619e8fdf9c3bfbe95c90da939f0342546e52ac  -->
<!--  Cert Fingerprint (MD5): 639ed5b4241047c8382f897fc459a714  -->
</X509Data>
</KeyInfo>
</KeyDescriptor>
<SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://sso.rcdevsdocs.com/openid/index.php"/>
<SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://sso.rcdevsdocs.com/openid/index.php"/>
<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://sso.rcdevsdocs.com/openid/index.php"/>
<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://sso.rcdevsdocs.com/openid/index.php"/>
</IDPSSODescriptor>
</EntityDescriptor>

Azure/Office 365 Configuration on the IdP (Client Policy)

The Azure/Office 365 configuration on the IdP consists of creating a client policy and configuring the required settings for the SP.

Let's create a Client Policy for Azure/Office365. Login on WebADM Administrator portal, click on Admin tab, click on Client Policies and then Add Client button. Name your client policy and optionally provide a description.

saml

Click on the Proceed and Create Object buttons.

You are now entering the policy configurator. Configure the Default Domain, a Friendly Name (optional), and set the Client Name Aliases to urn:federation:MicrosoftOnline value.

saml

Scroll down to Default Application Settings, click on the Enforced Settings checkbox and click Edit button. In Applications box, select OpenID & SAML Provider.
In the Common Features section, set the Name Identifier setting to ImmutableID.

In the SAML Service section configure the attributes returned in the SAML assertion.
e.g: fullname,phone=mobile,language=preferredLanguage,email=othermailbox

saml

Scroll down a little bit and configure the Assertion Consumer Service URL and the Logout Consumer Service URL with https://login.microsoftonline.com/login.srf value:

saml

Configuration is done, click on Apply to apply SAML settings to your client policy and on the next screen click Apply to save your client policy.

Verify and test your configuration

You can verify you configuration using the folloiwng Powershell command:

Get-MsolDomainFederationSettings -DomainName "<your_domain>"

Test the SSO configuration by attempting to sign in to Office 365 using your IdP credentials.

Configuration is done!

RCDevs Directory Identities

For this setup, we assume the identities are not sourced from Active Directory domains but from the RCDevs Directory (OpenLDAP) or any other LDAP directory different from Active Directory.
Identities can already exist or not on Azure/Office 365. They must exist in the LDAP directory configured with WebADM.
The matching must be done using a common username (generally the UserPrincipalName) on both Azure/Office 365 and the LDAP directory configured with WebADM. The advantage of OpenLDAP is that your can configure multiple username values in the uid. Configure in that case the samAccountName and the UserPrincipalName.

saml

The configuration above remains the same. The only difference is that during the first authentication, Azure/Office 365 will complain that the user doesn't exist because the ImmutableID sent by RCDevs IdP does not correspond to any Azure/Office 365 account.
With a synchronization of an on-premises Active Directory infrastructure to the Azure/Office 365 tenant, the ImmutableID is based on the objectGUID value of the user account.
With an OpenLDAP setup, there is no synchronization from the on-premises LDAP to the Azure/Office 365 tenant, and the objectGUID sent by the RCDevs IdP is not recognized by Azure/Office 365.

saml

If the user already exist on Azure/Office 365, you can set the ImmutableID value with the following command targeting the desired account:

Set-MsolUser -UserPrincipalName john.doe@rcdevsdocs.com -ImmutableId 30e7c96a825af4603e8cef2ca0047df6

If the user do not already exist on Azure/Office 365, then create it with the following command:

New-MsolUser -UserPrincipalName john.doe@rcdevsdocs.com -ImmutableId 30e7c96a825af4603e8cef2ca0047df6 -DisplayName "John Doe" -FirstName John -LastName Doe -AlternateEmailAddresses "john.doe@rcdevsdocs.com"

Once it is done, you can retry the authentication and you should be authenticated successfully on Azure/Office 365 portals.