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!
Category Archives: Relying Party
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 mydomain.com
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 
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 https://login.microsoftonline.com/extSTS.srf
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
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.
Message-Level
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 
Page-level
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.
Summary
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!
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 training@azuresprout.net, 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.
Release Notes for AD FS 2.0 RU3 updated
Working with a customer recently, we ran into problems with RU3 and the sharing of SAML signing certificates between RPs in their test environment. After applying RU3, as mentioned in the previous post, additional manual actions are required. However, it turns out, following a nice long troubleshooting call with those lovely folks at support, that there are is more to this tale:
1. The PostReleaseSchemaChanges.ps1 script applies only to AD FS Windows Internal Database (WID) configurations. The script is provided with the RU3 update under the SQL sub-folder.
2. AD FS SQL database configurations need to run a script locally on a SQL Server node. This file is known as RelaxedRequestSigningCertsv2.sql and is available via a newly updated article on the support site (KB 2790338) or directly via the following link:
http://gallery.technet.microsoft.com/scriptcenter/SQL-script-to-relax-unique-5ce353d1
The updated release notes for RU3 can be found here:
http://support.microsoft.com/kb/2790338
Please read, share and alert your fellow AD FS brethren 
The Access Onion 