Backup and Recovery with the AD FS Rapid Restore Tool

Slipping out of the Microsoft stable recently with little fanfare, the AD FS Rapid Restore Tool. As the name suggests, this is a tool geared at aiding in the recovery of your AD FS configuration / environment, in the event of server failure or disaster. To date, effectively backing key material and/or relying parties has been a proverbial thorn-in-the-side for AD FS administrators, so the release of this utility is very interesting.

Does this tool do the trick? Let’s give it a whirl…

Download the MSI and install the tool.  You can get the MSI from here. Supported versions are AD FS 2012 R2 and AD FS 2016. The tool is directly installed on the farm node and the installation process is very straightforward ( a la Next Next Next).


With the tool installed we can launch a Administrative PowerShell prompt and then import the module.


Let’s look at some of the command option via Get-Help Backup-ADFS -full


As can be seen from the graphic above, when we call the Backup-ADFS cmdlet, backup of the AD FS configuration is possible to both the filesystem or to Azure. In these test scenarios, the local file system is used.

A backup folder (e.g. C:\ADFSExport) is created manually as the backup/restore location. The Backup-ADFS cmdlet is then run. Here’s the syntax used for testing.

Backup-ADFS -StorageType “FileSystem” -StoragePath “C:\ADFSExport\” -EncryptionPassword “12345678” -BackupComment “Clean Install of ADFS (FS)” -BackupDKM


Oops.. a warning. As the Microsoft documentation points out, your AD FS SSL/TLS certificate will only be backed up during the export if the private keys are marked as exportable and the associated Manage Private Keys permission is given to the user running the script. In the above example, my certificate does not fit that criteria. A simple way to check beforehand is to attempt to export the SSL certificate via the Certificate Export Wizard.  If “Yes, export the private key” is greyed out, it’s not exportable. Now go find that PFX ……


Where the script can’t handle the service communication certificate migration, the PFX should be manually imported on the replacement server before the restore script is run.

By the way, the token signing and decryption certificates (incl. private keys) used by AD FS are stored in the AD FS configuration database itself. These certificates are then encrypted using something called the Distributed Key Manager (DKM). A container is created in the local Active Directory  of your AD FS during installation of the first AD FS node in the farm. The DKM master key is then stored in this container. The recovery tool provides for backup of the DKM facility and in the export command-line above the “Backup-DKM” is used. I’m no expert on DKM, so if you require a more detailed information, I suggest you go hunting here.

Onto the recovery. Here I wanted to test a number of changes.

Same Server Recovery

For this simple test, we elected to remove the AD FS farm (primary) role  in each case and cleaned out the AD FS container in Active Directory (CN=ADFS,CN=Microsoft,CN=Program Data). A fresh installation of AD FS was then made, the tool installed and then the restore operation begun.  Any existing configuration database was overwritten.

Restore 1 – Basic

To begin with, in the first restore, we help the tool along a little bit by partially rebuilding the AD FS server. I added the AD FS role manually via Server Manager, specified the federation service name, the SSL certificate to use and the relevant service account. Here the recovery script was as follows:

Restore-ADFS -StorageType “FileSystem” -StoragePath “C:\ADFSExport\” -DecryptionPassword “12345678” -RestoreDKM

Restore worked fine. No errors and the WAP connected back to the “new” farm without issues.

Restore 2 – Complete

This option required providing the command-line with a little more information as the role was not pre-installed. Consequently, those missing elements, pre-loading of SSL/TLS service communications certificate aside, needed specifying.

Restore-ADFS -StorageType “FileSystem” -StoragePath “C:\ADFSExport\” -DecryptionPassword “12345678” -RestoreDKM -ADFSName “” -DBConnectionString “WID” -GroupServiceAccountIdentifier “MYDOMAIN\gmadfs$”

Again, no issues. Impressive.

That SSL error during the initial export was still bugging me though. Just to make sure that SSL export really was supported, I flipped the Service Communications certificate in AD FS to one with an exportable private key (the replacement certificate was one from a local test CA, complete with Server Authentication EKU). The cert then needed to be assigned to AD FS  via PowerShell.

dir cert:\LocalMachine\My
Set-AdfsCertificate -CertificateType Service-Communications -Thumbprint thumbprint
Set-AdfsSslCertificate -Thumbprint thumbprint


After an AD FS  restart, with the new certificate in place, I then reran a new export:


As can be seen from the above screenshot, with the exportable cert in place there were no SSL errors this time. Removing AD FS and then rerunning the Restore-ADFS cmdlet an additional  time then demonstrated that the SSL certificate was then imported as part of the recovery.  Nice.

New Server Recovery

Of course, no test is worth its weight in custard unless we actually go the extra mile and try and break stuff.  In the next scenarios, we’ll tweak the configuration a little, moving AD FS to a completely new server and do a database recovery to a new format.

Restore 1 – WID to SQL

As well as introducing a new server, complete with different IP, computer name etc., we will also migrate the recovered solution to a new database form factor, as part of the recovery. Via the script, the original Windows Internal Database (WID)-based AD FS solution will be refactored in SQL Server.

Restore-ADFS -StorageType “FileSystem” -StoragePath “C:\ADFSExport\” -DecryptionPassword “12345678” -RestoreDKM -ADFSName “” -DBConnectionString “data source=sqlserverFQDN;initial catalog=adfsconfiguration;integrated security=true” -GroupServiceAccountIdentifier “MYDOMAIN\gmadfs”

The change in the script is minimal from previous cases. In order to effect the transition from WID to SQL we simply provide the necessary connection string in the Restore-ADFS cmdlet so that the recovery tool can provision the AD FS configuration and Artifact database on the SQL Server. Running the restore script against Backup ID 8 (in this example).


The restore is complete without errors. On the SQL Server in Management Studio, the databases are successfully provisioned.


On our Web Application Proxy (WAP) in a HOSTS file (or DNS – YMMV), we update the reference to the AD FS farm pointing to the new IP address. Excellent! Cue login test page and successful logon.


Restore 2 – SQL to WID

Believe it or not, the request to move from SQL to Windows Internal Database (WID) does come up from time-to-time on Technet forums, so I thought I’d validate this scenario also. Here we’re moving back our AD FS configuration database(s) running on a SQL workload to WID. We back up our ADFS/SQL server  and then copy the C:\ADFSExport folder to the newly minted server. Here the following syntax is then run:

Restore-ADFS -StorageType “FileSystem” -StoragePath “C:\ADFSExport” -DecryptionPassword “12345678” -RestoreDKM -ADFSName “” -DBConnectionString “WID” -GroupServiceAccountIdentifier “MYDOMAIN\gmadfs$”


Item 9 is the ADFS/SQL backup which we wish to restore. Again, on the WAP we point away from our old ADFS / SQL pair to our freshly restored ADFS / WID combination and test logon and we’re up and running.


This is an outstanding tool and one every AD FS administrator should be in possession of. Not to be underestimated, the AD FS Rapid Restore tool not only  adds great value to the recovery process, but also provides an excellent means for copying/mirroring your environment AD FS for testing. Moreover, as can be seen from the previous screenshots, it’s also an excellent way of backing up and charting your AD FS configurations vis-a-vis change management.

AD FS – Old Habits (idpinitiatedsignon.aspx)

Usually after building an AD FS/WAP farm I test locally from the Internet and the Intranet using (to-date) a fairly reliable source of verification that the service is up and running. I’m referring to, of course, the IdP sign-in page (../adfs/ls/idpinitiatedsignon.aspx). This offers a simple way of validating login via AD FS.

With Windows Server 2016, this page is no longer surfaced “out-of-the-box”.. if you want to do a SAML 2.0  IdP-initiated sign-on, this functionality will need to be enabled. Otherwise, connecting to the obligatory sign-in page, will produce an error similar to the following:


Testing from the Web Application Proxy itself directly,  pointing to the AD FS farm, we may see an HTTP 503 Service Not Available error.

Via Powershell, it can be switched back on:

set-adfsproperties -EnableIdpInitiatedSignon $True

Now, before we get too hasty,  knowing that we can turn it back on versus actually turning it back on are two different things🙂 If it’s directly required, IdP-driven sign-on is a feature of your federation setup, then you may have no choice. For example, certain SaaS/Cloud applications simply don’t support SP-initiated workflow.

For some organizations I’ve worked for though, this page is seen as insidious because it reveals the relying parties configured on your AD FS farm anonymously.

AD FS 2.0


AD FS 2012 R2


Going back to AD FS 2.0, customers are often unwilling to float this data anonymously via the sign-in page and want to hide the RP enabled trusts visible on the page, sometimes re-writing the code behind to do so or even hiding it from the browser via obfuscation.

Whatever your view, it’s off by default in Windows Server 2016. Those of a paranoid bent may now breathe …………. in….. out….in… out…. there you go🙂



Blogging @ Route443

While I continue to post identity and access-related material here, a note to let you know that you can also find posts from myself and other colleagues on a blog over at Route443. This is a new organization recently co-founded and setup to aid and assist companies make better use of nascent technologies, such as cloud, for business advantage. You can find more about the company here.

Here’s a quick summary of what’s been posted so far on the blog.

My colleague, Edwin, set the ball rolling back in March with a post about Azure Identity Protection. He followed this up quickly with a nice piece on the Evolution of Access Control. In April, came a post about Azure AD as an Identity Provider from yours truly. Then last week, another colleague (Dennis) pipped everyone to the post by writing an excellent walk-thru of the new SAML Authentication capability found in the next (7.9) release of Citrix XenDesktop and XenApp. A highly recommended read and a world “first”.

In the coming weeks, we’ll be taking Azure AD out for a test drive…

See you there, oh … and here🙂

Damian / “Mylo”


Back to the Home Realm Discovery in 2012 R2

Hello all.  You may recall from older posts on this blog (2012) that we’ve played around in the past with Home Realm Discovery (HRD) in AD FS.

First with IWA and forms logon here and then a little bit more for good measure. Since then it’s been a little quiet on the HRD fence and not a subject delved into much since. That is, until an issue a colleague and I  ran into an issue recently… confronted with the following AD FS R2 access conundrum:

How can we route (automatically) external  logon requests to a third-party claims provider,  continue to route internal logon requests to the native AD claims provider (i.e. maintain transparent SSO), eliminating any Home Realm Discovery (HRD) for our users to have to walk through and select?

Or… to put it more simply. How can one automatically route external route requests to claims provider A, continue to route internal requests to (AD) claims provider B, whilst altogether avoiding Home Realm Discovery (HRD) for all users?

We’ll discuss the exact use case in a moment. This is a RP-initiated work-flow. No IDP-initiated flow or smart links are allowed.

First, a bit of background. Let’s head back to the first look posts on AD FS 2012 R2 in 2013/2014. In there I wrote:

In AD FS R2, HRD customization options through PowerShell now allow us to determine how the UI is presented to the end-user during logon, based on:

1. target suffix resolution – providing suffix routing on a per claims provider basis
2. limiting the claims providers visible for the relying party concerned

With the move to kernel-mode in R2, customization previously possible under IIS in AD FS 2.0 was no longer applicable. To redress this issue and to provide greater flexibility, the above customization options were provided. Suffix routing enables AD FS 2012 R2 to select an appropriate claims provider based on the domain suffix credentials provided by that user. Broadly speaking, this is just how O365/Azure AD works in attempting to discover the Federated home realm v Microsoft realm of the connecting user. Similarly, for on-premise AD FS, suffix routing enables us to refine our logon decision-making based on the home realm of the connecting user. Here’s an example:

  • Users from the Cranky Nuts organization, connecting via AD FS, use a domain suffix. Accordingly, we need to send authentication requests to the Cranky Nuts Identity Provider.
  • Users from the Wobbly Wheels organization, connecting via AD FS, use a domain suffix. Accordingly,  we need to send authentication requests to the Wobbly Wheels Identity Provider.

In AD FS 2012 R2 we can configure this within Powershell:

Set-AdfsClaimsProviderTrust –TargetName “Cranky Nuts IdP” –OrganizationalAccountSuffix @(“”)
Set-AdfsClaimsProviderTrust –TargetName “Wobbly Wheels IdP” –OrganizationalAccountSuffix @(“”)

Wonderful! Using this approach can be a little hit and miss though. It’s making certain assumptions about the level at which we’re prepared to divert authentication on, i.e. the domain level. That’s not always the case.

We could, alternatively, opt for the other method: targeting claims provider selection at the Relying Party Trust level. Again, this is  useful functionality. Here’s an example.

Set-AdfsRelyingPartyTrust -TargetName “BodgeIT Inventory ” -ClaimsProviderName @(“”)

This makes the “BodgeIT Inventory” Relying Party/Web Application, available to users of the Cranky Nuts organization, bypassing the local AD claims provider.  Should we need to extend access to additional claims providers, such as our local Active Directory, then we can add that issuer to the mix. The downside of this option, is that we’re forced into making a home-realm discovery selection during logon.

The Suffix and RP-specific claims provider options, therefore, do have some limitations.  Indeed, for the scenario that we were faced with, neither option fit.  In  our situation,  two claims providers existed for a single organization,  with each CP containing the same set of users. The use case?  Two-factor authentication.  The upstream claims provider (CP) provides two-factor authentication (2FA) for users connecting from the outside , while the incumbent local AD claims provider covers local Windows logon.

Of course, two claims providers means Home Realm Discovery (HRD) and HRD can be confusing.  We can remedy this for internal users, ensuring they don’t get the HRD prompt by defaulting to the use of the local AD claims provider via Powershell:

Set-ADFSProperties –IntranetUseLocalClaimsProvider $True

This doesn’t solve the problem for access from the outside. Moreover, we expressly wish to send all connecting users to our 2FA claims provider, rather than to the in-build AD claims provider…. We could use auxiliary authentication provided by the MFA Adapter in AD FS 2012 R2, thereby eliminating the use of the upstream claims provider. However, that might not be feasible as:

  1. Leading with the AD password as the primary authentication credential  may not be allowed.
  2. The vendor has an MFA adapter for AD FS 2012 R2.

Even where the latter is available, the (security) policy prerogative might be that use of  1) is not allowed, thereby overriding (2).

