PingFederate Integration with Workspace ONE Access Part 4

Office 365 integration

this blog is the fourth part of the tutorial.

Part 3: ServiceNow integration with PingFederate

Part 4: Office 365 integration with PingFederate

Part 5: PingFederate integration with Workspace ONE Access

Introduction

After I had successfully configured a SAML federation between PingFederate and ServiceNow, I thought adding another popular service provider like Office 365 would be straightforward. I did however bump into a few issues when I was following the PingFederate documentation.

Just in case anyone else faces these problems, I will document here how I made it working. However, since Office 365 is such a popular and well known platform, I will assume:

You have already requested an Office 365 trial tenant
You have added and verified your custom domain name on Office 365
You have configured AD connect with default settings
You have assigned licenses for Office 365 to your user objects in the Office 365 admin portal

This blog post will guide you through the following topics:

Deploying the Office 365 Provisioner files on PingFederate
Enabling the SAML federation on Office 365 using PowerShell
Creating a new SP connection for Office 365 on PingFederate

Install Office 365 Provisioner files on PingFederate

PingFederate offers the same out-of-the-box integration for Office 365 as it does for ServiceNow. Head over to the Ping Integration Directory and download the Office 365 Provisioner zip file.

Note: since I’ve configured AD connect to sync users and groups, I will not be using the provisioning capabilities of this integration.

First, stop the PingFederate service.
Extract the files and merge the content of the dist folder with the <pf_install>/pingfederate/server/default/deploy directory.
Next, restart the PingFederate service.

Configure SAML federation for Office 365

Note: I tried to use the PowerShell commands described in the PingFederate documentation for the Office 365 Provisioner, but never got it working. At first I thought it was because I already had added and verified my domain in Azure, but even after removing the domain from Azure (and uninstalling AD Connect), the PowerShell commands used in the PingFederate simply weren’t accepted.

First, ensure you have the MSOnline PowerShell module installed: Install-Module MSOnline

In the PingFederate admin console, navigate to Security > Certificate & Key management > Signing & Decryption Keys and export your signing certificate (without private key):

Open the .crt file in a text editor and copy the content without the “——BEGIN CERTIFICATE——-” and “—–END CERTIFICATE——-” bits.

Then navigate to System > Server > Protocol Settings and take note of the SAML 2.0 Entity ID:

Open a text editor and edit the variables in the PowerShell script below:

Connect-msolservice

Set-MsolDomainAuthentication -DomainName "<your domain name>" -FederationBrandName "<your domain name>" -Authentication Federated -PreferredAuthenticationProtocol SAMLP -PassiveLogOnUri "https://<your pingfederate hostname>:9031/idp/SSO.saml2" -ActiveLogOnUri "https://<your pingfederate hostname>:9031/idp/sts.wst" -LogOffUri "https://<your pingfederate hostname>:9031/idp/startSLO.ping" -IssuerUri "<your pingfederate hostname>" -SigningCertificate "<your pingfederate signing certificate>"

Even though the command may have been accepted, it may take a long time for the authentication flow to switch to SAML (definitely if you compare it with changes made on PingFederate or Workspace ONE Access).

Verify the federation settings using the following command:

Get-MsolDomainFederationSettings -DomainName "<your domain name>"

Note: to revert the change, use the following command:

Set-MsolDomainAuthentication –DomainName "<your domain name>" -Authentication Managed

Configure Office 365 as a service provider in PingFederate

At this point, Office 365 should be redirecting all authentication requests to PingFederate, so let’s get started with the configuration at the IDP side.

First, we need to collect the Office 365 metadata, which can be downloaded here: https://nexus.microsoftonline-p.com/federationmetadata /saml20/federationmetadata.xml. Save the page as xml for later use.

If you look at the SAML documentation for Office 365, you can see Entra ID is expecting to find 3 items in the SAML response sent by the IdP:

So we need to make sure that PingFederate is sending the immutableID as the subject. We’ll have to configure PingFederate to send the objectGUID with Encoding type Base64, so it matches the on-premises immutable ID attribute in Entra ID.

Navigate to System > Data Stores and select your AD data source. Click LDAP configuration and then select Advanced. Open the Binary Attributes tab, add objectGUID and click Save:

Next, In the PingFederate admin console, navigate to Applications > Integration > SP Connections and Select Use a template for this connection. Select Office 365 Connector from the list and upload the metadata obtained in the previous step:

On the connection Type screen, unselect Outbound Provisioning and select next:

On the General Info, you can set a more convenient name for the Connection (optional):

Click Next until you reach the Browser SSO screen. Select Configure Browser SSO:

On the Assertion Creation screen, select Configure Assertion Creation.

On the authentication source mapping screen, select Map New Adapter Instance:

Select your HTML Form adapter on the Adapter Instance screen:

On the mapping method screen, select the Retrieve additional attributes from a data store option:

On the Attribute Sources & User Lookup screen, select Add attribute Store:

On the Data Store screen, select the Active Directory store and provide a description:

On the LDAP Directory Search screen, enter the Base DN and add the userPrincipalName and objectGUID attributes (select show all attributes in the root object class column to find all attributes):

Ensure the Attribute Encoding Type is set to Base64 for objectGUID (if mS-DS-ConsistencyGUID is your source anchor in Entra ID):

On the LDAP filter screen, set the filter to sAMAccountName=${username}

On the Attribute Contract Fulfillment screen, configure these values:

IDPEmail – LDAP – userPrincipalName
SAML_NAME_Format – Text – urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
SAML_Subject – LDAP – objectGUID

Click Done on the Summary screen. Then click Next to go to the Failsafe Attribute Source screen. Select abort the SSO Transaction:

On the Summary screen, select Done. Click Next on the Authentication Source Mapping screen and Done on the Summary screen.

On the Protocol Settings screen, select Configure Protocol Settings:

Delete all Bindings except POST:

All other screens in the Protocol Settings section can be left on their default values, so keep clicking next until you reach the Summary screen. Click Done.

Click Next and review your Browser SSO settings on the Summary screen. Click Done

On the Credentials screen, select Configure Credentials:

Select your Signing certificate and click Done:

On the Activation & Summary screen, review the configuration and enable the application:

Quite a few steps to perform, but now you should be able to log on to Office 365 using PingFederate as your IdP.

Troubleshooting

In case of issues, install a SAML tracer in your browser and make sure you’re sending the proper subject and userPrincipalName values. The subject should match the on-premises immutable ID found in Azure for that user!

See you in the last (and longest) part of this series, where we will finally configure the integration with Workspace ONE Access!