Category Archives: AD FS 2.0

AD FS 2.0 Claims Workflow with Issuers and Identity Providers

If you’re working with an AD FS farm with multiple claims providers, you may find it advantageous to generate “identifier” claims from those providers, so that in subsequent workflow in the claims pipeline, this can be used to build authorization logic around them and claims issued.

For example, let’s say we have Identity Providers FOO and BAR, using e-mail address as the inbound assertion/claim.

In the claims provider settings for each we’re going to validate the inbound request from the Foo IdP and the Bar IdP, based on the Issuer (Entity ID) and then insert a value into a claims description called

Foo Issuer / IdP

c:[Type == "", Issuer == "https://foo.mydomain/com/idp"]
=> issue(Type =, Value = "Foo IdP");

Bar Issuer / IdP

c:[Type == "", Issuer == "https://bar.theirdomain/com/idp"]
=> issue(Type =, Value = "Bar IdP");

If we then wish to insert further values  from an attribute store or  modify the claim later on , then this allows us to do so by calling upon the previously defined description, validating the value against our expected result and then issuing a new claim according to our requirements.

AD FS 2.0 and Multiple Claims Providers

Carrying on from where we left off in the last post, let’s look at some sample scenarios for implementing mixed authentication scenarios using a combination of AD FS and third-party identity providers. As usual, the assumption is that some sort of split-DNS in the federation service namespace is available.

In this example, AD FS will act as a hybrid Security Token Service (STS).  In addition to the out-of-the-box AD FS claims provider (IP-STS) role,  AD FS must act as a Relying Party Security Token Service (RP-STS) for two claims providers; the first where it trusts a SAML capable  two-factor authentication claims provider,  the second where it trusts a gateway portal that provides IdP-initiated sign-on.


In the above diagram, note the use of split DNS to differentiate between user experience inside and outside of the organization; namely, internal resolution of  the AD FS federation services endpoint points to the AD FS farm, whilst externally resolving to the AD FS Proxy(s).

Here are the sign-on use cases:

External SP-initiated Sign-On

  • Authentication: Two-Factor Authentication (OTP)
  • Customization: AD FS Proxy Configuration

A1  – Client accesses Web Application
A2  – Client is redirected to AD FS RP-STS for processing (A2-1)
A3  – Client is redirected to 2FA Provider for logon.
A4  – Following successful authentication at 2FA, client SAML assertion is passed to AD DS RP-STS for claims processing.
A5  – Client is redirected to Web Application (RP)

External IdP-initiated Sign-On

  • Authentication: (a) X509 Certificate + Username/Password (b) Grid Authentication
  • Customization: None (use of Smartlinks)

B1  – Client accesses IdP-capable Portal
B2  – From the portal,  client selects bookmarked Web Application (Smart Link)
B3  – Client is redirected to IdP to determine whether user has valid logon token for SSO
B4  – Client is redirected to AD FS RP-STS for claims processing
B5  – Client is redirected to web application (RP)

Internal RP/SP-initiated Sign-On

  • Authentication : Integrated Windows Authentication (Kerberos/NTLM)
  • Customization : AD FS Farm Configuration

C1  – Client accesses web application
C2  – Client is redirected to local AD FS IP-STS for processing. AD is set as default realm via customization (no realm selection allowed)
C3  – Integrated Windows Authentication (IWA) is performed at STS and claims are processed.
C4  – Client is redirected to web application (RP)


To make the above scenarios work, some minor customization is needed. The first barrier that we hit is home-realm discovery. If AD FS trusts two additional claims providers, besides Active Directory, how can authentication requests be routed correctly?

The answer rests partly with tweaking the AD FS proxy and farm configuration, the other in the way the Portal IdP calls AD FS. The customization on the AD FS side is relatively straightforward.

Let’s look  at each access scenario:

1. External SP-initated sign-on

In external scenarios that are initiated at the relying party or service provider, we want to use the strongest authentication possible, our 2FA provider. This is accomplished by editing the homerealmdiscovery.aspx.cs on farm members and inserting the following line on the Page_Init section.


2. External IdP-initiated sign-on

IdP-initiated sign-on envisages the use of access gateway solutions such as Juniper SA / Citrix CloudGateway. In these scenarios the user authenticates  to the gateway using the authentication mechanism required by the organization. Access to back-end applications is then performed using service provider initiated sign-on. Having already authenticated at the gateway, with the gateway configured as a claims provider on the AD FS side, the user is not prompted for credentials again and SSO to the application is  provided.

This scenario has some  interesting use cases. It allows the organization to use a different authentication method for accessing the gateway IdP than via the service provider initiated sign-on route (2fa). If the gateway employs some form of endpoint component checking and machine validation, then the organization may wish to adopt a more lenient access and user friendly authentication mechanism for managed/trusted devices (e.g. username/password).

Integration with AD FS is accomplished through using smart-links and selecting both the claims provider, via the home realm parameter (whr), and the relying party (wtrealm), in the query string, e.g.

NB: I’ve omitted Forefront UAG in this list as its relationship with AD FS is that of a relying party rather than an identity provider. Redirects using the whr= parameter to a stronger authentication provider than AD FS are possible.

3. Internal SP-initated sign-on

In this scenario, we want the relying party of SAML 2.0 service provider  to select the Active Directory authentication provider, rather than the other two trusted claims providers. This is accomplished by editing the homerealmdiscovery.aspx.cs on farm members and inserting  the following line on the Page_Init section.

SelectHomeRealm( PassiveIdentityProvidersDropDownList.SelectedItem.Value );

This will automatically select the highlighted item, the native provider always the first chosen.


In this post we’ve looked at supporting multiple claims providers for AD FS with the minimum of customization.  Changing the homerealmdiscovery.aspx.cs file on the  AD  FS farm ensured all internal authentication requests are  passed to Active Directory.  Similarly, externally, we specified the realm the AD FS proxy should use to select the 2FA provider. With home realm discovery now set both front and back-end servers, additional claims providers that support IdP-initiated sign-on may be used and invoked through smart links.

Juniper SA and AD FS 2.0 Integration – Part 2

The recent release of the new 7.2 firmware for the Juniper SA and a timely nudge from colleagues, proved the perfect tonic to continue the second post about integrating the Juniper Secure Access service and AD FS 2.0. 

In Part 1, the article emphasized the use of the Juniper gateway as a SAML Service Provider, with AD FS acting as the Identity Provider. Login at the Juniper, via service provider initiated (single) sign-on, would take place via the AD FS identity provider.  What I neglected to mention in the previous post (silly me), is where this sort of setup can be used, so here are a few examples:

  • as a rendition layer for Citrix Web Interface / StoreFront, for internal users  with Kerberos SSO enabled
  • as a landing page/portal for internal users with Kerberos SSO enabled
  • use of AD FS as an identity provider for single sign-on to MS applications
  • use of AD FS for performing claims augmentation

In this post, we’ll look at the Juniper as an identity provider. In this role role it offers a number of capabilities

  • as a policy enforcement point for managed and unmanaged clients of federation protocols
  • as an authentication bridge between SAML and other protocols for federated SSO scenarios, e.g. RADIUS 2FA/OTP
  • as an Identity Provider (gateway mode)
  • as an Identity Provider (peer mode)
  • as an Access Portal

On the AD FS 2.0 side, AD Federation Services occupies the role of  SAML Service Provider and Relying Party  Security Token Service (RP-STS) to Windows applications running behind it.

There are two operational modes for the Identity Provider, using SAML SSO, that are particularly interesting with the 7.2 release of the Secure Access gateway. These are:

  • Gateway Mode
  • Peer Mode

NB: SAML SSO scenarios described are using HTTP POST.

Gateway Mode

In Gateway Mode, access to web applications / SAML service providers and traffic flows are through the Juniper as a portal. In this mode, logon is initiated at the SA as the Identity Provider (IDP-initiated) and then access is provided to the web application.


In Gateway mode, if the application is on-premise, we can also place the relying party / web application directly behind the Juniper, with the application host [A] record resolving to the gateway address). This configuration is not described in this post.

Here’s a walk-thru of Gateway Mode logon.

1. The user access the URL for the SA gateway and is presented with a logon form.


2. From the portal landing page, the user selects the web application, e.g. Contoso Web, and the request is processed. The behaviour may change according to how the web application has been configured in the web resource profile.


3. The relying party web application redirects the request to AD FS . If a home discovery realm (HRD) cookie doesn’t exist, the user will be requested to do the realm selection in order to logon to their home realm. If smart links are being used for the bookmarked web application(s)  (see later in this post for a further explanation) , then HRD selection may be bypassed.  If smart links aren’t used and realm persistence is also disabled in the AD FS configuration, then the user will be prompted each time to select their home realm, otherwise a cookie of 30 days (default) will be written to disk, once authenticated.


4. The logon request will be submitted to the Identity Provider (IdP). If the user has a valid logon ticket then further logon processing will continue.

5. Once processed correctly, a SAML redirect back to the AD FS server is carried out for further logon and claims processing at the RP-STS.

6. Claims processing at the RP-STS is carried out and it and relying party claims are processed, the user obtains access to the web application.

Peer Mode

In Peer Mode, access to SAML service providers is not initiated via the Secure Access (SA) gateway.  The user accesses the resource directly and they are redirected to the Identity Provider for logon .


Normally speaking, the user is redirected from the service provider to the identity provider for sign-on.  In this configuration, however, behavior is different as AD FS is brokering authentication traffic for web applications that are WS-Federation based and acts an intermediary or Relying Party Security Token Service (RP-STS) between the application and the Juniper.

In Peer Mode, the user will begin RP or SP-initiated logon. Let’s look at the process of how a Windows Identity Foundation (WIF) application behind AD FS 2.0 would work:

1. The user accesses the Contoso web application URL

2. The user is redirected to the AD FS RP-STS

3. The home realms discovery process within AD FS service and user must select the Juniper SA claims provider.

4. The user is redirected to the Juniper Secure Access Service for logon processing


5. The user is presented with a logon form, within which their Juniper logon credentials must be entered. In the example above we’re doing a login against a primary authentication server (RADIUS using One-Time Passwords) and the local Active Directory as a secondary (uid/password).

6. Following a successful logon, the user is returned to the SAML 2.0 Service Provider, AD FS 2.0, for further processing of logon and claims.

7. The Relying party claims pipeline is processed and claims are harvested.

8. If authorized, the user has accessed to the web application.


URL Rewriting

On the Juniper configuration side, to allow successful processing of redirects to AD FS, we need to ensure that the URL of the AD FS is not rewritten at the Secure Access appliance. This is accomplished by the creation of a Web Resource Profile that includes an Autopolicy: Rewriting Options policy set to No rewriting.


We will use this facility later on when we create bookmarked applications and smart-link to our relying party web applications through the AD FS web resource profile.

Identity Provider Configuration

Let’s look at the Identity Provider (IdP) capability of the Secure Access Service. Under Configuration | SAML | Settings of the SA we need to configure our Identity Provider (IdP) with a Host FQDN for our SAML service.


(We’ll cover Pulse NC in a later post)

