Tag Archives: Office 365 Grid

AD FS 2.0 Rollup 1: Client Access Policy Support for O365

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 Smile … 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:


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).


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.


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….


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).

TMG Pre-Authentication Options with Office 365

Let’s have a look at some of the authentication methods/options that are possible with TMG, Federation and Office 365. I believe Microsoft at some point will expand on the supported TMG scenarios for O365 and how these options work in conjunction with AD FS 2.0. In the meantime, there are a few TMG front-end pre-authentication methods/combinations to try out with O365 and AD FS 2.0.


As the diagram above illustrates, TMG supports a number of authentication types. Let’s have a look at authentication combinations with TMG and AD FS 2.0 with the Office 365 suite as a relying party.

No Authentication

The basic reverse proxy scenario, or No Authentication scenario as I’ll refer to it, is described here on the Office 365 community site.


This is the only Microsoft-documented TMG configuration thus far for Office 365. The article provides an excellent starting point for configuring TMG with AD FS 2.0, so I’d recommend beginning with this configuration.

From a user experience perspective, using OWA as an example, the user may approach the web application through the Microsoft portal at https://portal.microsoftonline.com or directly via https://www.outlook.com/mydomain.com. Once the user hits AD FS, the user logon is processed according to whether:

  • If the machine isa domain member, the URL of the TMG (e.g. sts.mydomain.com) is in the trusted sites zone, and the browser is configured to automatically logon with username and password, then the user will silently logon to the on-premise AD FS and be redirected to their OWA mailbox
  • If the machine is not a AD domain member, or the URL of the AD FS is not in the trusted sites zone, the user will be challenged to enter their domain username and password (NTLM)


With no AD FS proxy present, the TMG is setup to reverse proxy traffic to the AD FS backend. The user request is proxied to the AD FS server and the AD FS picks up the logon request.

This scenario is called No Authentication as a reference to the fact that TMG isn’t performing any pre-authentication itself. It’s simple and doesn’t “interfere” with the federation logon process like the other approachesdescribed. It’s downside, one can argue, is that this approach may be less than satisfactory from a security perspective, with some form of pre-authentication at the edge more preferable.

For browser-based clients there are pre-authentication options with TMG, in conjunction with authentication delegation to the AD FS service that can be used. They are:

  • HTML Forms Authetnication
  • HTTP Authentication
  • SSL Client Certificate Authentication

From a Office 365 web application testing perspective (for browser-based applications), logon from the following apps was performed:

  • Outlook Web  App
  • Sharepoint Online
  • Microsoft Office 2010 Clients (excluding Outlook)

HTML Forms Authentication

HTML Forms Authentication or Forms-based logon is likely familiar to most TMG administrators as it is often used in web publishing scenarios. The use enters their credentials via a form; username/password, One-Time-Password etc.


On the TMG-side, when configuring the web listener for HTML-Forms authentication, there are a number of authentication validation methods.


In this case we’re interested in seeing what authentication options are possible with the Delegation tab on the publishing rule and which ones are available according to the authentication validation method selected.


For a more detailed read on authentication methods versus supported delegation, refer to the following Technet article:


Using Windows (Active Directory) as an authentication method, we can see on the publishing rule that a wide selection of delegation methods to AD FS are possible. For completeness, I tested a variety of HTML forms logon configurations using various authentication delegation methods:



I didn’t have an RSA Authentication Manager/ACE server in my sandpit so was unable to test SecurID.

Logon in the majority of pre-authentication scenarios using Forms Logon worked fine. Basic authentication didn’t work because the AD FS farm uses the default local authentication type of Integrated. Shifting Basic to the top of the pile in the AD FS web.config might have meant that basic delegation would have worked for forms-based username/password scenarios, but I can’t think of any reason why I would use basic delegation when integrated authentication (Negotiate) was available Smile 

  <add name=”Integrated” page=”auth/integrated/” />
  <add name=”Forms” page=”FormsSignIn.aspx” />
  <add name=”TlsClient” page=”auth/sslclient/” />
  <add name=”Basic” page=”auth/basic/” />

HTTP Authentication

With HTTP Authentication configured on the TMG (AD FS) web listener , the user will receive a challenge prompt rather than a form when the Office 365 relying party redirects the user to AD FS through TMG.


TMG then processes those logon details entered in the dialogue. Depending on the client authentication method we have selected (Basic, Digest or Integrated), there are typically fewer supported authentication validation methods against which credentials can be evaluated.


From a delegation perspective, I used the HTTP Basic Authentication method on the TMG side.


Results-wise,  the majority of pre-authentication mechanisms involving TMG and various delegation scenarios worked. The same caveats concerning configuring web publishing rules, delegation etc. apply here.

Changing the client authentication method to HTTP Integrated Authentication on TMG were unsuccessful (so far).


HTTP Authentication with Digest was not tested.

SSL Client Certificate Authentication

SSL Client Certificate Authentication is an interesting approach as it logs the user on using an X509 certificate. I issued my client (in this case my domain user account) with a client certificate from a local issuing CA. If the incoming connection does not possess a client certificate, then TMG can be configured to fallback to HTTP authentication, e.g. HTTP Basic.

