A little more OpenAM……10.0

OpenAM 10 Early Release is now available for download and there’s lots of changes and new access capability/features in there:

  • OpenIG – ForgeRock Identity Gateway. A reverse proxy with credential replay to support OpenAM for non-federated web applications.
  • New SAML 2.0 IdP Adapter plug-in that allows additional processing to be performed before releasing the assertion or when some form of user interaction may be required.
  • OAuth 2.0 Client Authentication Module
  • OpenAM .NET Fedlets with support for encrypted assertions
  • Support for adaptive risk authentication
  • Support for multiple RADIUS servers in RADIUS authentication module
  • Distributed Authentication Service (DAS) HTTP Header mapping when forwarding requests
  • Support for LDAP servers that support Behara IETF draft Password Policy for LDAP Directories, e.g. OpenDJ, OpenLDAP
  • Active Directory password expiration response processing (correct)
  • Windows Desktop SSO, kerberos and user profile improvements

Completely selfish of me, I’ve hand-picked the stuff from the Release Notes that I thought particularly interesting or was bugging me in earlier releases Smile

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 idp.mydomain.com  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 https://blog.auth360.net/2011/02/20/disable-local-authentication-in-ad-fs-2-0/)

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 https://contoso.auth360.net/sts with metadata at: https://contoso.auth360.net/sts/FederationMetadata/2007-06/FederationMetadata.xml

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 == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] == "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 == "http://schemas.auth360.net/2012/01/requestcontext/claims/x-am-uid"]
=> issue(claim = c);

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

