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.

Things that don’t update when changing an AD FS URL in Windows Server 2012 R2

Windows Server 2012 R2 introduces a number deep changes to the way that AD FS works, which means that as practitioners, we need to look for solutions to problems in new, unexpected places. For instance, in the old world, if AD FS was completely unresponsive, the first place I would look after AD FS itself would be IIS. In AD FS 2012 R2, IIS doesn’t play a role. Requests are still served by the HTTP.SYS kernel driver but we interact with it using NETSH HTTP, which connects to the driver via the User Mode HTTP Server API. IIS and other familiar components would also interact with this API previously, but they provided a friendlier layer of abstraction between an administrator and the API. Interacting with HTTP.SYS using NETSH HTTP brings a learning curve with it, particularly when it comes to understanding what is and is not controlled here. Also, there is no GUI and the security that HTTP.SYS enforces is stricter than the abstracted layer that IIS has historically opened up. This web server architecture change and other new differences add to the difficulty of tracking down problems when things don’t work as expected, as detailed in this post.

Continue reading “Things that don’t update when changing an AD FS URL in Windows Server 2012 R2”

Significant Identity and Access Management Improvements in Windows Server 2012 R2

Last week, Microsoft released Windows Server 2012 R2 Preview. Some information about new features like the Web Application Proxy role began to emerge from recent industry events, but there isn’t an awful lot to absorb at the moment. Having played around with the preview for a few days, I’m pleased to report that the new features look good. While there are always niggles and unsupported scenarios, the features themselves are bringing Microsoft’s Identity and Access Management (IAM) offerings nearer to parity with the industry leaders. These changes should be of particular interest for SharePoint on-premises and Office 365 customers, as a number of scenarios that were on the bleeding edge of ADFS/UAG capabilities have been brought into the fold with some important enhancements to ADFS, which isn’t just for federation anymore.

In short, we get a new Claims-Aware Reverse Proxy, Device Claims in and outside of the network, Multiple-Factor Authentication and other enhancements for making access control decisions on more than just a username and password. I’ve discussed all of these topics routinely over the last couple of years in SharePoint on-premises and Office 365 contexts, but the current provisions in ADFS and UAG are not as elegant as what we find in the preview, so I’m keenly exploring the new functionality and will try to keep the content flowing. In this post I will focus on the features themselves, as there’s a lot of new stuff and the implementation of this functionality will only be clear with a bit more information than what you’ll find online today. I’m kind of rushing this out after limited use because I know there’s a big appetite for knowledge about the Microsoft Reverse Proxy roadmap, so apologies for the incompleteness in advance.

Continue reading “Significant Identity and Access Management Improvements in Windows Server 2012 R2”