Install ADFS 2.1 on Windows Server 2012 for Office 365 (Part 1)

This article takes the reader step-by-step through initializing a new domain in Office 365 (Wave 15, or version 2013), its verification, and configuration for single sign-on. This guide will show how to perform these steps using PowerShell wherever possible, and on Windows Server 2012 with AD FS 2.1.

As a prerequisite, you will need:

  1. A 64-bit computer (Win7, Win8, Server 2012) with WAAD PowerShell and MOSSIA assistant
    1. Microsoft Online Services Sign-In Assistant (MOSSIA) 7.2 Beta, 64-bit can be downloaded directly from Microsoft. Beta version is the one currently shipping with Office 365 Dirsync Tool (end of June 2013) and it is safe to use
    2. Windows Azure Active Directory PowerShell Module (WAAD Posh), 64-bit can be downloaded directly from Microsoft. WAAD requires MOSSIA.
    3. The latest versions of both components can also be obtained from Office 365 Portal, but only after the domain is added via the portal UI
  2. Global Administrator credentials to an Office 365 account

Step 1: Add a New Federated Domain to Office 365

Using WAAD Posh on the computer with MOSSIA:


You will be prompted for Office 365 administrator credentials

New-MsolDomain -Authentication Federated -Name

A new SSO domain is added. (If you already added a domain using Office 365 Portal, you can use Convert-MsolDomainToFederated to enable SSO on it). We now need to add the required TXT record for ownership verification. To get the TXT record that we need to add to the DNS:

Get-MsolDomainVerificationDns -DomainName

The output of the command shows Label parameter, which is what we need to add as a TXT record to the root of external DNS zone.

Get-MsolDomainVerificationDns output

The record that needs to be added is as follows:

@ 3600 IN TXT "MS=ms*******2"

(Stars to be replaced with numbers from Get-MsolDomainVerificationDns Label output).

To confirm that the TXT record is added successfully and is visible from the internet, you can always use NSLOOKUP:

Confirming TXT record change with nslookup

Step 2: Prepare to Install ADFS Services on the First ADFS Server

Before you install ADFS 2.1 on Windows Server 2012, you have to think through some of the requirements. This article will not go through a detailed planning, but for the purposes of walking through the remaining installation steps we will assume that:

  • Our environment has some 50,000 user accounts in Active Directory
  • Will feature two ADFS farm servers
  • Will have two ADFS proxy servers
  • Will have one DirSync server
  • Will use Microsoft multicast NLB on both ADFS farm and ADFS proxy servers
  • Due to the size of the environment (50,000), external SQL server will have to be used
  • This SQL server must not be running SQL Express edition. We will use SQL Standard 2012
ADFS Topology Diagram

In addition, we need to determine a few things upfront, as it will speed up the installation work:

  • External IP address of the federation service
  • DMZ IP address of the federation service (which will be assigned to NLB as a shared virtual IP address, or VIP)
  • DMZ server dedicated IP addresses, or DIPs
  • Internal ADFS farm VIP assigned to the ADFS farm NLB
  • Internal ADFS server DIPs
  • Fully qualified DNS name of the federation service, or ADFS FQDN
  • Service accounts used for various purposes in the setup
  • Certificates used for server authentication and token signing

For the purposes of this article, we will install only the first ADFS server, just so we can complete the setup of the federated domain in Office 365. The next article will deal with the remainder of this somewhat advanced setup.

Determine the ADFS Farm Name

We really need to get this information sorted first, because our certificate requests will be based on the FQDN of the farm name, and it isn’t possible to install ADFS services without a server authentication certificate.

Two popular choices are and FS would represent federation services, while sts – secure token service.

We’ll use – this name will be used by external clients as well as by Office 365 federation services. This certificate absolutely must be issued by a public CA (but of course, for testing purposes, we will use a self-signed certificate).

Create or Request a Server Authentication Certificate

Really quick overview of ADFS certificates: there are three certificates used by ADFS; one is used for server authentication (i.e. clients validate this certificate when they connect to your ADFS service); the remaining two certificates are used for ADFS token signing and verification (these can be self-signed and can be configured to be managed automatically by ADFS). In this section we are concerned with the server authentication certificate.