c:[Type == "http://schemas.auth360.net/2012/01/requestcontext/claims/x-am-mail"]
=> 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 == "http://schemas.auth360.net/2012/01/requestcontext/claims/x-am-mail"]
=> issue(Type = "
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn", 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 https://contoso.auth360.net/sts (Relying Party) in Organization B.
  2. User does not have a valid authentication cookie and so is redirected to Organization A https://sts.mydomain.com/adfs/ls (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 https://idp.mydomain.com/openam/SSORedirect/metaAlias/idp?SAMLRequest
  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 https://contoso.auth360.net/sts.

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: https://blog.auth360.net/2011/10/15/ad-fs-2-0-rollup-i-multiple-issuer-support/ 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 mydomain.com -SupportMultipleDomain
Update-MsolFederatedDomain -DomainName yourdomain.com -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 https://sharepoint.mydomain.com/_trust/

An operation failed because the following certificate has validation errors:\n\nSubject Name: CN=ADFS Signing – sts.mydomain.com\nIssuer Name: CN=ADFS Signing – sts.mydomain.com\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 https://idp.mydomain.com/openam/encode.jsp  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 …..

IIS 7.5 SSL Bindings and Socket Pooling (

Socket Pooling in IIS, useful for improving SSL performance,  can also be a pain if you’re trying to run multiple SSL-enabled web applications on the same server. I continue to run into this with IIS and Apache Web Server/ Tomcat.  To specify which IP Addresses HTTP.SYS (IIS) should explicitly listen on can be manipulated through NETSH.

show iplisten

This should return blank if you have socket pooling enabled. To add a listener on a given IP use the add iplisten command

add iplisten ipaddress=x.x.x.x

where x.x.x.x is the IPv4 address of your choice. IPv6 is also supported. 

There’s an article on MSDN that highlights this and other commands for manipulating http.sys.



C:\Users\Administrator>netstat -an|find “:443”
  TCP    x.x.x.29:443              LISTENING
  TCP    x.x.x.30:443              LISTENING


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

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

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

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

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

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

Onto the new capability….

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


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

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

X-MS-Forwarded Client IP

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

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


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

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


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

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

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

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

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

Active clients are rich clients such as Outlook and ActiveSync.

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

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

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


Once all five were added:


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


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

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

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


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


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


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

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

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

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

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

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

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

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

Windows 8 Login: Claims Providers as Credential Providers?

BUILD 2011 hinted at some ground-breaking possibilities in Windows 8 and what lays ahead with Windows Server 8 and AD FS 2.1. One of the biggest attraction points  may lie in the depth at which identity claims will be integrated into the Windows platform itself. This is (potentially) massive, particularly when Microsoft are touting it as covering the whole AAA gamut (authentication, authorization and auditing). That represents either some major architectural changes (and capability) within Windows, not to mention a few burning questions:

  1. How deep will Identity Claims really go in the OS.. really down to NTFS and SDDL?
  2. What level will we be able to match identity claims against embedded metadata such as FCI or document classification metadata?
  3. How will this integration work with next generation mobile devices?
  4. What does this mean for (Information) Rights Management ?
  5. Will non-AD authentication providers / claims providers be available as credential providers for logon . e.g. LiveID, SAML 2.0 IdP’s?
  6. Will AD FS 2.1 be available on Windows 2008 R2 in the same way that AD FS 1.0, 1.5 options appeared in 2003 R2/2008 RTM?
  7. Will the claims-aware AAA concept be back-pedaled into Windows 7?

Early days and the Developer Previews are just that, but the Access Management concepts do look promising.

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 (www.forgerock.com). 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 (http://wiki.apache.org/tomcat/FrontPage).

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. idp.mydomain.com.

2. Point your browser to https://idp.mydomain.com/openam. 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. https://idp.mydomain.com:443) and cookie domain (.mydomain.com)


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. https://idp.mydomain.com/openam. 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 https://portal.microsoftonline.com or directly via https://www.outlook.com/mydomain.com. Once the user hits AD FS, the user logon is processed according to whether:

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


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

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

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

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

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

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

HTML Forms Authentication

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


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


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


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


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



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

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

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

HTTP Authentication

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


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


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


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

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


HTTP Authentication with Digest was not tested.

SSL Client Certificate Authentication

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

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


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

Web Publishing Rules

On the TMG side, two publishing rules are required.

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

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

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


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


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


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


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


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


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


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


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

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

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

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

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


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


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


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

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

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

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


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


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

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


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


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


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

Share your experiences and have fun testing!


DirectAccess and CRL’s

I was at a a customer recently where they were experiencing a problem with DirectAccess;  roaming users, home or travelling, would suddenly lose their DirectAccess  connection. Investigation revealed that these were IP-HTTPS users that were working out of office and their connections would mysteriously drop. These were normally Teredo clients but there are documented scenarios of Teredo quirks that cause a fail back to IP-HTTPS. The users in question had been travelling and logging on on other corporate LANs so fallback to IP-HTTPS was plausible (the ins and outs of Teredo behaviour can be found in the following blog entry):


On the IP-HTTPS side, we were noticing that the tunnel negotiation and setup was failing. Logs from the user(s) experiencing the problem were captured via the DirectAccess Connectivity Assistant. The details in the IP-HTTPS portion of the log were revealing:

https://access.mydomain.com:443/IPHTTPS Last Error Code : 0x80092013 Interface Status : failed to connect to the IPHTTPS server.

The Certificate Distribution Point (CDP) of the online Issuing Certification Authority could not be reached (error code 0x80092013).

The Certificate Distribution Point (CDP) offline message turned out to be misleading.  The CA CDP was online and reachable, but investigation revealed a key omission in our configuration. The CDP of the Issuing CA URL was not in the Direct Access tunnel exemptions list. This meant that every X hours or so the CRL cache on the local Windows 7 clients was expiring. When the client did need to obtain a fresh CRL from the CA, it failed because of a race condition where  the client was unable to setup the infrastructure tunnel because the server authentication certificate issued to the IP-HTTPS listener (running under IIS) could not be validated as the CA CDP was unreachable and the CRL not downloadable because the tunnel hadn’t been established (loop to infinity)…..

Lessons learned:

  • Use a third-party certificate to avoid the aforementioned scenario OR
  • Ensure that the URLs of certificate distribution points (CDP) are not resolved through the infrastructure tunnel and are exempt from DirectAccess

Nice!! Smile



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 https://sts.mydomain.com/adfs/ls/auth/integrated/……

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

Disable DirectAccess on the Windows 7 Client (Temporarily)

I was looking for a way to temporarily disable DirectAccess on the Windows 7 client recently when testing UAG with AD FS 2.0 and needed a quick and relatively pain-free manner of making sure that DA wasn’t interfering… Giving the IP Helper service a kick on servers in the past has often given the right result with IPv6 and ISATAP, so it seemed logical that stopping the IP Helper service on the client might also have the desired effect


This did the trick.. no more DirectAccess..  nothing has blown up and restarting the Helper service using NET START IPHLPSVC brought DA back up 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.mydomain.com)
  • Extranet AD FS (extranet.mydomain.com)
  • Forefront TMG 2010 SP1 (sts.mydomain.com)
  • Corporate AD FS Proxy (sts.mydomain.com)
  • Corporate AD FS Farm (sts.mydomain.com)
  • Sharepoint 2010 Farm (sharepoint.mydomain.com

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 (sharepoint.mydomain.com) directly and this is where the authentication process kicks in.  Walking through the process.

1. The client accesses the Sharepoint URL (https://sharepoint.mydomain.com). (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 sts.mydomain.com (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.

XENApp 6 Fundamentals: Failed to configure component Citrix Licensing

Installing XENApp 6 Fundamentals recently, the installer would through an error when  adding the Citrix Licensing component. Looking at the Citrix Access Essentials Installer log under C:\Users\%USERNAME%\AppData\Local\Citrix was the following error:

“failed to configure component citrix licensing”

The installer will fail if the user does not run as Administrator AND any Licensing Service components should be removed before trying again. Removing the service in Add/Remove Programs and then restarting the installer with RunAs Administrator then allowed the installation to continue.


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 mydomain.com

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 ‘mydomain.com’ 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 yourdomain.com

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 yourdomain.com
+ 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 yourdomain.com… 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 sts.mydomain.com and sts1.mydomain.com 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 (https://mydomain.com/FederationMetadata/2007-06/FederationMetadata.xml). 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. sts.mydomain.com)

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,

Realm: https://sts.mydomain.com/InternalSite/ADFSv2Sites/ADFS

Federation Metadata: https://sts.mydomain.com/InternalSite/ADFSv2Sites/ADFS/FederationMetadata/2007-06/FederationMetadata.xml

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 (sts.mydomain.com) 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. sts.mydomain.com


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: www.outlook.com .


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 https://www.outlook.com/owa/mydomain.com 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, sts.mydomain.com. :

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!