Azure Active Directory - Single Sign-On and Provisioning

The benefits of using Azure Active Directory outweigh the costs because a lot of issues that you have on-premises are handled automatically by Microsoft and the only thing that you have to do is to manage them properly from a management / security standpoint.

Single Sign-on is not something new or fancy or “next-gen,” a lot of people have been doing it using either ADFS or third-party tools or a combination of both. The problem was that this required a lot of knowledge of how the authentication mechanism works. With ADFS it was no joke to set up, and if there were no tutorial out there, you were left to figuring it out.

I won’t cover how to set-up apps with AAD because Microsoft has done a good job with this via https://docs.microsoft.com/en-us/azure/active-directory/saas-apps/tutorial-list

This blog post will cover the quirks that come up during the SSO / provisioning setup ?

To start off, first you need administrative access to the application(s) that you want to federate with because if you don’t have access then this is a little more complicated because you have to give out the right information to the person that’s managing that application.

Let’s assume, that you have all the access that’s required to third-party applications. Check the AAD tutorials if your application exists here

If your application is missing from the tutorial gallery, chances are it’s not out-of-box supported and you will have to build a custom application for it.

If you find your application exists in the gallery, don’t do the victory dance yet because you will still need to check your third party application if it supports custom SSO with a specific IDP or it requires a plan upgrade. If it’s none of the above then validate if the documentation is not outdated because if it is then you’re going to have issues during the configuration step.

Next up is the testing phase and the most painful if the app documentations don’t match. Once you’ve set up everything for the application to work with AAD, you have a testing step where you can validate if SSO is working. If SSO is not working then you need to run some debugging steps.

The best place you can look for the error codes that pop up is here. Some error codes are simple to debug. Most of them pop up during misconfiguration but some of them are ugly as hell and require a different type of debugging using Fiddler.

One example that I can provide is when I configured Google Apps with Azure Active Directory. The users were correctly provisioned in Google but for some reason, trying to open any Google APP resulted in a generic “Server Error”

How do you debug this one? The screenshot from above is the whole error. This can throw you off because you don’t think it’s an AAD problem but a Google problem right?

Well, the reality is that it was indeed an AAD problem but the problem started from on-premises. In AD the users didn’t have the E-Mail field populated and AAD Connect didn’t map them correctly in Office 365. After a thorough inspection, it turned out that the error was related to the fact that the new users got a domain suffix based on a primary domain which was with the xyz.onmicrosoft.com format, and that information was exclusively visible in the Exchange Online portal not AAD nor Office 365 user portal.

This was found during a Fiddler trace where we decoded the SAML response and presto, we found that AAD was sending the onmicrosoft.com domain to Google and not the correctly configured one.

So whilst Google returned the most generic (and useless) error one can think it, the error was correct.

Auto-provisioning is another fun thing available in AAD where it allows you to configure automatic provisioning for third party applications based on direct user assignment or via groups.

The problems that start here can be related to throttling, service issues or simple “un-optimized” coding.

The screenshot from above shows the automatic provisioning for Google Apps where you see that I have to press an Authorize button and enter a set of credentials there. The problem as you might have guessed is that auth token expires after a while (hours, days) if you have SSO configured with the same app. The solution to this one is to have another app for Google with Auto-Provisioning enabled. Some apps like Salesforce require a specific set of credentials which get encrypted or Service Principals.

The errors appear right the provisioning tab in the Enterprise Application and there you can find out if you have any type of problem

Beware that some applications simply do not have automatic provisioning enabled and that’s where you will have to have a mechanism to synchronize those identities. Azure Functions might works flawlessly for that ?

That’s all folks! Have a good one!

LE: Updated blog post and screenshots to be more accurate to today’s portal ?