As I mentioned in a previous post, earlier this month Microsoft released an update for AD FS 2.0 on 12th October.

There are a few of us who have been waiting for client access policy support. Enterprise customers, in particular, will be a little happier with the options the enhancement offers. Client Access Policy support provides a means to restrict access by extranet clients to O365 resources. In particular, use of Outlook Anywhere outside of the organization can now be blocked, should your security policy require it and without this being at the expense of ActiveSync connectivity.

Note that changes to the Exchange Online environment come at the expense of Lync support:

"All client access policy scenarios have the effect of blocking external access to Microsoft Lync Online and Office Subscription Services."

Additionally, this approach is geared around limiting the user rather than the device, so at this moment we still cannot handle managed/unmanaged clients. Nonetheless, far be it from me to begrudge progress … the fact that we are able to limit the use of rich clients such as Outlook to certain access conditions is good news.

Onto the new capability….

AD FS can now process new claims types sent by Exchange Online and then use these in acceptance transform rules with the O365 identity platform relying party. There are five new claim types:

X-MS-Proxy

Claim type: http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy

This claim is inserted by the AD FS Proxy, before passing the authentication request to the back-end AD FS server farm. For example, the servername of the AD FS proxy proxy.mydomain.local will be inserted into the X-MS-Proxy caller identity.

X-MS-Forwarded Client IP

Claim type: http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip

This claim is used for assisting in determining the IP address of the user, populated in the authentication request sent from Exchange Online, thereby allowing for limiting traffic to certain locations (e.g. corporate only). I’d suggest using some form of IP lookup tool to help determine where your IP/translation boundaries lie (this caught me when I discovered my “IP” was that of my upstream ISP).

X-MS-Client-Application

Claim type: http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application

For example, use to lockdown external access to just Exchange ActiveSync.

X-MS-Client-User-Agent

Claim type: http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent

This one is optional but allows targeting of the user agent header to further assist in determining which mobile device types are allowed within the organization. I didn’t try this, but I’d use this with care also because

• the proliferation of different types of user agents
• how this reacts to normal browser-based clients.
• you can always use Exchange ActiveSync device policies for soliciting access to mobile clients.

X-MS-Endpoint-Absolute-Path (Active v Passive)

Passive clients are browser-based clients: Outlook Web App, Sharepoint Online, Office 365 Portal

Active clients are rich clients such as Outlook and ActiveSync.

Since Lync isn’t part of Exchange Online, Lync clients will not pass an endpoint absolute path.

Step 2 – Add five claim rules to the Active Directory Claims provider trust

You can paste the claim URL directly into claims rule itself as the document describes, but I decided that I might want to use these claims descriptions later, so for expediency I added them as claims descriptions for each of the five new claims identifiers described  in the document. This can be accomplished through the AD FS 2.0 console under AD FS Service | Claims Descriptions using the Add a Claims Description option. Here’s an example for X-MS-Forwarded-Client-IP.

Once all five were added:

Time to add them to a Pass thru claim rule. For example:

Step 3: Update the Microsoft Office 365 Identity Platform relying party trust

On the relying party trust we create an Issuance Authorization Rule that is used to restrict actions based upon our specific requirements. In this case, the following limitation is to be applied.

Allow access to users to the Office 365 based on a certain set of criteria  defined in the issuance authorization rule.

The interesting part of course is making all this work together: the various rule nuances/conditions and defining them according to the requirements of your organization.  Let’s have a look….

EXAMPLE

In this test case, I wanted to deny Outlook Anywhere access to unauthorized users. Other functionality such as ActiveSync must continue to work, as must Outlook Web App and Sharepoint Online and Outlook Anywhere internally.

So, an Active Client (Rule 4:TRUE), using Outlook Anywhere (Rule 3:TRUE), not connected to the corporate network (Rule 2: TRUE),  connects to Exchange Online from the Internet via the AD FS Proxy (Rule 1:TRUE) and if the (allowed) Group SID does not exist in the claim (Rule 5:TRUE) then the subject is DENIED access.

The group support is experimental and the documentation appeared to contradict itself. Scenario 4 states:

“The following example ……blocks access from clients residing outside the corporate network that have an external client IP address, except for those individuals in a specified Active Directory Group.”

And then the Descriptions of the claim rule language syntax section observes:

“This rule states that the only users in a particular Active Directory group (based on SID value) should be denied. Adding NOT to this statement means a group of users will be allowed, regardless of location.”

exists([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value =~ "{Group SID value of allowed AD group}"])

So which is it? From testing, if the Group SID (allowed) exists in the claim, then the client will be allowed access. If the Group SID does “NOT EXIST” then they will be denied access (all other rules notwithstanding).