Category Archives : Windows

Using alterative AD attributes to authenticate to AD FS 3.0


We have a requirement at the moment to modify AD FS 3.0 (which is a role in Windows Server 2012 R2) to allow users to authenticate without having to specify the domain name. 

This is for two reasons – the current external system doesn’t have a requirement to prefix a domain (or to authenticate with UPN format), and the organisation would prefer users to not have to worry about knowing the domain name (which is a DMZ domain).

AD FS 3.0 supports this scenario – sort of – but the landing page which handles authentication has some hard coded forms validation logic which won’t let users authenticate with a username which doesn’t have the DOMAIN\\ prefix or that is not in UPN format.  Awkward.

The Problem

AD FS 3.0 is the first release which doesn’t run under IIS.  As a result, this self hosted solution doesn’t have web content directly available for customization.  However, using PowerShell commands, it is possible to customize the user interface, although only client-side elements, like scripts (.js).

Since our issue is with client side validation, we have a way forward.  This article will demonstrate how to remove the domain prefix (or UPN format) requirement without having to modify ADFS binaries directly (which as a general rule you should never do).

Assigning an Alternate AD attribute to use for identifying a user’s credential (i.e. ‘username’) is simplicity itself.  In a PowerSHell console (elevated permissions) execute the following where [AD ATTRIBUTE] is the schema field you want to use to identify users.

Set-AdfsClaimsProviderTrust -TargetIdentifier “AD AUTHORITY” –AlternateLoginID [AD ATTRIBUTE] –LookupForest <your forest>

You can pretty much use any AD schema which makes sense, e.g. CN which is what I’m using in this scenario.


You don’t get this view by default, if you want to view AD schema attributes, you need to switch the AD management console to Advanced View:


Fixing the client-side validation

This part is trickier.  You’re going to have to modify the out-of-the-box AD FS behaviour in order to modify the way ADFS validates the username field. 

You’re going to need to create a new AD FS theme (based on the default) and then dump the default web theme to the file system using PowerShell commands:

New-AdfsWebTheme -name Custom -SourceName default
Export-AdfsWebTheme -Name Custom -DirectoryPath c:\AdfsTheme

You’ll need to configure this on each ADFS host if you have multiple. For more information on customizing AD FS 3.0 have a look at this TechNet article.

Once you’ve completed this step, have a look at the contents of the folder you specified to the –DirectoryPath parameter (e.g. c:\AdfsTheme).  There should be a subfolder called script, and it will contain a file called onload.js. 

We’re going to edit that file.

The Concept

The out-of-the-box implementation adds some client side JavaScript which checks the username field when the user clicks the submit button, or on a keypress (e..g Enter key).  We need to hijack that script and replace it with a cut down implementation, removing the domain format checking.

We unfortunately can’t do this with a script injected only on logon pages (using the SignInPageDescriptionText location)!  That approach injects custom script above the out-of-the-box script, which means we can’t modify form validation behaviour.  We have to instead change the onload.js which is run on every ADFS web page (the downside).

