ADFS Claims Based Rules - I'm stuck!

This was what worked for me. I eventually had to use the user agent claim. Agreed, it will only cover Outlook but that works for now, will add additional useragents in future.

Although I am not sure at this point, it looks like this started affecting users on the network who had mailboxes on prem but archives in the cloud, or who had calendar sharing with users int he cloud because they continued to see prompts in Outlook, which makes no sense because all the conditions are ANDed and insidecorporatenetwork is set to false.

exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path", Value =~ "/adfs/(ls/|services/trust/2005/usernamemixed)"])
&& exists([Type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"])
&& exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent", Value =~ "Outlook"])
=> issue(Type = "http://schemas.microsoft.com/authorization/claims/deny", Value = "true");

Thanks to much help from Vasil and research in Azure AD Conditonal Access, I was able to determine that nothing is going to prevent Modern Authentication clients at the AD FS level.  There is no x-ms-client-application being presented by the application anymore (with modern auth).  Instead you have to use Azure AD Conditional Access which is in preview in the new portal.  It seems to work well. 

I used conditional access for the modern auth and for legacy auth I used this claim rule

NOT exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip", Value =~ "\bXXX\.XXX\.XXX\.XXX\b"])
 && exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application", Value =~ "Microsoft.Exchange.Mapi|Microsoft.Exchange.Autodiscover|Microsoft.Exchange.OfflineAddressBook|Microsoft.Exchange.WebServices"])
 => issue(Type = "http://schemas.microsoft.com/authorization/claims/deny", Value = "DenyUsersWithClaim");

It is quite easy to see what is going on in the Security Log when you properly enable auditing per this article https://jorgequestforknowledge.wordpress.com/2013/07/08/enabling-auditing-of-issued-claims-in-adfs-v2-x-and-adfs-v3-x/ 

Look for EventIDs, 299, 500 & 501

This way you can adjust your claim rules to your environment.

Hope this helps!

The best way to troubleshoot ADFS claims is with fidler. Fidler can catch your certificate thumbprint so you can see the claims which are communicating. If you are doing this make sure you have your ADFS, and party trust in the right order. Then you go to the page https://adfs.domain.nl/adfs/ls/IdpInitiatedSignOn.aspx and logon with an account that needs SSO. Make sure Fidler runs simultaneously and catches your data.

I'm working on this exact same problem. Discouraging to see there is no accepted solution. Also using ADFS 3.0 with WAP, Outlook 2016 and modern auth. Need a solution to this MS! I'll let you know what we find as it's high priority for us.

Kevin --

I never got it to work - but to be honest, I had to put it down and work on other, higher priority projects.  That being said - I had a rule that seemed to work *sometimes*, and I couldn't pin down exactly what was going on.  I did learn a lot about reading the logs and I intend to pick this up again in the future.

I believe this is where I left off:

exists([Type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"])
&& NOT exists([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value =~ "S-1-5-21-xxx-xxx-xxx-xxxx"])
&& exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path", Value == "/adfs/services/trust/2005/usernamemixed"])
&& exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application", Value == "???????"])
=> issue(Type = "http://schemas.microsoft.com/authorization/claims/deny", Value = "true");

I believe the x-ms-client-application should be Microsoft.Exchange.RPC OR Microsoft.Exchange.ActiveSync (not sure on the case), OR Microsoft.Exchange.Autodiscover (not sure on case), OR Microsoft.Exchange.Webservices.  I just never got the syntax quite right.

Also - my clients are not using modern authentication.  Last I knew, all modern authentication traffic presented itself to the adfs/ls endpoint and thus - you could not decipher active from passive connections.  Maybe that has changed in the past couple of months?!?!

If this helps or you end up getting the rule right - please let me know.  I would love ot have someone working in toward the same goal to bounce ideas off of.

Thanks

sb