Snippet #02: Staged Authentication Rollout

I thought the day would never come! Since it’s announcement at Microsoft Ignite last year, I’ve been waiting patiently for this feature to make a pubic appearance. The initial indications we by the end of last year, then Q1, then Q3… finally this week, Staged Authentication Rollout made its way to Public Preview.

I thought I’d post a brief introduction to the feature, following the theme of my previous “Snippet” on the GA of Windows Virtual Desktop.

Why the Hype?

For those that aren’t aware, I highly recommend you have a look at this session from Ignite last year. Skip to the 16 minute mark for an overview of the feature. In essence, Staged Authentication allows you to migrate users from federated to cloud authentication in a phased manner. To date, this transition has been a global one, set at the domain level using either Azure AD Connect, or PowerShell. Whilst it’s a low-impact change if everything goes to plan, the “big-bang” nature (naturally) introduces concern for larger organisations. This is exacerbated when you consider associated features that might be enabled at the same time; Conditional Access, MFA, Self-Service Password Reset etc. The prospect of thousands of users needing to enrol into these services simultaneously is a daunting one for Service Desk teams.

How Does Staged Authentication Rollout Work?

Once enabled, Staged Rollout appears in your Azure AD portal under the Azure AD Connect blade:

If you navigate to the feature, you’ll see a handful of options you can enable. Staged Rollout supports a transition to either Password Hash Sync (PHS), or Pass-Through Authentication (PTA). You can’t use the tool to implement a mix of both (for testing or otherwise). Microsoft’s guidance is to pick one, migrate, and then cut-over fully once all users are staged. The process of doing so is simple:

• Configure Azure AD Connect for PHS / SSSO or
• Deploy PTA Authentication Agents / SSSO
• Enable the relevant service option (PHS, or PTA)
• Add Users to a corresponding group, and assign this to the policy
• Test Sign-In using a staged account

The change should take place immediately, with any associated MFA / SSPR activity triggered at next logon for your test / migrated users. On completion (or when the bulk of your users are transitioned), you can make the global change to disable federation for your chosen domain.

Fuller documentation is available on the Microsoft Docs site here.

Obviously the feature is in Preview, and with that come the usual caveats. Support will be limited, and the experience may well change before this becomes Generally Available. All of that said, we’ve been involved in several projects recently that have leveraged this feature in a Private Preview capacity. In each case, it’s use has been flawless.

In Summary

There’s a broader question around whether you should transition away from ADFS. I hold some fairly strong views on that which I’ll put into a dedicated post when I get a moment. Regardless of your opinion this is a much-desired feature that’s hugely advantageous for larger organisations. If you federate today and are considering moving to Cloud authentication you need to take a look at this feature… I guarantee it will remove some of the nerves you might have around the change!

Happy playing! 🙂