Once OWA had redirected the browser to TMG, a selection dialog requesting the client certificate for authentication was prompted.


After processing the client certificate,  logon was completed and access to OWA given. Note that Client Certificate Authentication only supports Kerberos Delegation as a delegation method. This approach deserves a little more attention and I’ll look at how this works in a future post. In particular, I’m curious how smart cards would work in this configuration and/or with the TLSClient option in the AD FS backend.

Web Publishing Rules

On the TMG side, two publishing rules are required.

  • a web publishing rule for web applications that will use forms-logon such as Sharepoint Online, Outlook Web App, Office  etc,
  • a web publishing rule for rich applications such as Outlook Anywhere, Lync Communicator Client and ActiveSync. that have special requirements.

Passive Clients: Outlook Web App / Sharepoint Online / MSOL Portal / Office 2010 (except Outlook)

Attached are the relevant screenshots for the  Office 365 web applications that will use TMG for pre-authentication (forms-based logon).


The To: field in the publishing rule is important. In the above example, the computer name field contains myserver.mydomain.local, referring to the FQDN of the test AD FS server. In a highly available AD FS scenario where the admin wishes to use Kerberos Constrained Delegation, this field will be blank and the load-balanced URL and service principal name (SPN) of the AD FS federation service will need to be configured with the AD FS application pool service account (via the Delegation tab in AD Users and Computers)


The public name of the TMG matches that of the AD FS federation service and an (A) record is registered to the public IP of the TMG FBA listener.


We also need to specify certain paths for TMG as pre-authentication scenarios require two publishing rules, with the public URL of the AD FS service being shared across the two rules.


With forms logon example I’m using Kerberos Constrained Delegation.  If Kerberos is to be used as the delegation method (recommended), ensure that the TMG computer account is trusted for delegation in AD Users and Computers, either for the AD FS server (single server scenario) or for the application pool (AD FS farm scenario).


We’re bridging SSL traffic as AD FS is HTTPS only.


The built-in All Authenticated Users group should be used in this rule, contrasting with the All Users group mentioned later in the Outlook Anywhere / EAS / Lync configuration section.


As the Office 365 wiki article mentions, AD FS 2.0 requires link translation to be disabled.


HTTP Filtering will also need to be modified to ensure that Verify normalization and Block high bit characters are disabled.

Let’s have a look at how TMG works for our non browser-based friends.

Active/MEX Clients: Outlook Anywhere / Lync 2010 Communicator / Exchange ActiveSync

As mentioned earlier, a second web publishing rule is required for certain “rich” clients. Active clients (Outlook/ActiveSync) and MEX clients in Microsoft speak, cannot be authenticated at the TMG. Instead,  we must adopt the reverse proxy approach for selective paths to the AD FS service endpoints  that can handle authentication of these clients.

The Active client uses a password proxy-based mechanism where the Office 365 Exchange service will authenticate against Exchange services on  behalf of the client using Basic Authentication.  We can see the WS-Trust service endpoint used on the AD FS service handler.


Conversely, the MEX client is a true federation web service (MEX = Metadata Exchange) that can perform authentication without the use of a “proxy”. This supports multiple forms of authentication. The metadata document for MEX clients is:


I’ve included the MEX above MEX path in the publishing rule for reference. It’s not mandatory. The actual service handler for authentication:


While this distinction is important in understanding how the client works, it makes no difference to TMG Smile  We use the same publishing rule, with anonymous access through TMG for Active/MEX clients and a connection proxied to AD FS where the actual authentication is processed. 

Configuring this second web publishing rule, be aware of the following key points:

  • All Users on the users tab is required rather than Authenticated Users  (TMG is not authenticating)
  • Publish only the relevant service endpoints for Active and MEX clients through this rule (and optionally federation metadata)
  • Delegation is set to none but the clients may authenticate directly
  • All the other TMG configuration setup points are as is

Again, I’ve attached screenshots and hopefully they’ll assist.


The paths field needs to contain the AD FS service endpoints that are used by the Outlook client (/adfs/services/trust/2005/usernamemixed/*) and Lync (/adfs/services/trust/2005/windowstransport/*). The Federation Metadata (/federationmetadata/2007-06/*) and MEX endpoints  (/adfs/services/trust/mex*) are optional (I use them for testing the publishing rule).


UPDATE: 05/09 – /adfs/services/trust/mex  needs to stay in the web publishing rules otherwise connection problems may arise.

The clients communicate directly with the AD FS endpoints, so no pre-authentication via TMG is possible.


With the absence of authentication on the listener for the above paths, the All Users user set should be used rather than the All Authenticated Users user set seen in the previous rule.


I always finish these posts thinking I’ve forgotten something Smile … I did find this Technet article a useful reference.


A word of caution, aside from the usual test test test waiver I throw in, it’s important that you think of the use cases under which you intend to deploy this type of configuration. If there are other relying parties that are in use behind AD FS 2.0 then it will serve you well to test integration-wise whether these are affected. TMG is not federation-aware and we animate the logon process to federation services through credential delegation. While this works well enough in this scenario, TMG is effectively becoming the Internet proxy for AD FS activity.

Share your experiences and have fun testing!