It is possible to set a different Host FQDN from the gateway or use the gateway name itself. Experience/testing so far suggests that both configurations work. For simplicity, I’ve aligned the FQDN for SAML with the Host FQDN for the Juniper gateway itself ( Once the FQDN are set, there’s also an option to update entity IDs that already exist with the new FQDN. While it won’t automatically update the metadata of partners, it is a handy way of automatically updating entity IDs on the Juniper side.

Next up, a menu option under Authentication | Signing-In | Sign-In SAML is new for 7.2. This provides two configuration tabs, one for the metadata provider and the other for the identity provider.


The Metadata provider Entity ID is automatically populated with the FQDN defined earlier.

On the Identity Provider tab, we configure the main settings for our IdP.

In the first area of the page, we define what bindings we intend on using, use of signing certificate, token decryption certificate etc.


In the second section, we define Service-Provider related settings for the Identity Provider


I want to spend a little time expanding on authentication scenarios and  what kind of logon scenarios are possible.  The Sign-in Policy value allows the administrator to select which policy is to be effective for the IdP. In the example above, I’ve elected to use */ which also happens to be the default sign-in policy for the gateway itself. However, I can customize the sign-in policy so that the IdP has its own authentication scheme independent of gateway mode settings.


In this test configuration, the default sign-on policy is using RADIUS (OTP) and AD authentication.  I’ve setup sign-In policies /idp1 and /idp2 just to illustrate that other sign-on options are available for choice.  Any service provider (including AD FS 2.0) configured with the Juniper as its Identity Provider will be redirected to the Juniper for sign-on, processing the /* policy.


On the IdP configuration screen above, I’ve highlighted the User Identity section. This is the SAML Name Identifier that the IdP will present to the service provider (SP) in the assertion. In this case, I’ve set the Subject Name Format to Other. This translates to NameID unspecified: urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified

On the AD FS 2.0 side (in Gateway and Peer configurations), the Juniper is configured as a claims provider. Using our mythical FQDN, let’s add a Claims Provider and enter the FQDN of the Juniper as the URL


Walk thru the remainder of the wizard, give the IdP a name, skips claims rules configuration and from within the properties of the claims provider, switch the secure hash algorithm to SHA-1. Using the NameID Unspecified example above, we can add the following custom claims rule:

c:[Type == "", Properties[""] == "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"]
=> issue(Type = "", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);

In the above rule we map NameID to Windows Account Name. On the Relying Party Contoso web application, we then pass thru Windows Account  Name to the claims-aware web application.

c:[Type == ""]
=> issue(claim = c);

Peer Service Provider Settings

Within the Identity Provider configuration screen within the Secure Access Service, we also define a list service providers  that make make use of the identity provider. This provides additional options concerning  the Service Provider configuration, and we can elect to override the default sign-on policy for the Identity Provider (IdP).


In overriding the default configuration, it is possible to assign a unique authentication scheme (sign-on policy) and assertion mapping  to a particular service provider. This is useful in scenarios where we wish to use a given authentication type for a particular service provider or web application.

Gateway Mode Configuration

For an IdP-initiated logon, users will typically logon to the FQDN for the gateway (e.g. and the default sign-on policy (/*) will execute.  Using the example described earlier in Peer mode, this would mean the user logs on to authentication realm A using RADIUS (OTP) plus AD password for logon. Since the identity provider is associated with this sign-on policy (/*), this means a valid SAML token is generated at the gateway during login.

To test this, create a Web Resource Profile for the web application, using a custom resource profile for a claims-aware test web application. Click on Show ALL autopolicy types and ensure that AutoPolicy:rewriting options are set to No rewriting for the URL of the web application


As can be seen in the above example, the web application I’ve created is for a  sample WIF application


Add the default Users role to the Selected Roles (or roles of your choice).


A bookmark is automatically created for the web resource profile.

Let’s logout of the administration interface and logon to the gateway (e.g.


The user must enter their user ID, AD password and PIN/OTP code.


In the web bookmarks, we see the Contoso Web application created earlier.

Clicking on the Contoso Web application will take us to the WIF application and initiate Steps 1-8 described in the Peer Mode Configuration, with the notable exception that Step 4 will now be removed as we already have a valid SAML token (and AD FS trusts the Juniper IdP as a Claims Provider).

All good, but when I hit the AD FS proxy, I hit that pesky home discovery dropdown and users must choose between AD FS or Juniper as their claims provider.


This process of having to select the home realm may be acceptable to your users, but if not, we need to look at alternatives that address this home realm issue.

Smart Links and IdP-Initiated Sign-On

Smart-links may be familiar to those who work with Office 365. They can be used in conjunction with applications such as Outlook Web App, to reduce hop count and speed up the login process.  A good article on them can be found here:

They potentially have a role to play with IdP-Initiated Sign-On scenarios with the Juniper where web application and single-sign on can be processed  with the minimum of fuss and limit user intervention in the sign-on process. More importantly, we can bypass home realm discovery for the Juniper IdP as a  claims provider. This can be accomplished by incorporating smart links into bookmarks.

For example, let’s say that the URL of AD FS 2.0 server is I can provide information in the query string about my relying party and the claims provider that needs to process the logon,  accomplished through the wtrealm (relying party) and whr (claims provider) values. This is particularly useful because the home realm discovery selection process in AD FS, where the user has to select the claims provider (e.g. AD or Juniper) can be confusing. By creating a web resource profile for  AD FS, we can exploit the use of smartlinks for bookmark / hot linking access web applications. Using the examples from earlier, I want to create a bookmark for my Contoso web application.

To accomplish this, on the Juniper, we can update the AD FS web resource profile and go to the bookmarks tab. We can then create a new bookmark, Contoso Web  (you’ll need to clean up the stale Contoso Web bookmark that was creating earlier in the post to avoid duplicates) and use the following URL:

This allows bypassing the home realm discovery dropdown and go directly to the IdP (Juniper) for sign-on.

Note that SP-initiated sign-on is still possible. If we do not wish to allow this or wish to handle it differently, there are a couple of further options. On the AD FS proxy instance we may choose to:

Home Realm Discovery Cookie Persistence

Under the <microsoft.identityServer.web> of the web.config on the AD FS proxy, we can disable persistence for the identity provider selection

<persistIdentityProviderInformation enabled="false”

This limits the validity of the identity/claims provider selection to the current browser session, meaning that home realm discovery and the provider selection dropdown will re-appear next time the user logs on.  If you’re not customizing home realm discovery on the AD FS proxy then it’s probably a good idea to set this value.

Note that this changes are limited to and scope-wise affect the AD FS proxy only.

Mixing IdP and SP-Initiated Sign-On

So far in the configuration examples, we’ve aligned IdP and SP-Initiated Sign-On, using the same authentication schemes. However, there are scenarios whereby this may not be desirable. In an IdP initiated sign-on scenario, for example, we may wish to use some sort of additional controls (e.g. host-checking) on the Secure Access gateway for clients. For managed clients, should the client pass host-check validation, we may wish to accept a weaker form of authentication (e.g. username and password)  at the gateway. Conversely, in peer mode, we may opt to continue to use two-factor authentication, irrespective of the client type, because we are bypassing host-checking functionality.  This flexibility is possible because we can shift the sign-on policies and override the default peer mode configuration for our service provider (AD FS). This allows us to take advantage of the security handshaking/enforcement capability of the SA platform to better effect, and, at the same time, allows things such as browser favorites/bookmarks to be preserved when accessing the service provider via SP initiated SSO, something that gateway-induced logon is often accused of breaking.

In either case, on the AD FS side, no change in the claims provider configuration is required because the switching is handled on the Juniper side, according to whether IdP or SP-initiated logon is taking place.



From an access scenario point-of-view, I’ve been looking at cases where both the Juniper and AD FS can operate in an IdP capability.  Internally, AD FS 2.0 can fill the gap and act as an internal identity provider to the Juniper (service provider) for claims-enabled processing and Kerberos SSO capability. Externally, the Juniper provides a broad access platform to operate from and, in turn, an identity provider to AD FS and indirectly relying party applications behind it. In a split DNS configuration this allows you to reap the benefits of both platforms (as per the diagram above).

As ever, test, test, test and break the back of that beast they call test before putting this sort of thing into production…

Have fun!

Juniper SA and AD FS 2.0 Integration – Part 1

Following up from the last post where we integrated OpenAM as an identity platform with Active Directory Federation Services (AD FS) 2.0, we’re going to flip roles and products this time. In this post, we’ll look at using a Juniper SA SSL-VPN gateway and plugging this into AD FS 2.0  Since Release 7.1R1 of the SA firmware, SAML 2.0 support has been available with the platform, with the SSL-VPN being deployable in the guise of a SAML Service Provider, Identity Provider or as a Policy Enforcement Point (PEP).

In Part One of this article, we’ll examine the role of the Juniper SA as a SAML 2.0 Service Provider (SP) and AD FS 2.0 as the SAML 2.0 Identity Provider (IP).


In Part 2we’ll reverse roles, using the Juniper as an Identity Provider (IdP) and AD FS 2.0 as the Service Provider (SP). Note that at the time of writing, the IdP capability in the 7.1Rx release, as I understand it, is not yet fully feature complete (The J-SA release used in this particular post is 7.1R6.0), with the full feature set available in the 7.2 release: expected Q2 2012.

Before we begin configuring our Juniper as a SAML 2.0 Service Provider, there are a number of steps that we need to perform on the Juniper side first. First, the prerequisites:

  • you have a running Juniper SA and AD FS 2.0 configuration ..
  • you have the necessary SSL certificates for your appliance/application (e.g., etc.) and installed them
  • you have a token signing certificate on the Juniper (e.g. self-signed certificate).
  • you have set time correctly on all devices are using a reliable time source (e.g. NTP)

Juniper SA Service Provider

Login to the Administrator Sign-In page of the Junos Pulse Secure Access Service.

From a federation standpoint, the SA will use the hostname, defined in System | Configuration | Networks, in entity IDs and names for SAML Endpoints, unless the appliance is part of a cluster, in which case the Cluster FQDN should be used.

Begin by creating a New Metadata Provider.  Go to System|Configuration|SAML and click the New Metadata Provider button.


Give the metadata provider a name, e.g. AD FS Identity Provider. The administrator is then given the option of uploading the metadata file from the identity provider or connecting to the remote IdP to obtain metadata. I elected to go with the file route, as trying to obtain the remote metadata produced errors (Extract metadata info failed : Metadata file does not have a valid saml entity). I assumed this was down to the federation metadata not being interpreted correctly as it contains WS-Trust metadata.

Download the federation metadata from your local AD FS 2.0 instance, e.g. and save the XML file to disk. The file needs sections of metadata WS-* protocols removed from it as well as Service Provider metadata. Remove the following sections.

  • ds:Signature
  • Role Descriptor
  • SPSSODescriptor

You should be left with a metadata file that looks something like this:


Upload the metadata file.


If the file is formatted correctly, it will be accepted when the configuration is saved.


In the Metadata Provider Verification Configuration section, we need to import the AD FS Token Signing Certificate. This certificate can be exported from the AD FS 2.0 Management snap-in by clicking on the AD FS 2.0|Service|Certificates section, double clicking on the certificate, highlighting the Details tab and then pressing the Copy to File button. Select Base64 in order to use a format supported by the Juniper, save to file and then upload the certificate on the Juniper configuration. In the example below Certificate Status Checking is also enabled.


Save the configuration.

From the main Junos Pulse Secure Access menu select Authentication|Auth Servers. From the dropdown selection choose SAML Server and click on the New Server button.


Give the new configuration a name, e.g. AD FS ..


Change the SAML Radio button to 2.0. As soon as this is done the service provider entity ID of the Juniper SA will be populated. The SA entity ID defined here for this SAML Server is unique to this SP-IDP pairing.


What I mean by this is, is that if I have two SAML servers in the Authentication Servers section on the Juniper, with each one pointing to a different Identity Provider, the SA Entity ID for each entry will change. For example, the service endpoint may be: for Service Provider A and Identity Provider A pairing for Service Provider B and Identity Provider B pairing.

Make a note of the endpoint/entity ID information at this point so we can cut and paste this into AD FS later.

In the next section we need to specify the remote partner that the SA will be paired to for this SAML Server entry. Since we’ve already defined AD FS 2.0  as a potential identity partner in System|Configuration|SAML, the entity ID and Single Sign On Service URL is automatically populated when we click on the Metadata radio button.


We can always configure the settings manually, but we’ll then need to enter SSO URLs and Entity IDs manually for AD FS.

Change the configuration mode to manual so that:

  • SSO Method is set to Post
  • the Signing Certificate can be specified.


I’ve also selected a Device Certificate for Signing the metadata.


A self-signed certificate can be created using OpenSSL, IIS7.x, Portecle (see previous posts) and then the .P12/.PFX file imported into Configuration|Certificates|Device Certificates section of the Juniper.


In the Service Provider Metadata settings section of the SAML Server there is an option to not Publish SA metadata. If this checkbox is enabled, AD FS 2.0 will not be able to connect to the SAML endpoint of the Juniper to service metadata. In which case the Service Provider metadata will need to be exported to file from the Juniper via the Download Metadata button and then import it manually into AD FS. In this post, we’re using published endpoints.


Click on Save Changes when you’ve finished entering the SAML Server information

As a final step, we can create a separate User Authentication Realm in the SA Configuration or associate the authentication server with the default Users realm. In the example below, a realm called AD FS IdP is created and the AD FS authentication (SAML) server specified.


On the default sign-in pages, the AD FS IdP realm has been chosen to use for logon.


AD FS 2.0 Identity Provider

In AD FS 2.0, we’ll need to create a Relying Party via Relying Party Trusts |  Add Relying Party Trust option.

Enter the URL of the Juniper SA endpoint (this is the SA Entity ID information from earlier)


Click on Next and give the Relying Party/Service Provider entry a name.


Click on Next


With the Relying Party information entered we can then enter the necessary claims rules to pass to the RP.


We’ll do this by:

  1. Creating a rule that extracts the e-mail address from AD
  2. Create a transform rule that transforms the incoming claim type: e-mail address to the Outgoing claim type: NameID with the Email format

Under Issuance Transform Rules, Click on the Add Rule button and select the Send LDAP Attributes as Claims template.

From the AD Attribute Store, we’re going to map the LDAP attribute E-Mail-Addresses to an outgoing claim of e-mail address. Click on Finish when done.


Add a second rule. Create a Transform an Incoming Claim rule and in this rule, we’ll map the incoming E-Mail Address claim to an outgoing claim type of Name ID using the format Email. *


Click Finish when done.

If you attempt to access the Juniper gateway, an get the following error:


Double-check that the claims values you’ve entered are set correctly.

If you get an error such as the following:


This may occur because the signature value on the relying party in AD FS is set to SHA-256 instead of SHA-1. Additionally, the error can occur because of issues with the relying party URI. When we have a look in the AD FS 2.0 admin log, we see an Event ID 184:

A token request was received for a relying party identified by the key ‘;, but the request could not be fulfilled because the key does not identify any known relying party trust.

This request failed.

User Action
If this key represents a URI for which a token should be issued, verify that its prefix matches the relying party trust that is configured in the AD FS configuration database.

Looking at the Service Provider metadata from the Juniper service through its URL (, the entity ID does not match the expected identifier reported in the event log error ( When setting up the Service Provider, the identifier is set to

Go into the relying party settings for the Juniper and on the Identifiers tab add an additional identifier for

Go to the Sign-In page configured


You should be able to logon successfully to the Juniper portal using your AD credentials.


As ever, test extensively before trying to put this into any production level environment.

* NameID mappings from the Juniper Service Provider metadata


Forgerock OpenAM 9.5.3 and AD FS 2.0 Integration – Part 3

In the final part of this configuration, we’ll look at setting up both AD FS and OpenAM for federation.

Before we start, let’s quickly recap on the access scenario.  OpenAM is an identity provider in another organization, with whom we are performing identity federation with. 


We intend to provide users  in Organization A with access to web resources in Organization B.  This is accomplished by setting up a federation trust via the local AD FS 2.0 instance in Organization B. Communication is across an untrusted network; consequently, all traffic between parties is encrypted using HTTPS.

In  Part 2, we created the identity provider on the OpenAM side and registered the remote AD FS SAML 2.0 service provider. A few tasks still remain though:

  • Finalize the OpenAM Identity Provider (IdP) Configuration
  • Configure the Remote AD FS 2.0 Service Provider (SP) in OpenAM
  • Configure the Identity (Claims) Provider in AD FS 2.0
  • Create test users in OpenAM
  • Configure a Windows Identity Foundation (WIF) test application
  • Configure AD FS 2.0 claims

Finalize the OpenAM Identity Provider (IdP) Configuration

There are a couple of changes that we need to make on the OpenAM IDP side. The IDP attribute mapper is used to specify which user attributes will be included in an assertion. The default attribute mapper (com.sun.identity.saml2.plugins.DefaultIDPAttributeMapper) retrieves attribute mappings from the (user) data store and sets that value as the attribute value of the specified SAMLV2 attribute.

Assertion Content

On this tab of the IdP configuration, we’re going to specifiy the NameID format that the Identity Provider will use and also the value mappings to map the Name ID to.  A number of NameID formats are supported by OpenAM, according to the SAML 2.0 protocol:


In this example, we’ve set the Name ID format on the IdP to accept both a NameID format of Transient or Unspecified. 


We want to create a mapping with the selected format to an attribute from the user’s profile. In our case, the defined Name ID format is used in the protocol, resulting in the profile attribute value being used as the NameID value for the user. In the example below we map the transient format to the user common name (cn) attribute and unspecified to the user ID (uid) attribute.


Note that the default NameID convention that AD FS will follow/submit as a SAML 2.0 Service Provider (unless told otherwise) is urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified . For more information, I’d suggest reading a great article from Adam Conkle on Technet :

Assertion Processing


In the Assertion Processing section of the IDP we map the configuration used by the attribute mapper. Using the convention of SAML v2-attribute=user-attribute convention, we map, in the above example, the user store userattribute of uid to the SAML attribute uid, the Common Name of the object and the mail address.


Configure the Remote AD FS 2.0 Service Provider (SP) in OpenAM

Under Entity Providers in OpenAM we need to configure settings for the SAML 2.0 Service Provider, AD FS 2.0.

Assertion Content

Under the Assertions Content tab, check that that the Assertions are Signed.


We’ll also inform the SAML 2.0 Service Provider of the NameID formats supported/expected. An identifier is used so that both parties can agree on third-party authentication of a user, using identifiers that are meaningful to both. Here we configure that the expected NameID format and the content presented by AD FS 2.0 is an identifier with transient semantics or one of unspecified.


We’ll set this also on the AD FS 2.0 claims provider shortly.

Assertion Processing

The assertion processing tab allows us to map attributes to submit to the relying party/Service Provider.  This provides us with an opportunity to map through our custom claims descriptions as SAML attributes to the corresponding attributes in the OpenAM user directory.


You may recall that we created these custom claims descriptions earlier in Part 2 and we can now use these descriptors to map against their OpenAM LDAP counterparts.

Configure the Identity (Claims) Provider in AD FS 2.0

In AD FS 2.0 we need to register our OpenAM SAML 2.0 Identity Provider. Create a Claims Provider and point AD FS to the online OpenAM metadata address. In a lab/testing environment, using online metadata publishing is fine. Across untrusted networks, and in production environments, organizations may be reluctant to publish metadata online, in which case file exchange is an option.


We’re not using realms within OpenAM, so the default URL for the IdP under the root realm is used. Using the naming example of  from our previous posts, the IdP service endpoint, therefore, would be:


Click past the skipped federation metadata warning.


Give your Claims Provider a name. ***


Validate that the selected URL and federation partner information is correct.


You can add the claims now (detailed below) for the IdP or uncheck the Open Edit Claim Rules dialog as I’ve done here, adding the claims later. I’ve chosen here to adjust the claims provider properties first before setting up the claims rules, but it’s ultimately down to personal preference…


On the IdP properties, click on the Advanced tab and change the hashing algorithm from SHA-256 to SHA-1 and click on Apply / OK when done.

*** Note that this will be the name used on the Home Realm Discovery page and the user will need to select between the local AD FS 2.0 realm or the OpenAM IdP realm (assuming that local AD FS authentication hasn’t been disabled (a la

Configure a Windows Identity Foundation (WIF) test application

This is a well documented process by Microsoft, so I’m not going to spend much time on this section Smile 

To get your WIF application running I’d suggest reading this article

Alternatively, you can use a Sharepoint 2010 Claims web part (if you happen to have Sharepoint floating around)… For the remainder of this document, I’m assuming that you’ve gone the WIF route and the assumption therefore is that this will be the relying party.

Here’s a screenshot of the FEDUTIL tool and setting up the Application URI.

Hint: Look at using the ClaimsAwareWebApplicationWithManagedSTS


Once you’ve configured your Claims aware web application via FEDUTIL, it’s time to configure the Relying Party (RP) on the AD FS 2.0 side. Now this could be another SAML 2.0 Service Provider, but in the .NET world (at the moment) this is not released yet (CTP). So, in the above example, we’re using a relying party that has a WS-Federation Passive endpoint of with metadata at:

Create Test User in OpenAM

Let’’s assume that we’re using the built-in datastore as the default authentication store for users.


If we go into Access Control, select the Top Level Realm and then click on Authentication, we’ll see that ldapservice (Datastore) is the organizational authentication scheme for our users (note there is a separate authentication scheme for realm admins) , so we’ll need to create a user with a password. From the Top Level Realm, select Access Control | Top Level Realm | Subjects | New


Fill out the mandatory fields (denoted by an asterisk) for the user. The ID field is the logon ID used for subsequent logon.


One item to check is the User Profile in the Authentication tab of the Top Level Realm. Click on All Core Settings and check that the User Profile is set to Required. I notice to my cost, that if this is set to Dynamic or Ignored then OpenAM will not pass any user SAML attributes to the AD FS service provider apart from NameID. I’ll be honest… I don’t know whether this is my testing, a bug or is by design, but it certainly proved to be a quirky stumbing block in my test setup Smile


Configure AD FS 2.0 Claims

Back in AD FS world, we’ll need to setup claims on both the Claims Provider (OpenAM IdP) and Relying Party (WIF) side of things.

Claims Provider


In Claims Provider Trusts, right click on the OpenAM IdP and select Edit Claim Rules.

We’re going to create the following rules as seen in the screenshot below.


If you’ve followed the previous articles, then you should have two custom claims descriptions already for UID and Mail, so it should be relatively easy to creat the mappings thru the GUI using the above claims or below using custom rules based on:

  • NameID set to Transient (which is the Common Name attribute from OpenAM)
  • Pass thru Custom Claims Description for AM UID (which is the uid attribute from OpenAM)
  • Pass thru Custom Claims Description for AM UID (which is the mail attribute)

The transient rule looks like this:


[Pass thru Incoming Claim Type of Name ID and Incoming Name Format Transient Identifier – Pass All Claims Values]

c:[Type == "", Properties[""] == "urn:oasis:names:tc:SAML:2.0:nameid-format:transient"]
=> issue(claim = c);

[Pass thru Incoming Custom Claim for UID – Pass All Claim Values]

c:[Type == ""]
=> issue(claim = c);

[Pass thru Incoming Custom Claim for Mail – Pass All Claim Value]

c:[Type == ""]
=> issue(claim = c);

Relying Party

In the Relying Party Trust section within AD FS, we also need to create some pass thru rules on our WIF web application. We can use the same rules defined above. Follow the same process, albeit this time right-clicking on the relying party and editing the claims rules on the RP. I’ve also added a transform rule in testing to transform the x-am-mail claim to UPN (see the screenshot below). It’s not required, but is merely used to demonstrate how incoming values can be also be transformed/passed to other attributes.

[Transform Custom Claim for Mail – UPN]

c:[Type == ""]
=> issue(Type = "", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);


With all the parts coming together, here is the abridged version of the logon process, starting at the relying party.

  1. User in Organization A accesses (Relying Party) in Organization B.
  2. User does not have a valid authentication cookie and so is redirected to Organization A (FP-STS) . for logon
  3. AD FS performs Home Realm Discovery
  4. User selects their Organization A home realm (OpenAM IdP) for logon
  5. User is redirected to Organization A
  6. User logs on to OpenAM realm with local user account and is authenticated
  7. User is redirected back to AD FS (FP-STS) for further processing
    • AD FS processes (Claims) Acceptance Transform Rules on Claims Provider
    • AD FS processes (Claims) Acceptance Transform Rules on Relying Party
  8. User is redirected to relying party web application

I’m simplifying the logon process somewhat to give a more concise view of events, not to mention saving me typing…  It’s important to note that since this is a passive web federation scenario, the browser and user are effectively bounced around from RP to FP-STS/SP to IdP and back during the logon process.

In the claims-aware web application, the resultant claims should be now visible.


That’s it on the configuration side of things! If you come unstuck, just post comments and I’ll try and get back to you ASAP. I hope this helps those who are looking at integrating OpenAM with AD FS. Meanwhile, as ever, this is all done in the hygienic and wonderful user free environment of a test lab, so don’t go all production grade on me without beating this first with the testing stick……

Expiring AD FS 2.0 Token Signing Certificates

O365 OrgID Error





The above error surfaced recently when logging in at an O365 tenant. While the message itself is a fairly generic one, and can be attributed to a number of possible causes, in this case the organization (using identity federation) had an expired token signing certificate in their AD FS 2.0 configuration.  They had automatic certificate rollover disabled on their AD FS farm so that AD FS could not rollover the configuration with new certificates. For some organizations, with web applications such as Sharepoint 2010, this may be a desirable configuration, with the process of certificate rollover being manually administered, rather than AD FS silently and automatically handling it.

Hindsight is a wonderful thing in this case and paying heed to warning messages about expiring certificates in the event logs in the preceding weeks may well avert some nasty surprises.  However, calamities happen and should this problem evade your radar in the future, looking at what recovery options are available may be useful.

When the token signing certificate is due to expire (2-3 weeks before),  the AD FS 2.0 Admin Event Log will begin to blurt out warning messages (Event ID:385).

AD FS 2.0 detected that one or more certificates in AD FS configuration database need to be updated manually because they are expired, or will expire soon. See additional details for more information

Additional Details:
Token-signing certificate with thumbprint ‘4E8F5194309E48EDB7EF8440B47082FB3D1594B6’ is set to expire on 12/30/2011 1:00:00 AM.

Should the warnings be ignored, and the certificate has expired, the Event ID 385 warning changes to:

Token-signing certificate with thumbprint ‘4E8F5194309E48EDB7EF8440B47082FB3D1594B6’ expired on 12/30/2011 1:00:00 AM.

At this point the AD FS wheels are wobbling and an Event ID 381 may start popping up:

An error occurred during an attempt to build the certificate chain for configuration certificate identified by thumbprint ‘4E8F5194309E48EDB7EF8440B47082FB3D1594B6’. Possible causes are that the certificate has been revoked or certificate is not within its validity period.
The following errors occurred while building the certificate chain: 
MSIS2013: A required certificate is not within its validity period when verifying against the current system clock. 

User Action:
Ensure that the certificate is valid and has not been revoked or expired.

This may be followed closely behind by Event ID 102:

There was an error in enabling endpoints of Federation Service. Fix configuration errors using PowerShell cmdlets and restart the Federation Service.

Additional Data
Exception details:
System.ArgumentNullException: Value cannot be null.
Parameter name: certificate
   at System.IdentityModel.Tokens.X509SecurityToken..ctor(X509Certificate2 certificate, String id, Boolean clone, Boolean disposable)
   at System.IdentityModel.Tokens.X509SecurityToken..ctor(X509Certificate2 certificate)
   at Microsoft.IdentityServer.Service.Configuration.MSISSecurityTokenServiceConfiguration.Create(Boolean forSaml)
   at Microsoft.IdentityServer.Service.Policy.PolicyServer.Service.ProxyPolicyServiceHost.ConfigureWIF()
   at Microsoft.IdentityServer.Service.SecurityTokenService.MSISConfigurableServiceHost.Configure()
   at Microsoft.IdentityServer.Service.Policy.PolicyServer.Service.ProxyPolicyServiceHost.Create()
   at Microsoft.IdentityServer.Service.SecurityTokenService.STSService.StartProxyPolicyStoreService(ServiceHostManager serviceHostManager)
   at Microsoft.IdentityServer.Service.SecurityTokenService.STSService.OnStartInternal(Boolean requestAdditionalTime)

As the original title graphic intimated, federated logon at this point is not working.

Depending on your AD FS configuration you may have automatic certificate rollover enabled.  This can be checked via Get-ADFSProperties

In this particular case it was set to:


This meant that that once the signing token certificate expired, a replacement was not automatically assigned. In this case a new certificate needs to be provisioned manually. Of course, you could also elect to activate the autocertificaterollover function. 

Preparing to make the change

Whether you elect to go the manual or the automatic route, in either case, you’ll still have some investigation to do. Before nuking your AD FS configuration, consider the impact of assigning / replacing the token signing/decryption certificates in AD FS.

  • Who are the claims providers and relying parties involved?
  • Can they process metadata?
  • What application specific changes are required to support the certificate change?

Of course, if you’re facing a production federation service outage then there’s likely to be other pressures to consider as well Smile, but try and determine which relying parties or claims providers will be able to process the details of the change (automatically) via updated federation metadata exchange or not. In the case of the latter, some sort of manual intervention may be required. Applications, for example, such as Office 365 and Sharepoint 2010 will need to be informed of this change.

Option 1: Manual Rollover

Via this method, you can generate your own certs using the Self-SSL feature built into IIS 7.x, or use Keytool, OpenSSL etc.. Alternatively, you may have your own  internal PKI. I don’t see any benefit in using a third-party certificate for token signing encryption/decryption. No doubt someone out there may have a valid reason for doing so, but self-signed certs / internal PKI serve the purpose in this scenario. With IIS, under Service Certificates, I opted to create a self-signed certificate


Give the certificate a recognizable “friendly” name and IIS creates the certificate.


If you’ve elected to use an internal PKI, then there may be a certificate chain involved. Claims providers or relying parties will require a copy of the corresponding chain (.P7B) file or individual CA (.cer)  files. The AD FS service account needs to be able to manage the private key of the certificate. This can be accomplished through the MMC Certificates|Computer snap-in. Right-click over the certificate:


Select Manage Private Keys and give the AD FS service account Full Control to the certificate. Now you need to prepare to make the change.

Option 2: Automatic Rollover

To configure automatic rollover:

Set-ADFSProperties -AutoCertificateRollover $true

To trigger an automatic replacement of the existing certificates  the following needs to be entered.

Update-AdfsCertificate –Urgent

BEWARE! By selecting the urgent option you are voluntarily hitting the self-destruct button and hosing any working configuration. Relying parties and claims providers will not have refreshed their federation metadata with you and at this stage will be working against stale metadata. It is best, therefore, to carry out these activities out out-of-hours and co-ordinate with the parties concerned refreshing of metadata. As I discuss later in this post, some parties need manual intervention.


With the automatic rollover option selected, any existing token signing / decrypting certificates will be deprecated and replaced with a fresh one years’ validity alternate.

Exporting certificates to file


Once you’ve added a new token-signing certificate (manual route) or run the Powershell script to set automatic rollover you’ll need to export the certificate to file. Double click on the AD FS Token Signing certificate, click on the Details tab and then select Copy to File. The export format varies according to the target system. Windows systems will generally accept DER and Base64. If it’s a Java web container / application server then use Base64. Ditto with Linux/Unix…

In the examples below, I’ve used Office 365 and Sharepoint 2010 as two examples of web applications that need manual intervention.

Office 365 – MSOL

To rectify the problem of a token signing certificate change in Office 365, we need to update Online Services with new information concerning our certificate. As covered in the post here: AD FS 2.0 now supports multiple UPN suffixes, so you’ll need to run this per UPN domain to update the respective information in Powershell.

Connect-MSOLService -cred $cred
Update-MsolFederatedDomain -DomainName -SupportMultipleDomain
Update-MsolFederatedDomain -DomainName -SupportMultipleDomain

Substitute your own UPN suffixes with the examples above and the effect should be instantaneous and logon to MSOL possible once the update has been carried out. Run this through your test environment first to make sure you get the desired effect.

Sharepoint 2010


Sharepoint throws an error when the token signing certificate is invalid when accessing the Sharepoint Security Token Service at

An operation failed because the following certificate has validation errors:\n\nSubject Name: CN=ADFS Signing –\nIssuer Name: CN=ADFS Signing –\nThumbprint: 611CBD4AE55FE2F2C3F0648C16C57A231AA51491\n\nErrors:\n\n The root of the certificate chain is not a trusted root authority..

In the above example, I triggered automatic certificate rollover on the AD FS side without notifying Sharepoint of the change and this threw an error (screenshot). To rectify this we’ll need to export the token signing certificate from AD FS instance and import it into Sharepoint 2010.  We’ll then assign the register and assign the replacement certificate. This occurs at two levels:

  1. Registering the certificate as a root authority. The certificate is self-signed and Sharepoint stores its own certificate trust hierarchy, outside of normal Windows conventions.  This means that the self-signed certificate, effectively  a root certificate, needs to be assigned as a Trusted Root Authority.
  2. Updating the existing trusted token issuer. This means replacing the existing trusted identity token issuer value for the signing certificate with the new one.

The following Powershell script shows an example configuration.

$certPath = "C:\temp\ADFS Token.cer"
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("$certPath")

$root = New-SPTrustedRootAuthority "AD FS 2.0 STS" -Certificate $cert
$upd = Set-SPTrustedIdentityTokenIssuer -Identity "ENTER THE NAME OF YOUR EXISTING ADFS INSTANCE " -ImportTrustCertificate $cert

Your own configuration may vary and you’ll need to ensure that the identity to be updated is set correctly.

As ever TEST, TEST, TEST!!!!…..

Forgerock OpenAM 9.5.3 and AD FS 2.0 Integration – Part 2

It’s been a couple of months since Part 1, so time to put pen to paper. I’ll post Part 3 up in the next few days. Sorry for those who’ve had to wait…

In the previous OpenAM/AD FS  post we covered the installation of OpenAM . In this post we’ll concentrate on preparing the platforms for identity federation. One thing I won’t be doing is covering the actual installation of AD FS 2.0. That’s well documented elsewhere. I’ll assume that you have a working AD FS 2.0 configuration.

We’ll begin on the AD FS 2.0 side by creating two custom claims descriptions. If you read the previous post concerning AD FS 2.0 Rollup 1: Client Access Policy Support for O365, then you may recognize this process.  From the AD FS 2.0 MMC snapin and service panel, I’ve create two custom claims descriptions:


It’s important to stress that the URLs are not real ones. They are there for reference and administrative purposes and:

  • they are to aid managing our rulesets and are used in the federation metadata exchange between OpenAM and AD FS 2.0.

  • using short attribute names for claims type descriptions, e.g. mail, uid etc.,  while possible, can causes headaches, particular with multiple claims providers, as we’re dealing with common attributes / descriptions. A provider-specific namespace helps avoid this confusion;

  • we want to create a unique association between the entities concerned: OpenAM and AD FS 2.0…

We’ll reference these claim descriptions on the OpenAM side later in the setup process. We create them now so that when we register the remote service provider in OpenAM, the relevant metadata is there.

Let’s return to OpenAM …… for federation purposes, we will need to configure a signing key  to be used by OpenAM . This key is then used to sign metadata. This can be quite a confusing process, so as ever, test test… OpenAM comes with a default test (signing) key that is common to all installations and, as a result, use of this test key should not be considered secure. We’ll create a new test signing certificate and import this into the Java keystore that OpenAM uses.

Note: This is a different Java keystore (JKS) to the one referred in the previous article and used by the web container, Tomcat.

Login to the OpenAM console as amadmin, click on the Configuration tab, then on Servers and Sites and then click on the OpenAM server URL. On the next screen, select the Security tab and scroll down


Based on settings from Part 1, the %BASE_DIR% variable that we set in the graphic above alludes to C:/OpenAM. The current certificate alias is set to test, meaning that the server is currently using the default test certificate for token signing. We need to change this. First we’ll need to turn off inheritance so that we can manually change the certificate alias value. This is accomplished by clicking on the Inheritance Settings  button in the top left corner.


On the subsequent screen, select the Uncheck the Certificate Alias option.


This now enables us to change the Certificate Alias to be used for Token signing from the Test certificate to something else.


In this example, we’ll switch the alias and call it openam token signing cert..


OpenAM needs to reference keys and certificates for the hosted server instance. This includes a key pair for the host running OpenAM in a JKS format. Under the JDK in the BIN folder is the Java keytool file. Using this tool we’ll now create a new Java Keystore (JKS) to replace the default one.


The certificate properties (Name, OU, City, State, Postcode/ZIP, X500 code etc.) will be asked for when the tool runs. Note that we can also create a keystore in tools such as Portecle or Keytool UI if we so choose. Whichever route you select, both will require the keystore to be protected with a password to access the store and also a password for individual keys. These passwords must be encoded with OpenAM, and the information therein stored in the files .keypass and .storepass (these files live in the OpenAM configuration directory).

We can encode the password a couple of ways.

Option 1: Encoding Servlet

There’s an encoding servlet at  as well as command-line tools. This encoding servlet allows for a quick and simple way to encode a password for the .keypass and .storepass files. For example, let’s use the example password of fubarfubar


Click on the Encode button.


Cut and paste the encrypted password string from the webpage into a text file, e.g. MYPASSWORD.TXT. If you’d prefer not to use the ENCODE.JSP option, read on….

Option 2 : OpenAM SSO Admin Tools

Download the OpenAM tools from the ForgeRock website and extract them into a folder (e.g. C:\Tools).

NOTE: These tools can be used after we first set our JAVA_HOME environment variable.


In the example below, SETUP is being run from the tools folder, and when queried for I’ve provided the configuration path information for the OpenAM server, Debug and Log directories.


Once the tools are installed, I’d recommend adding the BIN folder to the PATH environment variable. It’s useful to be able to call them from other locations when performing administration via the command-line.


With the tools setup we can also call the ampassword utility to generate an encoded sequence. Using the same example as the GUI, I first created a file with the password fubarfubar in it and then call the encode parameter.

C:\temp>type test.txt
C:\temp>ampassword -e test.txt

The encoded text can be cut and pasted into notepad and then saved as .keypass and .storepass. in the OpenAM configuration folder.

  1. Drop to the OpenAM configuration folder (C:\OpenAM\OpenAM)
  2. Create a folder called BACKUP and copy the original .keypass and .storepass and  keystore.jks into this BACKUP folder.
  3. Copy the JKS file (keystore.jks) created in C:\TEMP earlier to the configuration folder, overwriting the existing JKS
  4. Copy MYPASSWORD.TXT to .keypass and .storepass overwriting the default files.
  5. Restart the Apache Tomcat service.

We can validate whether the signing key is defined correctly by selecting the Create Hosted Identity Provider option on the Common Tasks screen.


On the metadata screen, select the Signing Key dropdown box and if the token signing cert appears (no errors), we’re good…..


Once we have a proper token signing certificate, we can start setting up OpenAM as an Identity Provider (IdP). OpenAM and AD FS can be linked up in a couple of ways via:

  • SAML 2.0

  • WS-Federation

In this example, we’ll use OpenAM as a SAML 2 Identity Provider (IdP) and AD FS 2.0 as a SAML 2.0 Service Provider (SP). From the metadata screen previously, let’s fill in the necessary details:


We need to create a Circle of Trust (COT). A circle of trust is a collection of Identity and Service Providers within OpenAM that engage in identity federation.  It becomes an authentication domain shared between partners, typically one or more service providers and an identity provider, where the parties can communicate in a secure and seamless manner. We can create a circle of trust (COT) manually, or, as in the above example,  during the IdP creation process.

I’ve selected the signing key from earlier, entered the URL for my Identity Provider (IdP) and created a new circle of trust (COT) called ADFS2. In this case, we will have a COT between a SAML 2.0 Identity Provider (OpenAM) and a SAML 2.0 Service Provider (AD FS 2.0).


Click on the Register a Remote Server Provider link.


On the ensuing screen, change the radio button to File when asked for where the metadata file resides. To make the metadata from AD FS understandable to OpenAM we need to trim the information provided by its federation service, so that we retain only the entity identity and descriptor information within the federation metadata XML that is relevant to SAML 2.0 Service Provider (SP) descriptors.  In other words, anything with WS-Trust material in needs to go….

To do this, obtain a copy of the federation metadata file by pointing to the AD FS metadata, e.g:

  1. Download the XML document and save it to file on your desktop / workspace.
  2. Create a copy of the file (let’s call it SPDATA.XML)
  3. Open SPDATA.XML with an XML Editor (or Notepad if you’re feeling brave)
  4. Remove the section beginning <ds:Signature .. ending at </RoleDescriptor>, i.e. all XML tags between EntityDescriptorID and SPSSODescriptor.
  5. Keep the <SPSSODescriptor> </SPSSODescriptor> section. 
  6. Remove  the <IDPSSODescriptor> </IDPSSODescriptor> section.
  7. Keep the remainder of the remaining metadata to end-of-file.
  8. Save the SPDATA.XML file
  9. Check that the file is not corrupted by opening the XML file via IE.

The SPDATA.XML file can now be uploaded to OpenAM


Click the Upload button to upload the file.


The file should then upload successfully, otherwise it’s likely a formatting error in the XML file. in which case, try opening it in a browser and see whether you get an error about a corrupt / incorrectly formatted XML file.  Repeat and rinse …….. Smile

Next up, the OpenAM Identity Provider configuration and AD FS 2.0 Service Provider …..

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:

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:

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:

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


Claim type:

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 == "", 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).

AD FS 2.0 Rollup I : Multiple Issuer Support

As you may already know, update Rollup 1 for AD FS 2.0 is available. Big news if you’re an Office 365 user:

It’s all described here:

What is not obvious from the above document is how one actually goes about setting up multiple domains. To work that one out you’ll need to read this post.

In short, plan for this! The relying party for the Microsoft Online Identity Platform will need to be deleted, the federation trust for the existing AD FS realm updated with the –SupportMultipleDomain option, thus allowing support for (further) issuer/domain suffixes.

Thanks to Ross Adams from MSFT for the tip… this one had me scratching my head Smile

ForgeRock OpenAM 9.5.3 and AD FS 2.0 Integration : Part 1

OpenAM, previously OpenSSO, is a commercial grade open source offering from Forgerock ( It provides conventional access management capability using agents, as well as federation and web services single sign-on (SSO). In the coming posts we’ll look at integrating OpenAM with Active Directory Federation Services using federated identities with SAML 2.0. Specifically, we’ll look at using OpenAM as a SAML 2.0 Identity Provider (IdP) and AD FS 2.0 as a SAML 2.0 Service Provider (SP). This is a fairly common configuration for organizations that have already deployed OpenAM and now need to integrate their access management product with the Microsoft claims aware application landscape.

OpenAM is a Java-based web archive (WAR) application, so we’ll need to install both a Java SDK and a Java servlet web container on which it can run. I’m using the Oracle 1.6.0.x JDK for Windows (x64) and Apache Tomcat 6.0.x  as my web container in this example, although platforms such as Glassfish, JBoss, Websphere, Weblogic are eminently useable.

For expediency, Windows is being used here as the testing platform.

Apache Tomcat 6.0.x Configuration

This is a quick walk-thru and (relatively) barebones explanation of the Tomcat server configuration.  If you’re unfamiliar with Tomcat then have a look at the Apache site wiki (

In this example, the x64 version of Tomcat 6.x is being installed under Windows 2008 R2. Once installation is complete, run the service.bat file from the BIN folder to install Tomcat as a service.

Usage: service.bat install/remove [service_name]

C:\apache-tomcat-6.0.xx\bin>service install
Installing the service ‘Tomcat6’ …
Using CATALINA_HOME:    “C:\apache-tomcat-6.0.xx”
Using CATALINA_BASE:    “C:\apache-tomcat-6.0.xx”
Using JAVA_HOME:        “”
Using JVM:              “auto”
The service ‘Tomcat6’ has been installed.

One thing that does need modifying is the amount of memory available to the Java Heap space and the PermGen space. Normally this is done through the CATALINA.SH file. However,  since we’re running Tomcat under Windows as a service, this can be changed using the TOMCAT6.EXE  file in the BIN folder.

tomcat6 //US//Tomcat6 –JvmMx 1256 ++JvmOptions=”-XX:MaxPermSize=256m”

The label //US//Tomcat6 updates the existing server parameter. Here we’re increasing the maximum heap size to 1256.  Since AD FS 2.0 is involved, the Tomcat web container also needs to be using SSL. We’ll need to customize the SERVER.XML within Tomcat to support the use of HTTPS with a certificate. In the example below we’re using a wildcard certificate (keyAlias)

<Connector port=”443″
sslProtocol=”TLS” />

The keystorefile directive uses Unix paths, although drive letter literals are accepted.  Again, this can be a bit overwhelming at first so a read of the Tomcat SSL Configuration HOW-TO may be advised if SSL/Tomcat is something new.

Tomcat, in this configuration, is using a Java keystore (JKS) to store digital certificates, within which will reside our wildcard certificate for web server authentication. Some form of keytool utility to import the certificate with private key (PKCS#12 file) is required. There are various Java keytool progs out there. Here we’re using Portecle, available off SourceForge:

Portecle can also be used to import intermediate certificates into the core Java certificate store, should your third-party certificate provider have an extended certificate chain. This file can be found under the Java program path /jre/lib/security/cacerts

OpenAM Configuration

The latest OpenAM files are available from the Forgerock site. The OpenAM ZIP file contains a deployable-war directory containing an opensso.war file. This file can be dropped under the WEBAPPS folder of the Tomcat application server. Here we’ve renamed the file to openam.war in the process of copying it over as this becomes the Server URI path for logon. Restarting the Tomcat services will expand and deploy the WAR file. 

OpenAM comes with an embedded LDAP server which can be used simultaneously for storing identities and also as a configure store/repository.  This is a Java-based LDAPv3 compliant open-source directory, formerly known as OpenDS, and delivered by Forgerock under the OpenDJ moniker. We’ll use an embedded configuration store in this example.

1. Create a host record (A) record in your local DNS for the name of the OpenAM server or create a loopback entry in your hosts file under system32/drivers/etc, e.g.

2. Point your browser to The configuration options wizard will begin. Select Create New Configuration


3. Enter a password for the default administrator user (amAdmin). is the default administrative/super user used for administration of OpenAM.


4. Enter a server URL for OpenAM (e.g. and cookie domain (


5. Use the embedded (OpenAM) configuration data store.


6. Select OpenAM as the User Data Store (this is a development/test environment). In a production environment, one of the other LDAP user stores should be used.


7. This is a development/test environment, it’s not behind a load-balancer, hence the No selection.


8. Enter a password to be used by OpenAM Policy Agents and click Next.


9. Review the configuration summary and click Create Configuration when ready.


10. OpenAM configuration should now begin.


11. Once setup is complete, reboot the server.

12. Launch a browser and point it the OpenAM instance, e.g. Login with the amadmin account and the password chosen earlier.


13. The common tasks wizard screen will appear.


In the next article: configuring OpenAM and preparing it for identity federation is the subject.

Good luck!!


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 or directly via 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. 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!


Just Another Relying Party: Federation with Forefront UAG 2010 SP1 and Office 365

I wrote in previous posts about some of the more unusual access scenarios involving Office 365 and UAG with AD FS 2.0.  In doing so I’d not gone through and covered setting up a basic  federated trunk scenario using UAG, AD FS 2.0 and Office 365. With  this post I’ll attempt to remedy that.

In a normal O365 federated identity setup, UAG would be configured as a relying party to provide single sign-on to web applications at the edge.  As a relying party UAG then processes security tokens issued by the AD FS security token service. For UAG admins, there is a key difference in the way UAG works with AD FS compared to other authentication services. Normally speaking, it is the UAG that is directly responsible for front-end authentication. Here, however, UAG adopts the role of an AD FS proxy and uses the AD FS infrastructure to provide the authentication and process the requisite claims required for single sign on to back end web applications. There is no authentication taking place on the UAG. This is borne out when we look at the web application configuration the for the trunk, with UAG configured like any other claims-aware application or relying party.

On the AD FS web application itself, we must allow unauthenticated access to the AD FS web server / farm


Additional authentication services cannot be used on the same trunk. Also, unlike the AD FS proxy, UAG does not provide a forms-based logon page. Instead it uses challenge/response. So a user who is accessing O365 from a non-domain joined machine can expect to an NTLM challenge response.


Because UAG does not process AD FS authentication, the request is proxied to the AD FS service in the backend using the Integrated Windows Authentication (IWA) handler. This can be seen in the redirect to……

Connecting to an Office 365 web resource from the Internet with a domain joined machine on the Internet,  users can logon via IWA and get the single sign-on experience to the O365 resource when the STS is in the Local Intranet zone of the browser. Looking at Fiddler, one can see a  kerberos service ticket in the negotiate header.

No Proxy-Authorization Header is present.

Authorization Header (Negotiate) appears to contain a Kerberos ticket:
60 82 06 38 06 06 2B 06 01 05 05 02 A0 82 06 2C  `‚.8..+….. ‚.,
30 82 06 28 A0 30 30 2E 06 09 2A 86 48 82 F7 12  0‚.( 00…*†H‚÷.
01 02 02 06 09 2A 86 48 86 F7 12 01 02 02 06 0A  …..*†H†÷……

From a non-domain joined machine, the fact that we’re doing IWA and and Negotiate means that it falls-back to NTLM (and the logon challenge/response)…..

No Proxy-Authorization Header is present.

Authorization Header is present: Negotiate
4E 54 4C 4D 53 53 50 00 03 00 00 00 18 00 18 00  NTLMSSP………
96 00 00 00 60 01 60 01 AE 00 00 00 00 00 00 00  –…`.`.®…….

Whether you like the idea of challenge/response over form-based logon is down to personal preference Smile

Federated SSO Logon with AD FS 2.0 in an Extranet with UAG

This is one of those “what if?” scenarios with AD FS 2.0 which arose at a customer recently: they wanted to provide secure logon to users in an Extranet Active Directory to web resources in their corporate Active Directory (e.g. Sharepoint). In a pure AD setup, with no third-party SSO products involved, this sort of thing has often been accomplished in the past through the use of a forest trust between extranet and corporate forests. This approach, however,  tends to make network and security departments unhappy; with all sorts of firewall ports needing to be opened, making swiss cheese of interior firewalls. With Windows 2008 R2, we can also do this sort of thing by configuring an Extranet AD FS 2.0 instance(s) in the DMZ (limiting firewall traffic to HTTPS only) and then establishing a federation (claims provider) trust between the corporate AD FS and the Extranet. This is similar to the partner or federated SSO scenarios that Microsoft describe in their documentation.  In this scenario, the Extranet AD FS instance is analogous to the Account Federation Partner and the corporate AD FS instance  to the Resource Federation Partner.

To make this process more interesting (life is never dull), it was suggested we put a UAG in the Extranet (in place of the AD FS Proxy) to support strong/two-factor authentication requirements. This meant that some form of jiggery-pokery with Kerberos Constrained Delegation would be required between the Extranet UAG instance and the Extranet AD FS farm, to ensure that groovy Web SSO experience was maintained all the way to the target web application.


  • Forefront UAG 2010 SP1 (
  • Extranet AD FS (
  • Forefront TMG 2010 SP1 (
  • Corporate AD FS Proxy (
  • Corporate AD FS Farm (
  • Sharepoint 2010 Farm (

So we have two zones bridged by an AD FS federation trust: an Extranet Zone and a Corporate Zone.

Extranet AD FS

The above is how I configured the sandpit for testing. Our example web application (Sharepoint), is configured as a claims-aware application and the client has bookmarked it as a favourite. He/she is able to link to the Sharepoint site ( directly and this is where the authentication process kicks in.  Walking through the process.

1. The client accesses the Sharepoint URL ( (reverse proxied through TMG). The Sharepoint web application is configured as a claims-aware web application with the Corporate AD FS 2.0 farm configured as its SP_TrustedIdentityTokenIssuer using e-mail address as the primary claim.

2. The Sharepoint 2010 security token service (STS), a relying party of the corporate AD FS 2.0 instance, redirects the client to the corporate AD FS 2.0 farm. The client is connecting from the Internet, meaning that the fully qualified domain name (for AD FS) on the Internet resolves to a public IP address, namely that of the AD FS Proxy. The client is redirected to the proxy.

3. The corporate AD FS, with the proxy as arbiter for the AD FS farm, possesses two claims providers: the default corporate Active Directory and a claims provider trust setup to point to the Extranet AD FS instance (Partners and Affiliates in the graphic). AD FS itself cannot determine which realm the client belongs to, so when the client connects he/she home realm discovery (HRD) is performed and the client must choose between selecting the corporate or Extranet realm (this process can be automated… we’ll cover this in a later post). As a result of Home Realm Discovery, the client is thereby redirected to the services endpoint for the Extranet AD FS.  In this scenario, this translates to the public IP address of the UAG trunk.


4. With the client redirected to the UAG for logon, the UAG server(s) processes the logon request. In this example, UAG is configured to use RADIUS for authentication. This is because we’ve opted for strong authentication (using tokens). RADIUS is being used to bridge the connection between UAG (as a RADIUS client), and the strong authentication provider. The token is  submitted via an application running on a smartphone and the client enters the One-Time-Password (OTP) and PIN via the UAG form (4a).  The credentials are forwarded by UAG to the RADIUS server (4b) running on the OTP provider. In this example, the user repository for the one-time password is also the Extranet AD (4c), accessed via LDAP. The UAG server(s) are also domain members within the Extranet AD. Once the OTP logon process is complete, we can chain the logon process to perform federated back-end authentication to the Extranet AD FS instance(s), obtain a kerberos ticket from the Token Service using Kerberos Constrained Delegation (KCD).   This is possible because the UAG server(s) is trusted for delegation by the AD FS server(s).  This process is described in a previous blog post (Federated Identities with UAG 2010 SP1 and Office 365). On the Extranet AD FS, the Corporate AD FS instance is configured as a relying party. We extract the e-mail address from the AD (Send LDAP Attributes as Claims), providing this information to the relying party in a  pass-thru rule (issuance transform rules) .

5. When authentication is complete at the Extranet AD FS, an HTTP POST  by the client is submitted to the corporate AD FS Passive Federation Endpoint.  The Corporate AD FS, acting now as an FP STS, processes the claim according to acceptance transform rules configured (pass thru e-mail), before handing over to the relying party where the issue transform rules are then processed (pass thru e-mail address).

6. The client is then redirected the Sharepoint web application, the e-mail address claim is processed  by the Sharepoint STS, and they gain access to the Sharepoint site.


Extranet UAG Configuration

To make this configuration work on the Extranet UAG side, we have to ensure that the federated logon process is not interrupted or interfered with.  At the same time we still have to deal with the strong authentication requirement. As stipulated in previous posts, with non-federated trunk authentication we can satisfy both strong authentication requirements and federated logon to the local (Extranet) AD FS instance. This time, however, the resource lives in the corporate realm. UAG is not directly responsible for proxying connections to the Sharepoint web application. Nonetheless, there are some unusual requirements. 

On the Extranet UAG, there are three authentication providers configured:

  • RADIUS/OTP Server
  • Extranet Active Directory Domain Controller (can be used for Authorization by the RADIUS server)
  • Extranet Active Directory Federation Services (AD FS)

The AD server is optional should you wish to use AD-based authorization groups with the RADIUs authentication server. The AD FS 2.0 server is required for the Extranet federated logon piece.

Surprisingly, there are also two web application templates that need defining:


Each of these web applications are configured to use the Extranet AD FS server as their authentication server. Without these web applications being defined, the login process fails at the UAG with  a “request was unable  to reply to an HTTP 401 request from application AD FS” being logged within the UAG Web  Monitor. This one had be stumped for a while as UAG is not responsible  for proxying traffic to the corporate AD FS proxy or the Sharepoint web application.  I can only surmise at the moment this is done to the fact that UAG assumes the web application is behind it and therefore a corresponding application must exist.

I’ve mapped the logon process out in Visio.

Extranet AD FS

If I have the time, I’ll deep-dive the entire setup in a later post. If this would be of interest to anyone, please let me know.


UPDATE 28/06: Microsoft have updated their documentation describing partner access using federated claims to Sharepoint 2010.

Office 365 SSO and AD FS 2.0 Namespaces: There can be only one…..

If you are an E3 customer and you’ve been setting up federated identities for Office 365 then doubtless you’ll be familiar with the following prose:

Connect-MsolService -Credential $cred
Set-MsolADFSContext -Computer myADFSserver
Convert-MsolDomainToFederated -DomainName

This little bit of Powershell  connects the (AD FS) organization to the Microsoft Online domain  and converts a standard MSOL domain to a federated one…

Successfully updated ‘’ domain.

And the process completes…cue muffled screams of joyous rapture / sighs of relief (delete as applicable), as we have a federated domain ready for use with Office 365, with SSO to the corporate mothership (AD). For 90% of us this is a most satisfactory result and worthy of a few grunts of appreciation. However, for the 10% whose avaricious nature compels us to add more Internet domains / or we simply have a morbid curiosity that can only be satiated by trying to break things with O365, we decide to try the same command again:

Convert-MsolDomainToFederated -DomainName

Convert-MsolDomainToFederated : The federation service identifier specified in the Active Directory Federation Services 2.0 server is already in use. Please correct this value in the AD FS 2.0 Management console and run the command again

At line:1 char:30
+ Convert-MsolDomainToFederated <<<<  -DomainName
+ CategoryInfo          : InvalidData: (:) [Convert-MsolDomainToFederated], FederationException
+ FullyQualifiedErrorId : DomainLiveNamespaceUriConflict,Microsoft.Online.Identity.Federation.Powershell.ConvertDomainToFederated

Hmm.. this time round the very same command fails .. note that I’m adding a 2nd hypothetical domain called… Looking at the Office 365 documentation for an explanation of why, a few pearls of wisdom are offered:

Active Directory Federation Services only allows for one namespace per farm/instance”. 

I’ll ghost the words “with Office 365” on the end of that.  Apparently, this is an O365 beta issue that is, according to feedback from the forums, slated for resolution before go-live……  if you can’t wait, and need to add a second namespace, it entails standing up a completely new AD FS farm/instance in the meantime… an incentive methinks, if ever I’ve seen one, to move off bare metal and virtualise Winking smile

1:1 Trunk to AD FS 2.0 Farm

In recent posts, I’ve been flicking between two configuration states on two different trunks:

  • Federated Trunk A
  • Non-Federated Trunk B

I’ve been using  two ADFS instances in the back-end, testing various combinations using the mythical and endpoints.


There is one limitation that becomes very clear during testing:

an AD FS instance may be used by a single trunk only

AD FS instances cannot be shared across trunks. What !@#!.. that’s crazy!! Well, not really.. When you consider that UAG is proxying federation services endpoints, this does make a lot of sense.  We cannot arbitrarily share instances of our federation service across different trunks, because that goes against the very nature of a federated trust. It can be represented in one and only one place.  When we try and share the same service across multiple trunks, UAG chucks out the following message:

The AD FS authentication server ‘AD FS 2.0 …" is used in more than one trunk: TrunkA, TrunkB. Configure the UAG to use the AD FS 2.0 authentication server in one trunk only.

Which reminds me of something else I needed to post………………………


Federated Identities with UAG 2010 SP1 and Office 365

Following recent posts and discussions on the Office 365 forums, it seemed like a good time to look at integration between UAG 2010 SP1 and AD FS 2.0 and logon scenarios using Office 365 beta. Not much has been written about this to date, so I’ve been wading through the pre-production landscape of Office 365, trying to come terms with the complexities that these co-existence scenarios can bring.

Since UAG 2010 SP1, Microsoft have provided out-the-box support for AD FS 2.0. For Office 365 as a claims-aware platform, this gives us an opportunity for integrating UAG and AD FS 2.0 on-premise with Office 365 Enterprise web applications. UAG 2010 SP1 supports the WS-Federation passive profile, allowing for Office 365 web apps to be published through the UAG portal.

Microsoft highlight a number of integration topologies in their Forefront UAG 2010 SP1 with AD FS 2.0 documentation.

From an Office 365 perspective, there are two topologies in the above link that had particular resonance for me in testing:

1. Remote employee access using claims

UAG is configured as a relying party for an on-premise AD FS 2.0 server (Resource Federation server in the diagram). Remote users authenticate to both the UAG trunk using and also the back-end application using claims-based authentication.

2. Remote employee access using non-federated trunk and federated application authentication

In this configuration, users connect to the UAG trunk using non claims-based authentication, for example, strong/two-factor authentication. They then authenticate to the published application using federated authentication. This configuration is the supported two-factor authentication that the Office 365 documentation alludes to. If the front-end authentication solution uses a separate user database from the Active Directory, then also consider that some form of matching shadow accounts are required within Active Directory (remember that AD FS uses AD as its authentication repository) to bridge access between front and back-end.

Why use UAG?

If you’re wondering what benefits UAG may offer with Office 365.

  • Support identity federation at the edge
  • Support claims-aware applications for SSO
  • Support for strong/two-factor authentication with Office 365 web applications
  • Replace the AD FS Proxy function
  • Utilize access policies for web-based applications
  • AD FS Single Sign-Out

There are some limitations that you should be aware of. When Microsoft refer to the WS-Federation passive profile, they’re talking about UAG and the browser, meaning Outlook Web App, Sharepoint Onlne and the Office 365 administration portal. The sign-in experience that we’re referring to in this post is with federate identities.  In this scenario a user may access the Office 365 sign-in service. The service  determines that the domain name referred to (via the UPN) is part of a federated domain and accordingly redirects the user to the on-premise  Active Directory Federation Server (AD FS) 2.0 instance. Where UAG is in front of AD FS, this call is intercepted because the UAG is in-line for processing traffic.


There are a couple of pre-requisites for our UAG/O365 configuration.

  • AD FS 2.0 Single Sign-On for Office 365 has been prepared:

      • Microsoft Online Services Assistant has been installed
      • Microsoft Online Services Module for Powershell has been installed
      • MS Online domain has been converted from standard use to federated

  • Directory Synchronization between the organization/Office 365 tenancy is active.
  • An AD FS 2.0 server/farm is available and configured in the corporate environment.
  • UAG 2010 SP1 is a member of the corporate Active Directory domain. *
  • The Federation Services Endpoint certificate (SSL certificate) used by AD FS has been exported and imported into the UAG computer certificate store. This will be assigned to the trunk.
  • The external (A) record for the AD FS service points to the UAG federated/non-federated trunk. For client hosting a HOSTS file will suffice initially.

* This option is not mandatory and one could argue against its use in the federated trunk scenario, as we’re doing full claims authentication, i.e. domain membership is not really necessary. For the purposes of this post, however, we’re using AD domain-membership to perform kerberos constrained delegation for the non-federated trunk configuration scenario.


Configure an AD FS 2.0 Authentication Server

Both UAG access scenarios require the services of an AD FS 2.0 authentication server. This can be done during trunk creation or, in this example, from the Admin menu, by selecting Authentication and Authorization Servers.

To create the relationshjp with AD FS 2.0, we must create an authentication server, obtain federation metadata from AD FS  and then define the claim that will be used as the lead value (of interest).

Add an ADFS 2.0 Server. In the example below, I’ve created an Authentication Server calling Training, pointed it to the on-premise AD FS 2.0 Server / Farm at ( I then retrieved the metadata from this URL and then selected Name to be the attribute of interest.


NOTE: If you get an error while retrieving metadata stating “the Federation Metadata is signed, but the UAG server does not trust the certificate”,  check that the Token Signing Certificate, if it is self-signed, is imported into the Trusted Root Certification Authorities store of the UAG. Alternatively, if there is a certificate chain involved, via an internal authority, ensure that the corresponding chain is imported. Any PKI CDP URLs for internal issuing authorities should be visible/reachable. You may need to edit the underlying TMG CRL Download System Policy to ensure it is checked.

Once the authentication server has been created, it can be referenced for usage within a trunk. This can be:

  • for front-end authentication, with the AD FS 2.0 server as a federated trunk
  • for federated back-end authentication, whilst using a non-federated trunk on UAG

I’ll cover the federated trunk configuration first and the hybrid configuration immediately after.

Federated Trunk (Remote employee access using Claims)

In this configuration we define the ADFS security token service (STS) as an identity provider and authentication server for UAG

  • Create a Portal Trunk
  • Assign the trunk a name (imaginatively called ADFS in this example)
  • Give the public host name the same name as the federation services endpoint URL (e.g.

In the example below I created a trunk with the name of ADFS


As the above summary screen warns, the UAG relying party must be configured in AD FS. This needs to the point to the UAG URL assigned by the wizard,. This URL must be the public (external) address of the (federated) trunk.

You can review the Advanced Trunk Configuration afterword, under the Authentication tab to confirm the configuration information for the UAG relying party necessary in AD FS.


For example,


Federation Metadata:

The STS should be reachable through the internal DNS of your organization, i.e. UAG is configured to use internal DNS and not external DNS.

 Configure AD FS 2.0

In AD FS 2.0 we need to add a relying party trust.

  • Start the Add Relying Party Trust wizard.
  • Import data about the relying party published online


Add the federation metadata endpoint described in the previous section. This needs to point to the (external) trunk. Before this will work you’ll need to create HOSTS file entry(s) on the AD FS server(s) pointing to the UAG federated trunk. This enables AD FS to resolve the address of the relying party. Remember that the UAG federation trunk URL is proxying traffic to the AD FS federation services endpoint ( and internally that resolves to the AD FS farm/server(s). We need the AD FS to be able to reach and resolve the UAG address.

Having created the HOSTS file and successfully connected to the UAG relying party, we need to create a claim rule for the UAG. In this example, I’ve created a simple Pass-thru claim that passes thru the Name attribute.


Now we’re set to create an Office 365 web application… skip the next section and go to Configure an Office 365 web application.

Non-Federated Trunk (Remote employee access using non-federated trunk authentication and federated application authentication)

Non-federated trunk mixes authentication protocols between front-end and back-end systems, namely:

  • Front-End authentication using classic UAG authentication
  • Back-End authentication using claims-based authentication through AD FS 2.0

The initial configuration for this scenario should be familiar if you’ve used UAG or IAG before as we select one of the classic supported authentication protocols (e.g. LDAP, AD, RADIUS, SecurID etc).  For the purposes of this article, the front-end authentication type (RADIUS/LDAP etc) that we settle for is not important.

In this example, I’ll be using a front-end authentication process through RADIUS. It helps for purposes of demonstration to choose a different front-end authentication provider, e.g. a 2FA OTP provider,  from that of the the back-end provider (AD FS). In this setup, therefore, I’m using an OTP solution (Pointsharp ID) with software tokens.



Generating an OTP code from my smartphone, I  enter my user ID and OTP to successfully complete the logon process. However, for this process to work correctly, we need to integrate AD FS 2.0 as a back-end authentication provider.

To setup AD FS 2.0 in a non-federated trunk scenario, we need to add it in UAG via the Add Application wizard. In this configuration, AD FS does not “live” on the trunk; rather,  it exists as a web application.

From the Add Application Wizard, select the Active Directory Federation Services 2.0 template.


I’ve used the defaults here until Step 5.  On the web servers screen fill out the details for the AD FS server/farm address. Enter the FQDN of the federation service, e.g.


The server address (FQDN) and the public host name assigned must be the same.

On Step 6 – Authentication, leave the SSO checkbox unchecked, we’ll fill this in in a moment.

On Step 7 – Portal Link, leave the Add a Portal and toolbar link unchecked (we call the application implicitly through the published relying party web application).

Once the application has been created, enter the application properties and click on the Authentication tab. Check the SSO tab and change the radio dialog to Use Kerberos constrained delegation for single sign-on. AD FS uses an application pool identity for the farm AD account, so the http://* application SPN should be used.


NOTE: When AD FS 2.0 is configured for trunk authentication, you may notice the between the way that it is configured when  non-trunk authentication is done on the front-end and claims authentication in the backend. In the latter configuration, as the above graphic indicates, we’re using Kerberos constrained delegation to  trigger the logon process (to AD). In the federated trunk scenario, however, we’re doing pure claims-based authentication. In this configuration, the checkbox Allow unauthenticated access to web server is checked.


This actually does make sense. In the federated trunk scenario,  UAG is in essence claims-aware and needs to allow unauthenticated proxy requests to reach the web server so that logon can be initiated.

Configure an Claims-aware application (Office 365)

To add a claims-aware web application within UAG, there are a number of steps involved:

  1. Select a web application template
  2. Define a name and type for the application
  3. Define endpoint / access policies
  4. Specify the address/location of the web server
  5. Specify how (SSO) credentials are passed to the published application
  6. Define whether the application will be shown within the portal

In this example, we’ll use Outlook for Web Access (OWA 365) as a sample web application. The inbuilt Exchange 2010 wizard doesn’t work in this scenario so we’ll create a web application using the portal trunk..

In the Applications window, click on Add to Launch the Add Application Wizard

At Step 1, Select an Application, choose Web | Other Web Application (Portal Hostname)


Give the application a name and select whether the endpoint policies you wish to enforce. I’ve used the defaults until Step 5 – Web Servers.  In the addresses box here enter: .


On Step 6 Authentication, check the SSO checkbox and select the AD FS 2.0 server created earlier as the authentication server.


In Step 7, enter the URL for your Outlook for Web Access 365 web application


In the above I’m using as an example.


The processes described above support portal-initiated logon (via the UAG) and also relying-party initiated logon from the Microsoft online website itself.

As ever, please read the documentation on the Office 365 website as those gaps are being filled every day. Oh…and validate your single sign-on usage scenarios!!!

As always, if you have any comments, corrections, questions or have some insight on this subject , please contribute!


O365 and TMG with Strong Authentication (Part II)

Using TMG as a strong-authentication capable proxy for passive O365 clients and reverse proxy for rich/active clients

In the previous post I looked at configuring TMG  to allow it to support both strong authentication of Office 365 (passive) web clients and at the time act as a reverse proxy for rich/active clients that use classical username/password for authentication.

Attached is a diagram highlighting the high-level communication flows associated with the previous post.  I’ve emphasised the HTTPS traffic between the Federation Gateway and TMG for rich/active clients (the thick arrow), as it’s bi-directional in nature.

o365 Blog Diagram

Unlike the passive client where all communication occurs through HTTP redirects, rich/active clients  bounce around from server to server. This makes building a solution that supports multiple (strong/weak) authentication schemes difficult to implement and why, in the long term, customisation of the AD FS proxy pages may be the easiest route.

O365 and TMG with Strong Authentication (Part I)

This post looks at how TMG 2010 may occupy a role of hybrid AD FS Proxy for Office 365.

In previous posts on this blog we looked at using TMG as an AD FS 2.0 proxy .. When testing this back in Q4 2010, there was some uncertainty when testing (at least on my part), as to whether TMG as an AD FS proxy replacement was actually a supported configuration. Happily, it looks like these questions  have been answered. In TechEd in Atlanta, the Office 365 deck on Identity and Access Solutions (OSP215) describes TMG as an alternative proxy offering for Office 365.  

Here TMG substitutes the role of the AD FS proxy for corporate users using identity federation, with it being responsible for authentication of browser traffic (passive clients) coming from the Internet and traffic from Microsoft (active/MEX clients). One of the things about TMG  is its flexibility and versatility. This was borne out in testing and it’s possible to support multiple flavours of access through a single web listener. For example, let’s say we need to support strong authentication for external / Internet-based clients using OWA 365 and Sharepoint 365, whilst at the same time we support internal/external users with rich clients, using conventional username and passwords, running Outlook and Lync. Let’s list those again:

  • Single factor (username/password) authentication for rich/active clients inside/outside the corporate environment… covering ActiveSync access from the outside, Outlook 200x from the inside/outside and  MEX clients, such as Lync 2010 inside/outside
  • Single-factor authentication (username/password) for passive clients inside the corporate environment (OWA/Sharepoint)
  • Two factor authentication (2FA) for passive clients outside the corporate boundary (OWA/Sharepoint)

Inside the organisation, passive clients make use of the local AD FS 2.0 instance (rather than TMG), whereas Rich/Active clients use a more complex process . In fact, the latter makes for an interesting challenge, for any would-be admin, as the Microsoft Federation Gateway needs to call-back to the on-premise AD FS instance. Normally speaking, active and rich clients must, therefore, go through the AD FS Proxy for logon. In this post, we substitute the AD FS Proxy role for TMG, so that we may leverage capability that TMG can offer  (I’m using the example of strong authentication).

The key to making this approach work with TMG lies in creating multiple web publishing rules, each with their own authentication requirements, using a single web listener. In doing so, we:

  • Create a web publishing rule that allows direct communication to the AD FS back-end for active and rich clients (effectively anonymizing authentication on the listener for the published paths in question)
  • Create a web publishing rule that triggers authentication (two-factor) on the TMG front-end and then uses delegation to the AD FS back-end using Negotiate authentication. 

We are then able to support access requirements for both two-factor (external) logon from the browser, whilst also supporting the ability of single factor logon for active/rich clients, domain-joined and non-domain joined……..

There are a couple of tweaks in the TMG configuration necessary to ensure compatibility with AD FS 2.0…..

  • Disable Verify Normalization on the HTTP Filtering tab of each publishing rule
  • Disable Block High-Bit Characters on the HTTP Filtering tab of each publishing rule
  • Disable Link Translation on each publishing rule

Also, please ensure that:

  • DNS records for the AD FS Proxy point to the TMG web listener
  • A SAN or wildcard certificate is installed on the TMG listener with the appropriate FQDNs for the AD FS Federation Service endpoint (hint: export the certificate plus private key from AD FS and import into TMG)
  • Kerberos Delegation is configured for the AD FS Farm Application Pool Account or ADFS Computer Account (if the AD FS server is a single machine)

We create two publishing rules with the public name matching that of our AD FS 2.0 server/farm, :

Rule Authentication Delegation Paths Users
#1 Kerberos Constrained Delegation /adfs/ls/* All Authenticated Users
#2 No delegation, but client may authenticate directly /adfs/services/trust/2005/usernamemixed/*/adfs/services/trust/mex/* All Users


  • Rule #1 applies for the passive clients doing two-factor authentication on the web listener
  • Rule #2 applies for the rich/MEX and Active client profiles for Lync and ActiveSync/Outlook respectively.

The more restrictive rule (two-factor) should be applied first in the firewall list. As a general rule of thumb, let the TMG Logs and Reports tracker, together with Fiddler, help debug any protocol issues that may arise.

Next stop ….. UAG !!!!


According to official documentation, Office 365 strong authentication scenarios include:

  1. Two-factor authentication at Windows/Domain Logon
  2. Two-factor authentication via Forefront UAG 2010 SP1 for web applications
  3. Two-factor authentication via customized AD FS Proxy sign-in pages

If you have a fully-fledged public key infrastructure with smart cards, then you’re probably wondering what the fuss is about 😉

Option 2 looks promising.. However, after testing it and then reading and then re-reading the Office documentation, it appears that the working two-factor scenarios are limited to passive clients only (OWA/Sharepoint) and that Outlook and ActiveSync (O365) are not supported via UAG. Because a UAG server doing 2FA is acting as non-federated trunk, rich/active clients get stumped during authentication. Now, this may be possible to get working with some tweaking  but it looks like some sacrifices would be required (e.g. disabling access policies on the trunk). I’m hoping I’m missing something here and some bright spark will put me right, part the clouds and show how it can be done Smile

Option 3 is very much possible if you’re prepared to roll up your sleeves and do some sort of customization of the ADFS Proxy sign-in pages to support 2FA, with your strong authentication vendor of choice. I’d expect to see some sort of progress from MS on this, given that Office 365 launches this month.

Getting this working through TMG was really the motivation for me here. If, as a prospective Office 365 customer, you have a requirement for strong authentication for external users, whilst at the same time you need to support traditional username/password logon internally, then maybe this option can assist..… as ever, your mileage may vary and please don’t deploy before testing this to death in anything close to production!

Adding multiple claims-aware web applications to a Sharepoint 2010 Farm.

This is more of a mental note to self (and something which I kept forgetting the correct syntax for, despite using it in the past)… How to add an additional claims-aware web application to an existing Sharepoint 2010 farm.

$uri = new-object System.Uri(““)
$ap.ProviderRealms.Add($uri, “urn:sharepoint:mydomain”)

The original post courtesy of Steve Peschka:

Disable Local Authentication in AD FS 2.0

Perhaps you’re working with another Web Access Management (WAM) product and want to disable local realm authentication in  AD FS 2.0. To do this, the web.config needs to modified and the appropriate sections commented out.

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

Wrap the above section with comments <!—and –-> to disable the listed authentication types. With all types commented out, AD FS will no longer authenticate users and will forward all requests to any configured claims providers.

Why do this? You may want to use AD FS  as a broker, passing traffic between WS-* / WIF applications and an upstream WAM solution (e.g.  Shibboleth, OpenAM etc.), making AD FS a SAML 2.0 Service Provider (SP) as part of this process.