ClaimsXRay in AzureAD with Directory Extension

Howdy folks!

Michele Ferrari here from the Premier Field Engineer- Azure Team in San Francisco, here today to talk about use the famous ClaimsXRay application with AzureAD to problems with SAML single sign-on for 3rd party tool applications.

Why you might want to read this blog:

You have an Application that you want to integrate with AzureAD providing the Single Sign-on experience for your users. This Application supports a SAML-based protocol but requires some ad-hoc claims to work properly, for example it expects specific Claims to identify your users, attributes that only exist in your on-premises and not in Azure (yet).

If you have been working in AD FS, you probably came across this awesome tool called: Claims X-Ray (https://adfshelp.microsoft.com/ClaimsXray/TokenRequest) to debug and problems with claims issuance in AD FS. Today, we're going to re-use this tool with AzureAD !

At the end of this blog you will be able to:

  • Integrate ClaimsXRay with an AzureAD application to test SAML claims issuance
  • Understand use Directory Schema Extension Attributes for sending user data to applications in token claims
  • rfc1274 – did you know there is an attribute called ‘drink' in Microsoft's ?
  • Learn about the Tenant Schema Extension App in your tenant

Ready? Let's do it, follow me!

  • Integrate AD FS Help ClaimsXRay with AzureAD

Open AzureAD https://aad.portal.azure.com/ and then click on Enterprise Application

img_1.png

Add a Non-Gallery Application:

img_2.png

Choose the name for your application:

img_3.png

Click on Single-Sign-On

img_4.png

Click on the pencil to Edit the Basic SAML Configuration

img_6.png

As Identifier we are going to use urn:microsoft:adfs:claimsxray

As a Reply URL: https://adfshelp.microsoft.com/ClaimsXray/TokenResponse

Identifier (Entity ID) Uniquely identifies the application. Azure AD sends the identifier to the application as the Audience parameter of the SAML token. The application is expected to validate it.
Reply URL Specifies where the application expects to receive the SAML token. The reply URL is also referred to as the Assertion Consumer Service (ACS) URL

Since we are re-using the ADFS ClaimsXRay published by Microsoft, we need to use the Identifier it is expecting and, tell our application where to send/redirect the SAML token.

Note: ClaimsXRay does not enforce the validation of the Identifier. This means that you could potentially have multiple ClaimsXRay applications in your tenant:
 If you use different identifiers, you can register multiple versions of ClaimsXRay for various tests (example, one with and one without required, one with session controls, etc.)

img_7.png

At this point Save the configuration.

img_8.png

Click on No, I'll test later as there is still something we need to configure

img_9.png

Click on Users and groups and then Add User

img_11.png

Search for an User Account and assign it to this Application. This will allow that user to “consume” this app and at the same time, this app will be visible into the myapplications portal

img_12.png

Open a new tab in your favorite browser and go to https://myapplications.microsoft.com/

Search for the name of the application you have just created:

img_13.png

And here the SAML claims with all of its claims:

img_14.png

Now, let's move into the Claims customizations.

My Application requires the On-premises User Drink attribute to be passed within the SAML assertion to my Application and the onPremisesSamAccountName.

Following this documentation https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-sync-feature-directory…

We're going to configure ADConnect to synchronize the Drink attribute since the onPremisesSamAccountName is already available in AzureAD.

Connect to your ADConnect server and lunch the Azure AD Connect app. Remember that you must remember to close this application at the end, as this is going to pause the sync engines for the time you work on it.

img_15.png

Click on Configure

img_16.png

Click on Customize synchronization options and click Next

img_17.png

with your AzureAD Global Admin user

img_18.png

Click Next

img_19.png

Click Next

img_20.png

Select Directory extension attribute sync and then Next

img_21.png

Search and select Drink and add it to the Selected Attributed and then click Next

Did you know that there is an attribute called ‘drink' in Microsoft's Active Directory?
The drink (Favorite Drink) attribute type specifies the favorite drink of an object (or person).
It's been RFC since 1991! :smiling_face_with_smiling_eyes:

img_22.png

Click on Configure

img_23.png

Click Exit to complete the configuration

img_24.png

I'm going to initiate a Delta Synchronization to avoid waiting until the next sync cycle:

Start-ADSyncSyncCycle -PolicyType Delta

powershell_1.png

Now, let's confirm that the Drink attribute flowed into Azure AD. Open the Synchronization Service app

img_26.png

You will notice that as a result of a directory extension change, ADConnect choses to perform a Full Import that, in big environment can take even hours so, always test where possible and plan accordingly as it wont be able to do any other sync operation until it completes the import.

This configuration creates an Inbound Sync Rule to Import the Description attribute From the Connector Space into the Metaverse “In from AD – User DirectoryExtension” and an Outbound SyncRule to export it from the Metaverse into the AzureAD Connector Space where then the object is exported and in AzureAD “Out to AAD – User DirectoryExtension”.

The interesting thing it's how the Object is named in AzureAD: extension_180973d8aa5f4e049c25bb863c66de18_department

img_27.png

What's is 180973d8aa5f4e049c25bb863c66de18?

It's nothing more than the ApplicationId of our Tenant Schema Extension App in our Tenant. Every customer gets a different AppId so do not try to search mine into your tenant.

img_28.png

Directory Schema Extension Attributes provide a way to store additional data in Azure Active Directory on user objects and other directory objects such as groups, tenant details, service principals BUT only extension attributes on user objects can be used for emitting claims to applications and those attributes  are always associated with an application in the tenant and are referenced by the application's applicationId in their name: Tenant Schema Extension App.

As you can see the Identifier for a Directory Schema Extension Attribute is of the form of Extension_xxxxxxxxx_AttributeName, where xxxxxxxxx is the applicationId of the application the extension was defined for.

Once a directory extension attribute created via AD Connect is in the directory, it will show in the SAML SSO claims configuration UI.

Let's go back to our ClaimsXRay Enterprise Application in the AAD Portal

img_29.png

Then click on Single sign-on

img_30.png

Click on the pencil to edit User Attributes & Claims

img_31.png

Click on Add new claim

img_32.png

Type a Name for your new claim and select the user.drink extension we just created and then click on Save

img_33.png

Open a new tab in your favorite browser and go to https://myapplications.microsoft.com/

And click on your ClaimsXRay application

img_34.png

And we can see the new Favorite_Drink claim we just created, which is a synced attribute from our on-premises AD Department attribute:

img_36.png

This concludes this Blog Post. I want to thank you for your time and I'll see you soon here!

Michele Ferrari

 

This article was originally published by Microsoft's Core Infrastructure and Security Blog. You can find the original article here.