As mentioned earlier, normally you would request this certificate from a public CA. This certificate must:

  • not contain dotless (short name) format names
  • not contain subject alternate names
  • not be a wildcard certificate
  • just have one subject name on it,

Folks have reported that SAN or wildcard certificates were seen working, but if you go that way and something does not work later down the road, your support options may be limited at this time. Moving on, my request will be self-signed, and contain a subject alternate name of (we’ll use this second name later with IdP-Initiated Sign-On):

New-SelfSignedCertificate -DnsName, -CertStoreLocation cert:\LocalMachine\My

Then, we need to obtain the hash of this certificate, as follows:

certutil -store my

In this output, find the certificate with Subject: (or your domain name, obviously) and make note of Cert Hash field. We will use it later in ADFS setup.

certutil output

Also, export this certificate with private key using its Serial Number as follows:

certutil -exportpfx -my <serialnumber> export.pfx ExtendedProperties

Service Account for ADFS Federation Service

Next, we will create a service account for the purpose of installing and running ADFS Federation Service. This service account, FLEXECOM\service-adfs, will be used to perform initial installtion of the service as well as SQL databases. During this initial installation, the service creates certificate containers in Active Directory, as well as SPN records for the shared IIS pool identity, service-adfs (itself). To perform these tasks, the service account must be at least a Domain Admin, but later can be demoted to Domain User with local administrator privileges on all ADFS farm servers (don’t forget db_owner rights on the two SQL databases it will create on the SQL server, AdfsConfiguration and AdfsArtifactStore).

Step 3: Install ADFS Service on the First Windows Server 2012 Server

At this point I have two servers:

  • lab-adfs-01 (Windows Server 2012)
  • lab-sql-01 (Windows Server 2012 with SQL Server 2012)

On the lab-adfs-01 server, configure pre-requisites:

  1. Install msoidcli_64.msi (version 7.2 beta, see links at the beginning of the post)
  2. Install AdministrationConfig-en.msi, 64-bit WAAD PowerShell module
  3. Add service-adfs to local administrators
  4. Copy to Desktop
Certutil.exe -importpfx

In elevated PowerShell:

Add-WindowsFeature NET-Framework-Core, ADFS-Federation


C:\Windows\ADFS\FsConfig.exe CreateSQLFarm /serviceaccount FLEXECOM\service-adfs /sqlconnectionstring "database=AdfsConfiguration;Server=lab-sql-01.flexecom.lab;Integrated Security=SSPI" /autocertrolloverenabled /federationservicename /cleanconfig /certthumbprint "long certificate thumbprint with spaces"

Reminder: during this command, FLEXECOM\service-adfs account must have the following privileges – Domain Admins, SQL server sysadmin. If you are unable to grant SQL sysadmin privileges (it will create new database), you will have to use FsConfig.exe to generate database scripts and send them over to your DBA. Following the installation, the service account will be used to run Application Pools on ADFS Federation services, so it will be using service-adfs account to connect to the SQL databases and Active Directory.

This is what you want to see during installation:

Installing ADFS SQL Farm from the Command Line

Step 4: Complete Verification of the Office 365 Federated Domain

Now that we have a functional ADFS Federation service, we are switching back to the WAAD PowerShell:


In case it timed out…

New-MsolFederatedDomain -DomainName

When you run this New-MsolFederatedDomain WAAD commandlet, it verifies the TXT record that we set up in the opening section of this post, enables it for SSO/Federation in Office 365, creates a relying party trust in your ADFS Farm, and updates Office 365 federation service with the particulars of your federation service endpoints, i.e. what is the address of the service, which certificates should be used to verify token signing, and other metadata. You can now confirm that relying party trust exists in your ADFS Farm:

Get-MsolFederationProperty -DomainName

This command will print the Office 365 relying party trust configuration as it currently exists in Office 365 and in your ADFS farm configuration store.

Now we can open AD FS Management console to view federation details:

AD FS Management console

And in Office 365, we now have an Active, federated domain

Federated Domain List in Office 365

Domain Status in Office 365

This brings us to the end of this post. In the next few posts, we’ll cover additional configuration and installation steps and bring this Office 365 SSO / ADFS 2.1 infrastructure on Windows Server 2012 to a usable state.

Next post: Part 2, installing additional ADFS farm members using PowerShell, configuring NLB


Leave a Reply

Your email address will not be published. Required fields are marked *