Here’s the out-of-the-box validation script, which you can see by viewing the page source of the ADFS logon page.  Note that the Sign In page description text field is located above this (id=”introduction””.


What we will do is add an implementation to the onload.js file which replaces the OOB implementation – we do this by appending the following to the end of the onload.js file’s content:

// rewire form validation
function override_form_validation() {
    Login.submitLoginRequest = function () {
                var u = new InputUtil();
                var e = new LoginErrors();

                var userName = document.getElementById(Login.userNameInput);
                var password = document.getElementById(Login.passwordInput);

                if (!userName.value) {
                    u.setError(userName, “Username must be supplied”);
                    return false;

                if (!password.value) {
                    u.setError(password, e.passwordEmpty);
                    return false;

                return false;

if(location.href.indexOf(‘SignOn’) > 0){

The last part executes the overridden form validation only if the page’s URL contains the text “SignOn”.

Publishing the Changes

Once we’re done modifying the JavaScript, we use a PowerShell console to publish the updated file back to AD FS.  Note that you need to do this on each AD FS server if you have multiple.

Set-AdfsWebTheme -TargetName Custom –AdditionalFileResource @{Uri=”/adfs/portal/script/onload.js”; Path=”c:\AdfsTheme\script\onload.js”}


This script will run on each ADFS page.

Adding additional script files and referencing them

If you would like to add separate script files to the custom theme, you can do this too.  Simply use PowerShell and the following command:

Set-AdfsWebTheme -TargetName Custom -AdditionalFileResource @{Uri=’/adfs/portal/script/yourfile.js’;path=”c:\AdfsTheme\script\yourfile.js“}

To reference the script, use another PowerShell command to inject a reference to load the script where appropriate:

Set-AdfsGlobalWebContent –SignInPageDescriptionText “<script type=””text/javascript”” src=””/adfs/portal/script/yourfile.js“”></script>”

There’s also –SignOutPageDescriptionText as an option as well.  Check out the command help documentation for more places to inject your own custom scripts.

Windows 10 Technical Preview


Well, it’s been a week of big announcements.  Hot on the heels of finding out the next version of Windows will be Windows 10, Microsoft has today released a new “Technical Preview” of Windows 10, Windows Server and System Center.

Be a part of every step

Join the Windows Insider Program so you can be part of every key moment along the way as we create Windows 10. You’ll get Windows 10 Technical Preview, all the builds as soon as they’re available, and an easy-to-use feedback app.

Naturally, I immediately pulled down an .iso of the Windows Desktop edition (UK English) and have begun running it up in a VM.

There’s a site dedicated to Windows 10 and it’s called the “Windows Insider Program”.  Here’s an extract from the site:

Help us shape the future of Windows

With the Windows Insider Program, you’ll get all the latest Windows preview builds as soon as they’re available. This means you’ll be one of the first to experience the new ideas and concepts we’re building.

In return, we want to know what you think. You’ll get an easy-to-use app to give us your feedback, which will help guide us along the way.

This program is designed exclusively for people who want be involved in the process. So if you want to help us build the best Windows yet, we want you to join us.

My Installation Experience

I’m running this preview version up on my VM server, and for this new VM I’ve configured it with 2 vCPUs (utilizing a hex-core Intel i7 processor), 8096mb of 1600GHz RAM and an initial HDD of 80GB.

Well, I’ve begun the installation process, and so far there’s no noticeable differences.


The installer is the same trusty version we encountered in previous versions, as is the initial boot and configuration process.


After a reboot, we’re loaded into the new Windows..  The experience is the same as with Windows 8.1 and I use custom settings, disabling most options.


Again, you’re forced to use a Microsoft Account and cannot use a local Windows user account.


Once you’re past the bulk of the initial configuration, Windows goes off to configure apps

Initial Experience

Given the configuration, Windows 10 has detected I’m in a Desktop environment, so the first thing loaded is the trusty desktop.  Interestingly, Windows displays a roaming profile wallpaper for my desktop background – maybe it did that in Windows 8.1 but I didn’t notice.


The first thing to do, obviously, is check out the old/new Start Menu:

After a few clicks, I’m prompted for feedback


Searching for installed applications and apps is fast and accurate (predictive matching etc.):


Back to the new Start Menu, I can scroll Windows apps and also install apps which are presumably linked to my Microsoft account (from prior usage in Windows 8.1?):

image image

While we’re speaking of apps, do try out my Aussie Wine Guy and Sanders Technology apps!  Running up a formerly-called-metro app gives us the app hosted in a resizable dialog shell (as advertised):


Double clicking on the “Welcome to Tech Preview” link launches Internet Explorer 11 and navigates to the following location.

image image 

The keyboard combination of Windows key + C still brings up the dreaded charm bar, however right clicking on the Windows icon (start menu) still provides a handy shortcut context menu as an alternative:


Navigating to Settings->PC Info provides us with the following “compliance plate” information:

image image


As it is just past 8:00am local time, I have to go and get ready top shuttle off to work, so I’ll have to leave my Tech Preview experience for a later time.  So far, the preview has delivered on the rumours which have surfaced over the past 12 months.

I’d encourage you to download and participate in the Technical Preview program.  Microsoft has claimed that the removal of the start menu was in reaction to statistics they captured during similar programs in the past, so they obviously take this information very seriously.  If you want a say in the future of the Windows operating system, now’s your chance!

Tomorrow, I’ll take a look at the Windows Server Technical Preview – hopefully they’ve canned the formerly-known-as-Metro screen, which never made sense to me for a server platform.  Enjoy.

Returning to ADFS

It’s been over two years since my last foray into the murky waters of Active Directory Federation Services (ADFS) 2.0 and it came past due for a return to claims-based authentication and federation.

My previous journeys were somewhat chronicled here and here.  This time around though, I’m going to be focusing on the latest and greatest – meaning Windows Server 2012 R2 (with update), which has been a far more pleasant journey thus far.

I literally started from scratch, because I rather like the environment to be clean before establishing a baseline configuration.  From my earlier article:

so if you’re going to do this properly, get your certificates sorted out up front.  My approach is to install and configure an Enterprise Certificate Authority and issue certificates from there.  Then, it’s just a matter of trusting the root CA (signing) certificate in your environment, and your cert chain should be valid

I’m excited to say I took my own advise and started with the basics first.  As you may recall from my earlier writing, my preferred scenario architecture is the segregation of external and internal entities by way of separate Active Directory forests.

As last time, I’m working predominantly with an initial set of four separate virtual servers, configured as follows:


Using an Enterprise CA, I trust the root CAs and then issue certificates as needed, and manage the DNS within each Active Directory forest.  This time around I fully configured the CAs in both domains for web enrolment and device enrolment as well as updating group policy to include the Enrolment Policy locations.



I also added the Root CAs of each domain to the Trusted Root Certificate store in the opposite domain’s DC (where AD FS is located) so that the federation Uris would be valid when the trusts were established.

Believe it or not, this doesn’t take very long to set up.  Configuring each domain at the same time (in parallel), I had most of the configuration working and tested in about an hour or so.  Having done it many times before, I knew the correct order to install and configure which makes a huge difference.

Installing IIS on the CA server also means you can avoid having to install IIS on the domain controller server, which is a nice win in terms of resource minimisation. 

Since we’re dealing with a few certificates here and there, it’s important to remember that clients/machines that do not trust the root CA signing certificate will experience warnings or other inconveniences – in other words, don’t do this in a Production environment unless it’s only used solely in-house, where you can deploy the CA signing certificate into the trusted root CA stores. 

External AD FS installations should always be signed using a certificate from an external (public) CA like which offers free class-1 certificates.

Certificate Path

My Desired Outcome

What I want to be in a position to do is to offer users a choice of realms:


For the sake of keeping things clear, I’ve labelled the relying parties to indicate which domain they live in, but you probably would label the DMZ as ‘External Users’.

What should happen, once a user has authenticated, is that their subsequent requests to claims-aware applications shouldn’t require any further authentication, and their identity should be available across both environments.

Generating Valid Certificates – The Low Effort Way

Another tip – the AD FS installation expects a certificate (plus private key) with the common name of the ADFS service you’re going to configure to be in the .pfx format.

if you want a fast way of generating a web server certificate and you have an Enterprise CA installed and configured within the domain, you can switch to IIS Manager and request a Domain Certificate when viewing the server features (under Server Certificates):


Here you can add the common name and friendly names


When you’ve entered the information, the wizard will go off and request a Web Server certificate based on the common name, and then will automatically store it in the Computer Account’s Certificate store.  You can fire up MMC and add the Certificates snap in (FIle –> Add/Remove Snap In) making sure you select ‘Computer account’ along the way:


Once the certificate is located, you can simply export it including the private key.  Just move the exported .pfx file to the ADFS host, and you’re ready to install with a valid certificate.

A word about ADFS installation

I’m not going to go into detail about how to set up AD FS 3.0 itself, the existing documentation on the Internet is quite accurate, and honestly, if you’ve established the environment correctly, it’s really not tricky to do.  In Windows Server 2012 R2, ADFS 3.0 is a bona fide server role (in 2008/R2 the server role was ADFS 1.0/1.1, 2.0 was a separate download & install).

Sanity Checking the ADFS configuration

As mentioned in an earlier post, a quick browse to the following location: https://<your adfs location>/federationmetadata/2007-06/federationmetadata.xml should yield a metadata response:



This was just a brief intro to the environment I’ve configured, I’ll be going into more detail about how to live in a claims-aware environment in subsequent articles.