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.

Creating an InsideCorporateNetwork Claim for AD FS 2.x

AD FS 2012 R2 ships with the InsideCorporateNetwork Claim. It evaluates to “True” when a request is received directly at AD FS, or “False”, if a request is received at the WAP. This Claim doesn’t exist in AD FS 2.0/2.1, and it’s fair to say this is one of the more poorly understood differences in behaviour across the versions.

I’ve recently been asked to find out if it’s possible to create an InsideCorporateNetwork Claim in AD FS 2.0/2.1. The benefit of creating it for the older versions is that InsideCorporateNetwork would be usable in exactly the same way that we use it in AD FS 2012 R2 and later, which opens up the following options: Continue reading “Creating an InsideCorporateNetwork Claim for AD FS 2.x”

Keeping AD FS Integrated Windows Authentication (IWA/WIA) Clients Signed In

Over the last couple of years we’ve started doing less AD FS work, with the advent of Password Hash Sync for Azure AD sign-on, and Microsoft’s continued investment in Azure AD Premium. We’ve also seen a few organisations struggle to operate AD FS successfully, even if I personally like the technology. So I’ve changed our approach to unveil all of this with as much realism as possible, and to draw some feature comparisons in both directions. We also spend a lot of time talking about expectations of SSO, and how the ways we think about SSO on the web aren’t quite as automatic as what we get with Windows hashes and tickets.

So… what this means is that we don’t do as much AD FS work anymore, and when Microsoft released a hotfix for AD FS in the August 2014 update rollup, it didn’t catch my eye. This hotfix and the related configuration that needs to be added to the AD FS trust with Azure AD are documented in the newer Configure Persistent Single Sign-On article, and I first picked up on this configuration in the Azure MFA article for AD FS. At any rate, this configuration specifies two new Issuance Transformation Claims Rules for the AD FS Relying Party Trust with Azure AD (AKA “Microsoft Office 365 Identity Platform”):

Continue reading “Keeping AD FS Integrated Windows Authentication (IWA/WIA) Clients Signed In”

Creating a broadly compatible, modern SSL certificate with Active Directory Certificate Services

After recently hitting the default two year expiration point with our SharePoint development environment’s AD CS-issued SSL certificates, I set about updating that environment with a new five year template. I took this opportunity to see if I could make it as good as possible without breaking compatibility with anything. I will discuss some of these compatibility issues along the way. I will also make the certificate exportable, make sure it’s using the SHA256 hash (SHA1 will be deprecated in the near future), change the Certificate Authority (CA) configuration so that HTTP Distribution Points will be contactable from “outside the network”, and set permissions on the template in a way that it will be generally usable.

Steve Peschka tackled some of these basics about 18 months ago, but as he notes, his posts covers the simplest updates you can make. I think a few other options are worth considering. I don’t pretend to know all that there is to know about Active Directory Certificate Services (AD CS), or PKI in general, but I do think we can advance considerably beyond the default with a few changes. This is not a well-documented subject, so I hope to pull a few disparate resources together and propose an improved template. If you think anything here can be improved further, please post in the comments and I’ll try to incorporate that feedback.

Continue reading “Creating a broadly compatible, modern SSL certificate with Active Directory Certificate Services”

The Rules of AD FS Claims Rules

Many people think of AD FS as merely a federated authentication service. And with a name like Active Directory Federation Services, it’s easy to see why. However, it also has the capacity to make authorisation decisions within its Claims Engine. This may be most familiar as the Office 365 Client Access Policies, but those policies are basically just a flavour of AD FS Issuance Authorisation Rules. An AD FS Issuance Authorisation rule provides a gate at AD FS, where permissions can be granted or denied to authentic users, per-Relying Party, before giving the user Claims for the requested Relying Party. In most cases we will think about these rules as coarse controls, to block a wide category of requests, such as those originating from outside the network, for members of a group, or for any combination of request-based, device-based and user attribute-based Claims. We can even create authorisation rules based on the user’s Identity Provider, or from additional factors of authentication. We will typically still implement most of our authorisation logic within the Relying Parties we are authenticating to, but in some cases it’s very useful to control access at this intermediary tier – especially if a large class of users, devices or networks should be treated as higher risk.

These concepts are not new, and the TechNet documentation I reference here dates back to the earliest wave of AD FS 2.0 RTW content:

Ultimately, I think these articles do answer the question of how to create an AD FS Issuance Authorisation rule, but I can’t point very clearly to the place on these pages that spells it out, and I do think there is a lot of confusing information about this in other places which may lead people astray. Namely, there is a lot of information that only concerns itself with the default Active Directory Claims Provider Rules and the Claims that come from request headers. Also, some of the most referenced AD FS + SharePoint content seems to have been written without authorisation rules in-mind. I want to try to clear some of that up in this post.

UPDATE 24/2/2015
I’ve added a fairly significant update regarding the new MFA stage in the pipeline half-way down this post.

Continue reading “The Rules of AD FS Claims Rules”

Coordinating AD FS 2012 R2 token lifetimes to reduce logon prompts, enforce revocation and limit session duration over public networks

Back in February, I posted a question on the Geneva forum about Adjusting token lifetimes at the Web Application Proxy (WAP) for external access:

Does the Web Application Proxy or AD FS have any separate controls for adjusting token lifetimes to a different value via WAP than directly at AD FS? I can see there’s a session cookie for EdgeAccessCookie that WAP issues but this seems to be entirely undocumented at present. I’ve poked around in C:\Windows\ADFS\Config\microsoft.identityServer.proxyservice.exe.config (also undocumented as far as I can tell) but I’m not finding anything there either. We used to have some of these controls (sort of) with TMG/UAG. Are they totally gone now? With the AD FS Proxy this was less of an issue because it was only publishing AD FS but this is something that I’d hope to be able to control with a Reverse Proxy. Any ideas?

I didn’t get any replies, but after carrying out some tests of my own, I noticed the EdgeAccessCookie, and found a bit of information on TechNet:

After the user is authenticated, the AD FS server issues a security token, the ‘edge token’, containing the following information and redirects the HTTPS request back to the Web Application Proxy server:

  • The resource identifier that the user attempted to access.
  • The user’s identity as a user principal name (UPN).
  • The expiry of the access grant approval; that is, the user is granted access for a limited period of time, after which they are required to authenticate again.
  • Signature of the information in the edge token.

Web Application Proxy receives the redirected HTTPS request from the AD FS server with the edge token and validates and uses the token as follows:

  • Validates that the edge token signature is from the federation service that is configured in the Web Application Proxy configuration.
  • Validates that the token was issued for the correct application.
  • Validates that the token has not expired.
  • Uses the user identity when required; for example to obtain a Kerberos ticket if the backend server is configured to use Integrated Windows authentication.

If the edge token is valid, Web Application Proxy forwards the HTTPS request to the published web application using either HTTP or HTTPS.

This quickly became one of those things where there was insufficient documentation and limited project time, so I had to put this inquiry on hold. Then in July, I posted a question on the Application Proxy blog (a great resource), to see if this is something that they planned to document. The response that I got from Ian Parramore was unexpected and pleasing:

Continue reading “Coordinating AD FS 2012 R2 token lifetimes to reduce logon prompts, enforce revocation and limit session duration over public networks”