In this series of five blog posts I want to show you how you can create your own Authentication Provider in AD FS on Windows Server 2012 R2. This Authentication Provider can then be used in AD FS for multi-factor authentication (MFA). The solution will use the users mobile device as a second factor for authentication, by sending a One-Time Password (OTP) or PIN to the device.

For those of you interested only in the AD FS related components, part 2 will be most interesting. That's where we will be creating the Authentication Provider itself. But if you are looking for a complete, working, solution, you might want to go over the entire set. So you might be interested by now what's in the other parts... or at least I hope you are. So here's a quick agenda;

1. Introduction
2. Creating the Authentication Provider
3. Setting up Azure Mobile Services
4. Creating a Windows Phone Authenticator App
5. Putting it all together

Now, before we get started I have to remind you that this blog post series is only to show you how you can create this Authentication Provider. By no means is the solution we are creating an enterprise ready MFA solution. If you are looking into such an enterprise ready solution, I would recommend you take a look at the Windows Azure Multi-Factor Authentication.

Now... Let's get going with Part 2: Creating the Authentication Provider.

Part 2 - Creating the Authentication Provider

AD FS in Windows Server 2012 R2 allows a developer to create a custom Authentication Provider by implementing at least two interfaces to the Microsoft.IdentityServer.Web.Authentication.External class.This class is defined in the Microsoft.IdentityServer.Web.dll file that is present in all Windows Server 2012 R2 AD FS servers. AD FS is installed in the Windows directory, under ADFS. So by default, this file would reside in C:\Windows\ADFS.

Prerequisites

