Windows Azure Pack with ADFS and Windows Azure Multi-Factor Authentication – Part 1

ADFS Series
Windows Azure Pack with ADFS and Windows Azure Multi-Factor Authentication – Part 1
Windows Azure Pack with ADFS and Windows Azure Multi-Factor Authentication – Part 2
Windows Azure Pack with ADFS and Windows Azure Multi-Factor Authentication – Part 3

The last couple of weeks I have been testing a lot of federation scenarios for Windows Azure Pack. Out of the box Windows Azure Pack provides two authentication sites. A Windows Authentication site for the administration portal and a Tenant Authentication site based on a ASP.NET Membership provider for the tenant management portal. It is also possible to use Active Directory Federations Services (ADFS) for authentication with Windows Azure Pack.

Active Directory Federation Services

This opens the door to numerous interesting scenarios. I have tested Windows Azure Pack scenarios with the default ADFS Active Directory claims, federation to partner organizations, federation to Windows Azure ACS (that Shriram Natarajan also posted in an excellent blog a couple of days ago) and integrate ADFS with Windows Azure Multi-Factor Authentication.

Multi-Factor Authentication

If you ask an average person what password policy he or she is using for the online services they access the answer is quite scary. A single password for different entities. How many have been victim of phishing, identity theft  or know someone who has been. And if we look at an average business and their security policies, well… it’s a mess usually. Unless you are disciplined with complex passwords, a simple username password does not cut it any more. Multi-factor Authentication can address these security issues by adding an additional layer of authentication. Besides the username and the password it is possible to validate the user by a phone call, a text message, a validation app, etc. In the past these functionalities where quite complex to implement, let alone integrate in to existing applications. Microsoft announced General Availability of Windows Azure Multi-Factor Authentication in September 2013. This service in Windows Azure Active Directory takes away the pain of setting up Multi-Factor Authentication yourself and allows for easy integration with existing applications by integrating on premises ADFS servers.

In this blog I’ll describes the steps to configure the tenant site in Windows Azure Pack to use ADFS for authentication and also add Multi-Factor Authentication by leveraging Windows Azure.

First lets have a look at the end result. A tenant opens the Windows Azure Pack tenant portal and is redirected to the ADFS, or even better the Web Application Proxy (Yep, WAP to WAP). The tenant enters his active directory credentials and is prompted to proceed with Multi-Factor Authentication. After proceeding the tenants is called within a couple of  seconds on his mobile (you can configure other options as well). When asked, the tenant presses # in the call and he is instantly logged in to Windows Azure Pack. No matter if you show this to an IT pro, a customer or your boss, it will bring a smile to their face. Guaranteed!

Prerequisites

Before we start clicking away we need to get some insight in the moving parts and the corresponding prerequisites.

Windows Azure Pack and ADFS are accessible through a browser. In a production or even a lab environment it is a good idea to change the out of the box endpoints to user friendly values. This requires changing the endpoints to HTTPS on port 443 and specifying readable FQDNs. In this blog we will create the DNS records in the internal DNS server. This will also be valid for a configuration that is publically accessible, except for the DNS records that will have to be created in a public DNS zone.

Open DNS manager on the server running DNS in your environment and create a new forward lookup zone. You can create a single zone for all the records or create a zone for each records. The advantage of a single zone is easier management, but the DNS server is authoritive for the complete zone. If you try to resolve a record that is not created in the zone the DNS server will not forward it. You can also create a zone for each record and add a blank A record pointing to the IP that must be resolved. This will generate more administrative overhead but if a record is requested from the matching domain (one level up) then the DNS request is forwarded to the public DNS. For this blog we need the following three A records created.

The installation of Windows Azure Pack will create self-singed certificates for each site. ADFS requires a certificate in place before you can configure it. All endpoint accept a default web certificate and can cope with wildcard web server certificates. For this blog the following certificate was created by a public Certificate Authority.

Windows Azure Pack will create SQL logins for all services. Active Directory Federation Server requires a domain service account for configuration.

You have the possibility to create different designs. In the upcoming CloudOS whitepaper series, different designs and choices will be discussed. For this blog all components are installed in the same domain without high availability. The following table describe the virtual machines and their roles for this blog.

Windows Azure Pack

In a production environment it is recommended to distribute the components o
ver multiple servers and configure high availability. In this blog we will install all Windows Azure Pack components on a single server. All the Windows Azure Pack components and dependencies can be installed using the Web Platform Installer. Download and execute the Web PI on the server that will run Windows Azure Pack and install Windows Azure Pack: Portal and API express.

After the installation completes the wizard will open the configuration site on https://localhost:30101. In the configuration page specify the SQL server name, select SQL Server Authentication, enter the SA account and credentials and finally specify a Passphrase. The installation configures the database and the services. The first thing to do after the installation finishes is to logoff and logon again. The administrator is added to the local MgmtSvc Operators group. This will only take effect after logging in again. Before we configure anything else in Windows Azure Pack we will install ADFS.

Active Directory Federation Services

Logon to the server that will run the Active Directory Federation Services role. Import the web server certificate that you will use for the ADFS web service in the Local certificate store. Add the ADFS role in the Add roles/features wizard. When the installation wizard is complete select to run the Post-Deployment Configuration from the Server Manager.

In the Welcome screen, select the option to create the first federation server in a federation server farm. Specify an account with Active Directory domain administrator permissions.

The Specify Service Properties tab has a couple of fields that must be configured carefully. First of all select the web server certificate we imported earlier. The Federation Service Name will be populated from the common name of the selected web server certificate. If you selected a web server certificate with a wildcard or subject alternate names you need to edit the Federation Service Name manually to the value that will be used by clients using the federation service. The web server certificate should be valid for the Federation Service Name. The Federation Service Display Name is created as the default claims provider trust to Active Directory. This name is also displayed in the web page when ADFS is configured with Form Authentication. I have not find a way to change this name afterwards, yet.

In the Specify Service Account tab, select the domain service account that was created in the prerequisites (in this example SVC_ADFS). This domain account requires no special permissions or group memberships. A default domain account that is member of the default domain user group is sufficient.

The tab Specify Database allows you to select the type of database that is used for ADFS. You can choose to create a database on the ADFS server using the Windows Internal Database or use create the database on a SQL server. There are a couple of things to note here. In the configuration with the Windows Internal Database it is still possible to create redundancy by adding a an ADFS server to the ADFS farm. The seconds ADFS server will also run a Windows Internal Database. One ADFS server in the farm will run the primary database and the other ADFS servers will replicate the changes to their database. A failover to another server requires manual interaction by marking a secondary server as primary. Another difference is the influence on the limits of ADFS. A Windows Internal Database farm has a limit of five federation servers does not support token replay detection or artifact resolution (part of the Security Assertion Markup Language (SAML) protocol). For this example we will use a SQL server.

After all settings have been entered, verify the selections and complete the wizard. In the next part of this blog series we will configure Windows Azure Pack and ADFS for federation.