If you still haven’t caught up on Modern authentication, you definitely should. You can start by watching this session from last year’s Ignite conference or at least get the slides. I also did a session on it few months back and you can get my slides here. When using Modern auth, there are certain changes to the way clients work and correspondingly the way we secure different applications. I’ve been meaning to write an article about this for a while now, and finally got the time to do so.
In a nutshell, the changes revolve around the fact that all ADAL-enabled clients will use the passive endpoint (/adfs/ls) and we need to adjust our claims rules accordingly. In addition, Modern auth/ADAL made it possible to have proper support for 2FA across all Office applications and every other ADAL-enabled app, which in turn gives us more freedom with configuring the Additional authentication rules. I’ve blogged about the way you can add multiple AARs few weeks back, and while doing this via PowerShell is certainly not a pleasant experience, the added flexibility outweighs the troubles. Plus, once Windows Server 2016 finally arrives, we will be able to do this via the GUI.
Another point that you have to account for in redesigning your claims rules is the fact that the Client application clam (http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application) is no longer present for any ADAL-enabled client. But as you will most likely need to support “legacy” clients as well, at least for some time, you can actually use the presence of this claim to easily distinguish them. Well, either this claim or the endpoint, which will be different now. And since you can now happily force MFA without having to worry about “rich clients” or “app passwords”, you might want to augment your claims rules with checks on whether MFA was performed and what the MFA method was.
You can find the full article on ENow’s Solutions Engine blog.