Start using Claims X-Ray with Azure AD

Dusting this thing off to share a quick tip for Single Sign-On work. For a while now I’ve been a proponent of using Claims X-Ray for interrogating/troubleshooting AD FS Claims. The tool is created by the AD FS / Azure AD team, and I have always found it to be a massive help. However, I had never tried using it with Azure AD, and it isn’t really presented as a tool that you would use with Azure AD. Ultimately there is no reason you can’t though, and I am finding it just as useful as I do with AD FS (if not more so). When I say “more so”, consider that many attributes are not easily discoverable in the interface, in PowerShell, or with Graph queries. Even attributes as important as user.onPremisesSamAccountName are quite hard to find unless you know the Graph syntax, so in some cases it may be simplest to add an unknown Claim to Claims X-Ray and interrogate away.

Here’s a view of my configuration. It will literally take two minutes (by which I mean 4 minutes and 24 seconds in the first empirical data to arrive) to deploy in your labs, and there is no reason not to target it at All Users, since it only unveils their own data.

Navigate to Enterprise Applications in Azure AD

Add a Non-Gallery Application, and name it “Claims X-Ray”, or whatever you like.

Configure Single Sign-On

Configure SAML

Extract the Redirect URL and Identifier from the Claims X-Ray site

Open the Basic SAML configuration options

Paste in the Identifier from Claims X-Ray as Identifier (Entity ID). Paste in the Redirect URL as Reply URL (Assertion Consumer Service URL)

When this is Saved successfully, do not choose the testing option yet, as the application hasn’t been assigned.

Add All Users (or whichever Group you would like to target). Personally, I see little reason to target this narrowly in a test environment.

Test the application from the My Apps portal.

That’s it! You will see a response like this in the default configuration.

And you can even view the Raw token data if you need to look at things like the token format, etc.

Hope this helps! In my view this should become a standard part of anyone’s Azure AD test environment.

Forget what you know about Kerberos before configuring Exchange Server to use Kerberos

My colleague Mike Parker has a great new series of posts up on securing Exchange Server 2016 with Azure AD. This option may seem counter-intuitive at a glance, but given that most organisations are on a trajectory from Exchange Server to Exchange Online, this configuration can consolidate access control for e-mail in a single location (for instance, over the duration of a migration or for long-term co-existence). It also means that Azure AD Conditional Access policies can be used for Exchange resources on and off-premises, which improves security while enabling mobility.

This configuration has two parts:

  1. Get most Exchange Server components to use OAuth 2.0. This is known as Hybrid Modern Authentication.
  2. Publish Outlook Web App (OWA) and the Exchange Control Panel (ECP) using the Azure AD Application Proxy.

The second step is necessary because these components are not currently supported for Hybrid Modern Authentication. The major pre-requisite for publishing an application with the Azure AD Application Proxy is that it should be authenticated with Kerberos and the Application Proxy Connector machine accounts need to be configured to use Constrained Delegation (KCD) for the OWA and ECP Service Principal Name (SPN). Mike’s article takes you through all of this step-by-step. My post deviates a bit from Mike’s guide to consider the idiosyncrasies of the Exchange Alternative Service Account Credential (ASA), which has underpinned Kerberos in Exchange Server since 2010 SP1. If you are familiar with configuring Kerberos, the ASA will almost certainly hold some surprises. Maybe even a fourth head.

Continue reading “Forget what you know about Kerberos before configuring Exchange Server to use Kerberos”

Product reuse at Microsoft as seen through a FIM lens

Microsoft and other large software vendors often fall foul of criticisms that products overlap significantly, or that discreet functionality in one product has been written afresh when the facility is already mature in another technology. As I’ve grown to know it better, I think Microsoft’s Forefront Identity Manager (FIM) provides some interesting examples of the benefits and drawbacks of product re-use. I put these thoughts out as a set of considerations to counter the view that reuse is always a positive thing.

Note: I wrote this article a long time ago, and have always been on the fence about posting it because it’s an editorial rather than purely technical content. I’m not 100% certain this is the right place for this content, but I am publishing it here now rather than letting it rot. Because this was written a long time ago, some references are dated. Like this doesn’t speak of MIM, AADSync or AAD Connect in any detail, so put that knowledge to one side for now.

Continue reading “Product reuse at Microsoft as seen through a FIM lens”