<PLUG>To demonstrate issue, cue favorite authentication platform PointSharp (</PLUG>

PointSharp possess both a Security Token Service (STS) that can stip atop AD FS as a 2FA claims provider role and also have an MFA adapter for AD FS 2012 R2 / 2016. Since use of the MFA adapter has been prohibited by the customer according to the rules above (not wanting to lead with AD password as a primary authentication credential), the STS as a Claims Provider was selected instead.

You’ll recall we turned off HRD for internal users by setting the IntranetUseLocalClaimsProvider setting to TRUE. With the PointSharp STS configured as a claims provider, external users will get continue to get the HRD screen as AD FS cannot determine where the user lives without the appropriate “hint”.  In AD FS 2.0 it was possible to workaround this by customizing the AD FS 2.0 proxy configuration, modifying the Page_Init section of the homerealmdiscovery.aspx.cs file.  We could then remove Active Directory as a claims provider (0)


Once that was done, default realm selection would fall to our other claims provider (STS)

SelectHomeRealm ( PassiveIdentityProvidersDropDownList.SelectedItem.Value );

As you are no doubt aware, IIS has been supplanted in AD FS 2012 R2 with everything running in kernel-mode. Thankfully, all is not lost though. Some of the functionality previously possible under IIS has moved to Javascript and customization of the onload.js script is covered in a couple of scenarios here..

Variables previously living in .NET code-behind are visible in the View Source of the web page of the HRD screens. Options for both claims providers are visible.

….HRD.selection(‘;);” onclick=”HRD.selection(‘’); …….
….HRD.selection(‘;);” onclick=”HRD.selection(‘’); …….

HRD.selection is the main feature of interest. There’s an action on clicking the realm manually that specifies the HRD we require. We can automate this by moving the selection to the onload.js script, thereby automating selection of the PointSharp Claims Provider. First, we need to customize our AD FS setup.

We create a new theme called PointSharp based on the default AD FS theme

New-AdfsWebTheme –Name PointSharp –SourceName default

Export the default theme to allow our customization

Export-AdfsWebTheme –Name default –DirectoryPath c:\scripts

Copy the default onload.js to the C:\Scripts folder and edit it. At the end of the script, we simply add the reference to the PointSharp claims provider using the following syntax (replace with your own CP) :


We then import the new PointSharp theme including the modified onload.js.

Set-AdfsWebTheme -TargetName PointSharp -AdditionalFileResource @{Uri=’/adfs/portal/script/onload.js’;path=”c:\scripts\onload.js”}

Activate the new theme.

Set-AdfsWebConfig -ActiveThemeName PointSharp

External users will be now routed to the PointSharp claims provider for login, whilst AD logon for internal users is still preserved. Please note that this is a GLOBAL change affecting all users of the AD FS farm and test extensively as it might not be your cup of tea…

Customizing AD FS Relying Parties in Windows Server 2012R2

You may recall a previous post from a few weeks back, concerning customization of AD FS Relying Parties in Windows Server 2016.  This functionality is now out-of-the-box in the latest version of AD FS. What was less well-documented was examples of how this could be accomplished in Windows Server 2012 R2. Pierre Audonet from Microsoft has thankfully solved that problem by posting this great article on Technet, that describes how to customize the onload.js script for registering custom URIs and illustrations to bind to your relying parties. Thanks Pierre!

Office 365 and MFA in AD FS 2016 (TP4)

I recently added my O365 tenant, for testing purposes, to a AD FS in Windows Server 2016 TP4 and noticed something rather unusual. Via the AD FS Management snap-in it was not possible to assign an access-control policy in AD FS to my Office365 Relying Party (RP). Looking at my RP Trusts, I could see the Access Control Policy section was blank.


Right-clicking over a Relying Party in AD FS 2016 TP4 reveals an additional menu option for editing Access Control Policies:


Doing this on the O365 RP, only the Issuance Authorization Rules pipeline is visible, nothing else.


If we compare that with a normal RP.


Right-clicking and selecting access control policy, the administrator is presented with the option of choosing an appropriate policy for that RP: in our case, the desire to use multi-factor authentication.

Why this does not appear on the O365 pipeline, I can only speculate. It might be partially explained by the fact that creating the Office 365 Identity Platform relying party is normally performed via PowerShell and Microsoft wanted to keep this procedure ubiquitous across all versions of AD FS since v2.0.  For example, the following command will create the Office 365 Identity Platform RP should it not exist.

Update-MsolFederatedDomain -SupportMultipleDomain -DomainName

Alternatively,  following the principle of Occam’s Razor, it could be Microsoft have simply not got round to updating their code to detect AD FS 2016 during O365 Relying Party creation Smile Either way, from previous experiences of using MFA under Office 365 via AD FS 2012 R2, we do know it IS possible to use MFA with O365, so getting it working with AD FS 2016 just requires a little more effort. ..

Looking at our O365 RP in PowerShell (Get-ADFSRelyingPartyTrust) , we see no access policies configured. Under the O365 Relying Party it’s blank.


Compare this to an RP that does have an access control policy configured:


Since the UI doesn’t allow enabling MFA in an access policy for our O365 RP, playing around with PowerShell reveals that it is possible  using the Set-ADFSRelyingPartyTrust cmdlet .

Set-AdfsRelyingPartyTrust -AccessControlPolicyName ‘Permit everyone and require MFA’ -targetidentifier

Check the O365 relying party (Get-ADFSRelyingPartyTrust) that an Access Control Policy has been added.


In the GUI, we then see the applied policy (Permit Everyone and require MFA) appearing.


Connect to Office 365 and we’re redirected to our AD FS instance. Enter the AD credentials for the user and then MFA kicks in:


As ever, play and test at your own peril Smile

Customizing AD FS Relying Parties in Windows Server 2016 (TP4)

A while back I was lucky enough to chat with a member of the AD FS development team, to compare notes and discuss features missing or lacking in the current release.  One item that popped up and  which I rued the absence of, was the ability to customize relying parties. It turned out that this was a fairly common feature request. This omission, I’m glad to see, has been addressed in AD FS under Windows Server 2016. While the changes described are mostly cosmetic, they do allow some basic changes to the look and feel of the environment and, most importantly, improve overall user experience.  Let’s have a look at some of these.

Our basic configuration consists of a Windows Server 2016 TP4 server with the AD FS role installed and the presence of a relying party trust to a SAML-based web application.  Our relying party, called ‘simpleSAMLphp Demo’, will be the guinea-pig for this little exercise, though it plays no real part besides kicking off the sign-in process (RP-initiated sign-on). All changes are made on the AD FS side to customize the login experience.



Here we tinker with messages presented to the connecting user/device via the Set-AdfsRelyingPartyWebContent cmdlet.

Set-AdfsRelyingPartyWebContent -TargetRelyingPartyName “simpleSAMLphp Demo” -CompanyName “Cepa Fidelis ” -OrganizationalNameDescriptionText “Enter your Access Onion account” -SignInPageDescription “This is for access to simpleSAMLphp Demo RP”



Logos and Illustrations

In addition to customizing messages, it’s also possible to present specific logo and illustrations on a per RP basis. Here we copy the content to the AD FS server and then run the Set-AdfsRelyingPartyWebTheme cmdlet : 

Set-AdfsRelyingPartyWebTheme -TargetRelyingPartyName “simpleSAMLphp Demo” -Logo @{path=”C:\Content\rp1\logo.png”} -Illustration @{path=”C:\Content\rp1\illustration.png”}



…and connecting users are magically transported to the Tirol Winking smile



This allows for page-level changes on a per RP basis. Previously in AD FS 2012 R2, such changes were possible only at the federation service level and thereby applicable to all relying parties.

Set-AdfsRelyingPartyWebTheme -TargetRelyingPartyName “simpleSAMLphp Demo” -OnLoadScriptPath @{path=”c:\content\rp1\onload.js”}

As with Windows Server 2012 R2, we can export the default theme to obtain the javascript (onload.js) that we wish to modify.

Export-AdfsWebTheme –Name default –DirectoryPath c:\content\default

One of the more common onload.js customization changes employed in AD FS 2012 R2 lay with a code change to support the use of sAMAccountName style formatting, similar to that supported in AD FS 2.0. This involved changing the onload.js file and then hardcoding the domain name into the form as described here.


Well, that’s nice, but these examples are just scratching the surface.. Take a look at the Get-AdfsRelyingPartyWebContent cmdlet  and we can see there are multiple additional options that can be changed.


Let’s set a descriptor for additional authentication text.

Set-AdfsRelyingPartyWebContent -TargetRelyingPartyName “simpleSAMLphp Demo” -SignInPageAdditionalAuthenticationDescriptionText “This application requires additional authentication. Please choose the appropriate multi-factor authentication mechanism. Time wasters will be shot.”



Similarly, looking at the cmdlet (Set-AdfsRelyingPartyWebTheme) used to configure logos and illustrations, there’s also some hidden nuggets.


Here, we copy the web theme from one RP (simpleSAMLphp Demo) to another (Office 365). 

Logon to Office 365 and the default AD FS theme has logos and illustration changed.


Note that the text/messaging has not been altered, because we did not elect to change this for our O365 RP via Set-AdfsRelyingPartyWebContent.

Explore… explore… have fun!

Certificate Requests and Server Core (and a little AD FS)

Just a quick post describing how to request an AD FS SSL (service communications) certificate from within Windows Server Core. The OS being used is Windows Server 2016, but, unless otherwise stated, this also applies to Windows Server 2012 R2.

For the enrollment and submission of the request, as well as parsing of the response,  we’ll look at two mechanisms:

  2. PowerShell

The issuing authority is an Active Directory Certificate Services Enterprise CA.


This is the legacy tool uses for certificate enrollment since Windows 2000. While a little cumbersome, it’s provide to be very useful over the years. It’s a command-line utility that parameterizes the request, submission and processing of the request file and certificate response to the Certificate Authority (CA).  As a rule-of-thumb, it’s used where traditional enrollment mechanisms: web enrollment or MMC are not available or valid.

To begin a configuration (TXT) file needs to be created. This serves as an input file for completing information concerning the request. We’ll call it ADFSDEMO.TXT.


Signature= $Windows NT$


Subject = “ 1, OU=Demo, O=Access_Onion, L=City, S=State/Province, C=NL” ;
KeySpec = 1
KeyLength = 2048
Exportable = TRUE
MachineKeySet = TRUE
SMIME = False
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
ProviderName = Microsoft RSA SChannel Cryptographic Provider
ProviderType = 12
RequestType = PKCS10
KeyUsage = 0xa0
Hashalgorithm = sha256 2


OID= ; Server Authentication OID 3

SAN=”” 4

1 is the common name for our certificate, i.e. the federation services URL.

2 specifies a hash algorithm of SHA-256. Note that CNG algorithms are only supported in AD FS in Windows Server 2016. Use SHA-1 for older versions.

3 is the Server Authentication object identifier (OID) required for an SSL certificate

are Subject Alternate Names added for Workplace Join and the new certificate enrollment endpoint in Windows Server 2016 / AD FS 4.0

5  For third-party certificate authorities or a stand-alone AD CS CA, the CertificateTemplate=”WebserverV2″ line can be dropped.

On our AD Certificate Services Enterprise CA, support for Subject Alternate Names (SAN) needs to be enabled:

certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2

net stop certsvc&&net start certsvc

A template called WebServerV2 has been created (this is a copy of the WebServer built-in template, with compatibility level set to Windows Server 2003 and with certificate duration to 2 years).  From CERTREQ.TXT, we generate a REQ (Request) file for submission to the local issuing authority


This is done with the following command:


A response from the local policy filter

Active Directory Enrollment Policy



CertReq: Request Created

And it’s now possible to submit the request file to the CA


The authority requests confirmation via a popup-window


Click on OK and the CA requests a location to save the generated certificate on the local disk of the server. For consistency, we call it ADFSDEMO.CER.

To complete the installation of the certificate the following command is run:

certreq –accept ADFSDEMO.CER


This section is the picture of conciseness as PowerShell simplifies the enrolment process  for us.  Here’s the request, submission and installation of the certificate, succinctly rolled-up into one command.

Get-Certificate -Template WebServerV2 -DnsName,, -Subjectname -CertStoreLocation cert:\LocalMachine\My



Note that on the AD FS server, it’s possible to drop into Powershell to have a look at the issued certificate

dir cert:\localmachine\my

Assuming the server has already been domain-joined, has had the AD FS feature installed (Add-WindowsFeature ADFS-Federation) and a service account  created in AD,  then the configuration wizard of the AD FS farm can begin. Here’s an example of a WID-based deployment for the first farm node, utilizing the thumbprint of the SSL cert. The credentials for the service account are collected via the variable $cred, before being called in the Install-ADFSFarm cmdlet.


Install-ADFSFarm –CertificateThumbprint 57C0D558EC02… –FederationServiceDisplayName ‘Access Onion’ –FederationServiceName –ServiceAccountCredential $cred –OverwriteConfiguration

Till next time..

Interoperability scenarios with simpleSAMLphp and AD FS


Hello all and Happy New Year!

In this post we’ll look at inter-operability scenarios involving simpleSAMLphp and Active Directory Federation Services (AD FS).

simpleSAMLphp is a native PHP application that provides support for a number of authentication protocols/methods. Its origins lie with the SAML protocol, but it also provides support for a range of other authentication protocols (e.g. WS-Federation, OAuth, LDAP, RADIUS).  It’s a very capable and robust platform that can run on a number of different web surfaces.

In this post we’ll be covering identity federation scenarios with simpleSAMLphp and our usual incumbent: AD FS, getting the two to play nicely together.  We’ll look at both sides of the coin via a:

(a)    simpleSAMLphp Service Provider (SP) / AD FS Identity Provider (IdP) pairing.

(b)   simpleSAMLphp Identity Provider (IdP) / AD FS Service Provider (SP) pairing;


In both cases, setup is applicable to both AD FS 2.0 and AD FS 3.0/2012 R2.

For an introduction to simpleSAMLphp, start here.  It runs on a wide variety of web servers (Apache, Nginx, IIS among others).  In these scenarios we’ll use IIS as our web server for deployment.


The latest PHP libraries can be obtained through the IIS Web Platform Installer. In this setup PHP 5.5.x is used and simpleSAMLphp 1.13.x.

The latest binaries for simpleSAMLphp are available via their website (

For SAML integration with AD FS, SSL certificate(s) are required to secure the IIS website(s) and the underlying simpleSAMLphp application(s). This pre-requisite stems from AD FS supporting HTTPS only.  In the test configuration described here, the simpleSAMLphp instances are also published behind an AD FS Web Application Proxy (WAP). The pass-through (reverse) proxy functions of the WAP are then used to publish the simpleSAMLphp IdP/SP endpoints.  On the IIS side, Server Name Indication (SNI) is also enabled. 

The test setup used here comprises four virtual machines:

(i)                  An Active Directory Domain Services (AD DS) and Certificate Services (AD CS) node;

(ii)                An Active Directory Federation Services (AD FS) 2012 R2 Farm node;

(iii)               A Web Application Proxy (WAP) 2012 R2 node;

(iv)              An IIS 8.5 Web server with php loaded as an application. This hosts the simpleSAMLphp Identity Provider (IdP), Service Provider and test applications, under dedicated websites/paths.


The AD DS and AD CS instances provide authentication and the SSL certificates for the IIS web services. On the Web Application Proxy (WAP) a third-party certificate is installed. This goes somewhat against the grain with Microsoft recommendations of using the same certificate pairing on the WAP and AD FS. However, since we’re not using device management/Workplace Join in this scenario, which I believe the requirements stem from, there are no immediate issues.

On our “application server” IIS is installed. Herein, I’ve created four websites (idp1, idp2, site1 and site2), representing two simpleSAMLphp SAML 2.0 identity providers and two simpleSAMLphp service providers. The website configuration can be seen in the below graphic:


In each case the simpleSAMLphp files are unzipped to a folder per function, e.g:

·         c:\inetpub\idp1 and c:\inetpub\idp2 for the SAML identity provider (IdP) root paths

·         c:\inetpub\web1 and c:\inetpub\web2 for the SAML server provider (SP) root paths

In IIS Manager, we can see the folder structure of an exploded simpleSAMLphp configuration for a single instance.


In each instance, under the config folder, a baseurlpath setting in the config.php file is set to indicate the root path for simpleSAMLphp content. By default, this is set to www.  Should we wish to change this, such that the desired path to our simpleSAMLphp is say  rather than the default, then we make the change to the baseurlpath from ‘www/’ to auth/ and rename the www folder accordingly. Note the use of the trailing slash that should always be present in the  baseurlpath value.

From a simpleSAMLphp standpoint, there’s a few tweaking steps required before we get going in our test setup.

By default, a secretsalt setting is configured in the config.php file and it’s strongly recommended to change this. This should be a random string, as the salt is used to generate cryptographically secure hashes.

Also, we should consider getting logging working properly. This will reap dividends later when it comes to troubleshooting. As with other settings so far mentioned, logging settings are defined in config.php.

Firstly, debug is enabled via setting:                               

‘debug’ => TRUE,

By default, the logging level is set to SYSLOG.  Here we’ll also switch the logging level to DEBUG and then alter the handler to file. This is done by setting the following values:

     ‘logging.level’         => SimpleSAML_Logger::DEBUG,

       ‘logging.handler’       => ‘file’,


In later sections of the CONFIG.PHP file, the output filename is also specified. This writes to the log folder of the instance.

‘logging.logfile’          => ‘simpleSAMLphp.log’,

This log file lives under the /log folder of the simpleSAMLphp instance. However, simply specifying the file to use is not sufficient for logging under IIS to work.   For that little feat, the IUSR needs to been given modify access to the simpleSAMLphp logfile.


Repeat this process for each instance of simpleSAMLphp running under IIS on your server(s), giving the IUSR account the appropriate permissions.

Once logging has been configured, we can see the benefits of verbose logging as it provides a rich level of detail. Here’s a sample:


Sep 19 17:30:19 simpleSAMLphp DEBUG [5805446797]       <Attribute xmlns:a=”; Name=”; a:OriginalIssuer=”CLIENT CONTEXT”>

Sep 19 17:30:19 simpleSAMLphp DEBUG [5805446797]         <AttributeValue>172.16.x.6</AttributeValue>

Sep 19 17:30:19 simpleSAMLphp DEBUG [5805446797]       </Attribute>

Sep 19 17:30:19 simpleSAMLphp DEBUG [5805446797]       <Attribute xmlns:a=”; Name=”; a:OriginalIssuer=”CLIENT CONTEXT”>

Sep 19 17:30:19 simpleSAMLphp DEBUG [5805446797]         <AttributeValue>212.x.y.5</AttributeValue>

Sep 19 17:30:19 simpleSAMLphp DEBUG [5805446797]       </Attribute>

Sep 19 17:30:19 simpleSAMLphp DEBUG [5805446797]       <Attribute xmlns:a=”; Name=”; a:OriginalIssuer=”CLIENT CONTEXT”>

Sep 19 17:30:19 simpleSAMLphp DEBUG [5805446797]         <AttributeValue xmlns:tn=”; xmlns:b=”; b:type=”tn:boolean”>false</AttributeValue>

Sep 19 17:30:19 simpleSAMLphp DEBUG [5805446797]       </Attribute>

Sep 19 17:30:19 simpleSAMLphp DEBUG [5805446797]       <Attribute xmlns:a=”; Name=”; a:OriginalIssuer=”CLIENT CONTEXT”>

Sep 19 17:30:19 simpleSAMLphp DEBUG [5805446797]         <AttributeValue>/adfs/ls/</AttributeValue>

Sep 19 17:30:19 simpleSAMLphp DEBUG [5805446797]       </Attribute>

Sep 19 17:30:19 simpleSAMLphp DEBUG [5805446797]       <Attribute xmlns:a=”; Name=”; a:OriginalIssuer=”CLIENT CONTEXT”>

Sep 19 17:30:19 simpleSAMLphp DEBUG [5805446797]         <AttributeValue>Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.3; WOW64; Trident/7.0; Touch; .NET4.0E; .NET4.0C; .NET CLR 3.5.30729; .NET CLR 2.0.50727; .NET CLR 3.0.30729; Tablet PC 2.0; InfoPath.3; MASEJS)</AttributeValue>

Sep 19 17:30:19 simpleSAMLphp DEBUG [5805446797]       </Attribute>

Sep 19 17:30:19 simpleSAMLphp DEBUG [5805446797]       <Attribute xmlns:a=”; Name=”uid” NameFormat=”urn:oasis:names:tc:SAML:2.0:attrname-format:basic” a:OriginalIssuer=””&gt;

Sep 19 17:30:19 simpleSAMLphp DEBUG [5805446797]         <AttributeValue>student</AttributeValue>

Sep 19 17:30:19 simpleSAMLphp DEBUG [5805446797]       </Attribute>

Sep 19 17:30:19 simpleSAMLphp DEBUG [5805446797]     </AttributeStatement>


Back in IIS, I’ve elected to employ the services of our friend Server Name Indication (SNI). This is defined on the website. Unlike with AD FS, SNI is an option under IIS J



SNI allows us to run multiple web sites under IIS, using different certificates/domain combinations per website, all bound to a shared single IP address. This makes it possible in this test setup to run with numerous instances of simpleSAMLphp, in identity and service provider roles, all on the same server; without having to deal with the hassle of SSL Host Headers, listener changes, tweaking friendly names on certificates etc.

Web server setup itself is pretty straightforward. For simpleSAMLphp instances, either identity or service provider, we prep the web server with the following steps:

    1. create an A record for the URL in AD DNS, e.g.
    2. create an A record for the URL in Internet/External  DNS and point this to the IP address/VIP of the Web Application Proxy.
    3. create a website in IIS for simpleSAMLphp and point the configuration to the baseurlpath, of your choice, e.g. c:\inetpub\wwwroot\idp1\www
    4. add an SSL binding on the website, with Require Server Name Indication (SNI) enabled and a host header matching the URL, e.g.
    5. publish the new website on the reverse proxy (Web Application Proxy) using a pass-through rule
    6. configure the simpleSAMLphp configuration as described later in the post
    7. repeat for each additional new instance

Web Application Proxy (Optional)

In this lab, we’re using the AD FS Web Application Proxy (WAP) to reverse proxy HTTPS traffic to the various simpleSAMLphp endpoints. The following pass-through proxy rules are created.


External URL

Backend Server URL











No name/URL translation is performed. Servers idp1 and idp2 are SAML 2.0 identity providers, whilst web1 and web2 are SAML 2.0 service providers.

For integration testing with AD FS, we’ll run through the following scenarios:

1.       configuring AD FS as an Identity Provider and simpleSAMLphp as a service provider

2.       configuring simpleSAMLphp as an Identity Provider and AD FS as a service provider


Scenario 1 – AD FS Identity Provider (IdP) and simpleSAMLphp Service Provider (SP)

Let’s start with simpleSAMLphp in the SAML 2.0 Service provider (SP) role.

For a basic configuration, there are a number of key simpleSAMLphp files we work with. These are:




In the authentication sources document (authsources.php), various service provider properties are defined. A single authsources.php containing information of all setups can be used and shared across multiple environments, in our case (web1 and web2), or we may elect to store settings separately, using a unique authsources.php per environment .

For expediency, I highlight the use of a common authsources.php. Each authentication module/configuration is represented by its own section in the document.

Here’s an example of two SAML service provider configurations in a test authsources.php:


‘onion1-sp’ => array(



              ‘entityID’ => NULL,

‘idp’ => NULL,

              ‘discoURL’ => NULL,


              ‘redirect.sign’ => TRUE,

              ‘assertion.encryption’ => TRUE,

              ‘sign.logout’ => TRUE,

              ‘privatekey’ => ‘web1.key’,

              ‘certificate’ => ‘web1.pem’,




       ‘attributes’ => array(




       ‘signature.algorithm’ => ‘;,





‘onion2-sp’ => array(



‘entityID’ => NULL,

              ‘idp’ => NULL,

              ‘discoURL’ => NULL,


              ‘redirect.sign’ => TRUE,

              ‘assertion.encryption’ => TRUE,

              ‘sign.logout’ => TRUE,

              ‘privatekey’ => ‘web2.key’,

              ‘certificate’ => ‘web2.pem’,



       ‘attributes’ => array(




       ‘signature.algorithm’ => ‘;,





Notice the different section names (onion1-sp and onion2-sp) and use of separate certificate keypairs (web1 and web2) in each section.  With the entity ID/identifier set to ‘entityID’ => NULL, simpleSAMLphp will handle the naming for the (RP) identifier of that service provider * and an entity ID is generated based on the metadata URL. In the above config, using and as URLs, this would translate to:


It’s also perfectly acceptable for you to choose your own identifier in the entityID section, rather than defaulting to NULL.


The IdP section refers to the entity ID (identifier in AD FS terminology) of the IdP that the service provider (SP) should contact. Like the entity ID value of  NULL used for the simpleSAMLphp service provider, this can also be set to NULL for the idp value. Where multiple identity providers exist, then the user will be shown a list of available IdPs to select from.






To corroborate the identity of the service provider, we can (optionally) digitally sign requests and a certificate is required to accomplish this.  Reference to this cert for a service provider (SP) is made in simpleSAMLphp by the privatekey and certificate setting values in the authsources.php.


By default, simpleSAMLphp uses the same certificate for token signing and encryption. The certificates comprising the private key (.key) and public key (.pem) will reside in a cert folder  made off the SimpleSAMLphp base configuration path.


‘privatekey’ => ‘web1.key’,

              ‘certificate’ => ‘web1.pem’,


In this particular configuration, we’ve elected to enable the SP to sign authentication requests (redirect/post), using the the `redirect.sign` =>TRUE option.

While use of signing and encryption is generally considered an unsightly configuration overhead and an optional, use of token signing comes into play with SAML requirements for Single Logout (SLO) and where service providers request specific functionality. As an identity provider, AD FS does expect SAM 2.0 service providers (simpleSAMLphp) to sign logout requests. With this in mind, we elect to use certificates and logout requests are signed by the SP, specifying ‘sign.logout’ => TRUE. 


To satisfy the above requirements, when creating the token signing/encryption certificate(s) for simpleSAMLphp, OpenSSL is used here to generate a certificate using the SHA2 signing algorithm. Here’s an example (2 year validity).

openssl req -x509 -nodes -sha256 -days 730 -newkey rsa:2048 -keyout my.key -out my.pem


If we’re not satisfied with simply signing tokens, then we can also require the content of the token to be encrypted, by requesting encryption using ‘assertion.encryption’ => TRUE.


Our SP is expecting that the AD FS identity provider will provide the attributes uid and mail attributes in the SAML response, as expressed by:


‘attributes’ => array(





A SHA2 (SHA256) algorithm is used to sign messages generated by the service provider. 


‘signature.algorithm’ => ‘;


If you’re not up to date on this and as the help text in the configuration files explain, SHA-1 as a signing algorithm is largely being supplanted by use of stronger schemes.


At this point we have the makings of a basic setup authentication-wise. Additionally, simpleSAMLphp needs to be made aware of the AD FS identity provider configuration. This is collected from federation metadata belonging to the AD FS IdP and then stored in the saml20-idp-remote.php file, located in the metadata folder. This file contains configuration details for all remote SAML 2.0 Identity Providers (IdP) known to that service provider.

As we’ll see, the process for pruning metadata and converting it into a simpleSAMLphp friendly format is useable for both service providers and identity providers, thereby applicable for Scenario 2.

Getting the AD FS metadata into a simpleSAMLphp-friendly format is aided by using tools found under the installation page simpleSAMLphp (matching the baseurlpath path). Browsing to the service provider URL, e.g. shows the simpleSAMLphp installation page.


It’s a good idea to password protect this page. This can be done by editing settings in the config.php file. The settings described therein protect the main admin page and the ensuing metadata pages.

‘auth.adminpassword’          => ‘adminpasswordtobeset’,

‘admin.protectindexpage’      => true,

‘admin.protectmetadata’       => false,


In the above, the installation page is protected and metadata left unprotected to allow automated exchange.

The installation pages allow us to perform a number of tests to prepare and configure the installation.

    1. Review the simpleSAMLphp configuration, installed/enabled modules, PHP versions etc.
    2. Use the built-in tools to parse federation metadata from identity or service providers, e.g. AD FS, subject to role, using the XML to simpleSAMLphp metadata converter.
    3. Validate the configuration by testing configured authentication sources (applies to both identity and service provider roles) via the authentication tab
    4. Observe federation metadata endpoints configured and exposed simpleSAMLphp (valid for both identity and service provider configurations)

The Federation tab on the installation page provides useful information relating to metadata and tools for assisting in the setup of federation trusts. At the foot of the federation screen, note the XML to simpleSAMLphp metadata converter.


Use this to convert federation metadata from remote sources into a simpleSAMLphp friendly format.


Here the metadata from the AD FS SAML 2.0 Identity Provider (IdP) needs to be converted for consumption by the simpleSAMLphp service provider. Download the metadata from AD FS and save it to a text file. Metadata is reachable at:

https://<YOUR FEDERATION SERVICE URL/FederationMetadata/2007-06/FederationMetadata.xml

Open the file in Notepad, copy the contents to the Metadata parser in the browser and then click on the Parse button. This will convert metadata into two formats:

(a)    saml20-sp-remote.php used where AD FS is a remote SAML 2.0 Service Provider

(b)   saml20-idp-remote.php used where AD FS is a remote SAML 2.0 Identity Provider

Since AD FS is the identity provider in this scenario, then we require Option (b). In the converted metadata section of the page, find the section relating to saml20-idp-remote.php and copy the text to clipboard. Open the saml20-idp-remote.php file found in the metadata folder of the IdP configuration, paste the contents, appending the parsed metadata into this file and save it.

NB: I’ve read on the simpleSAMLphp forums that it’s also possible to save files to the metadata folder and reference these in your configuration directly. I’ve not tested this, but if interested it’s worth checking out the simpleSAMLphp github on how this can be done.

Back at the installation page, the federation tab is also worth checking out. It shows the SAML 2.0 SP metadata endpoint information needed to configure the simpleSAMLphp relying party on the AD FS side. Here’s an example of a shared configuration file (authsources.php) representing multiple service providers.


If the simpleSAMLphp URL is reachable by the AD FS IdP, then automatic exchange of metadata is possible. Where the metadata page is password protected, then file exchange of metadata can be performed.

Let’s jump to AD FS now. We’ll add the SP instance, utilizing the “default-sp” label as our SAML 2.0  relying party of interest.


Here our endpoint is reachable across the “Internet” so we can automatically configure the RP by consuming the metadata of the service provider concerned. We create our relying party and simply take the URL mentioned above, parse it into the wizard and AD FS consumes the remote XML document automatically. Should this not be possible, say where the metadata document is password protected, or policies at the SP state otherwise, we can import the file using the AD FS wizard as mentioned earlier.

In the Issuance Transform rules on the Relying Party (RP), we can mine the claims from AD (as our claims provider), to populate the simpleSAMLphp requirements. In this example we:

          use the Send LDAP attributes as claims rule to send E-Mail Address and sAMaccountName as uid and mail, required by this relying party

          use a transform rule to send a Name Identifier in the transient format


As can be seen from the above graphic, we’re using E-Mail Address and sAMAccountName to use as incoming claims to populate in our  outgoingSAML assertion as mail and uid respectively.

Incidentally, when initiating federated logon with the SAML 2.0 protocol, a name identifier is typically used.   AD FS as an identity provider, does not send name identifier information in the format expected by simpleSAMLphp. By default, simpleSAMLphp expects a nameid format using the transient identifier (urn:oasis:names:tc:SAML:2.0:nameid-format:transient).

A quick way to get this going, albeit not conforming to SAML specs, is to transform an incoming claim rule, extracted from our AD provider, to populate as an outgoing name identifier.


In the above UI example an incoming UPN claim is transformed into a transient identifier.

Using the claims rule language, the two rules can be expressed as issuance transform rules on the simpleSAMLphp relying party as:

c:[Type == “;, Issuer == “AD AUTHORITY”]

 => issue(store = “Active Directory”, types = (“mail”, “uid”), query = “;mail,sAMAccountName;{0}”, param = c.Value);


c:[Type == “”%5D

 => issue(Type = “;, Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType, Properties[“”%5D = “urn:oasis:names:tc:SAML:2.0:nameid-format:transient”);


Verifying the RP configuration, we should see both token signing and encryption certificates represented in the appropriate tabs on the relying party, populated among other settings as part of the metadata exchange.


Above, the public key of the token signing certificate, on the Signature tab of the RP.


And on the encryption tab, the public key of the encryption certificate from simpleSAMLphp.


On the Advanced tab, the secure hash algorithm should be set to SHA-256


We’re now good to go for testing the configuration within simpleSAMLphp.

Here I select the Test configured authentication sources on the authentication tab.



Then choose to test the default-sp configuration.


If the idp value for the service provider in authsources.php is set to NULL, then a drop-down list of identity providers will  be presented (otherwise we’re routed automatically to AD FS)

Here’s an example of a drop-down dialog with the Access Onion identity provider selection.


This particular identity provider is running AD FS 3.0/2012 R2. Connecting from the Internet, we’re routed to the Access Onion AD FS instance (behind the Web Application Proxy) and presented with a logon form.


As part of the logon process the appropriate user credentials are posted to AD FS, in this case user mylo.  Sent back in the SAML response is also the e-mail address of the user, read from the mail attribute in Active Directory, with a value of  nomail@accessonion  for this user.  The resultant SAML assertion can be seen in simpleSAMLphp.



Note that the name identifier is not visible on the installation page, although its presence is mandatory.

Click on Logout to check that Single Logout is also functioning and that the two federation partners are configured correctly, signing algorithms are in synch etc.


And we’re logged out, token extinguished/gone.

This is a barebones configuration. Should you wish to employ more expansive configurations, incorporating simpleSAMLphp into the PHP code of your web application (Drupal/Moodle/Joomla etc.), then refer to the simpleSAMLphp website, where there are examples to illustrate this.

Quick note on Name Identifiers

With respect to the earlier comment on the SAML protocol and NameID, when passing a name identifiers of a transient sort, it’s preferable to use an opaque identifier commuted between relying parties that doesn’t reveal the identity of the individual concerned.  To get a better insight into this with respect to AD FS and SAML, I’d suggest reading this MSDN article, as it provides examples on how privacy-bearing claims can be used.

If we wish to use an opaque reference, borrowing from the aforementioned article:

Rule 1: generate a session ID value that can be used as a transient identifier. Add this rule to the claims pipeline.

c1:[Type == “”] && c2: [Type == “”]=> add (store = “_OpaqueIdStore”, types = (“”), query = “{0};{1};{2};{3};{4}”, param = “useEntropy”, param = c1.Value, param = c1.OriginalIssuer, param = “”, param = c2.Value);

Rule 2:  Using the previously generated session ID, map this to the outgoing claim type  as Name ID using the transient identifier and issue the claim.

c:[Type == ””] => issue(Type=””, Issuer = c.Issuer, OriginalUser = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType, Properties[“”]=”urn:oasis:names:tc:SAML2.0:nameid-format:transient”);

Now let’s look at a sample scenario where AD FS is the SAML 2.0 Servicer Provider (SP) and simpleSAMLphp is the SAML 2.0 Identity Provider (IdP)

Scenario 2 – simpleSAMLphp Identity Provider (IdP) and AD FS Service Provider (SP)

In the identity provider (IdP) capacity, simpleSAMLphp supports a number of authentication methods. These include:

·         Local authentication

·         Single LDAP/AD

·         Multi-LDAP

·         RADIUS

·         SQL

·         OpenID (FB/Twitter etc.)

·         Yubikey


That’s quite a diverse set of authentication mechanisms. There are also a number of additional custom modules developed within the community that support even more refined use cases.

We’ll look at a basic setup utilizing local authentication; namely, username/passwords stored in a flat file in the authsources.php file of the simpleSAMLphp IdP. As unglamorous as this might sound, it’s a good starting point for getting a working configuration up and running before mixing it with other more complex setups involving LDAP/RADIUS/SQL etc.

There are a number of files we work with in the identity provider configuration. These are:





On the SAML SP side, AD FS will be using simpleSAMLphp as a claims (identity) provider. We’ll also reuse the simpleSAMLphp SAML 2.0 service provider from Scenario 1 as a relying party (behind AD FS) to illustrate attribute flow.


Here’s the basic logon flow:

1.       User browses to the simpleSAMLphp Relying Party.

2.       User selects the AD FS authentication source and is redirected to AD FS.

3.      Rules logic on the AD FS determines that the user should be directly sent to the simpleSAMLphp claims provider, without showing a realm discovery page.

4.       User is redirected to simpleSAMLphp identity provider for logon where they log on as student

5.       User logs on with local identity (from authsources.php)

6.       User is redirected to AD FS for processing

7.       Claims provider rules are evaluated on the AD FS pipeline

8.       Relying Party rules are evaluated on the AD FS pipeline

9.       User is redirected to the simpleSAMLphp relying party

With all working swimmingly, we’ll end up on the simpleSAMLphp relying party page.


In this logon scenario, we’re using AD FS as Relying Party Security Token Service (RP-STS) in a “headless” capacity. It (AD FS) is not responsible for authentication but must still handle routing of the authentication request to the simpleSAMLphp relying party / test web application.  

In a multiple claims provider scenario, when sending requests via AD FS, we would normally be presented with the Home Realm Discovery (HRD) screen.


As can be seen from the above graphic, with AD FS (via AD) enabled as a claims provider, the “Access Onion” claims provider AND the simpleSAMLphp identity provider are both visible as authentication sources. For this scenario we want to exclusively send logon requests to the simpleSAMLphp identity provider, so the (home) realm selection needs to be suppressed for the simpleSAMLphp relying party/test web application. As mentioned in previous “First Look” posts on AD FS 2012 R2, this can be achieved by declaring the claims provider of choice for the relying party to use for logon in PowerShell.

Set-AdfsRelyingPartyTrust -TargetName “My Relying Party” -ClaimsProviderName @(“SimpleSAMLphp”)

This effectively takes the Access Onion Active Directory out of the mix for logon.

Back to simpleSAMLphp, we begin by enabling the SAML 2.0 identity provider functionality in config\config.php for our identity provider ( instance.

‘enable.saml20-idp’ => true,

Assigning true to this option enables the SAML 2.0 Identity Provider capability in this instance.

The saml20-idp-hosted.php file in the metadata folder is key for configuring the identity provider. Here’s an example (in bold) calling a local (simpleSAMLphp) authentication method known as example-userpass.


$metadata[‘__DYNAMIC:1__’] = array(

    ‘host’ => ‘__DEFAULT__’,

    ‘privatekey’ => ‘idp1.key’,

    ‘certificate’ => ‘idp1.pem’,

    ‘auth’ => ‘example-userpass’,

    ‘signature.algorithm’ => ‘;,

    ‘authproc’ => array(1 => array(‘class’ => ‘saml:TransientNameID’,),),


You may recognize common aspects of the configuration from the SP scenario applied previously in the authsources.php. Similarly these can be applied to our identity provider configuration in the saml20-idp-hosted.php file.

The identity provider calls the example-userpass authentication scheme from the saml20-idp-hosted.php file.  

The authentication element, expressed as ‘auth’ => ‘example-userpass’, cross-references the appropriate section of the authsources.php file, containing therein a list of users.

‘example-userpass’ => array(


      // Give the user an option to save their username for future login attempts

      // And when enabled, what should the default be, to save the username or not

      //’remember.username.enabled’ => FALSE,

      //’remember.username.checked’ => FALSE,


      ‘student:pa$$st@dent’ => array(

             ‘uid’ => array(‘student’),

             ‘mail’ => array(‘’),

             ‘eduPersonAffiliation’ => array(‘member’, ‘student’),


      ’employee:3mployEEP&ss’ => array(

             ‘uid’ => array(’employee’),

             ‘mail’ => array(’’),

             ‘eduPersonAffiliation’ => array(‘member’, ’employee’),




There are two test users: student and employee, with attributes uid and mail populated. As with Scenario 1, to build a federation trust with AD FS, information must be gathered via exchange of metadata to make the trust possible. For the simpleSAMLphp identity providers, extrapolated metadata from the remote AD FS service provider is stored in the saml20-sp-remote.php file in the metadata folder. On the AD FS side, we need to create a relying party trust for our test web application. We’ll re-use the service provider/relying party created in Scenario 1.

To populate the identity provider with the relevant information, the AD FS metadata file needs to be imported to the simpleSAMLphp identity provider (IdP) instance.

Open the installation page of the identity provider, e.g., authenticating where necessary, and select the federation tab.  

Download the AD FS federation metadata from the metadata endpoint and save it to text file.

https://<YOUR FEDERATION SERVICE URL/FederationMetadata/2007-06/FederationMetadata.xml

Open the AD FS metadata file in Notepad, copy the content to the clipboard and then launch the XML to simpleSAMLphp metadata converter on the federation tab.


Paste the contents to the Metadata parser form in the browser and then click on the Parse button.


Scroll down to the saml20-sp-remote.php section of the web page


Copy this section of text to clipboard.


In the identity provider configuration, open the saml20-sp-remote.php file found in the metadata folder and append the parsed metadata held in clipboard to this file. Save the file.

As a SAML service provider, during passive SSO logons, AD FS makes use of a default name identifier of emailaddress. This can be seen from the metadata screenshot (circled in green):

‘NameIDFormat’ => ‘urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress’,


Given that our identity provider prefers the transient format, this can be altered using Powershell by specifying the required NameID format. More on this in a moment….


From the identity provider ( installation page of simpleSAMLphp, the metadata endpoint information is visible on the federation tab. This corresponds to the Entity ID of the identity provider. This URL is used to configure the claims provider on the AD FS side.


Should the simpleSAMLphp IdP endpoints be visible to support online exchange of metadata with AD FS, then the claims provider can be configured automatically. Where metadata is password protected, or the published path of the endpoint is not reachable (for security reasons), then manual exchange of metadata via file will be necessary.

We now have sufficient information to create the claims provider on the AD FS side. In the Add Claims Provider Trust wizard, the above-mentioned URL is used.


As always I recommend the use of PowerShell over the UI for automating this process. While the initial learning curve/overhead is somewhat higher, it will reduce the margin for human error and also provides documented evidence and a path on how installations/configurations are performed.

Since we are hand-waving authentication to simpleSAMLphp as claims provider, any incoming attributes will need to be processed by AD FS as part of the logon process at both the claims provider and relying party.

Firstly, we’ll override the default AD FS behavior of using SAML 1.1 name identifiers (mail) in favor of the transient identifiers mentioned earlier. To do this the expected name identifier required by the identity provider (simpleSAMLphp) can be stated in PowerShell.


Set-AdfsClaimsProviderTrust -TargetName “simpleSAMLphp Identity Provider” -RequiredNameIDFormat “urn:oasis:names:tc:SAML:2.0:nameid-format:transient”


The following SAML attributes, expressed as claims rules on the claims provider handler, are defined:


1.       Transient Name identifier

c:[Type == “;, Properties[“”%5D == “urn:oasis:names:tc:SAML:2.0:nameid-format:transient”]

 => issue(claim = c);

2.       uid

c:[Type == “uid”]

 => issue(claim = c);

3.       mail

c:[Type == “mail”]

 => issue(claim = c);


In a completed configuration, if we were to enable debug and analytics on the AD FS server, we can see the claims processed via Event ID 1000 in the AD FS Debug tracing logs. Note the transient name identifier claim type value of _60b434c232f5cc7048fb85d80ea4c8775d38489f90 being passed when logging on using a test (student) user.


ClaimType Value _60b434c232f5cc7048fb85d80ea4c8775d38489f90 ValueType Issuer OriginalIssuer Property[] urn:oasis:names:tc:SAML:2.0:nameid-format:transient Property[] ClaimType uid Value student ValueType Issuer OriginalIssuer Property[] urn:oasis:names:tc:SAML:2.0:attrname-format:basic ClaimType mail Value ValueType Issuer OriginalIssuer Property[] urn:oasis:names:tc:SAML:2.0:attrname-format:basic ClaimType eduPersonAffiliation Value member ValueType Issuer OriginalIssuer Property[] urn:oasis:names:tc:SAML:2.0:attrname-format:basic Value student Property[] urn:oasis:names:tc:SAML:2.0:attrname-format:basic 


Wonderful J


Meanwhile, we need to ensure on the relying party/test web application, our simpleSAMLphp relying party from Scenario 1, that the appropriate rules are applied to ensure that claims originating from the issuer (simpleSAMLphp Identity Provider) are evaluated.

The two test users defined in config.php of the identity provider will emit two SAML attributes of interest for AD FS to process (uid and mail):

‘student:studentpass’ => array(

             ‘uid’ => array(‘student’),

             ‘mail’ => array(‘’),

             ‘eduPersonAffiliation’ => array(‘member’, ‘student’),


      ’employee:employeepass’ => array(

             ‘uid’ => array(’employee’),

             ‘mail’ => array(’’),

              ‘eduPersonAffiliation’ => array(‘member’, ’employee’),

To reiterate, we wish to pass identity-specific information originating from a SAML 2.0 identity provider (simpleSAMLphp), via AD FS as a SAML 2.0 Service Provider (RP-STS), to our test SAML 2.0 Service Provider/Relying Party (simpleSAMLphp). 

For the relying party, the fact that I’m using simpleSAMLphp (from Scenario 1) is merely for expediency. The application/relying party concerned may well be another application, i.e. a Cloud/SaaS or on-premise offering. However, the attributes mentioned above need to be passed by the identity provider through AD FS to the relying party application. For those not experienced with using claims providers with AD FS, this can sometimes be a little confusing.

In Scenario 1, we created a simpleSAMLphp relying party that surfaced claims from the local Active Directory as the claims provider (identity provider) using the Send LDAP Attributes as Claims claim ruleset.  This particular ruleset is not applicable to claims emitted for our simpleSAMLphp claims provider. Let’s look at the custom claims rule again:

c:[Type == “;, Issuer == “AD AUTHORITY”]

 => issue(store = “Active Directory”, types = (“mail”, “uid”), query = “;mail,sAMAccountName;{0}”, param = c.Value);


Note the reference to AD AUTHORITY. This is specifically targeting the local home Active Directory as the issuer for the claim.  When authentication is handled through the simpleSAMLphp identity provider, this rule is ignored.

Our test application (the same one used in Scenario 1) is expecting attributes uid and mail to be passed from AD FS.  We could add a single rule that states passing all claims rules to be processed by the relying party, covering the claims from the identity provider described above.


 => issue(claim = c);


This satisfies the requirement of passing the name identifier, uid and mail attributes from the simpleSAMLphp identity provider, but it also passes additional information from the AD FS RP-STS to the relying party.


Note the additional claims such as client IP, forwarded (NAT) client IP, user agent etc.

Alternatively, we could define three pass-through rules, expressly bound to the simpleSAMLphp identity provider through the issuer value.  Instead of sending all claims values, we only emit claims specific to that identity provider for the attributes concerned on the relying party rules.

1.       Name Identifier

c:[Type == “;, Properties[“”%5D == “urn:oasis:names:tc:SAML:2.0:nameid-format:transient”, Issuer == “”%5D => issue(claim = c);

2.       uid

c:[Type == “uid”, Issuer == “”%5D

 => issue(claim = c);

3.       mail

c:[Type == “mail”, Issuer == “”%5D

=> issue(claim = c);

Here we see the difference from the simpleSAMLphp relying party/web application in terms of claims/attributes emitted in the SAML response.


OK.. that’s it for this post. Feel free to post questions and and I’ll get back to you as soon as possible.

As ever: test, play and test a little more Smile



MFA Conditional Access Policies in AD FS 2012 R2

Hello again. The previous Multi-Factor Authentication (MFA) post on User Certificates provided an opportunity to expand and look at  some of the more interesting scenarios for MFA conditional access.  This “interest”, if I may call it that, stemmed from playing around with MFA over the last few months and looking at the role of conditional access polices therein.

Ramiro Calderon wrote a great article on MFA policy here and it comes highly recommended. As he mentions in his post, the AD FS claims engine computes MFA authentication requests (defined via the AD Management UI) in a logical OR fashion. This can be initially a little confusing and we’ll take a look at some more creative use of MFA policies, to handle more flexible access scenarios in R2.

MFA Primer

To make use of MFA, an MFA provider is required. In a vanilla AD FS R2 setup, this is limited to certificate authentication using client certificates (see previous post). For other MFA options, check with your favorite 2FA vendor to see if they’ve written an MFA adapter for AD FS R2.

In the global authentication policy, the MFA provider needs to be enabled.


Let’s have a look at what happens when MFA is enabled through the AD FS Management UI. MFA policies can be triggered either globally (applicable to all relying parties), or on the relying party itself.

In the example below, MFA is required for securing access to applications outside of the organization, what Microsoft call Extranet use.


Users connecting from outside the corporate network will be prompted after successful AD username/password authentication by the MFA handler.

When the MFA policy is set globally, this can be seen in PowerShell via the Get-AdfsAdditionalAuthenticationRule

c:[Type == "", Value == "false"] => issue(Type = "", Value = "");

If a global authentication policy is not specified, but the policy is enabled in a relying party rule, then an additional authentication rule, defined on the RP, is evaluated. This allows for a more refined use of policy and I’ll show examples of this, by way of scenarios, later in the post.

The AD FS Management UI is sufficient for applying the use of MFA in most single “context” access scenarios. By this I mean, we are able to enforce the requirement of MFA to satisfy policies, that stipulate additional authentication is required by use of one of either user/group, device or location. For example, if we determine that a MFA policy needs to be used by location only, e.g. Extranet, we simply select the Extranet location checkbox. All users connecting from outside of the corporate network must then use MFA. Conversely, if we want to enforce MFA for a specific subset of users/groups, irrespective of their location (Extranet/Intranet), by adding them via the users/groups option in the UI, this can be  also be set. Finally, we can also specify that unregistered or registered devices (a la Workplace Join) need to use MFA, via the devices checkboxes. The fact that these policies may also be applied independently on a per relying party basis, often satisfy basic access policy needs.

The challenge arises when dealing with a combination of policy, for example, when stating an MFA requirement by device and by location.


AD FS will now trigger MFA when an unregistered device (non-workplace joined) connects to AD FS AND also when users are connecting from the Internet  The policies are evaluated independently and we may unwittingly be enforcing MFA for a registered device in a Workplace Join scenario, when the desired outcome was actually to ensure that a single authentication factor (the device certificate paired with the user concerned) was sufficient for access from the outside. This is the logical OR behavior that Ramiro refers to in his post.

Similar behavior can be observed if the following settings are made.


Here we have a specific user/group requiring MFA and also the location (Extranet) checkbox is checked. Users who are members of the GU-SEC-ADFS-MFA group must always use MFA, irrespective of their location AND other users, connecting from outside of the corporate network, will be challenged by the MFA handler. Again, if the intention was to enforce MFA for a combination of outcomes; namely, by group and location outside, then this is not the outcome.

Rules  are evaluated independently when set via the UI. Given that requirements via the UI operate this way, if there is a requirement to enforce MFA via policy where:

      • it’s an unregistered device AND
      • connecting from the Internet
                OR in the second example where:
              • user is member of group X AND
              • connecting from the Internet

            The AD FS Management  UI doesn’t support this arrangement. Instead, more refined policies can be handled with PowerShell, using combinations of authentication rules. As with the UI, this can be expressed either as a global authentication policy applicable to all relying parties (Set-AdfsAdditionalAuthenticationRule) or MFA policies defined on a per relying party basis (Set-AdfsRelyingPartyTrust).  I’ll use the latter to drum up examples of setting finer-grained access rules in the scenarios that follow. More work for us admins, but greater flexibility to boot…

                    Scenario A: Externally connecting workplace joined device (registered user)

              Requirement: Registered users on Workplace Join devices connecting from outside the corporate Internet may authenticate using the device authentication certificate. All other users/devices must use MFA.

            $rp = Get-AdfsRelyingPartyTrust –Name "WIF Test Application"
            Set-AdfsRelyingPartyTrust –TargetRelyingParty $rp –AdditionalAuthenticationRules ‘c: [Type == "
  ", Value == "false"] && [Type == "", Value == "false"] => issue(Type = "", Value = "");’

              Requirement: Users who are members of Group X are exempt from a general policy stipulating use of MFA when connecting from the outside of  the network. All other users must use MFA. Note: We flip the behavior with the Group SID claim use in Scenario B by using the NOT EXISTS evaluation.

              $rp = Get-AdfsRelyingPartyTrust –Name "WIF Test Application"
              Set-AdfsRelyingPartyTrust –TargetRelyingParty $rp –AdditionalAuthenticationRules ‘exists([Type == "
    ", Value == "false"]) && NOT EXISTS ([Type == "", Value == "S-1-5-21-Insert your Group SID here"]) => issue(Type = "", Value = "");’

              Scenario D: MFA using a custom evaluation rule

              Requirement: The Azure Sprout organization is using “vanity” UPNs to enforce MFA for non-standard UPN suffixes. Corporate users with an UPN suffix may use single factor (forms) authentication from the outside. All other UPN suffixes in the “organization” must use MFA.

              $rp = Get-AdfsRelyingPartyTrust –Name "WIF Test Application"
              Set-AdfsRelyingPartyTrust –TargetRelyingParty $rp –AdditionalAuthenticationRules ‘NOT EXISTS([Type == "
    ", Value =~ "^.*@azuresprout\.net$"]) => issue(Type = "", Value = ";);’

              Scenario E: MFA based on custom claims extrapolated from an attribute store

              Requirement: An SQL attribute store is used to augment claims when accessing a business application. Values extracted  from the store are to be used as triggers for MFA.

              On the relying party, we connect to an attribute store and populate an sqlrole claim, based on running a stored procedure to find the user and the appropriate access information for user on application FOO.

              c:[Type == ""%5D => add(store = "SQL Attribute Store", types = (""), query = "EXEC dbo.GET_ACCESSTOKEN @UserID={0},@AppCode=’FOO’", param = c.Value);

            Next, on the RP pipeline, we define the MFA requirement based on value returned in the sqlrole claim .

            $rp = Get-AdfsRelyingPartyTrust –Name "WIF Test Application"
            Set-AdfsRelyingPartyTrust –TargetRelyingParty $rp –AdditionalAuthenticationRules  ‘c:[Type ==”, Value =~ "<Whatever the response we’re expecting for MFA trigger>"]) => issue(Type = "", Value = ";);’ 

              The latter scenario is a little more unusual, but I’ve used it to highlight what is possible (as with Scenario D) outside of the normal conventions provided by the UI.

              As a sneak peek into the new Window Server “10” release, it appears that Microsoft have expanded authentication support and making the nuances of policy-based access control more accessible to the end user, through the use of a new policy template editor, made available to the AD FS administrator.. more on this and another ADFS “stuff” to come…

              Here’s a snippet of the new rules editor from the pre-release.


            MFA with Client Certificates in ADFS 2012 R2

            There have been questions on this subject posted recently to comments and also on the TechNet forums, so I just wanted to quickly write up something about use of client certificates in the MFA (secondary) slot in AD FS 2012 R2.  You may recall from earlier AD FS R2 posts, that we used virtual smart card and smart card as examples. Let’s broaden that to include “soft” client certificates as an MFA/secondary provider. This functionality is provided “out-of-the box” in AD FS 2012 R2. An Active Directory Certificate Services (AD CS) infrastructure is required to serve up certificates for enabling users for PKI.

            In this post, I’ll be using an Active Directory Certificate Services (AD CS) role from Windows Server 2012 R2 as the Certification Authority (CA). I won’t be explaining the CA setup, beyond the templates used, as there’s been plenty of ink expended on this topic already on the Internet.  A Windows 2003/2008/2012 CA setup will suffice for the activities  concerned here.

            Testing was done with client certificates from a Windows 8.1 clients using:

            • a non domain-joined machine, via Certificate Enrollment (Policy) Web Services and Microsoft Management Console (MMC)
            • a domain-joined machines, via an auto-enrollment policy User-Context GPO.

            In AD Certificate Services (AD CS) a duplicate of the default User certificate template was made (called User V2). Under the Application Policy, the policy is limited to Client Authentication.


            For domain-joined clients, we can enable auto-enrollment via the security tab of the template. Here we see a group called GU-SEC-ADCS-Managed, which is given the necessary read, enroll and autoenroll permissions and we can add users to that security group.


            To enable auto-enrollment for domain-joined clients we need to activate a policy to accomplish this. Against best practices (boo), but for expediency (mine.. yay!), I enable the policy in the Default Domain Policy GPO. The actual settings can be find under Windows Settings|Security Settings|Public Key Policies. Select the Certificate Services Client – Auto Enrollment object and enable the Configuration model section as seen below.


            For the non-domain joined client, read and enroll permissions are given to a group I’ve called GU-SEC-ADCS-Workgroup. The test user, who will be a member of that group, can request the UserV2 certificate template via the Certificates|User MMC plug-in using AD CS Certificate Enrollment Web Services. Again, I won’t be describing how to setup enrollment web services. If you need help, just post in the comments section.

            With Certificate Services, we need to make available the template available to both sets of clients, by enabling the template in the Certification Authority MMC plugin – Certificate Templates|New|Certificate Template to Issue.


            In a correctly configured setup, domain-joined clients will obtain a certificate on the next GPO refresh cycle for the user (e.g. logon).

            As mentioned previously, I’m joining non-domain joined clients via enrollment web services using the MMC snap-in in Windows 8.  In the Certificates|User context of the MMC snap-in, we request a new certificate. In this particular test setup, there are three certificate templates visible for enrollment by the client from the CA:


            User V2 is the template we just created for use for “soft” client certificates.The certificate services enrollment point in this example is configured for Username/Password authentication. Logon is done with a test AD user account, who is a member of the GU-SEC-ADCS-Workgroup and authorized with the enroll permission.


            Once that’s done, a client certificate is installed in the user context.


            On the AD FS side of things, let’s assume we now need to apply MFA for users (with client certificates) coming from the Internet. Before we jump into the actual AD FS settings, it’s worth mentioning that any firewalls in front of the Web Application Proxy (WAP) will need to allow port 49443/TCP inbound, as this is the port the AD FS Smartcard Authentication Service listens on.

            We see evidence of this requirement in the Windows Firewall snap-in. AD FS creates a firewall rule during the installation allowing 49443/TCP inbound.



            In AD FS Global Authentication Policy for MFA, we enable certificate authentication:


            Note that at this point, I’m not enforcing the use of MFA globally, rather enabling it for use at a lower level on a relying party rule, for more incremental control. Whether to go for global or granular policies really boils down to a question of fit and the use cases may need to support. .

            On a test Windows Identity Foundation (WIF) relying party, MFA is enforced for externally connecting users.


            Logging on to the relying party, we hit the primary authentication handler (AD FS forms), enter our username/password.


            Connecting from the Internet, with MFA enabled, the secondary (MFA) authentication handler kicks in and we’re presented with a login popup.


            In the above graphic, we have an option to login with a virtual smart card (top) and an X509 client certificate (bottom). Click on the certificate and AD FS will authenticate the user using secondary authentication (MFA).

            The enrolled certificate is stored by AD CS in the userCertificate attribute of the user object within AD. This attribute contains the DER-encoded X509v3 certificates issued to the user. We can lookup the necessary certificate reference, for example, in the Attribute Editor of AD Users & Computers (ADUC).


            This is a multi-valued attribute.


            One thing that can be useful, should you be working with multiple certificates for a given user, is being able to cut and paste the hex encoded value into Notepad, save it, then check to see what the certificate value corresponds to using CERTUTIL.

            certutil –decodehex mylo.hex mylo.cer

            We can then open the .cer file to see what the certificate is.

            Returning to the test claims applications (having logged in successfully0, we pass all claims processed via an issuance transform rule of c:[]  => issue(claim = c);
            We can see the relevant authentication method references processed during primary and secondary logon.


            As I mentioned in an earlier post, the nice thing here is that you can use the Enhanced Key Usage (EKU) claim emitted for both client certificates and smart cards / virtual smartcards to moderate access to resources as you see fit.

            Looking at a user authenticating with a client certificate, the following EKU is emitted as a claim.


            Smart cards also emit the smart card EKU


            Access can also be further graded by using custom OIDs to differentiate between levels of access based on the type of MFA being used and the EKU value.

            Use of certificates in the MFA slot in R2 (I suspect) are really geared for use in a true two-factor (2FA) authentication capability, i.e. smart cards. While the use of a client certificate does offer value in offering richer access possibilities, this is not 2FA, in that it does not satisfy the mantra of “something I have and something I know”. Instead, this is more akin to 1.5FA.

            To finish up, Microsoft recently added support in Windows 7 for domain-joined clients via a hotfix. I’ll attempt to throw out a quick post on this, but in the meantime,  I’ll be following up by looking at conditional access policies for MFA.

            As always, thanks for reading and if you have any questions, please post a comment and I’ll do my best to answer quickly.

            Exchange 2013 SP1, Outlook Web App (OWA) and AD FS

            It’s over a year now since the last Outlook Web App article about integrating OWA with ADFS. In that post we explored the use of claims-based authentication with OWA in a Proof of Concept using WIF 3.5 and FedUtil. This was an unsupported setup in Microsoft eyes and, in the meantime, with the release of Windows Server 2012 R2, opportunities for supporting Exchange web applications such as OWA,  have arisen. The first, provided support via the use of a non-claims aware web application in AD FS R2 using Kerberos Constrained Delegation (KCD), utilizing the new Web Application Proxy (WAP) feature. The recent release of Exchange 2013 SP1 further expands OWA support, including native support for AD FS in the Exchange product, with claims-based authentication now possible for Outlook Web App (OWA) and the Exchange Admin Center (EAC).

            To get started, I’ll refer you to a Technet article here that provides a step-by-step. I used this article as a starting point for setting up OWA/EAC with AD FS R2. These two application endpoints in Exchange (OWA and ECP) need to be represented as relying parties within AD FS.

            Here’s an excerpt of the PowerShell rules required for creating the RPs:

            Add-ADFSRelyingPartyTrust -Name “Outlook Web App” -Enabled $true -Notes “This is a trust for” -WSFedEndpoint -Identifier -IssuanceTransformRules $IssuanceTransformRules -IssuanceAuthorizationRules $IssuanceAuthorizationRules

            Add-ADFSRelyingPartyTrust -Name “Exchange Admin Center (EAC)” -Enabled $true -Notes “This is a trust for” -WSFedEndpoint -Identifier -IssuanceTransformRules $IssuanceTransformRules -IssuanceAuthorizationRules $IssuanceAuthorizationRules

            The AD User and Group SIDs, together with UPN also need to be defined for each of the Exchange Relying Party applications in the form of custom claims rules: Windows Account Name (sAMAccountName)

            c:[Type == “”, Issuer == “AD AUTHORITY”] => issue(store = “Active Directory”, types = (“”), query = “;objectSID;{0}”, param = c.Value);

            Group SID (enumarate group membership)

            c:[Type == “”, Issuer == “AD AUTHORITY”] => issue(store = “Active Directory”, types = (“”), query = “;tokenGroups(SID);{0}”, param = c.Value);

            User Principal Name (UPN)

            c:[Type == “”, Issuer == “AD AUTHORITY”] => issue(store = “Active Directory”, types = (“”), query = “;userPrincipalName;{0}”, param = c.Value);

            On the Exchange side, via PowerShell, we specify the Relying Party Identifiers via the AdfsAudienceUris parameter and must also provide the token signing certificate thumbprint from the AD FS server.

            $uris = @(“”,””) Set-OrganizationConfig -AdfsIssuer “” -AdfsAudienceUris $uris -AdfsSignCertificateThumbprint “TOKEN SIGNING CERTIFICATE THUMBPRINT”

            Don’t forget to import the token signing certificate into the Trusted Root Certificate Authorities container of your Exchange servers, otherwise you may fall foul of the following error logging on to your mailbox.


            The source in pinpointing the problem here, lies in the query string of the error message

            In this (my) case, the token signing certificate had not been added to the Exchange servers as a trusted cert. Equally, the wrong Audience URI can present a configuration problem. It commonly arises when a unnecessary trailing slash is added to the Relying Party Identifier when configuring in AD FS, e.g. s something to keep an eye on. The correct RP identifier would be

            I’ve not yet tested setting up Exchange 2013 SP1 under AD FS 2.0, but there’s nothing untoward going on here to suggest that using it as your identity provider is not possible. If you’re running under AD FS Windows Server 2012 R2 then the Web Application Proxy (WAP) adopts the proxy role for external access scenarios and also supports host name translation. For example, I make use of as an external URL and map this to the internal name of Be aware that matching of path-based names is not supported in the current release of the WAP, so mixing path names between externally and internally published resources is a no-no.

            To illustrate this, let’s look at an example of an OK configuration:

            Add-WebApplicationProxyApplication -BackendServerUrl ‘’ -ExternalCertificateThumbprint ‘DD94E2ABAA123C6B6009CB42F16CE892AF96A47C’ -ExternalUrl ‘’ -Name ‘OWA’ -ExternalPreAuthentication ADFS -ADFSRelyingPartyName ‘Outlook Web App’

            Whereas, this is a non-workable configuration.

            Add-WebApplicationProxyApplication -BackendServerUrl ‘’ -ExternalCertificateThumbprint ‘DD94E2ABAA123C6B6009CB42F16CE892AF96A47C’ -ExternalUrl ‘’ -Name ‘OWA’ -ExternalPreAuthentication ADFS -ADFSRelyingPartyName ‘Outlook Web App’

            Note the use  in publishing of the same literal path in the first example, versus a rewritten one in the second

            If you’re contemplating the use of AD FS 2.0, then clearly host-name translation is not something that the AD FS 2.0 proxy brings to the table. Alternatively, a suitably equipped front-end load balancer may also fulfill that role.

            On the subject of load balancers, this rather conveniently brings me back to new features in AD FS R2. Server Name Indication (SNI) was mentioned in the “First Looks” articles about AD FS R2 and it’s worth checking that your current load balancer/reverse proxy in front of AD FS supports SNI and is supported/enabled on the device concerned. This is becoming a pain point for many, as evidenced by various posts on the Technet forums. The move to kernel-mode (HTTP.SYS) in R2 mandates the use of SNI. Therefore, it’s worthwhile checking that:

            • your friendly neighbourhood load balancer/device in front of AD FS supports SNI
            • clients and user agents support SNI and you’re not inadvertently locking them out
            • (08/04) SSL termination endpoints (e.g. load balancer / 3rd-party reverse proxies) in front of AD FS  may be affected by the recent heartbleed bug (, exposing vulnerable OpenSSL libraries and certificates used on those devices. Microsoft infrastructure, employing Secure Channel (SChannel)  not affected, may inadvertently become so through SSL termination endpoints on the aforementioned devices in front of AD FS. More information can also be found here (

            Accessing the OWA URL, via and the OWA Relying Party redirects the user to AD FS for logon. In a default AD FS R2 configuration, this equates to forms-based authentication for external users.


            Users accessing OWA internally, access via the farm using Integrated Windows Authentication (IWA). As usual when connecting to the farm, the URL for the federation service needs to be added to the Local Intranet Zone within IE and any corresponding configuration changes made to support Kerberos for other browsers.

            At this point, optional use of a clams provider (connecting to the local AD) or an MFA provider in R2 could also come into play to provide stronger authentication, should it be required. Having successfully authenticated via AD FS, we gain access to the user mailbox. image

            The Exchange Control Panel (ECP) was also configured as a relying party within AD FS and within the Exchange configuration. Accessing the Exchange Admin Center remotely, with the Exchange Organization Administrator mylo, we can see the gamut of administrative console options available under federated logon.


            This is one of those scenarios where it might be a good idea to apply stronger authentication (MFA)  to privileged user accounts when accessing the Exchange Admin Center. We can do this by applying policy-based access on the AD FS R2 server.

            In the next post, I’ll be taking a look at strong authentication access scenarios using ActiveSync and Lync (primarily with mobile clients), before completing Part 3 of the First Looks series of AD FS R2.

            First Impressions – AD FS and Window Server 2012 R2 – Part II

            Hi folks. Welcome back to Part II of our first look at the new AD FS release in Windows Server 2012 R2. This one has been a while in the making and for those who have been waiting, thanks for your patience. This is a pretty long post and the longest to date. For the most part it emphasises what is new and good in the Windows Server 2012 R2 incarnation of AD FS, in particular concentrating on the authentication and UI changes in the latest release.

            In the last post we looked at some of the new architectural changes in AD FS with Windows Server 2012 R2, such as the Web Application Proxy, Extranet soft lockout and a lightweight domain join facility, otherwise known as Workplace Join. In this post we’ll extend the look to some of the authentication/UI changes and how their application embraces a more conditional access approach and philosophy within the product.

            In AD FS 2.0, customization of IIS and sign-in pages could be performed on both the AD FS Proxy and AD FS farm with authentication types being used configured in the web.config file of each.

            The AD FS 2.0 proxy supported the following authentication types:

            • Username and Password (Forms)
            • X509/Client Certificate (including Virtual Smart Card/Smart Card Authentication)
            • Basic Authentication

            The AD FS 2.0 backend (farm) supported the following authentication types.

            • Integrated Windows Authentication (IWA)
            • Username and Password (Forms)
            • X509/Client Certificate (including Virtual Smart Card/Smart Card Authentication)
            • Basic Authentication

            Authentication mechanisms carried over from AD FS 2.0 are now available under the banner of Primary Authentication in R2 and handled through the AD FS Management UI or via PowerShell. As with AD FS 2.0, native authentication assumes the use of an Active Directory-based identity and the built-in AD claims provider for authentication. Support for Basic Authentication, available in AD FS 2.0, has now been deprecated in R2.

            Looking at the AD FS Management UI, we see an immediate difference over its predecessor with the inclusion of a new authentication policies pane.

            In AD FS 2.0 the base proxy and farm configuration supported Forms and IWA logon types respectively. Any changes beyond that required adjusting the LocalAuthenticationTypes
            methods used within web.config
            files on proxy and farm nodes. The context-sensitive (proxy v farm) aspects of authentication now move to the UI/PowerShell. There is also support for multiple authentication types for a given authentication context, such as simultaneous support both Forms and X509 Certificate-based authentication on the external context handler.

            Within the Management UI we may edit the Global Authentication Policy on the AD FS server to determine what authentication types we wish to support on the Primary authentication space and for internal/external user types.

            These settings can also be modified via PowerShell. For example, the following command sets forms-based logon as the authentication type for both Extranet and Intranet logons on Primary Authentication.

            Set-AdfsGlobalAuthenticationPolicy -PrimaryExtranetAuthenticationProvider {FormsAuthentication} -PrimaryIntranetAuthenticationProvider {FormsAuthentication}

            An additional authentication provider, in the form of Multi-Factor Authentication (MFA), allows support for additional (stronger) authentication types. This auxiliary component represents a significant enhancement for sign-in scenarios under AD FS in Windows Server 2012 R2.

            Under the previous release, native support for stronger authentication was limited to domain-joined clients using Smart Cards or Virtual Smart Cards, via the X509/Client certificate authentication handler. Third-party solutions materialised providing support for two-factor/multi-factor authentication in the federation logon process. How these were implemented varied per solution, but they typically fell into one of two basic categories:

            1. Agent-based or non-federated solutions (typically) running on, or in front of the AD FS proxy, handling two-factor authentication (2FA) for external access.
            2. Claims/Identity Providers trusted by AD FS.

            If you’ve followed this blog over time or from own experience, you’ll know these approaches can have their own quirks: be they issues with cross-domain SSO, redirection, home realm discovery, flexibility, user experience etc., they often warranted some attention configuration-wise to get working under AD FS 2.0, where possible.

            The R2 makeover overcomes some of these limitations by:

            1. Expanding access capability within AD FS, making available more fine-grained “conditional access” decisions;
            2. Improving login behaviour and user experience for sign-in scenarios;
            3. Improving customization of sign-in pages / error-handling;
            4. Including the option of a secondary MFA adapter (SDK) for vendors to integrate with, unifying the logon experience around AD FS itself.

            Let’s have a look at more conventional access scenarios, using AD FS 2.0 as a reference point. We begin by seeing how the new authentication changes enhance options during logon. In AD FS 2.0, while we were able to change the preferred authentication type, supporting multiple authentication options was not possible without significant customization. An example is provided here for reference.

            Customizing User Agent Behaviour

            Under AD FS 2.0 Integration Windows Authentication (IWA) provided transparent SSO to domain-joined Windows clients connecting web resources that supported Windows authentication. However, IWA is not supported by all browsers and under AD FS 2.0 the fall-back authentication was NTLM.

            The NTLM challenge/response dialogue often caused confusion for users. With AD FS in Windows Server 2012 R2, we can specify on the internal network which browser clients are allowed to use Integrated Windows Authentication (IWA) for transparent logon. This is done by modifying the supported user agents via the following cmdlet.

            Set-ADFSProperties –WIASupportedUserAgents

            Internal clients, using Internet Explorer 6.0 and above will default to using their Windows logon token (IWA) when connecting from the Intranet. All other browser agents, Firefox, Chrome etc. will revert to using forms-based authentication (FBA). If the user agent in question is added to a WIASupportedUserAgents list then IWA is attempted. This gives the IT Administrator greater control, whilst promoting a more user-friendly logon experience.

            We can customize our own User Agent values to pass to AD FS. I had to dig around to work out how to set this value correctly because it’s not obvious what the settings in AD FS are at first glance. If we type Get-ADFS Properties, we can see some of the current user agent settings, with the remaining values beyond MSIE 8.0, being obscured from view.

            The viewing properties are being limited by a setting known as $FormatEnumerationLimit in PowerShell. When we change the value of this to -1 we see the full user agent specification used.


            We can then change the supported user agents by using the Set-ADFSProperties
            cmdlet. I actually broke things at this point and my ignorance of PowerShell was to blame. As posters to Technet forums confirmed, the following syntax will not work:

            Set-AdfsProperties -WIASupportedUserAgents (“MSIE 6.0”, “MSIE 7.0”, “MSIE 8.0”, “MSIE 9.0”, “MSIE 10.0”, “Trident/7.0”, “MSIPC”, “Windows Rights Management Client”)

            It turns out that a string array is required and the user agent items need be in parenthesis and an @ included. Thank you PowerShell Pro. Reverting to the original configuration is possible by setting the following command and you can, of course, customize accordingly.

            Set-ADFSProperties -WIASupportedUserAgents @(“MSIE 6.0”, “MSIE 7.0”, “MSIE 8.0”, “MSIE 9.0”, “MSIE 10.0”, “Trident/7.0”, “MSIPC”, “Windows Rights Management Client”)

            If you’re propagating your own IE settings, e.g. via GPO, then these can be added to the list. If you’re using other browsers, besides IE, then it’s also worth considering turning off Extended Protection Authentication (EPA) / Channel Binding Token (CBT). This can be done via the following command:

            Set-ADFSProperties –ExtendedProtectionTokenCheck None

            Note the service restart request. Please note that EPA is intended as a protection mechanism against Man-in-the-Middle (MITM) attacks and as ever it’s a toss-up between usability and security. An overview can be found here.

            Authentication Changes

            Let’s look at an example of multiple local authentication types enabled. Here, Forms and X509/certificate authentication are enabled on the primary authentication provider for external (Extranet) access at the Web Application Proxy (WAP):

            In a logon scenario, with both options enabled, the user is presented with the following logon screen:

            The option to “Sign in using an X.509 certificate” is provided underneath the logon form. Logging on with username/password to a test claims aware web application, we see the normal forms logon behaviour as seen with the AD FS 2.0 Proxy, expressed through the use of the PasswordProtectedTransport value in the authnmethodsreferences

            With multiple authentication types enabled, users can logon using the forms logon option or using an X509 mechanism, e.g. a client certificate or virtual smart card/smart card.

            I’m using a Virtual Smart Card (VSC) as an example for the X509 access type. Clicking on the X509 hyperlink, using the VSC we see the following prompt.


            I select the VSC for user mylo.

            At the challenge prompt, the user must enter their PIN for that user, whereupon they gain access to the relying party.

            Looking at the claims emitted at this point through our test relying party, we can see that AD FS recognizes that stronger authentication has been used (MFA) and via the claim, it issues the value of More on this in a moment.

            Multi-Factor Authentication (MFA) on the Secondary Provider

            The previous example illustrated the use of both username/password and MFA through the Primary Authentication option. When we look at Multi-Factor Authentication (MFA) via an additional authentication policy rule, we can similarly use the native X509/Certificate Authentication provider. This implies the use of the AD username/password first as the primary credential, either via forms or IWA, according to your authentication policy rules, and X509 as the additional MFA credential.

            There’s a distinction here also worth noting between AD FS 2.0 and R2 behaviour. With the former we could potentially invoke multi-factor authentication (MFA) through protocol mechanisms, such as via a wauth parameter in WS-Federation, or in the AuthnContextClassRef in SAML 2.0. In doing so we were able to call an upstream identity provider that was MFA capable, or if stronger authentication mechanisms were available on AD FS 2.0, using X509 certificates or smartcard variants. The options here, at this point though were fairly limited and called on extensive customization to support multiple authentication methods.

            We can still use the protocol route in AD FS R2. In addition, Multi-factor authentication (MFA) can be triggered through both protocol and policy (new in R2) rules. For example, with WS-Federation the wauth= protocol parameter stipulates that the relying party requires invocation of MFA in the logon request (assuming this is enabled in the global authentication settings). This is the same claim type mentioned earlier during the smart-card logon process and is associated with the use of MFA.

            When we invoke MFA as a policy rule on the AD FS R2 server, we’re in fact calling the additional authentication rules handler and this policy-based behaviour can be configured at both global and relying party levels.

            In the UI, we can see the following options:

            The use of conditional access rules provide a more controlled demeanour to AD FS in how claims-based authentication is applied. In this example, I’ll disable Certificate Authentication in the primary authentication slot (leaving forms enabled) and enable it instead as an MFA method globally. We can then call on this (secondary) authentication method as we see fit.

            The equivalent PowerShell command is:

            Set-AdfsGlobalAuthenticationPolicy –AdditionalAuthenticationProvider CertificateAuthentication

            For this particular test, I’ll also enabled MFA as a requirement for external clients

            When logging on to AD FS R2, we get the standard forms sign-in page. We now using two-step authentication using the primary and the additional (secondary) authentication types.

            Logging on with a username and password, we’re then presented with an additional logon screen and a request to provide secondary (X509) MFA credentials.

            Again using a Virtual Smart Card( VSC) and our mylo test user, we select the appropriate VSC identity and enter a PIN.

            Looking at a test claims-aware Windows Identity Foundation (WIF) application, passing through all claims rules, we see the following detail:

            The aggregation of authentication types used during the logon process can be seen through the use of the
            claim. The first claims value seen in the screenshot is for urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport, indicating use of forms logon (username/password). The second and third references to tlsclient and x509 show that we’ve used a client certificate (in the form of the virtual smart card) during the logon phase. Finally, the last entry states that multi-factor authentication (MFA) has been used, reflected in the http://schemas\.microsoft\.com/claims/multipleauthn claim value. A similar claim value would also have been emitted if we’d used a third-party authentication provider registered as an R2 MFA provider. We’ll look at this later in the post.

            When we log on with a Virtual Smart Card (VSC), we can also see the Enhanced Key Usage (EKU) of a certificate emitted in the claim.

            Those of a PKI inclination will appreciate the benefits this may provide. We are able now, for example, to determine, via the EKU, whether a smart card was used in the logon process (, as opposed to say a vanilla client certificate and we can stipulate that as an access requirement during logon. If your organization is using a custom organizational identifier (OID) then we may also consider moderating access based on different levels of assurance associated with the OID bound to a particular certificate template. This also offers some promising developments with technologies such as Authentication Mechanism Assurance (AMA), which I’ll cover in a future post.

            The examples I use with smart cards are typically targeted at managed Windows (domain-joined) clients, who receive their configuration (certificates etc.) over the (local) wire through group policy (GPO) or scripts. Support for non-domain joined clients, however, is now also available to Windows 8.1 clients and enrolment can now be provided via certificate enrolment/policy web services.

            For a more granular approach to MFA, desired authentication can also be targeted to specific relying parties. The conditions under which we apply the policy rules (AD group/user, location, device, authentication type) can be refined on per relying party basis, as seen in greater detail in the next section with the MFA Adapter.

            The MFA Adapter

            This is a new feature in AD FS R2 that allows third-parties to register their authentication provider as an auxiliary authentication mechanism within AD FS, whilst unifying the login/sign-in experience around AD FS.

            To see how the MFA adapter works, the example user here is with Windows Azure Multi-Factor Authentication Server, formerly PhoneFactor. A tenant has been setup in Windows Azure, a pre-requisite, with the Azure MFA server plugging into the Azure cloud and the registered tenant. The MFA Server itself connects to AD FS through an installer that provides the necessary bridge between the AD FS MFA adapter/SDK and the Azure MFA Server.

            I’ll skim over the details of installing the actual Windows Azure Multi-Factor Authentication server itself and look at integration of the AD FS plug-in.

            The Windows Azure MFA server connects to the local organization Active Directory and synchronizes objects with it. Here we’re synchronizing objects under an OU subtree of Accounts/External in the imaginary “Azure Sprout” organization. A single container subtree is being synchronized.

            Looking at the User section of the console we see some test users in an organization called “Azure Sprout”.

            We’ll enable the training user for phone-call validation.

            Within the authentication server console, there’s an AD FS section where the appropriate adapter can be installed.

            If the MFA server is joined to the domain and the Active Directory configuration for securing communication between the ADFS Adapter and the Multi-Factor Authentication service is incomplete, the administrator must first complete the Active Directory integration setup, before the adapter can be installed. Once the adapter is installed, the desired multi-factor authentication methods can be then specified.

            In the testing example here, the AD FS adapter has been installed on the Federation Server and via the console, the necessary AD FS integration binaries installed. This can also be done manually, such as when the server is installed on a remote machine. The AD FS binaries can be copied through the C:\Program Files\Multi-Factor Authentication Server path and installed via an MSI (MultiFactorAuthenticationAdfsAdapterSetup64.msi). When run the installer sets ups the necessary resource files and connectors allowing AD FS to communicate with the on-premise WZAA MFA instance.

            A PowerShell script then needs to be run to register the Windows Azure MFA adapter within the local AD FS instance and make it available as an MFA option.

            With the Windows Azure Authentication Server installed and the MFA adapter registered, a new authentication type becomes available, which we can then enable in the Global Authentication Policy for the organization.

            The adapter is now available as an MFA authentication method. The Multi-Factor Authentication Server itself is bound to a Multi-Factor Authentication Service setup on my Windows Azure tenant.

            Let’s have a look at some test scenarios using MFA.

            In the above test setup are two AD FS instances, both on R2, representing two different organizations: “Access Onion” and an Azure-based setup called “Azure Sprout”. The “Access Onion” organization is hosting a couple of on-site SharePoint web applications. Apologies if the setup looks a little bit contrived, but I’m not at the stage yet where I’m prepared to fork out $$$ for moving certain “demo/test” resources such as SharePoint/SQL to the cloud, hence the dual on-premise and cloud combination J

            Two SharePoint web applications have been setup as relying parties to test some MFA scenarios:

            1. A Teamsite dedicated to “Azure Sprout” users resides in the “Access Onion” organization. For expediency, I’ve connected up the SharePoint Teamsite ( directly to the AD FS in the “Azure Sprout” organization to test direct trust access scenarios. The SharePoint teamsite ( in the “Access Onion” organization is setup as a Relying Party on the “Azure Sprout” AD FS instance.


            2. A Teamsite for users in the “Access Onion” organization that also provides secure access to users from the “Azure Spout” organization. For “Azure Sprout” users accessing the SharePoint Teamsite, they are routed via the “Access Onion” AD FS instance, acting in the role of a Relying Party Security Token Service (RP-STS). A claims provider trust is setup between the trusting (Resource) “Access Onion” organization and the trusted (Account) “Azure Sprout” organization, with the AD FS RP-STS setup as a Relying Party in the “Azure Sprout” organization AD FS instance.

            For testing, please note that:

            • Users in the “Azure Sprout” have a
              domain suffix
            • Users in the “Access Onion” have a
              domain suffix.

            We’ll look at various access scenarios that employ new functionality within the R2 release of AD FS and begin with the “Azure Sprout” Teamsite dedicated for that organizations use.

            Scenario 1 : Access to the “Azure Sprout” Teamsite

            This is a fairly straightforward setup. This Teamsite is only for “Azure Sprout” users and there’s a direct trust between the SharePoint web application, hosted in the “Access Onion” organization and the “Azure Sprout” AD FS organization. This setup is analogous (for this test) to that of a normal Web SSO setup. We wish to use local Windows authentication for “Azure Sprout” internal users and MFA for external users connecting through the “Azure Sprout” Web Application Proxy (WAP).

            The AD FS R2 instance for the “Access Onion” organization is omitted from the diagram as its role is secondary, with the Web Application Proxy being used as a reverse proxy for publishing the SharePoint application.

            Internal Users

            Represented in the diagram by blue numbering, users connected to the “Azure Sprout” Intranet can connect using their Windows credentials.

            1. The User accesses the “Azure Sprout” Teamsite within the “Access Onion” organization. This is published by the local Web Application Proxy as a Reverse Proxy rule. The SharePoint Security Token Service (STS) has been configured to use the “Azure Sprout” AD FS as a trusted claims provider.
            2. The user is redirected to the “Azure Sprout” AD FS instance. Since the user is connected to the Azure Sprout LAN, this passes the request directly to the farm instance, whereby the user can logon with their Windows credentials. A relying party rule is configured for the SharePoint Teamsite and claims rules (Send LDAP Attributes as Claims Rules) configured to pass the requisite attributes.

              c:[Type == “;, Issuer == “AD AUTHORITY”] => issue(store = “Active Directory”, types = (“;, “;, “;), query = “;userPrincipalName,tokenGroups,mail;{0}”, param = c.Value);


            3. The user is redirect to SharePoint whereupon (assuming permissions have been granted to the SharePoint site) they gain access.

              Here’s the identity provider configuration used for the “Azure Sprout” teamsite.

              $map = New-SPClaimTypeMapping -IncomingClaimType “; -IncomingClaimTypeDisplayName “EmailAddress” -SameAsIncoming

              $map2 = New-SPClaimTypeMapping -IncomingClaimType “; -IncomingClaimTypeDisplayName “Role” -SameAsIncoming

              $realm = “urn:azuresprout:teams”

              $ap = New-SPTrustedIdentityTokenIssuer -Name “Azure Sprout” -Description “Azure Sprout SAML” -realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map,$map2 -SignInUrl “; -IdentifierClaim

            External Users

            Represented in the diagram by black numbering, the logon workflow works as follows:

            1. The User accesses the “Azure Sprout” Teamsite within the “Access Onion” organization. This is published by the local Web Application Proxy as a Reverse Proxy rule. The SharePoint Security Token Service (STS) has been configured to use the “Azure Sprout” AD FS as a trusted claims (identity) provider.


            2. The user is redirected to the “Azure Sprout” AD FS instance. Since the logon request is coming from an external user, the request is resolved via external DNS, pointing to the “Azure Sprout” Web Application Proxy. A pre-authentication rule is configured for the SharePoint relying party on the web application proxy.

              Add-WebApplicationProxyApplication -BackendServerUrl ‘; -ExternalCertificateThumbprint ‘D9433C468CDEDF6BCD645BC2DE143CD5B4ED108’ -ExternalUrl ‘; -Name ‘”Azure Sprout” Teamsites’ -ExternalPreAuthentication ADFS -ADFSRelyingPartyName ‘SharePoint “Azure Sprout” Teamsites’

              External Users need to use MFA. We configure this on the “Azure Sprout” AD FS farm by specifying the appropriate location/MFA combination on the authentication policy for the SharePoint Relying Party.

              Within the UI:

              Looking at this in PowerShell, this translates to an additional authentication claim rule of:

              c:[Type == “;, Value == “false”]=> issue(Type = “;, Value = “;);

              In other words, if the user is inside the “Azure Sprout” corporate network, then the MFA rule will not apply because the insidecorporatenetwork claim value returns a value of $true). The use of the claim value is then used to trigger MFA as part of the rule above.

              As discussed earlier the primary authentication type needs to be satisfied first. The user must log on with their “Azure Sprout” AD credentials. From the outside, the forms login handler is initiated for the (primary) initial logon type for external (Extranet) users.

            3. Once the user has logged on with primary authentication, they must then logon with MFA. This is where the Windows Azure Authentication Server (MFA) provider comes into play. The user authenticates using their configured MFA type.

              In the test configuration, the setup is configured to allow the Windows Azure MFA server to ring the users phone to complete authentication. Once they click on the Continue button the call is initiated, based on the number derived from the mobile attribute of the user in the “Azure Sprout’ Active Directory (the AD attribute used can be customized). The user confirms the two-step authentication process by receiving the call and confirming with the hash/pound (#) key on their phone that a successful hook-up has occurred.

            4. The user is redirect to SharePoint whereupon (assuming permissions have been granted to the SharePoint site) they gain access.

            We may employ authentication fall-back processes where the MFA provider supports it. Windows Azure Authentication Server, for example, offers the use of security questions as such a mechanism during logon.


            This sort of flexibility should extend to other MFA providers via the adapter and bring their own capabilities to the fore.

            Scenario 2 – Accessing the “Access Onion” Teamsite

            This scenario is more complex as we have to take into consideration access requirements from multiple sources, in doing so hitting common challenges for Federated SSO concerning multiple organizations, realm discovery and authentication. Before we go into the obligatory diagram, we’ll recap on Home Realm Discovery (HRD), as it has a particular resonance in this scenario.

            There’s no place like Home (Realm Discovery)

            In AD FS 2.0, we are able to alter HRD behaviour either at the AD FS Proxy or AD FS Farm by changing the selector options visible to the user, for the claims providers concerned. This was possible by configuring the homerealmdiscovery.aspx.cs
            code-behind page to suppress the providers that we didn’t want the user to see.

            In AD FS R2, HRD customization options through PowerShell now allow us to determine how the UI is presented to the end-user during logon, based on:

            1. target suffix resolution – providing suffix routing on a per claims provider basis
            2. limiting the claims providers visible for the relying party concerned

            With Option (a) we define the home claim provider of the target user, by binding the UPN domain/suffix of a particular set of users to a given claims provider. For example:

            • For users in the “Azure Sprout” organization with a
              suffix, we send to the “Azure Sprout” claims provider.
            • For users in the “Access Onion” organization with a
              domain suffix, we send to the “Access Onion” claims provider.

            With Option (b) we identify the claims providers we wish to use for that relying party, specifying which ones we wish to make them visible in the HRD list. This is governed on per relying party basis.

            While having the flexibility of these options enhances functionality, they don’t eliminate HRD issues completely as we’ll see. Nonetheless, they can greatly simplify the user logon experience. You’ll ultimately need to find the right combination that works for you.

            Back to the scenario. Users connecting externally in each organization should use multi-factor authentication (MFA). In addition, external users connecting through the “Access Onion” organization have an existing 3rd party MFA identity provider and their (external) users must use this provider.

            Internal “Access Onion” Users

            Represented by the orange numbered items in the diagram, internal user workflow should be as follows:

            1. The User accesses the “Access Onion” Teamsite. The SharePoint Security Token Service (STS) has been configured to use the “Access Onion” AD FS as a trusted claims (identity) provider.


            2. The user is redirected to the local “Access Onion” AD FS instance. Since the logon request is sourced from an internal user, the request is resolved via internal DNS, pointing to the “Access Onion” AD FS farm.
              1. The Home Realm Discovery (HRD) process is invoked because there are three claims providers configured in the “Access Onion” organization:
                1. The local Active Directory claims provider
                2. The “Azure Sprout” claims provider
                3. A third-party claims provider (PointSharp STS) providing MFA.


            3. Once HRD processing is complete, the logon process continues. Since the user is connected to the Access Onion LAN, the request is processed at the farm, whereby the user is silently logged on with their Windows credentials. A relying party rule is configured for the SharePoint Teamsite and claims rules (Send LDAP Attributes as Claims Rules) configured to pass the requisite attributes.


            4. The user is redirect to the SharePoint “Access Onion” Teamsite whereupon, assuming permissions have been granted to the SharePoint site, they gain access.

            For internal access, we don’t want “Access Onion” users to see the Home Realm Discovery (HRD) selection screens. The AD FS server, therefore, can be configured so that Intranet users can bypass HRD. This is accomplished by issuing the following command on the “Access Onion” AD FS instance.

            Set-ADFSProperties –IntranetUseLocalClaimsProvider $True

            External “Access Onion” Users

            Let’s look at the logon workflow represented by the red numbered items in the diagram:

            1. The User accesses the “Access Onion” Teamsite. Since the user is connecting externally, the URL of the SharePoint teamsite resolves to the IP address of the Web Application Proxy. On the proxy the request is intercepted and processed. A pre-authentication rule has been created for the SharePoint teamsite URL.


            2. Before authentication can continue :
              1. The Home Realm Discovery (HRD) is invoked because there are three claims providers configured in the “Access Onion” organization:
                1. The local Active Directory claims provider
                2. The “Azure Sprout” claims provider
                3. A third-party claims provider (PointSharp STS) providing MFA.


            3. Once HRD processing is complete, the logon process continues and the user is routed to the 3rd party claims provider. At the logon page, the user enters their credentials, using whatever authentication methods have been prescribed on the PointSharp Security Token Service (STS): Hard token, soft token, SMS etc. The STS is configured to pass back the appropriate attributes that will satisfy SharePoint Teamsite requirements via the AD FS RP-STS.


            4. The user is then sent back to the “Access Onion” AD FS R2 instance, acting as an RP-STS. Here additional claims processing and authorization is for the SharePoint “Access Onion” Teamsite relying party.


            5. The user is redirect to the SharePoint “Access Onion” Teamsite whereupon, assuming permissions have been granted to the SharePoint site, they gain access. The URL termination of this connection is at the Web Application Proxy and connections to SharePoint are reverse proxied through the WAP.

            OK, let’s explore this a little further, particularly the realm discovery part. As mentioned in the previous section, the “Access Onion” AD FS R2 instance, beyond the default AD claims provider, has additional claims provider trusts with two claims providers: the “Azure Sprout” AD FS R2 Instance and the existing “Access Onion MFA” provider (PointSharp) running as a Security Token Service – PointSharp Identity Federation.

            A user logging on externally to the “Access Onion” organization, by default, would be faced with the following sign-in options.

            The blue icon represents the local “Access Onion” Active Directory claims provider.

            With R2, we can reduce the number of visible CPs used via the two methods discussed in the HRD section, namely:

            • Use of suffix routing
            • Naming claims providers on the relying party concerned

            For suffix routing, we can bind the suffixes used by each respective organization to target specific claims providers.

            Set-AdfsClaimsProviderTrust –TargetName “Access Onion 3rd Party IdP” –OrganizationalAccountSuffix @(“”)

            Set-AdfsClaimsProviderTrust –TargetName “Azure Sprout” –OrganizationalAccountSuffix @(“”)

            Users then see the following logon screen

            The (PointSharp) 3rd-party MFA provider is no longer visible, nor is the Azure Sprout organization. Clicking on the Other organization, we can then enter the appropriate suffix for the target claims provider.

            The user is then routed to the “home” claims provider. Users with the suffix, connect from externally, click on “Other Organization”, enter their credentials and are identified on the basis of the suffix entered, and routed to the in-house 3rd party MFA claims provider; in this case a PointSharp Identity Federation Security Token Service (STS). Because AD FS R2 is acting as a Relying Party Security Token Service (RP-STS), it will route all users with this suffix to the PointSharp (claims provider) STS.

            From here we continue the logon process, using whatever multi-factor authentication methods have been configured on the PointSharp provider.

            A couple of comments at this point:

            1. It would be nice to be able to customize the text for the “Other Organization” dialogue and screens. When I find out how this is possible or someone points me in the right direction, I’ll post an addendum to the article J
            2. The base AD claims provider, “Access Onion”, is available in the HRD selection during external logon. While it was possible to suppress the base claims provider on the AD FS 2.0 Proxy, I’ve not worked out to do this under R2 for external clients. (Note: Disabling all the authentication types via the UI doesn’t suppress the AD provider). It’s a relatively minor point and one specific to this scenario, but the fact that it was possible under 2.0 grates a little. There could be a hidden parameter somewhere in the configuration that allows this…

            Given the latter constraint, you’d be forgiven for trying Option (b) for HRD in this particular case. We can name preferred claims providers for our particular “Access Onion” Teamsite relying party by specifically limiting those we wish to see during logon for that RP. For example:

            Set-AdfsRelyingPartyTrust -TargetName “SharePoint Access Onion Teamsite” -ClaimsProviderName @(“Access Onion MFA”, “Azure Sprout”)

            This is a nice option for limiting web applications to given identity provider(s).

            In this example, users are faced with the following logon screen when redirected to the “Access Onion” AD FS instance.

            Great! No AD claims provider… really… I mean no AD claims provider J It prohibits the use of the AD provider in all login scenarios including internal ones, meaning that all users would now need to use MFA. While targeting identity providers is a useful feature, it’s not one applicable in this particular case.

            Settings for the RP can be restored to normal by:

            Set-AdfsRelyingPartyTrust -TargetName “SharePoint Access Onion Teamsite” -ClaimsProviderName @()

            Based on the above behaviour, we’ll settle on using suffix routing for realm discovery scenarios.

            Internal / External “Azure Sprout” Users

            Let’s have at the logon workflow for “Azure Sprout” for users connecting from within their organization to the remote “Access Onion” SharePoint Teamsite. The logon flow, because MFA is a requirement, means that only the primary authentication mechanism changes, based on whether the user is connecting from inside the “Azure Sprout” organization (blue text) using IWA or outside (black text) using forms.

            1. The User enters the “Access Onion” Teamsite URL. Since the user is connecting externally, the URL of the SharePoint teamsite resolves to the IP address of the Web Application Proxy. On the proxy the request is intercepted and processed. A pre-authentication rule is configured for the given URL.


            2. Before authentication can continue :
              1. The Home Realm Discovery (HRD) is invoked because there are three claims providers configured in the “Access Onion” organization:
                1. The local Active Directory claims provider
                2. The “Azure Sprout” claims provider
                3. A third-party claims provider (PointSharp STS) providing MFA.


            3. Once HRD processing is complete, the logon process continues and the user is routed to the “Azure Sprout” claims provider. The primary (AD) authentication provider processes the logon request. When the user is connecting to the “Azure Sprout” local area network, the URL of the federation service resolves to the IP address of the internal AD FS farm. Internal users use their local Windows authentication in the primary slot, as can be seen by the Intranet configuration below.

              External user logon, resolving to the external DNS of the Web Application Proxy, means that users employ forms-based authentication.

            4. Having provided their AD credentials, the user must then satisfy additional authentication requirements and use their Windows Azure Authentication (MFA) credentials to continue further logon. This is enforced on the “Access Onion” Relying-Party STS as an MFA rule.


            5. With logon complete the user is sent back to the “Access Onion” AD FS R2 RP-STS. Here additional claims processing, MFA checks and authorization for the SharePoint “Access Onion” Teamsite relying party take place.


            6. The user is redirected to the SharePoint “Access Onion” Teamsite whereupon, assuming permissions have been granted to the SharePoint site, they gain access. The URL termination of this connection is at the Web Application Proxy and connections to SharePoint are reverse proxy through the WAP.

            On the “Access Onion” SharePoint Teamsite relying party is a rule specifying all external users must use MFA.

            This corresponds to the following additional authentication rule:

            c:[Type == “;, Value == “false”]=> issue(Type = “;, Value = “;);

            Similarly, in the “Azure Sprout” organization, the “Access Onion” AD FS instance is a relying party and this is where the MFA requirement is enforced. This corresponds to an additional authentication rule for the “Access Onion” AD FS Relying Party of:

  ;, Value == “false”] => issue(Type = “;, Value = “;); c:[Type == “;, Value == “true”] => issue(Type = “;, Value = “;);

            Earlier, on the “Access Onion” side, we hand-waved all logon requests to the “Azure Sprout” organization when setting up Home Realm Discovery (HRD) by using suffix routing.

            Set-AdfsClaimsProviderTrust –TargetName “Azure Sprout” –OrganizationalAccountSuffix @ (“”)

            On the “Access Onion” AD FS side of things, we can validate whether MFA has been used during logon and the appropriate MFA claim value emitted by the “Azure Sprout” MFA Provider. On the “Access Onion” AD FS RP-STS, we create the following authorization rule for the “Azure Sprout” claims provider:

            c:[Type == “;, Value =~ “^(?i)http://schemas\.microsoft\.com/claims/multipleauthn$”]=> issue(Type = “;, Value = “PermitUsersWithClaim”);

            On the “Azure Sprout” AD FS instance, we configure MFA as a requirement for the “Access Onion” relying party (RP-STS). All users in that organization then use MFA when accessing the “Access Onion” SharePoint Teamsite.

            Logging on with our test user ( using their UPN and password and we’re faced by the Windows Azure MFA Server required authentication.

            As before, this second step involves the use of a call-back process and the test user I’m logging with receives a phone call, whereupon the hash/pound key has to be pressed to confirm I’m in possession of the device.

            Logging on to a test WIF claims aware web application, we can see that a claim value is issued for use of the Azure MFA via phone confirmation. This illustrates that it is possible for MFA providers to provide custom claims in their (MFA) response to AD FS.

            We can then access SharePoint, assuming the appropriate permissions are granted on the site concerned.

            Let’s extend the scenario to see how MFA works with the a mobile device, such as an iPad.

            MFA and Other Devices

            I’ll use the same Workplace Join conventions I described in the first post, this time with MFA as an auxiliary logon mechanism. On the Device Registration Service (DRS) relying party itself, we’ll set a requirement for MFA to be used for unregistered devices.

            From the iPad, we the Workplace Join process by entering the URL of the DRS endpoint in Safari. At this point we need to logon with our AD credentials.

            Then we hit the MFA logon requirement.

            Following a successful logon, we then start the enrolment process for Workplace Join on the iPad. The procedure at this point is the same as the one described in Part I. The user points their browser to an enrolment endpoint, e.g.


            We install a profile.

            Once completed and there is a successful join to the workplace, the device is registered within AD and a certificate installed in iOS. Device authentication then becomes available as a qualifier when setting conditional access policies to permit access to the enterprise network.

            Let’s look at an example using the “Azure Sprout” AD FS configuration accessing the “Access Onion” SharePoint Teamsites. Redirected to AD FS R2 instance during logon, the certificate is used to assert the identity of the user on this device.

            The HRD screens sign-in screens are similar to those we saw earlier on a Windows PC using Internet Explorer.

            Click on the Other Organization link and enter
            our as user for logon. The use of ensures that the user is routed to the “Azure Sprout” organization.

            At the “Azure Sprout” AD FS the user must logon with their AD primary authentication credentials.

            With MFA enabled on the AD RP-STS rule for the “Access Onion”, the connecting user must satisfy the MFA logon requirement with Azure MFA phone authentication:

            A call is made to the user phone to confirm authentication. Logon can continue.

            Claims are processed on the claims provider pipeline and then on the SharePoint relying party, and we’re into the SharePoint Teamsite. Having logged on with our user/device pairing, the SSO features of Workplace Join now come into play. The user registered to the device is now issued with an SSO token that is persisted for 7 days (default setting). Subsequent logons by that user will only require validation of the SSL device certificate when accessing AD FS until the token expires.

            This persistence behaviour can be adjusted via the Set-ADFSProperties –PersistentSSOLifetime setting (minutes). To disable this, we can use the following command:

            Set-AdfsProperties -EnablePersistentSso $False

            Don’t forget when testing that the SSO experience is bound to the user and device pairing. Logging on with another user will not exhibit the same behaviour.

            MFA with Non-claims Aware Web Applications

            All the examples to date have been with claims-aware web applications. R2 also provides support for relying parties that are non-claims aware using the kerberos protocol. This is a great feature and the combination is made possible by creating a non-claims aware RP within AD FS and then making the application available through publishing it via the Web Application Proxy (WAP) using Kerberos Constrained Delegation between the front-end WAP and the back-end web application. This, of course, means that the Web application Proxy must be domain-joined.

            In the test below four servers have been used, with all servers member of an Active Directory (a-onion.local):


            Server Name (FQDN)

            Web application FQDN (


            Internal (Kerberos)

            External (MFA)

            R2 Domain Controller



            R2 AD FS Server



            R2 Web Application Proxy




            R2 Application Server (IIS)




            Access to the IIS application is through a qualified name of rather than the actual name of the server. The kerberos web application is reachable internally via DNS using the URL of The app itself is a vanilla IIS web page protected using Integrated Windows Auhtentication (IWA).

            Here’s an overview:

            This was tested using the “Azure Sprout” organization only. There’s no RP-STS, other AD’s etc. to speak of in this configuration

            Let’s quickly go throw the configuration steps.

            1. On the IIS server enable Integrated Windows Authentication (IWA) on the IIS website. In real life, this is more likely to be a given path rather than the website itself.

            2. Test access internally by adding the FQDN of the website URL into the Local Intranet Zone of the browser (Internet Explorer). Here we’ve add the
              URL to that zone security list.

              If you continue to be prompted with NTLM Challenge/Response, check that the SPN for the URL of the web application has been registered under the computer account (in a web farm scenario this would be an application pool). For example:

              SETSPN –S http/ a-onion\server333

            3. On the domain controller or a client with remote administration tooling installed, run the ADSI Edit snap-in, drill down to the Web Application Proxy computer object, right-click, select properties. Add a Service Principal Name (SPN) for the computername of the Web Application Proxy, together with the fully qualified name.

              Using the examples from the diagram, this would translate to:




            1. In AD Users and Computers (ADUC), on the delegation tab of the WAP computer account (server555.a-onion.local), add the computer account for IIS (server333.a-onion.local) as being trusted for delegation for HTTP (ms-DS-AllowedToDelegateTo)

            2. Create the non-claims aware relying party within the AD FS UI using the URL and path of the web application as the RP identifier (don’t forget the trailing slash)

            3. Specify that an MFA rule will apply to this relying party

            4. External Users are required to use MFA


            5. We’ll use the default authorization rule of Permit All.

            6. On the Web Application Proxy, create a publishing rule for the non-claims aware relying party.

            7. On the Web Application Proxy, we configure the rule for together with the SPN of the back-end web server (http/server333.a-onion.local).


            External clients should now be challenged for MFA when accessing the IIS Web Application. I’ve used a workplace joined Windows 8.1 device using Chrome to highlight this (NB: IE11 doesn’t challenge for the device certificate).

            Logging in with forms-based logon (primary authentication)

            The additional authentication rule executes for the MFA provider for logon:

            The user gets called back, as per the previously described method. Once they’ve responded, redirection to the non-claims aware IIS web application, our vanilla IIS splash-screen.

            So that’s it for now. I’ve glossed over some of the finer details in this post and apologies for any brevity. If you do require more information, please post in comments and I’ll try and answer quickly. Meanwhile, we’ll cover more fine-grained access control decisions in Part III, as well as Work Folders, Server Core installation and (time-permitting) some OAUTH access scenarios.

            Until then ….Happy New Year!

            First Impressions – AD FS and Windows Server 2012 R2 – Part I

            In the next few posts, I wanted to take a look at the changes to be found in Windows Server 2012 R2 with respect to Active Directory Federation Services (AD FS).  At TechEd Europe, I was fortunate enough to chat with some of the folks from the Active Directory team about the new enhancements and to cover them here in a little more detail. As you may have read, there are a significant number of changes in the R2 version and I’ll spread coverage of this over a number of posts.

            Part 1

                      Architecture Changes

                      Workplace Join / Bring Your Own Device (BYOD)

            o   Windows 8.1

            o   iOS Devices

                      Web Application Proxy

                      Extranet soft account lockout policies

                      Lost Device Protection

            Part 2

                     UI Changes

                     Access Scenarios

                     Authentication changes

            o  Multi-Factor Authentication

            o   Context-based Authentication

            o   Claims/Non-claims aware applications

            o   Policy-based Evaluation

            Part 3

                      OATH2 support

                      Work Folders

                      Better event handling / reporting

                      Server Core

                      Other stuff undiscovered J

            Architecture Changes

            The use of IIS with AD FS in Windows Server 2012 R2 has been eschewed in favour of a move to kernel-mode (HTTP.SYS). The motive, highlighted in discussions at TechEd, is to improve performance, provide greater sign-in customization options and to assuage concerns for co-locating AD FS and AD DS on the same server (IIS on domain controllers has been a long-standing security no-no).  As the use of federation services goes more mainstream in everyday use with Windows 8.1, this shift is understandable and an important design consideration.  With the new kernel-mode approach, support for running under server core also appears as an option in the new release.


            From a basic architecture standpoint and overview, the AD FS proxy has been supplanted by a role known as the Web Application Proxy, servicing connections for external clients. The user interface (UI) through the migration to kernel mode is also significantly changed. Authentication undergoes a radical overhaul with a Multi-Factor Authentication (MFA) Adapter available for plugging into Windows Azure Active Authentication and third-party MFA providers. This is also seen in more nuanced behaviour with respect to authentication within the product, reflected in greater flexibility in access control decisions.

            With AD FS now built directly built on top of HTTP.SYS, a lot of changes  are abstracted from the user through the new MMC UI and also PowerShell. Nonetheless, it’s worthwhile familiarizing ourselves with kernel mode elements, as they serve a useful role in basic service troubleshooting/configuration . The NETSH HTTP command can be used to query and configure http.sys.

            The netsh http show urlacl command can be used to list URL reservations that AD FS makes within http.sys.  Here we can see the /adfs/ path reserved for use.


                Reserved URL            : https://+:443/adfs/

                    User: NT SERVICEadfssrv

                        Listen: Yes

                        Delegate: Yes

                        SDDL: D:(A;;GA;;;S-1-5-80-2965554544299-213434830-363436364-117610243-975697593) 


            And there’s this new guy, the Device Enrolment server, whose role becomes more apparent should we wish to make use of new Windows 8.1/iOS client (mobile) integration features.

                Reserved URL            : https://+:443/EnrollmentServer/

                    User: NT SERVICEdrs

                        Listen: Yes

                        Delegate: Yes

                        SDDL: D:(A;;GA;;;S-1-5-80-1321940109-3370001082-3650459431-215109509-2472514016)


            SSL bindings can be reviewed using the netsh http show sslcert command. The AD FS server in this demo setup I’ve created is

            PS C:Windowssystem32> netsh http show sslcert


            SSL Certificate bindings:



                Hostname:port                :

                Certificate Hash             : 1f54c1c62b057dscffgb1aec2b2cbd0876e5c559

                Application ID               : {5d89a20c-beab-4389-9447-324788eb944a}

                Certificate Store Name       : MY

                Verify Client Certificate Revocation : Enabled

                Verify Revocation Using Cached Client Certificate Only : Disabled

                Usage Check                  : Enabled

                Revocation Freshness Time    : 0

                URL Retrieval Timeout        : 0

                Ctl Identifier               : (null)

                Ctl Store Name               : AdfsTrustedDevices

                DS Mapper Usage              : Disabled

                Negotiate Client Certificate : Disabled


                Hostname:port                : localhost:443

                Certificate Hash             : 1f52c0d62b0570c6a26c7fec2b2cbd0876e5bc59

                Application ID               : {5d89a20c-beab-4389-9447-324788eb944a}

                Certificate Store Name       : MY

                Verify Client Certificate Revocation : Enabled

                Verify Revocation Using Cached Client Certificate Only : Disabled

                Usage Check                  : Enabled

                Revocation Freshness Time    : 0

                URL Retrieval Timeout        : 0

                Ctl Identifier               : (null)

                Ctl Store Name               : AdfsTrustedDevices

                DS Mapper Usage              : Disabled

                Negotiate Client Certificate : Disabled


                Hostname:port                :

                Certificate Hash             : 2f5c41c62b0570c6a26c7fec21d2d0876e5c559

                Application ID               : {5d89a20c-beab-4389-9447-324788eb944a}

                Certificate Store Name       : MY

                Verify Client Certificate Revocation : Enabled

                Verify Revocation Using Cached Client Certificate Only : Disabled

                Usage Check                  : Enabled

                Revocation Freshness Time    : 0

                URL Retrieval Timeout        : 0

                Ctl Identifier               : (null)

                Ctl Store Name               : (null)

                DS Mapper Usage              : Disabled

                Negotiate Client Certificate : Enabled


            Location-wise, the AD FS application files themselves are no longer held under C:Program FilesActive Directory or C:Program Files (x86). Instead, they’ve moved to C:WindowsADFS. For clarity, this was actually a change instigated first in Windows Server 2012 with the Active Directory Federation Services (AD FS) 2.1 role.  In this folder is the Microsoft.IdentityServer.Servicehost.exe.config file, where, as admins, we’ll be spending more time in the future in order to activate debug functions. From this file all trace options for various services and endpoints can be enabled. In the same folder is a configuration file for the new Device Registration service (DRS), responsible for activation and enrolment of controlled devices and represented by a new (Win8/IOS *) schema class in Active Directory Domain Services (AD DS). The file in question is called   Microsoft.DeviceRegistration.ServiceHost.exe.config. 

            Support for the new Device class requires a schema change to Active Directory. For those upgrading an existing Windows setup, the appropriate files can be found on the R2 installation CD under D:SupportADPrep.  From what I’ve seen/tested thus far, to support the new release, you’ll need at least one Windows Server 2012 domain controller, preferably two in any serious deployment scenario. This requirement stems from the use of Group Managed Service Accounts (GMSA) that are generated and maintained by the Key Distribution Service (KDS) on 2012 domain controllers. The new version of AD FS makes use of these GMSA accounts, defined during AD FS installation, that are then shared amongst connecting AD FS hosts. I suggest reading the following backgrounder and bear in mind that the AD FS Windows Server 2012 preview  labs incorporate a workaround for testing purposes, in activating the root key, that is not recommended for production environments.

            Update 29/10 –  SamD from the AD product team added that “gMSA is not required to be the service account that ADFS runs on. It is an additional optimization that is available to customers if they have Win2012 domain controllers available.” The traditional service account option is available during installation.

            Moving on, let’s take a look at the “broader” access audience that the new version emphasises. This can be immediately seen by viewing the claims descriptions list surfaced on a new AD FS installation.


            There are around 40 new claims descriptions available in the AD FS Windows Server 2012 R2 release. As we’ll see, use of these new claims types allow us to make more refined assessments concerning  access to web applications and resources.

            Workplace Join / Bring Your Own Device (BYOD)

            Through the new Workplace Join feature within R2, AD FS becomes a focal point for mobile access in the enterprise and an integral component in the Microsoft Bring Your Own Device (BYOD) vision. Workplace Join allows hitherto unmanaged/untrusted operating systems such as Windows RT/Windows 8 and IOS to be moved into a more controlled access context, by allowing their registration and affiliation with Active Directory. Devices will register with Active Directory through a Device Registration Service (DRS) and subsequently use an X509 certificate bound to the user context(s) on that machine for device authentication. In a default configuration, users will login via AD FS to initiate the join process using their AD credentials.  To further secure this process, additional factors can be also used with Windows Azure Active Authentication (PhoneFactor) or a third-party authentication provider exposed through the new AD FS MFA SDK.

            Devices that are workplace-joined emit additional claims during the logon process. These include:


            Certificate support in claims handling has also been enhanced.


            Windows 8.1

            In order to provide a comparison between old and new with Workplace Join, I began by looking at what claims (and any new ones) are processed from a vanilla Windows 8.1 Pro domain-joined machine, using a simple WS-Federation relying party to validate claims emitted the client and AD FS components.

            Firstly via the internal network and the AD FS farm using Internet Explorer. Here the browser uses Integration Windows Authentication/Negotiate and the user silently accesses to the WIF relying party via Kerberos. The usual configuration caveats apply here: the URL of the AD FS and RP instance are in the Local Intranet Zone of IE.


            To demonstrate a new change, I installed Mozilla Firefox and repeated the logon process. Instead of the Integrated Windows Authentication (IWA)/Negotiate process, the user is presented with a forms sign-in page. This represents a departure from the user experience and behaviour in AD FS 2.0. With the latter,  authentication would be downgraded to NTLM,  because IWA was assumed in the farm configuration and the browser needed to be configured to explicitly support Kerberos for seamless login. Where the latter action was not performed,  the user would receive an NTLM challenge/response prompt, often causing confusion. With the new release, support for IWA is now governed through setting registering User Agent types within AD FS that are capable of supporting Negotiate. Out of the box, this is constrained to IE, meaning any other browser will revert to using forms logon when accessing resources from an internally connected client . Here we see the claims output from a Firefox login:


            In internal login scenarios (IE/Firefox), we see new claims types emitted concerning location (whether the login request is sourced within the Corporate Network), an Application Identifier (corresponding to the Relying Party Identifier), the Client source IP (or translated) address, an Authentication Method Reference and a Client Request ID.

            Then, via an external network through the new Web Application Proxy:


            In addition to those claims types mentioned earlier is a new claims type for the client forwarded IP (x-ms-forwarded-client-ip) processed at the Web Application Proxy. The insidecorporatenetwork value  is now set to false, as we’re on an outside network.

            You may have observed at this point that there are no Device claims. This makes sense if we consider that their use is limited to client types that declare them, i.e. only workplace-joined clients currently make use of the Device class.  

            Onto the workplace join process itself. To get your test lab up and running, I recommend reading this TechNet article.

            If you follow the lab guide carefully, and, in particular, with emphasis on getting the dependent infrastructure working correctly, then with a little patience and time, you’ll be up and running. I tried this with the basic lab setup (a good starting point) and then expanded this in new setup using my own test domain. There are a few gotchas worth pointing out, hoping that you’ll avoid my growing pains …

            1.      Don’t use Cryptography Next Generation (CNG) algorithms when configuring your AD Certificate Services. They won’t work.

            2.      For simplicity in your CA configuration, I’d opt for use of HTTP Distribution endpoints, particularly if you intend to test “outside” configurations using the Web Application Proxy. Ensure the Certificate Revocation List (CRL) on the Certificate Distribution Point (CDP) and your Authority Information Awareness (AIA) URLs are setup correctly and reachable from the Win 8.1 client. If you’re using Delta CRLs and IIS as the web server for your CDP, don’t forget to allow Double Escaping on IIS in the Request Filtering section.

            3.      Ensure the Enterprise CA is trusted by the client and the certificate is installed in the Trusted Root Authorities section of the client. Importing the cert via the AIA endpoint is a good way of testing its availability and installing the certificate. Again, the certificate distribution point (CDP) URLs should be visible to the client.

            4.      Issue the AD FS certificate, complete with SAN for the Device Registration Service (DRS), before you begin your AD FS setup. The common name (CN) on the certificate should be the AD FS URL and two Subject Alternate Names (SAN) entries should contain the AD FS URL and one for the Device Registration Service (DRS) provided. For example, I’ve used an example using the MMC snap-in Certificate Request wizard, based on a copy of the default Web Server template for a common name of for the FQDN URL of the AD FS service and also as the first Subject Alternate Name (SAN) entry. A second SAN entry is used for the DRS endpoint,



            5.      As posted on the Technet forums (in the current R2 preview), both the AD FS server and the Windows 8.1 client need to be configured with time-zone of UTC 0:00 or less. My setup is using Pacific Time (UTC -8:00). Don’t ask me, I just blog here J

            6.      Don’t forget to enable Device Authentication in Global Primary Authentication settings within the UI or via PowerShell.

            7.      Use the Event Log Microsoft|Workplace Join to troubleshoot!! Here’s a collage of  first-hand events to illustrate it’s effectiveness in troubleshooting:



            URL (enterpriseregistration.xxxx.yyyy) cannot be resolved or reached.



            Can’t reach the CRL CDP of the AD CS endpoint.



            Root Authority is not trusted by the client.



            This message is stating a number of possible issues (generally bad):


            o   DRS Configuration and Activation was not completed successfully

            o   Issues with the SAN on the SSL certificate

            o   AD FS Device Authentication has not been enabled


            Once you start seeing messages like the following, you’re almost there.







            8.       Take particular note of any errors reported when trying to activate Device Registration Service; namely anything  along the lines of:

            WARNING: UPN values that are not included in the SSL certificate have been found in the enterprise. Users with these UPN suffix values will not be able to register their devices. To enable users with the corresponding UPN suffix to register their devices, provide a new SSL certificate containing the values listed below in the subject or subject alternative name.


            In the case of (8), I’d made the mistake of not registering the appropriate certificates with Subject Alternate Names (SAN) that included the DeviceRegistration CNAME record. Simply re-issuing the AD FS service certificate afterward, setting Manage Private Keys etc. and re-activating DRS in PowerShell was not sufficient to get the configuration working.

            The Workplace Join function can be accessed by first accessing the Change PC Settings option on the Windows 8 UI


            In PC Settings, choose the Network option

            Then select Network followed by the Workplace option:


            If your configuration is working, certificates are trusted, appropriate AD FS and PKI endpoints are reachable, stars are in alignment (just joking), then clicking on the Join button leads to AD FS responding with a challenge:


            Enter the Active Directory credentials for the user. In this example I’m using, the device is joining a test domain called Note the AD FS URL (connecting to my R2 instance at the top of the page. For the auto-discovery of the AD FS Device Registration Endpoints (DRS) a CNAME (Alias) record in DNS needed to be created for the service called This record points to the host (A) record of the AD FS federation service internally. This allows the discovery process to find the DRS endpoint and in an external setting this would point to the Web Application Proxy,  your own Reverse Proxy or other suitable edge device.

            The relying party (RP) for the Device Registration Service is created during the DRS activation process, so there’s nothing additional required on this side.


            Connecting Windows 8.1 clients will use the auto-discover function by matching the domain suffix of the user account provided during the join process against the enterprise registration CNAME record for that domain. The join process then attempts a call to the enrollment server web service. Using the domain as an example, the following endpoint is queried:


            If the service can be reached successfully, the join process is initiated.


            The process is now completed and the “join” associated with the Windows 8.1 user profile. I used a Microsoft Live ID account and as can be be seen from the above screenshot, a subsequent AD user called demo with a UPN of,in doing so  providing my AD credentials during the Join. Please note that the Active Directory domain I’m using is also called (dc=adfs2,dc=net) for convenience. In a real-world/production scenario, the DNS domain names used for Active Directory and that of the federation service itself may be different.

            The user account is then issued with a self-signed  X509 certificate with an Extended Key Usage (EKU) of Client Authentication. Jumping into the Certificates|User snap-in we see a certificate issued under the user context.


            Back to the WIF 3.5 relying party (RP), logging on to the RP from the outside we get redirected to AD FS for logon. Upon successful logon, the following claims are shown.


            With the Win 8.1 device now connected to the AD domain via a Workplace Join, we see additional claims consummated.

            ·         IsRegisteredUser

            ·         OS Version

            ·         OS Type

            ·         Identifier (Subject name of the cert)

            ·         Display Name (corresponding to the Device Name)

            ·         Registration ID (corresponding to an OU served up in the certificate)

            The device itself is registered within Active Directory at the following location: CN=<Device ID>,CN=RegisteredDevices,DC=mydomain,DC=com.

            Here’s an example with a SAML 2.0 Service Provider (SimpleSAMLphp), with a Workplace Joined Windows 8.1 client connecting to it.

            Inside the corporate network, we see the following:


            As tempting it is to delve further into authentication, I’ll refrain from doing so and leave this to a follow-up post. My apologies, otherwise this post will reach biblical proportions in length and we’ll be shaking hands with Santa Claus before we know it.

            iOS devices

            From testing, the auto-discover function using the enterpriseregistration CNAME record in DNS, described in the previous section, is limited to the workplace join process for Windows 8.1. iOS clients must directly connect to AD FS to initiate the join process. The endpoint settings on the DRS Relying Party refer to a URL of:


            This is the DRS Over-the-Air endpoint for non-Windows devices (currently iOS only).

            I used an iPad 3 running iOS 6.1.3 for this exercise. If you plan on using self-signed certificates for this type of testing, you’ll need to use the iPhone Configuration Utility to create a profile which can be then used to install the root certificate from your Certificate Services Issuing CA (and any optional chain).

            If you’re testing iOS or Windows 8.1 devices in an external setting, it’s worth mentioning that the Web Application Proxy (WAP), which I’ll cover in a moment, doesn’t provide an HTTP Reverse Proxy function. To ensure that any CRL/AIA distribution points are visible in an “outside” testing context, I elected to install IIS on the WAP, publish the CRL/AIA Certificate Distribution Points (CDP) via a UNC from the CA itself to be made available as an HTTP URL on the Web Application Proxy via IIS, making the distribution points reachable from an external perspective. Clearly, this is not something one would do automatically in a production environment, without a bit of forethought, but it works well in a demo environment. You can probably also do this with a kernel mode only approach, but I didn’t have time to test this (yet).

            Once the Apple configuration file (.mobileconfig) file had been deployed onto my iPad (via e-mail), a Profile containing the Root certificate was generated and the certificate installed.



            With the root certificate or chain correctly installed, going to the AD FS server URL, we should not receive any SSL errors or warnings in the browser, indicating that the chain and CRL/AIA distribution points are reachable. To test this, you can use the IdP initiated sign-on page in the default setup, e.g. https://YOURFQDN/adfs/ls/idpinitiatedsignon.aspx.  From the iPad, here’s the portrait view of the page.


            Playing around, I turned the iPad on its side and we get an automatically resized window. This is a nice feature in the new UI in AD FS 2012 R2 that supports dynamic adjustment and positioning of elements through CSS, resizing pages accordingly across various devices and user agents (think mobile client).


            In order to kick off the Workplace Join, we point Safari to the endpoint DRS mentioned earlier:


            This redirects the browser to a sign-in page where we need to logon with the AD account that will be bound to the iOS device for the workplace join.


            Logging on with the account I used in the Windows 8.1 example, the Safari page remains open in the background and the foreground switches to the install profile option on the mobile device.


            The install profile option and Workplace Join install option appears:


            Clicking on the More Details option, we can see that the AD FS Token Signing Certificate (public key) and the Device Enrollment Encrypted Profile Service are referenced during the profile installation.


            Clicking on Install Profile


            Once the profile is installed we see a Certificate issued to the device, issued with a common name of MS-Organization-Access, as per the Windows 8.1 join process.


            Returning to the profile screen we see the completed Workplace Join profile


            NB: The Demo Auth360 profile is the imported .mobileconfig containing the root certificate from earlier.

            Web Application Proxy

            Sitting in front of the AD FS farm is a new optional role, similar to the AD FS Proxy in AD FS 2.0, called the Web Application Proxy. This is a completely redesigned component, built to cater for federation services scenarios as well additional access scenarios beyond those seen in AD FS 2.0. 

            As with DirectAccess in Windows Server 2012, more roles are being moving into the mainstream product and the Web Application Proxy is a module in the Remote Access role within Windows Server 2012 R2.


            Configuration of the proxy itself also moves to the Remote Access Management snap-in.


            A configuration wizard is provided to connect the proxy to the back-end AD FS farm and a service account is required to register with the AD FS server(s) during installation. This service needs to be a member of the local administrators group on the AD FS farm.

            Once connected to AD FS, a number of simple options are available for configuration.


            The UI is at this stage is admittedly basic, but as with DirectAccess in 2012, there’s a greater emphasis on using wizards to get the job done and whatever can be done in the UI can be done (and more) via PowerShell; a PS configuration script is provided as a summary at the end of each publishing wizard rule to demonstrate this point.

            As with TMG/UG we can publish/proxy a particular URL or URIs/paths of that URL expressed as separate publishing rules on the proxy , e.g.

   (as one allow all rule) versus

   as Rule#1

   as Rule#2

   as Rule#3

            An interesting under-the-covers capability is support for Server Name Indication (SNI).  SNI, initially provided in Windows Server 2012, allows for multiple certificates to be bound to a single IP listener. Prior to IIS 8.0/SNI, sharing IP addresses amongst multiple websites was limited to the network endpoint and their IP:Port binding. SNI is a TLS extension that provides the hostname of the server the client is connecting to during handshaking. This allows much greater flexibility when configuring the proxy. With the move to kernel-mode, all the hard lifting is done through the UI or via PowerShell. familiarity with NETSH HTTP will also assist in any troubleshooting or ad-hoc configuration. The majority of browsers support SNI, although Windows XP in any configuration using Internet Explorer does not.

            The current preview of the proxy in the R2 release provides for connections as:

            1.       A reverse web proxy, connecting to back-end servers via HTTPS;

            2.       A pre-authentication web proxy, connecting to AD FS via HTTPS to validate credentials

            a.       For claims aware web applications

            b.      For non-claims aware web applications using Kerberos

            When we publish a new AD FS compatible application (pre-authentication), the proxy pulls the RP list/ configuration from the AD FS farm. Polling is done (looking at the event logs) every minute.

            Using a Windows Identity Foundation (WIF) test relying party application from another test domain (psid.local),  here’s an example of a publishing rule:

            Add-WebApplicationProxyApplication -BackendServerUrl ‘https://rp.psid.local/app9/’ -ExternalCertificateThumbprint ’91D8014979B9CDEF9C907171F7CE9AF398E66DC6′ -ExternalUrl ‘https://rp.psid.local/app9/’ -Name ‘WIF Test Application’ -ExternalPreAuthentication ADFS -ADFSRelyingPartyName ‘WIF 3.5 Application’

            This is a pre-authentication rule, meaning that AD FS process the login request, UI surfaced and  validates access and authentication credentials through the proxy via a back-channel connection before access to the relying party is processed.

            To complete this round of testing, I wanted to validate Workplace Join from an “outside” network via the proxy. DRS endpoints are automatically published, meaning no specific additional publishing rules needed to be created.

            On the Windows 8.1 client, I removed the client from the Join agreement created earlier in order to re-attempt the join via the proxy from the external network. When we attempt a join again from the “outside” via the Web Application Proxy, clicking on Join generates the following page.


            The user ID is automatically populated in the form, carried over from the Join request.

            Testing from the “outside” now, when we access our WIF application RP from our Workplace Joined client (via the Web Application Proxy), we’re served up with a sign-in form.


            That’s expected as we’re now an Extranet client (using MS terminology). This is confirmed by looking at the base AD FS configuration and the primary authentication provider serving up forms login for external clients.


            “Extranet” users are automatically assigned to the forms authentication sign-in process, whereas Intranet users are assigned Windows Authentication, browser considerations notwithstanding. For those familiar with fiddling with Local Authentication Types in web.config on the AD FS proxy/farm in AD FS 2.0, making this available through the UI and Powershell is a boon J

            Going back to our relying party application, we can see in the produced claims that the client connection is not through the corporate network and is via Web Application Proxy using the following claims:  




            The client is outside the corporate network and the user is now registered. As a simple test, if we only want to allow Registered Users access to our RP claims web application, we could do this through an Authorization Rule that states that only Registered Users are permitted access:

            c:[Type == “;, Value =~ “^(?i)true$”] => issue(Type = “;, Value = “PermitUsersWithClaim”);

            Logging on with a non-workplace joined client from outside the corporate network, we are denied access.



            Error pages are customizable and that’s something we’ll cover in Part 3.

            As I touched on earlier, we can use SSL bridging scenarios incorporating wildcard certificates on the front-end (proxy) and named certificates (on the back-end) in publishing scenarios. The pre-authentication parts allows integration with claims and non-claims aware (Kerberos) applications. Applications such as Exchange, which are not claims-aware or non-SAML kerberos claims SharePoint web applications can be configured via the Web Application Proxy. From testing rich client applications such as ActiveSync and Outlook, which use Basic/NTLM application, these are not currently supported on the Web Application Proxy either in a pre-authentication or pass-through capacity. The proxy defaults to SNI and this is not supported by some mail clients.  We’ll cover this and other authentication scenarios in Part 2.

            Just to wrap up, here are some observations from testing:

                    The proxy can translate host names in URLs but not path names. Make sure that the published path matches that of the application;

                     There’s no Edit function in the UI once you’ve created a publishing rule;

                     The Web Application Proxy is currently HTTPS only, so no HTTP publishing. Hopefully this will be corrected in the near future as scenarios such as CRL/CDP publishing, which use HTTP are not supported in Reverse Proxy scenarios today. Meanwhile, HTTPS-HTTP bridging, sometimes used in Kerberos Constrained Delegation (KCD) scenarios with TMG/UAG are also not possible as AD FS is HTTPS only.

            Extranet Soft Account Lockout

            Extranet soft account lockout imposes an option to temporarily lockout “extranet-connected” accounts, via the Web Application Proxy, by not incrementing the AD BadPassword count on the PDC Emulator in AD once the soft lockout threshold is set in AD FS.  If the latter is reached, further logon requests are not passed to AD so that AD Password Policy “hard” lockout measures are not immediately triggered.  As the name suggests, this is a soft lockout option that is governed by use of an observation/sliding window that determines how often in a given period a user may attempt to logon via the proxy before the soft count is reached. The goal here is to frustrate password guessing attempts via brute force/DoS from the outside by nefarious users.

            Update 29/10 –  SamD from the AD product team mentioned that the extranet lockout feature was also done with the view that customers with ADDS account lockout policies can prevent DOS attacks on specific user accounts by setting a threshold lower for the ADFS extranet lockout policy. This way the user still has internal access because ADDS has not locked out the user.

            Soft Account Lockout can be invoked through the use of PowerShell.

            $observationwindow = New-Timespan -Minutes 1

            Set-ADFSProperties –ExtranetLockoutThreshold 3 -EnableExtranetLockout $true -ExtranetObservationWindow $observationwindow

            Once set, we can see via Get-ADFSProperties, the changes applied:

            ExtranetLockoutThreshold              : 3

            ExtranetLockoutEnabled                : True

            ExtranetObservationWindow             : 00:02:00


            Here we’ve set the lockout threshold to three attempts with an observation window of two minutes.

            From a testing standpoint, In the demo AD Domain setup, “hard” account lockout is not set via GPO.


            Attempting to login at the RP WIF test application, we’re redirected to  AD FS for logon. I enter an incorrect password.


            The PDC Emulator FSMO role in AD, which monitors the bad password count (badPwdCount) increments by 1, likewise on the second and third bad password attempts.

            I entered a bad password five times in successive attempts. Continued attempts to logon with a bad password, once the observation window kicks in fails to increment the count beyond three for the windowed period of  two minutes. Once the window has elapsed, the bad password account is again incremented.


            One of the nicer aspects of this setting is that it applies to all endpoints, be they passive or active in nature. This is particularly relevant as it also applies to web services (WS-Trust) endpoints for rich clients, e.g. Office 365.

            Lost Device Protection

            As covered earlier, devices registered via Workplace Join are registered within Active Directory in the container CN=<Device ID>,CN=RegisteredDevices,DC=mydomain,DC=com. Lost devices can be denied access by disabling or deleting the appropriate object within AD (I moved the device objects to another OU to test this). Access through AD FS is immediately revoked for the workplace joined client.

            From testing thus far, devices joined, left and re-registered via Workplace Join are not currently cleaned up within the RegisteredDevices container. Some PowerShell scripting is currently required to enforce this and I would imagine some changes by GA or some scripts made available to manage this process.


            A very long post comes to an end.  Next up, we’ll look at UI changes and authentication/access in greater detail and there’s LOTS to cover. As ever, please feel free to comment, contribute, correct and I’ll get back to you!

            Home Realm Discovery– Supporting IWA and Forms Logon Local Authentication Types

            A recent use case propped up where it was necessary to support multiple authentication types from a local AD FS instance in an internal access scenario. The mechanics for such a requirement are described in this great post here:

            In our case, we’re substituting forms-based logon instead of the X509 client certificates described in the article. I’ve included a third MFA example to illustrate that additional legitimate claims providers can also be incorporated into the code changes.

            There are two points of interest to us where an ADFS installation typically displays a user interface. The first is during the initial client logon to the federation server / proxy.  The other is during the home-realm discovery process. Home-Realm Discovery (HRD) is a pre-authentication drop-down box in AD FS that allows users to select their “home” realm, sending them to their identity provider for correct logon processing. In a normal RP-STS scenario, where AD FS is both an authentication provider and a relying party, this could be:

            (a)    The default AD claims provider using Integrated Windows Authentication.

            (b)   A third-party claims provider / identity provider

            Both are valid claims providers in their own right, but I also needed to insert a third forms based “provider” option,  using local AD credentials, into this process. To do this, I used the customization of the HRD code-behind pages discussed in the post above.

            First, to ensure that the appropriate realm selection screen is provided each time, we need to disable persistent cookie use for home realm discovery. This is achieved by changing Home Realm persistence in the AD FS web.config. This changes from

            <persistIdentityProviderInformation enabled="true" lifetimeInDays="90"/>


            <persistIdentityProviderInformation enabled="false"/>

            Next, we’ll customize the local authentication types within the web.config so that Forms is the default logon method. More on this later…


                  <add name="Forms" page="FormsSignIn.aspx"/>

                  <add name="Integrated" page="auth/integrated/"/>

                  <add name="TlsClient" page="auth/sslclient/"/>

                  <add name="Basic" page="auth/basic/"/>



            When we click on this application, we see the HRD select screen, reflected in the following code in the homerealmdiscovery.aspx.cs code-behind page.

            protected void Page_Init( object sender, EventArgs e )



            PassiveIdentityProvidersDropDownList.DataSource = base.ClaimsProviders;



            As the article mentions, we can add our own logic in the Page Init section of homerealmdiscovery.aspx.cs to customize this approach. The base.ClaimsProviders data source will normally return the list of “enabled” claims providers within ADFS. By modifying the code behind,we define the existing claims providers and our new forms authentication type.  In the following example, we’ve three providers. The provider called AD that will use IWA, an MFA provider that calls out to the third-party IdP  (MFA) and our new custom forms logon provider (Forms).

            protected void Page_Init( object sender, EventArgs e )









            We then modify the PassiveSignInButton section of the code behind to handle the appropriate authentication and redirection.


            protected void PassiveSignInButton_Click( object sender, EventArgs e )


               //SelectHomeRealm( PassiveIdentityProvidersDropDownList.SelectedItem.Value );

               switch (PassiveIdentityProvidersDropDownList.SelectedItem.Value)


                        case "AD":

                            System.Web.HttpCookie cookie = new HttpCookie("MSISPAuthenticationMethod");

                            cookie.Value = "AD";

                            cookie.Path = "/adfs/ls";

                            cookie.Domain = HttpContext.Current.Request.Url.Host;


                            Response.Redirect("https://&quot; + HttpContext.Current.Request.Url.Host + "/adfs/ls/auth/integrated/" + HttpContext.Current.Request.Url.Query);



                        case "MFA":

                          System.Web.HttpCookie cookie2 = new HttpCookie("MSISPAuthenticationMethod");

                           cookie2.Value = "MFA";

                           cookie2.Path = "/adfs/ls";

                           cookie2.Domain = HttpContext.Current.Request.Url.Host;


                       PassiveIdentityProvidersDropDownList.DataSource = base.ClaimsProviders;


                      SelectHomeRealm( "; );



                        case "Forms":

                          System.Web.HttpCookie cookie3 = new HttpCookie("MSISPAuthenticationMethod");

                           cookie3.Value = "Forms";

                           cookie3.Path = "/adfs/ls";

                           cookie3.Domain = HttpContext.Current.Request.Url.Host;


                       PassiveIdentityProvidersDropDownList.DataSource = base.ClaimsProviders;


                       SelectHomeRealm( PassiveIdentityProvidersDropDownList.SelectedItem.Value );









            In the first case, we invoke the Integrated Windows Authentication (IWA) handler.

            In the second and third cases, we restore the original claims provider list,

            PassiveIdentityProvidersDropDownList.DataSource = base.ClaimsProviders;



            The second case invokes a third-party IDP by calling its home realm identifier. In this example, this is an upstream AD FS IdP recognizable via a identifer.

            In the third and final case – forms logon, we simply select the default claims provider, which you’ll recall, given the order of the web.config has been changed to forms logon. I did this for expediency, as calling formssignin.aspx directly just generated an error.

            Each time users connect, they’re now presented with the HRD dialog.


            As the folks from state in their post, to avoid irritating your users, you can set a cookie expiry period to persist the cookie  for a desired period for a given authentication method. In my test case, this wasn’t valid as users needed to regularly switch between various providers/authentication types. Of course, this has its own disadvantages from a convenience standpoint.

            PS: Thanks to a developer buddy of mine, Nico, who continues to exhibit remarkable depths of patience to a  certain .NET neophyte J

            Step-up Authentication Scenarios with AD FS 2.0 Part II

            With the R2 preview of AD FS in Windows Server 2012 out and the large number of changes that are taking place in the new release, I’m going to be bring this post to a quick end; more an abridged version than was originally intended.

            In Part I we looked at weaker authentication schemes for step-up scenarios. In Part II, we move onto two-factor/multi-factor authentication (2FA/MFA) use cases.

            There’s no real guided approach for doing this in AD FS 2.0, with solutions invariably becoming customized ones, according to the desired use case.  Whether AD FS is the authentication provider or occupying a hybrid/broker role, the use of authentication contexts, types and URIs provided by the supported SAML and WS-Federation protocols, become triggers for step-up.  Where a context is stipulated, in protocol terms, each is interpreted differently.

            SAML supported authentication methods

            Authentication Method Authentication Context Class URI
            Username/Password urn:oasis:names:tc:SAML:2.0:ac:classes:Password
            Password Protected Transport urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
            Transport Layer Security (TLS) Client urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient
            X.509 Certificate urn:oasis:names:tc:SAML:2.0:ac:classes:X509
            Integrated Windows Authentication urn:federation:authentication:windows
            Kerberos urn:oasis:names:tc:SAML:2.0:classes:Kerberos

            As we saw in the previous post, forcing authentication in SAML logon scenarios provides support for step-up, but at the expense of single sign-on. In passive federation scenarios, if we don’t specify an authentication method in the request, AD FS will apply authentication according to its own supported methods, attempting to match those against the local authentication types section of the web.config on the AD FS node.

            AD FS handles the SAML authentication in order of strength, lowest to highest, from top to bottom  as seen in the table: in the default configuration Kerberos is seen as the strongest method. The precedence of the authentication method can be adjusted using the Set-ADFSProperties –AuthenticationContextOrder command to ensure the order meets the requirement we need. The SAML comparison attribute can be used to also influence the authentication method chosen. with AD FS defaulting to a comparison=exact attribute.. As stated in the MSDN article Authentication Handler Overview, if the comparison attribute is set to “better”, “minimum”, or “maximum”, the method of authentication must be stronger than, at least as strong as, or no stronger than one of the specified authentication classes.  This gives us some latitude for using it to invoke the desired authentication method through customization of the sign-in process. With SAML the authentication reference is encoded in the SAML request, and to access and to use the information therein, in order to relay the authentication request to our third-party IdP,  we need to customize our sign-in process  so that the incoming SAML (AuthnContextClassRef) request is decoded. The information we then need needs to be extrapolated so that we can then make the correct routing decision, sending the client to the correct provider. Examples provided on Codeplex hint at how this can be done, by assigning a authentication methods to a relying party using FBA and IWA.

            On the other side, let’s look at an example using a WS-Federation based setup.

            WS-Federation Passive Profile supported authentication methods

            Authentication Method Authentication Context (wauth) URI
            Username/Password urn:oasis:tc:SAML:1.0:am:password
            Transport Layer Security (TLS) Client urn:ietf:rfc:2246
            Integrated Windows Authentication urn:federation:authentication:windows

            With the WS-Federation passive requester profile, the authentication type (wauth) parameter is specified in the query string of the browser or can be specified from the relying party application itself. The whr parameter is used to indicate the claims provide to use for logon.

              MFA Step-Up Scenario

              Let’s look at a step-up scenario using WS-Federation with an MFA provider.


              In the above graphic, we have a third-party MFA provider handling the authentication requests for internal access.. I’ve not included the AD FS Proxy for external access, but should we wish to do so,  we could adopt our AD FS proxy configuration and:

              – remove the local authentication handlers from the <localAuthenticationTypes> section  of web.config to ensure that MFA is always used in external access scenarios;

              – follow the same methods used for internal authentication described below;

              Internal access step-up scenarios imply the use of the default Integrated Windows Authentication (IWA) handler and the step-up mechanism. With a third-party multi-factor authentication provider, the (MFA) solution is configured within AD FS 2.0 as a claims provider.  I’ll use the example of the WIF-based STS from PointSharp which I mentioned in previous posts.

              In a step-up context, the STS needs to be able to process the required authentication request and pass this back to AD FS and the RP.   With WS-Federation we can do this via the browser as a query string, or, from the web application make use of the wauth and whr parameters to set the authentication method. 

              Step-Up at the Relying Party Application

              Using the WIF 3.5 SDK samples for our relying party, we modify the web.config to specify the desired authentication type.   I’ve chosen the X509 certificate handler. For our WIF application this corresponds to an authentication method value of urn:ietf:rfc:2246

                <wsFederation passiveRedirectEnabled="true" issuer=
     realm= requireHttps="true" authenticationType="urn:ietf:rfc:2246"
     <cookieHandler requireSsl="true" />

            The homeRealm value is used to specify the claims provider we want to call for step-up, otherwise AD FS itself will attempt to handle the logon, treating as an authentication request for an x509 certificate.

            On AD FS we configure the IP-STS as a claims provider.


            On the IP-STS, we configure AD FS as a relying party


            For convenience, both the STS and AD FS are sharing the same identity store (AD) and I’ve created a test user called demo in Active Directory and a security group called OTP, whom our user is a member of. We’ll use membership of that group on the PointSharp STS as a means of emitting an authentication method claim that corresponds to the expected authentication type. The claims value, urn:ietf:rfc:2246, is returned when a user logs on using MFA (e.g. OTP+password).

            The user demo points their browser to the RP URL and with the web.config modifications, the access request is redirected to AD FS and then to the PointSharp STS as the Windows home realm (whr).

            On the PointSharp STS during logon, the back-end PointSharp ID services handles the MFA logon request.  At the initial prompt, the user enters their user ID and AD password:


            They’re challenged to enter an OTP response (hardware/software token or SMS)


            Once authenticated, the STS then processes the matching claims rules.


            Above, demo is a member of the group OTP, as seen in the claims rule pattern, so a claims type of  http://schemas/ is generated. This is used to match the expected reply of the RP with a value urn:ietf:rfc:2246. and this claims is then passed back to AD FS.

            In our test web app we see the appropriate authentication method and values being returned. No claims rules on the claims provider or relying parties (at this point) have been done.


            Our MFA provider may also support multiple authentication types (AD password, SMS, tokens etc), so the fact that we logon at the STS is not necessarily indicative of a sufficient logon.With  AD FS as the RP-STS, we can also block requests that don’t emit the correct authentication method at the STS on the relying party claims pipeline.

            c:[Type == "", Value =~ "^(?i)http://schemas\.microsoft\.com/ws/2008/06/identity/authenticationmethod/tlsclient$"]
            => issue(Type = "
  ", Value = "PermitUsersWithClaim");


            With the authorization rule in place, another user, demo2, that is not a member of the OTP group, when accessing the RP,  logs on at the PointSharp STS, but gets the following error at AD FS:


            This translates in the event log to an access denied message:

            The Federation Service could  not authorize token issuance for caller ”. The caller is not authorized to request a token for the relying party ‘https://rp……..’. Please see event 501 with the same instance id for caller identity.


            While we can block in this fashion, it makes more sense to enforce and evaluate a more fine-grained access at the application itself. If the app is intended as an internal-only application though, we can also block access from the AD FS proxy via an access rule.

            exists([Type == "”]) => issue(Type = “”, Value = “true”);

            Step-Up within the Application

            The previous steps described step-up at the web application (relying party), rather than within the application itself. The WIF 3.5/4.0 SDK provides samples for step-up authentication using an example of a low-value and a high-value resource within a given application. Here we’re leveraging step-up against a particular resource within an application.


            Low-value resources are protected using normal Windows logon credentials (IWA), whereas high-level resources trigger step-up through the use of the certificate handler.


            This allows us to add in step-up authentication within the application itself, according to the value of the resource.

            A note on Virtual Smart Cards

            I mentioned in the last post about virtual smart cards (or VSCs).  As an authentication provider, they are available during Windows logon as a credential provider. Given that we wish to expressly enforce step-up at the application, then some sort of adjustment is equired.  It may be possible to suppress the use of the VSC as a credential provider and make it available post-logon for application-only access, something that I’ve not tried, but one could argue that this is a case of the tail wagging the dog. We could also use an alternate account as described in Part I or disable single sign-on in the web.config on the AD FS farm to enforce logon between relying parties. The fact that we’re using IWA for normal logon masks somewhat the behaviour of revisiting the AD FS server when switching between IWA-based relying parties.

            As ever, please extensively test before considering doing this sort of thing in a production environment.


            What’s been discussed so far relates to solutions that are on the “direct” authentication path from an identity federation standpoint. There are also MFA solutions that involve indirect authentication using multi-factor authentication. When I refer to Indirect MFA, Í mean some other component outside of the federation logon process that handles the strong authentication aspects of logon. Diagrams always help to illustrate the cause Smile…  

                1. Via a non-federation capable proxy or gateway component. This component does not integrate with AD FS, but can provide an MFA capability. All connections to the RP are through the proxy. Post-logon, the proxy does some form of credential delegation to the back-end AD FS service. Here’s an example of a logon scenario with Forefront UAG 2010 on a non-federated trunk. While UAG does support federated trunks (as a relying party), MFA on a federated trunk is not (to my knowledge) possible unless we use an upstream claims provider.


                2.  Via an MFA web agent running on the ADFS proxy as an ISAPI filter or module. This follows the traditional web access management approach of logon via a web agent, with the filter intercepting the call.  The user must logon using the stronger form of authentication before the web application, in this case the AD FS proxy pages are exposed. While functionally “integrated”, the two operate technologically independent of one another.


                  3. Via customization of the AD FS sign-in pages, allowing authentication to a MFA provider through web services. Of the three, this is (in my mind) is the most technically plausible, but handling step-up in such cases would also be complex and I’ll refer to that in a moment.


                    None of the above mechanisms are particularly well suited to step-up because the MFA logon process wraps around normal AD FS logon process, rather than integrating with it. While they may be valid in other access scenarios, i.e. the logon request is intercepted by a handler that doesn’t understand federated logon.

                    Option 3 is interesting as, via a slight modification, it supports illustrating where MFA is going in the next release of AD FS in Windows Server 2012 R2.

                    Windows Server 2012 R2


                      In AD FS R2, Microsoft are making available an MFA API for vendors to plug-in to and integrate with the federation service directly, allowing for a more rich logon experience. This also extends the concept of using multi-factor authentication not only at a protocol and application level, but at a policy level too, whereby policy per relying party for authentication is achievable. It also suggests that the redirect method via claims providers is being eschewed by Microsoft in favour of a more AD FS centric approach. I suspect the aim here is to provide a more level playing field for integrating external authentication providers with AD FS rather than placing the burden on the vendor and heavy use of customization to support scenarios described..

                      What this means for step-up scenarios we shall see. I’ll be looking at this raft of new features with AD FS R2 in future posts.

                    Virtual Smart Cards (VSC) and AD FS 2.0

                    Before I finish the second article on Step-Up Authentication, I thought I’d write something quick about Virtual Smart Cards (VSC), as they also feature in the next post.

                    While Windows 8 has been taking lots of flak for various UI changes, there are a number of nice new features that have snuck in rather quietly. One of these is support for Virtual Smart Cards (VSC). VSC’s  provide an alternate strong authentication mechanism  that removes the need for a physical smart card reader. They emulate the use of a physical card reader via the use of the Trusted Platform Module (TPM) found in most modern  business-grade computers. The TPM module stores the private key of the virtual smart card. While, it’s not two-factor authentication per se, (the virtual smart card is stored on the same device as the crypto module), it is nonetheless an improvement strength-wise over username/password and software-based digital certificates. We’ll give it the official 1.5x times authentication moniker (1.5FA) Smile.

                    Private keys are stored in the crypto functionality of the Trusted Platform Module (TPM) of the laptop. The private key is device centric, with the virtual smartcard stored on the same computer. The TPM module needs to be enable on the computer. This can be done manually (woo-hoo!) or via some form of script, or in conjunction with vendor client instrumentation software.

                    VSCs provide a number of nice features, but they add a little more added complexity in the setup stakes. Given that we’re emulating physical smart card behaviour, we’re going to need a certificate and that means Certificate Services and an enterprise Public Key Infrastructure (PKI).

                    I’ve used a Windows 2008 R2 CA in this example. On the enterprise certification authority (CA)  we can duplicate the built-in Smartcard Logon template found in certificate services using the V2 Windows Server 2003 compatible template.


                    With our new template, entitled Virtual Smart Card, on the Request Handling tab set the certificate purpose to Signature and Smart Card Logon and the minimum key size to 2048. On the Cryptography tab set the cryptographic provider to the Microsoft Base Smart Card Crypto Provider.


                    Give (authenticated) users Enrol permissions on the Security tab of the template and then issue the new certificate template.


                    We can use the built-in tool TPM Virtual Smart Card Manager (tpmvscmgr) to provision the smart card.

                    tpmvscmgr.exe  create /name Auth360Test /adminkey random /generate

                    The generate command formats the TPM virtual smart card so it can be then used to enrol for certificates.

                    From a LAN or DirectAccess connected PC we can enrol via use the MMC Certificate Users snap-in, using the Request New Certificate option


                    Select the Virtual Smart Card template.


                      During enrolment a PIN needs to be set.


                    With the VSC enrolled. we can now logout and the virtual smart card should be available for logon.

                    Click on our enrolled user and then logon with our PIN.


                    I thought I’d give this a whirl with AD FS. For the purposes of this exercise, to support VSC smart logon,  I changed my AD FS proxy configuration to support client certificate authentication, modifying the local authentication types parameter in the web.config on the AD FS proxy. We’ll cover other logon scenarios using VSCs in the next Step-Up authentication post.


                    Meanwhile, TLSClient (SSL Client Certificate) is elevated to the top of the list and switched with the default Forms authentication.

                    Users accessing the AD FS proxy with a VSC now get a prompt to select their certificate


                    Having highlighted and click my user, I now enter the PIN.


                    Users not possessing a smart card user certificate will get a 403 error.


                    The problem with this approach is that it’s a little generic. We’ve simply configured AD FS to authenticate users based on the presence of an X509 certificate.

                    We could always add our VSC users to a security group and reflect this in an authorization claim in AD FS, Even better we could configure authentication mechanism assurance and add an issuance policy to our virtual smart card template and then link that policy to a security group. Microsoft provide a couple of Powershell scripts to allow this, The Object Identifier (OID) of the certificate authenticating at AD FS needs to correspond to the linked claims rule to the OID in our “Virtual Smart Card Authentication” security group. We’ll look at  this in a future post about Bring Your Own Device (BYOD), Workplace Join and Work Folders, new features in Windows 8.1.

                    Step-Up Authentication Scenarios with AD FS 2.0 Part I

                    This post refers to additional logon schemes that can be supported in AD FS by forcing users to re-authenticate or step-up/step-down authentication to federated web applications. It was prompted by a  recent request from a customer :

                    “We wish to connect a SAML 2.0 Service Provider (SP) to AD FS. For security reasons,  we require our internal users to logon (again) when connecting to this web application. All users connecting through the AD FS proxy should be prohibited access.”

                    Whether we choose to call this process re-authentication or step-up authentication really depends on the access case.  To meet the requirement, we’ll be breaking single sign-on (SSO) when accessing the web application above by sending parameterised requests from the web application to AD FS, specifying how to handle authentication uniquely for this app.

                    Some folks may have pre-conceived ideas about what constitutes step-up, perhaps because it is often associated with multi-factor authentication. While the two do complement one another nicely, step-up is not necessarily multi-factor.  Rather, use of step-up as an access mechanism, is governed by the strength of authentication we wish to accrue to access, at a level commensurate with requirements for protecting that resource. We can use weaker (single factor) authentication where this is deemed sufficient or appropriate.  As an example, a customer may employ two-factor authentication on the outside/edge for all users and then elect to use the AD password, as an additional step-up mechanism for corporate users only to gain access to internal resources.  In authentication strength terms, this is step-down authentication, but in functional terms, it’s designed as a step-up method.

                    I make the above point, because in the examples described here, we have users logging onto their workstations either using weak (username/password) or strong (two-factor) authenticating against other federated web applications with these credentials.  In each case, we plan on forcing users to logon again when they access this particular SAML 2.0 web application to “step-up” security.

                    This is an internal only access scenario for the enterprise, meaning that users connecting via the AD FS Proxy should be denied access. Since AD FS Rollup 1, we’ve been able to specify Issuance Authorization Rule on the relying party (SAML 2.0 SP) pipeline that allows requests sourced from the AD FS Proxy to be identified and acted on via the claim description:

                    Accordingly, we’ll create a deny Issuance Authorization Rule on our SAML web application so that users connecting through the proxy will be blocked.

                    exists([Type == “”]) => issue(Type = “”, Value = “true”);

                    Sample Scenario

                    In a default AD FS farm setup, a domain-joined Windows machine internal user connects to the AD FS farm and authenticates via the Integrated Windows Authentication (IWA) handler using Kerberos/NTLM.  To alter this behaviour, for a given application, and force the user to re-authenticate, we must ignore the existing session cookie.

                    With WS-Federation, we can do this at AD FS, via a smart link, by specifying the wauth parameter:


                    For a relying party using the WS-Federation Passive Requester Profile (WS-PRP) we can also specify the request in the query string or within application code also via wauth.

                    This is a SAML 2.0-based use case though. As a backgrounder, I suggest reading about SAML Authentication Context Classes and Strengths with AD FS. Within the SAML 2.0 protocol, SAML service provider (SP) can emits certain values in the SAML request that ensures that the required authentication method from the SP is honoured by AD FS. From an SAML 2.0 protocol standpoint, this may be accomplished by:

                    1. Setting an Authentication Context Class Reference (AuthnContextClassRef) in the requested authentication context from the Service Provider;
                    2. Specifying the use of Force Authentication (ForceAuthn) in the request set to a value of true;
                    3. Use of a Comparison rule that is set to exact to expressly set the authentication method. Other settings are also possible (which AD FS supports) but are not covered in this post.

                    Let’s look at the farm-connected conventions mentioned above in a bit more detail.

                    Authentication Context Class Reference

                    In Windows SSO logon scenarios, the AD FS integrated handler uses the SAML  AuthnContextClassRef of urn:federation:authentication:windows. On our SAML 2.0 web application, we’ll request a authentication context class reference of urn:oasis:names:tc:SAML:2.0:ac:classes:Password, so that the forms handler (in AD FS) is targeted as the desired authentication handler.

                    Force Authentication

                    The specification of ForceAuthn=true in the initial SAML request from the service provider specifies that the Identity Provider (IdP) should force re-authentication of the user, even if they possess a valid session with AD FS.

                    Comparison Rule

                    The SAML 2.0 protocol supports the use of a comparison rule to determine the level of precision to be accorded to the authentication request. If none is specified, AD FS will assume that the attribute is set to exact, meaning that authentication should conform exactly to the AuthnContextClassRef request and is passed to the appropriate handler.

                    Configuring Service Providers

                    I’ve used two examples here:

                    • OpenAM
                    • SimpleSAMLphp

                    I also planned on including Shibboleth, but hosed my configuration in the process, by reverting the wrong Snapshot of my VM during testing.. *cough*… sorry about that Smile 


                    Using OpenAM as a SAML SP example, we’ll invoke SP-initiated sign-on through the spSSOInit.jsp page.  In the query string we’re specifying the authentication context and the desired force authentication.

           &ForceAuthn=true&AuthnContextClassRef=urn:oasis:names:tc:SAML:2.0:ac:classes:Password &idpEntityID=

                    Note: The above syntax is valid but watch out for white spaces in the example above, not to mention your own domain name.  I’ve added spaces to make the text more legible.

                    AD FS will parse the request based on the emboldened items in the query string and ask the user to re-authenticate via forms sign-in.


                    In SimpleSAMLphp, we can set the necessary settings in the configuration file authsources.php, specifying the authentication context and force authentication requirement.

                    ‘ForceAuthn’ => TRUE,
                    ‘AuthnContextClassRef’ => ‘urn:oasis:names:tc:SAML:2.0:ac:classes:Password’,

                    Authentication Options

                    How we choose to implement our step-up/re-authentication component depends on the question of sufficiency and what is an acceptable method to choose.  For this exercise, this could mean:

                    1. re-using the Windows logon identity (re-authenticate);
                    2. using an alternate identity from within the same AD forest (step-up);
                    3. using an alternate identity residing in a connected forest (step-up);
                    4. using an alternate authentication service; a third-party application that provides stronger forms of authentication

                    Option 1 – Re-Authentication

                    The  simplest option  sees the the user replaying their AD credentials, logging on again via the AD FS form, before gaining access to the web application. This is clearly not step-up and doesn’t afford any significant additional protection, , but may fulfil compliance/auditing requirements for access.

                    Advantages Disadvantages
                    Simple (uses same identity) Re-authentication not step-up authentication (same password policy)
                    Protects against inadvertent access to the application if the user is already logged on (e.g. where user fails to lock OS)

                    Security gain is nominal. Requires claims authorization rules on the relying party to differentiate between valid/invalid users.

                    Option 2 – Step-Up Same Forest (username/password)

                    Option 2 uses another set of credentials held within the same AD FS forest. Access to the SaaS application is limited to those users using these credentials (i.e. their “step-up” identity) and an authorization rule to supplement this.



                    Advantages Disadvantages
                    Authentication is stepped using another identity besides the corporate logon More complex. Requires additional identity to represent users (user management)
                    Supports use of stronger password policies on the second identity

                    Security gain is moderate.  Same factor (username / password) for step-up identity

                      Less user friendly (extra identity)
                      Shared authentication sources between identities (no isolation)

                    Option 3 – Step-Up Connected Forest (username/password)

                    A more complex rendition of this using multiple forests with a single AD FS instance (Option 3):image

                    In the above setup we have an account forest for our corporate users and a resource forest, where the AD FS server lives (with the AD FS application pool account running in the account forest). A one way forest trust between the two exists. In this option, the step-up identities reside in the resource forest.

                    Advantages Disadvantages
                    Authentication is stepped using another identity besides the current logon

                    More complex. Requires additional identity / shadow account represented in the  remote forest  (user management)

                    Supports use of stronger password policies on the alternate identity

                    Security gain is moderate. Same factor (username/ password)  for step-up identity

                    Shadow account can use same sAMAccountName in remote forest Less user friendly (extra identity)
                    Greater isolation / independence of action from account forest (supports selective authentication) More complex to manage

                    For Options 2 and 3, we can also provide further refinement by using AD fine-grained password policies to implement a stronger password policy / account lockout policy applicable to our web application, that exceeds the ordinary password policy levels used for for corporate AD users.

                    In all above cases, we should consider further restraining access by passing custom claims on the relying party, to assist in determining whether the user in question should have access.

                    From an AD FS standpoint, there are no configuration changes required in the cases described thus far.  You may note, however, that I’ve not yet mentioned IdP-Initiated Sign-On methods. SHAME! Well, there’s a couple of reasons for this, by which I’ll conveniently recuse myself Smile with tongue out 

                    1. Firstly, there a nice solution posted on CodePlex, that works similar to the actions described in this post, albeit by customizing the AD FS sign-in pages instead. It allows assigning the use of forms logon logic to relying parties and also covers IdP-Initiated Sign-On and WS-Federation.    Relying parties registered to use the forms logon are registered in AD FS web.config file, thereby bound to the forms handler.
                    2. Also, some customers may be unwilling to modify their default AD FS setup because of a fear that it will throw them outside the realms of Microsoft support. However, if you do wish to support IdP-Initiated sign-on scenarios using the methods above (AuthnContextClassRef and ForceAuthn),  then I’m afraid you don’t have much choice as customization of the  code-behind page for  idpinitiatedsignon.aspx.cs is required. Without these changes, sign-on, either via  logintoRP or relaystate  query parameters, will fail as the desired authentication context (AuthnContextClassRef) has not been set and is not passed by the IdP to the service provider. I used the following MSDN article as a reference to customize the  idpinitiatedsignon.aspx.cs and then tested this using logintoRP parameter, with the query string example below.


                    In Part II, we’ll look at step-up options with stronger / multi-factor authentication methods (aka Option 4). See ya!