• .NET Framework 4.5 (http://www.microsoft.com/en-us/download/details.aspx?id=30653) This is installed by default on Windows 8.1
• Visual Studio 2013 (http://www.microsoft.com/en-us/download/details.aspx?id=40787)
• Windows Server 2012 R2 with the Active Directory Federation Services role installed and configured.

We will assume you use Windows 8.1 and Visual Studio 2013, and have a Relying Party configured in AD FS that can be used to test the custom attribute store. In this example a custom attribute store will be created using Visual C#.

Copy down the file Microsoft.IdentityServer.Web.dll from the AD FS Server to your PC. The default location of this DLL in Windows Server 2012 R2 is C:\Windows\ADFS.

Building the Authentication Provider

Start Visual Studio, and create a new Project by clicking File, New and then Project, or by hitting Ctrl+Shift+N.

Create a Project of type Class Library (located in the branch Installed, Templates, Visual C#, Windows) and make sure the target framework is .NET Framework 4.5 (for AD FS 3.0). Give the Project a proper name, in my example MyAuthenticationProvider and click OK.

In Visual Studio, the Project should now have been created and a new Class file (called Class1.cs) should be opened. On the right side of the page, locate the References branch under your Project and your Solution in the Solution Explorer and right-click it. Click on Add Reference… to add a reference to the Microsoft.IdentityServer.Web.dll file you copied from the AD FS Server.

Select Browse on the left side, and click the Browse… button.

Now, locate the Microsoft.IdentityServer.Web.dll you copied down from the AD FS Server, and click it.

Click Add to select the DLL to be referenced in your project.

Make sure the checkbox in front of the filename has been checked, and click OK.

A new reference to the Microsoft.IdentityServer.Web.dll should now have been created in your Solution. The reference shows up as Microsoft.IdentityServer.Web.

Since this file is already on the AD FS server, and we will place our Authentication Provider in the Global Assembly Cache of the server, there is no need for Visual Studio to copy the file to the output directory of the project when we compile it. In the Solution Explorer, click the Microsoft.IdentityServer.Web reference, and, at the bottom of the screen, in the Properties window, select False from the pull-down menu next to Copy Local.

Now that the proper reference is in place, we can start building our authentication provider in code. First, let's delete the Class1.cs file that Visual Studio created for us, by selecting it in the Solution Explorer on the right and pressing DEL. (Or right-click it and select Delete.)

Click OK to delete the Class1.cs file.

Now, in Solution Explorer, right-click your projects name (which should be MyAuthenticationProvider if you followed this guide), select Add and click Class. (Or simply press Shift-Alt-C.)

In the Add New Item dialog box, next to Name:, type AuthenticationAdapter and click Add.

Your newly created AuthenticationAdapter class file called AuthenticationAdapter.cs will now open in Visual Studio. This is the place where we will implement the Authentication Adapter.

Underneath the existing using statements, type a new using statement;

using Microsoft.IdentityServer.Web.Authentication.External;

Directly after the declaration of the AuthenticationAdapter class, which should show like this;

public class AuthenticationAdapter

on the same line, at the end, add:

 : IAuthenticationAdapter

This way, we inform Visual Studio that this Class, called AuthenticationAdapter, will implement the Interface IAuthenticationAdapter (which comes from the Microsoft.IdentityServer.Web.Authentication.External namespace). The line should look like this:

public class AuthenticationAdapter : IAuthenticationAdapter

Your AuthenticationAdapter.cs code page should now look like this:

Now, right-click on IAuthenticationAdapter that you typed in the last step right after class AuthenticationAdapter, and select Implement Interface and Implement Interface.

Now, Visual Studio will create all the methods you need to properly implement the Authentication Adapter. Your code should resemble this;

So let's first briefly go over all the methods that we now need to implement in our Authentication Provider.

The IAuthenticationProvider Methods and Properties

In order for the Authentication Provider to work properly, we need to implement seven different methods in our Authentication Adapter. We will briefly discuss these different methods, and what actions AD FS expects these methods to perform.

public IAdapterPresentation BeginAuthentication(System.Security.Claims.Claim identityClaim, System.Net.HttpListenerRequest request, IAuthenticationContext context)

This method is called by AD FS once AD FS decides that Multi-Factor Authentication is required (and available) for a user. It will pass the Identity Claim to the Authentication Adapter. The Authentication Adapter decides on what this identity claim should be. (We will show how this works later on.) Think of a UPN or SAM Account Name. AD FS also passes the context of the authentication request. This context store data required by AD FS and the Authentication Adapter to perform and complete the authentication.

The method has to return a variable that implements the IAdapterPresentation interface. Hey... That's new. We currently have no class in our Visual Studio project that implements this interface. So it appears we need to implement this interface as well! We'll do that in one of the next sections of this blog post. Anyway, this return-type contains information that AD FS uses to build the proper web page to authenticate the user (during a browser based logon). Let's say you want the ask the user for a PIN, then we have to create a few lines of HTML code that show this input box, together with an appropriate text, to the end-user. That's just what this return value does.

public bool IsAvailableForUser(System.Security.Claims.Claim identityClaim, IAuthenticationContext context)

The IsAvailableForUser method returns either true or false and is an indication to AD FS that your Authentication Adapter can actually perform Multi-Factor Authentication for the user. In order to decide whether to return true or false, an identity claim is passed from AD FS to the Authentication Provider. Check the IAdapterPresentation method we will cover in a few moments for the usage of the identity claim (identityClaim) and authentication context (context).

The method should return true if this Authentication Provider can handle authentication for this identity, or user, and false when it can not.

public IAuthenticationAdapterMetadata Metadata

Metadata actually is not a method but a property. It is used by AD FS to learn about your Authentication Provider (just like the FederationMetadata.xml can be used by AD FS to learn about a relying party or claims provider). The property should 'return' a variable of a type that implements IAuthenticationAdapterMetadata. Again, this is an interface we have not yet implemented in our Authentication Provider and has to be implemented. We'll do this later on. For now, just think of the IAuthenticationMetadata as information about the Authentication Provider. One example would be that you can 'tell' AD FS what the Identity Claim is your authentication adapter expects when the methods like BeginAuthentication and IsAvailableForUser (both of which we have seen before) that are called by AD FS.

public void OnAuthenticationPipelineLoad(IAuthenticationMethodConfigData configData)

The OnAuthenticationPipelineLoad method is called whenever the Authentication Provider is loaded by AD FS into it's pipeline. It allows your adapter to initialize itself. AD FS will 'tell' your adapter which information AD FS has. The IAuthenticationMethodConfigData contains a single property called Data. For the developers; this property is of type Stream. In our sample Authentication Provider will not use this configData.

The method returns nothing.

public void OnAuthenticationPipelineUnload()

The OnAuthenticationPipelineUnload is called by AD FS whenever the Authentication Provider is unloaded from the AD FS pipeline and allows the Authentication Adapter to clean up anything it has to clean up.

The method returns nothing.

public IAdapterPresentation OnError(System.Net.HttpListenerRequest request, ExternalAuthenticationException ex)

The OnError method is called whenever something goes wrong in the authentication process. To be more precise; if anything goes wrong in the BeginAuthentication or TryEndAuthentication methods of the authentication adapter, and either of these methods throw an ExternalAuthenticationException, the OnError method is called. This allows your adapter to capture the error and present a nice error message to the customer.

Because we have to present a nice error message to the user, this method returns an instance of a class that implements IAdapterPresentation. We've touched that interface before. We will implement and explain it later in this article.

public IAdapterPresentation TryEndAuthentication(IAuthenticationContext context, IProofData proofData, System.Net.HttpListenerRequest request, out System.Security.Claims.Claim[] claims)

This method is called by AD FS when the Authentication Adapter should perform the actual authentication. It will pass the IAuthenticationContext to the method, which we have seen before. It will also pass the proofData variable, that implements IProofData. This is a dictionary of strings to objects, that represents whatever you have asked the customer for during the BeginAuthentication method. In our sample Authentication Provider, the PIN that the user typed is passed to the TryEndAuthentication method in the proofData variable.

The method allows you to use the "claims" out parameter. If the Authentication Adapter has successfully performed the authentication, this variable should contain at least one claim with type http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod. The value of this claim should contain the method of authentication used. It must be one of the values listed in the AuthenticationMethods parameter of the class that implements IAuthenticationAdapterMetadata. We have already seen this IAuthenticationAdapterMetada interface before, and already know we need to implement this one. So we'll get more details once we go over this interface.

The method returns a variable of a type that implements IAdapterPresentation. Typically, when authentication has succeeded you add the proper authentication method claim to the claims out parameter, and return null. Whenever authentication has failed, you can create a nice error message for the user and return this in the return variable. We've already see the IAdapterPresentation interface before, so we'll cover this interface in more detail later on.

More Interfaces

In the previous section we have seen that we need to implement at least two more interfaces, next to our IAuthenticationAdapter;

• IAdapterPresentation
• IAuthenticationAdapterMetadata

There is one additional complexity here; if we want to use Forms-Based Authentication (and our authentication adapter actually wants to use that), we also have to implement an interface that we haven't seen before. This is the IAdapterPresentationForm. So this one needs to be added to the list as well. We will implement the IAdapterPresentationForm in the same class that implements the IAdapterPresentation.

Now, using the exact same procedure as we used to create the interface implementation for the IAuthenticationAdapter interface, we will have to create two new classes in our project. By now, I'm sure you know how to create a class file. (Press Shift-Alt-C, type a name and click Add.) Using this method, create two new classes;

• AdapterPresentation
• AuthenticationAdapterMetadata

In both of these class files, add the using statement we've seen before;

using Microsoft.IdentityServer.Web.Authentication.External;

Have these classes implement the corresponding interfaces; so make sure the AdapterPresentation class implements IAdapterPresentationandIAdapterPresentationForm, and that the AuthenticationAdapterMetadata implements IAuthenticationAdapterMetadata.

The AdapterPresentation.cs file should cointain this line:

class AdapterPresentation : IAdapterPresentation, IAdapterPresentationForm

The AuthenticationAdapterMetadata.cs file should contain this line:

class AuthenticationAdapterMetadata : IAuthenticationAdapterMetadata

In both class files, right-click the interface names (IAdapterPresentation, IAdapterPresentationForm and IAuthenticationAdapterMetadata) and click Implement Interface. In the submenu, click Implement Interface again.

The class files will now contain the proper methods and properties that need to be implemented as well. We'll go over these briefly... We need to know what these do in order to successfully implement the AuthenticationAdapter Interface!

The IAuthenticationAdapterMetadata Methods and Properties

The IAuthenticationAdapterMetadata interface contains no methods, only properties. These properties are used to 'learn' AD FS about your Authentication Provider.

string AdminName { get; }

This is the friendly name of the Authentication Provider, shown to AD FS admins in the AD FS GUI.

string[] AuthenticationMethods { get; }

This should return a list (array) of strings, where each string is a supported authentication method. If, after successful authentication, the TryEndAuthentication method in the IAuthenticationAdapter interface return success, this methods must contain a claim of type http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod. The value of this claim should be one of authentication methods listed in the property. In our sample Authentication Adapter we support only one authentication method; http://schemas.microsoft.com/ws/2012/12/authmethod/otp.

int[] AvailableLcids { get; }

This property should contain all the lcid's (or languages) that your Authentication Adapter supports. We'll only implement lcid 1033 on our sample Authentication Adapter.

Dictionary<int, string> Descriptions { get; }

This property should contain a list of descriptions for the Authentication Adapter, per language. I haven't seen this being used anywhere in AD FS...

Dictionary<int, string> FriendlyNames { get; }

If multiple Authentication Adapters (MFA providers) are available for a user, a form us presented to the user where he or she can chose how to perform additional authentication. The strings in this property (per language) that are used to identify your Authentication Adapter in that form.

string[] IdentityClaims { get; }

This property should contain the claim types that your Authentication Adapter requires. These claims, and values, are passed to multiple methods in the IAuthenticationAdapter. My testing revealed that only the FIRST one you enter here is presented to the adapter; so we will use UPN here.

bool RequiresIdentity { get; }

This is an indication whether or not the Authentication Adapter requires an Identity Claim or not. If you require an Identity Claim, the claim type must be presented through the IdentityClaims property.

The IAdapterPresentation Methods and Properties

The IAdapterPresentation interface defines how the Authentication Adapter 'presents' itself to the user.

string GetPageTitle(int lcid);

The GetPageTitle method is used by AD FS to query to Authentication Adapter for the title of the authentication page. It passes an integer called lcid that represents the browser language setting of the user. For example, value '1033' is for English - United States. To learn more about these lcid values, or Locale ID's, please check out this page; http://msdn.microsoft.com/en-us/goglobal/bb964664.aspx By passing this lcid value, AD FS allows you to create a user interface in multiple languages. (Our example will only support 1033; English - United States.) This GetPageTitle string will actually go into the <title> element of the logon page.

The method returns a string; the title of the page.

The IAdapterPresentationForm Methods and Properties

The IAdapterPresentationForm is very much like the IAdapterPresentation, but this interface let's you define what and how you want to ask the user for additional authentication. In our example, we want the user to input a PIN in the sign-in page.

string GetFormHtml(int lcid);

The GetFormHtml is used to represent the HTML code that is inserted in the AD FS sing-in page. The lcid code passed allows you to localize the page.

The method should return the string, plain old HTML, that represents the code for whatever you want to do in the sing-in page. One important thing to note here though; It could very well be the case that a user that is authentication, is first hitting one server in the farm, enters the PIN and submits the PIN. This postback to the server could hit another server in the farm. Now the context of the logon would be lost. AD FS cannot rely on session state or anything like that. We need to 'manually' transfer the context of the logon together with the proof data that the customer provided. So if we need to use a form, make sure to include a hidden input element, that contains the context of the request. This is best done through a constructor that can be called from the BeginAuthentication and TryEndAuthentication methods in the AuthenticationAdapter implementation.

string GetFormPreRenderHtml(int lcid);

This method is used to allow the Authentication Adapter to insert any special tags etc. in the <head> element of the AD FS sign-in page. Again, with the same lcid value to localize your pages.

The method should return the HTML code you want to insert in the HTML <head> element of AD FS the sign-in page.

Implementing the required Methods

Now we have seen all the methods that we need to implement. Although this might seem a little intimidating at first, actually, you don't need to do a lot of work.

So let's start by implementing our AdapterPresentation class. (Only three simple methods to implement!) Now that we've seen what these methods do, combined with the fact that we're only implementing the Authentication Adapter in English, we need to replace the throw new NotImplementedException(); lines with proper code. Also, we want to create some constructors to be able to create new instances of the AdapterPresentation class that are useful for our specific use. We will introduce two private properties as you will see.

Here is the code I created to implement the AdapterPresentation class. You can replace the existing methods in your code with the ones here;

class AdapterPresentation : IAdapterPresentation, IAdapterPresentationForm
    {privatestring message;privatebool isPermanentFailure;publicstring GetPageTitle(int lcid)
        {return"My Authentication Provider";
        }publicstring GetFormHtml(int lcid)
        {string result = "";if (!String.IsNullOrEmpty(this.message))
            {
                result += "<p>" + message + "</p>";
            }if (!this.isPermanentFailure)
            {
                result += "<form method=\"post\" id=\"loginForm\" autocomplete=\"off\">";
                result += "PIN: <input id=\"pin\" name=\"pin\" type=\"password\" />";
                result += "<input id=\"context\" type=\"hidden\" name=\"Context\" value=\"%Context%\"/>";
                result += "<input id=\"continueButton\" type=\"submit\" name=\"Continue\" value=\"Continue\" />";
                result += "</form>";
            }return result;
        }publicstring GetFormPreRenderHtml(int lcid)
        {returnstring.Empty;
        }public AdapterPresentation()
        {this.message = string.Empty;this.isPermanentFailure = false;
        }public AdapterPresentation(string message, bool isPermanentFailure)
        {this.message = message;this.isPermanentFailure = isPermanentFailure;
        }
    }

Here is the code I created to implement the AuthenticationAdapterMetadata class. You can replace the existing methods in your code with the ones here;

class AuthenticationAdapterMetadata : IAuthenticationAdapterMetadata
    {publicstring AdminName
        {get { return"My Authentication Provider"; }
        }publicstring[] AuthenticationMethods
        {get { returnnewstring[] { "http://schemas.microsoft.com/ws/2012/12/authmethod/otp" }; }
        }publicint[] AvailableLcids
        {get { returnnewint[] { 1033 }; }
        }public Dictionary<int, string> Descriptions
        {get
            {
                Dictionary<int, string> result = new Dictionary<int, string>();
                result.Add(1033, "My Authentication Provider");return result;
            }
        }public Dictionary<int, string> FriendlyNames
        {get
            {
                Dictionary<int, string> result = new Dictionary<int, string>();
                result.Add(1033, "My Authentication Provider");return result;
            }
        }publicstring[] IdentityClaims
        {get { returnnewstring[] { "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" }; }
        }publicbool RequiresIdentity
        {get { returntrue; }
        }public AuthenticationAdapterMetadata()
        {

        }
    }

Here is the code I created to implement the AuthenticationAdapter class. You can replace the existing methods in your code with the ones here;

class AuthenticationAdapter : IAuthenticationAdapter
    {public IAdapterPresentation BeginAuthentication(System.Security.Claims.Claim identityClaim, System.Net.HttpListenerRequest request, IAuthenticationContext context)
        {returnnew AdapterPresentation();
        }publicbool IsAvailableForUser(System.Security.Claims.Claim identityClaim, IAuthenticationContext context)
        {returntrue;
        }public IAuthenticationAdapterMetadata Metadata
        {get { returnnew AuthenticationAdapterMetadata(); }
        }publicvoid OnAuthenticationPipelineLoad(IAuthenticationMethodConfigData configData)
        {
        }publicvoid OnAuthenticationPipelineUnload()
        {
        }public IAdapterPresentation OnError(System.Net.HttpListenerRequest request, ExternalAuthenticationException ex)
        {returnnew AdapterPresentation(ex.Message, true);
        }public IAdapterPresentation TryEndAuthentication(IAuthenticationContext context, IProofData proofData, System.Net.HttpListenerRequest request, out System.Security.Claims.Claim[] claims)
        {
            claims = null;
            IAdapterPresentation result = null;string pin = proofData.Properties["pin"].ToString();if (pin == "12345")
            {
                System.Security.Claims.Claim claim = new System.Security.Claims.Claim("http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", "http://schemas.microsoft.com/ws/2012/12/authmethod/otp");
                claims = new System.Security.Claims.Claim[] { claim };
            }else
            {
                result = new AdapterPresentation("Authentication failed.", false);
            }return result;
        }
    }

Now that we have implemented all required methods, we can actually compile the project and start using it on our AD FS server(s).

Compiling the Authentication Provider

Now that we have implemented all the classes and methods required by AD FS, we can build our Authentication Provider. But before we do so, there is one more thing I need to point out. The output of this project, a DLL, will have to be installed into the Global Assembly Cache, or GAC, of the AD FS server. Now, how we do this is something that I will come back to, but in order to place a DLL in the GAC, the DLL needs to be signed. So this is something that we need to do in Visual Studio first.

Right-click the name of our project in the Solution Explorer on the right of the screen. From the menu, click Properties.

From the Properties page, click Signing, on the left, and then check the checkbox marked Sign the assembly. Then, from the Choose a strong name key file: pull down menu, select <New...>.

In the Create Strong Name Key dialog, type a name for the key file and a password that you can remember.

Then, click OK.

The newly created key file should now be present in your solution.

Now we are ready to build our project Authentication Provider!

Click Build and then Build Solution (or simply hit F6) to build the solution:

Check the Output window, at the bottom of the screen, to see if any errors occurred:

Our Authentication Provider is now ready for use and is in the \bin\Debug\ folder of our project folder. In my case, that's D:\Visual Studio Projects\MyAuthenticationProvider\MyAuthenticationProvider\bin\Debug\MyAuthenticationProvider.dll

First, since we need to register the DLL in AD FS by using the Register-AdfsAuthenticationProvider PowerShell command on the AD FS server, we need to get the Public Key Token. This public key token is 'created' when we created the key and signed the DLL using that key. To learn what the Public Key Token for the DLL is, you can use the SN.exe (More information: http://msdn.microsoft.com/en-us/library/k5b5tt23(v=vs.110).aspx) Start the Visual Studio x64 Win64 Command Prompt, and run the SN command with the -T parameter and the location of the file;

SN -T "D:\Visual Studio Projects\MyAuthenticationProvider\MyAuthenticationProvider\bin\Debug\MyAuthenticationProvider.dll"

For me, the Public Key Token is: 91f62883da29f7cd

This file must now be copied over to all the AD FS servers in the farm. I'll create a new directory, called MyAuthenticationProvider in C:\ and put the file there. So my DLL is at C:\MyAuthenticationProvider\MyAuthenticationProvider.dll

After you have copied the file, you need to add it to the Global Assembly Cache of the AD FS server. Our best practice would be that you create a proper installer for your project, and use the installer to add the file to the GAC. Another solution is to use Gacutil.exe. (More information on Gacutil.exe: http://msdn.microsoft.com/en-us/library/ex0ss12c(v=vs.110).aspx) This tool should be on your on development machine, but won't be present on the AD FS server. It's part of the Windows SDK and we don't want to install the Windows SDK on our AD FS server(s), so we're using method 3; PowerShell.

Here is the PowerShell to add our DLL to the GAC of the server. (This is run on the AD FS server, where the DLL now resides.)

Set-location "C:\MyAuthenticationProvider"
[System.Reflection.Assembly]::Load("System.EnterpriseServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a")
$publish = New-Object System.EnterpriseServices.Internal.Publish
$publish.GacInstall("C:\MyAuthenticationProvider\MyAuthenticationProvider.dll")

Now that the DLL is in the GAC of the server, we can, finally, register the Authentication Provider in our AD FS server, again, by using PowerShell. Please note; we have to copy the file to each server, and add it to the GAC on each server, but we have to register it only once!

$typeName = "MyAuthenticationProvider.AuthenticationAdapter, MyAuthenticationProvider, Version=1.0.0.0, Culture=neutral, PublicKeyToken=91f62883da29f7cd"
Register-AdfsAuthenticationProvider -TypeName $typeName -Name "MyAuthenticationProvider" -Verbose

The $typeName here contains a special string. The first part, MyAuthenticationProvider.AuthenticationAdapter, is the namespace and the class name in our project;

namespace MyAuthenticationProvider
{
    class AuthenticationAdapter : IAuthenticationAdapter
    {
 ....

Then, after a comma, the name of the DLL itself (without .DLL), then the version of the file (which we can set in Visual Studio and see by checking the properties of the DLL in Explorer, the 'Culture' of the DLL (neutral) and the public key token we checked previously.

After running the Register-AdfsAuthenticationProvider PowerShell command, we should see a notification like this;

WARNING: PS0114: The authentication provider was successfully registered with the policy store.  To enable this provider, you must restart the AD FS Windows Service on each server in the farm.

So, let's restart the AD FS service and we can start using the Authentication Provider! (And no, I'm not going to add screenshots or a howto on how to restart the AD FS service.)

After restarting the AD FS service, check the Eventlog (which is in the Event Viewer under Applications and Services Logs, AD FS, Admin.
Check if the service has successfully started (Event ID 100) and if the Authentication Provider is properly loaded (Event ID 106).

Now that we have confirmed that the Authentication Provider has been loaded, start the AD FS Management Console.

From the console, right-click Authentication Policies and select Edit Global Multi-Factor Authentication and select our Authentication Provider (My Authentication Provider) from the list under Select additional authentication methods.

Make sure you did not modify any other checkboxes; this will impact authentication for your existing relying parties!
Press OK to apply this setting.

Then, under Authentication Policies open Per Relying Party Trust. (we don't want to use our Authentication Provider for all relying parties on the AD FS server, only for a single test application.)
From that page, right-click the Relying Party you want to configure for Multi-Factor Authentication and click Edit Custom Multi-Factor Authentication...

We will now enable our Authentication Adapter for internal as well as external users (at least for testing), for registered and unregistered devices. So for now, we pretty much want MFA to happen whenever a users logs on. If we do not specify any users on which we want to apply MFA, MFA applies to all users.

Select all the checkboxes, and click OK.

By now, MFA should be enabled on this application. I'd say; test it! Navigate to the Relying Party application you just configured and, if required, logon to AD FS. You remember the PIN? It was hardcoded to 12345.

Entering the wrong PIN would prompt you for the PIN again. A correctly entered PIN would redirect you to the application you were trying to access.

Congratulations. Our hard work paid off! We have a working Authenication Provider for AD FS.

But using a hard-coded PIN doesn't make sense. So in the next chapters we will create a Windows Phone app that receives PIN codes from AD FS. Obviously, we have to come back to our Authentication Provider later to make some modifications to it.

Take me to Part 3 - Setting up Azure Mobile Services

Take me back to Part 1 - Introduction