When discussing and reviewing Office 365 with customers, I wanted to have a series of posts to illustrate the steps involved when deploying Office 365. In the burgeoning drafts folder Active Directory Federation Services (AD FS) was at the top, so that got finished first!
The act of deploying and configuring AD FS 2012 R2 for Office 365 will be broken down into three separate blog posts
-
Install AD FS (this post)
Identity, Identity, Identity
The IT security landscape keeps evolving. One of the recent changes is a move away from ACLs on files in the NTFS file system to an access control system that is based on claims. Claims based authentication is an industry standard security protocol to authenticate users. This is the underlying WS-* standards that describe the usage of Security Assertion Mark-up Language (SAML) tokens. Claims based auth requires these tokens, and by extension an entity that can issue the token. This is the Secure Token Service (STS). The STS server can be based on Active Directory Federation Services (AD FS) or other platforms that provide this service.
AD FS lights up one of the three options for Office 365 identity management, which is option #3 in the below list:
-
Cloud Identity – users are created, and managed, in Windows Azure Active Directory (WAAD). No connection to any other directory. This is the simplest model as there is no integration to any other directory. Each user has an account created in the cloud which does not synchronise anywhere else. Note that you will still typically need additional on-premises credentials to gain access to a local workstation and local resources.
-
Directory Synchronisation – Users are created and managed in the on-premises directory and get synchronised up to Office 365 so they can access Office 365 resources. Typically this means running the DirSync appliance, or in some cases FIM with the Windows Azure Active Directory Connector. The newer builds of DirSync allow for the user’s password hash to be synchronised up to Office 365. Note this does not say clear text password. This allows user’s to logon to Office 365 using the same credentials as on-premises with no additional infrastructure.
-
Federated Identity – Federation relies on directory synchronisation so that WAAD is populated. When the authentication request is presented to Office 365, the service will then contact the on-premises AD FS infrastructure so that AD is responsible for authenticating the request.
AD FS is the primary choice for customers who want to use federated identities with Office 365. In addition to this there are a variety of qualified third party identity providers that can be connected with Office 365 to provide the necessary plumbing for federation. The shortcut URL aka.ms/SSOProviders links to the ‘Works With Office 365’ Identity program, and lists the identity providers that have been qualified with Office 365. Please read the notes on the TechNet page with regards to the testing and support aspects of these services.
Some customers will use these services as they do not wish to invest in a fault tolerant and geographically dispersed AD FS implementation. The availability of AD FS is a key discussion point when discussing federation. For whatever reason if the AD FS infrastructure is unavailable, then Office 365 cannot complete the authentication process and thus users cannot get access to Office 365.
In addition since DirSync now replicates the user’s hashed password to WAAD, some customers now use DirSync to provide Same Sign On / Single Sign On (SSO). DirSync version 1.0.6385.12, which was released in May 2013, and latter builds provide the ability to synchronise passwords. DirSync can be downloaded here, and the TechNet Wiki has details on the release history. When running the configuration wizard with this release you will get the shiny “Password Synchronization” window:
This is worthwhile to mention as there is still a perception that AD FS is a hard requirement to get SSO. That is soooooooooooo Q1 2013!
Anyway, I digress let’s get back to AD FS…..
We shall look at installing AD FS 2012 R2 since there are numerous compelling features in this release!
What’s New And Improved In AD FS 2012 R2
The quick answer is a lot! Some examples include:
-
IIS dependency removed
-
Single server installation option removed and now have single farm install (recommended to install a farm always in prior release anyway)
-
Separate AD FS proxy role removed. AD FS proxy now based off Web Application Proxy (WAP), and is used to publish the AD FS server to the Internet. WAP can publish many other applications, not just AD FS.
-
AD FS extranet lockout – AD DS account lockout protection via the AD FS proxy
-
Access control based on network location to control user authentication to AD FS
There are many others, but check here for them since we are focussing on Office 365 usage for AD FS.
Note that you will not see me call this release AD FS 3.0. Its full and proper name is AD FS 2012 R2. for reference here are the older versions and what some folks call them:
AD FS Build |
Notes |
| AD FS 1.0 | Released with Windows 2003 R2. Built into OS. |
| AD FS 1.1 | Released with Windows 2008 and 2008 R2. Built into OS. |
| AD FS 2.0 | Released After Windows 2008 / 2008 R2. Separate download from here. |
| AD FS 2.1 | Windows 2012 |
| AD FS 3.0 | Windows 2012 R2 |
Update 5-5-2014: Please also see this post on exploring AD FS 2012 R2 Extranet Lockout protection.
Update 29-5-2014: Please also review update 2948086 Update that improves AD FS proxy and STS reliability in Windows Server 2012 R2 when multiple clients sign in.
Update 9-9-2014: For the other posts on ADF S, please view this tag cloud.
Planning And Prerequisites, And Other Fun Details
Prerequisites
The prerequisites are listed on TechNet and now also on docs.microsoft.com. Of course before jumping into the install the installation needs to be planned.
AD FS Role Planning
The AD FS role should be deployed within the corporate network, and not in the DMZ. The AD FS proxy role (WAP in Windows Server 2012 R2) is intended to be installed into the DMZ.
The default topology for Active Directory Federation Services (AD FS) is a federation server farm, using the Windows Internal Database (WID), which may contain several federation servers hosting your organization’s Federation Service. In this topology, AD FS uses WID as the store for the AD FS configuration database for all federation servers that are joined to that farm. The farm replicates and maintains the Federation Service data in the configuration database across each server in the farm.
Since the availability of Office 365 relies upon the availability of AD FS when the domain is federated there is a strong recommendation to have at least two AD FS servers with a redundant AD FS proxy infrastructure.
Please review the design guidance on TechNet.
AD FS Service Account
We can now use a standard service account or a Group Managed Service Account in AD FS 2012 R2.
In this case since the KDS root key was not configured, lets leverage a standard service account.
The installation process should set the required Service Principal Names (SPN) on the account.
AD FS Namespace
Select what name you are to use to access AD FS. Typically this is along the lines of:
sts.wingtiptoys.ca
adfs.tailspintoys.ca
Note that this is the namespace for the AD FS service. Since we will be using Kerberos to access AD FS internally, there must be a Service Principle Name (SPN) registered for this name. This will be associated to the service account, and since SPNs operate in the “Highlander – there can be only one!” mode you do not want to duplicate the SPN on the AD FS server by naming the computer the same as the AD FS namespace.
You also want to discuss what display name should be chosen, as this will be visible to users.
Additionally you may also wish to plan to also enable Device Registration Service (DRS) as well, this is a separate namespace. For more details please see Configuring Device Registration. For the Workplace Join client to discover the Device Registration server using a well-known DNS CNAME record, AD FS must be configured with a server SSL certificate that includes the well-known Device Registration server names. You must include one server name for every userPrincipalName (UPN) suffix in use at your company in the format of:
enterpriseregistration.<upnsuffix>
This would be enterpriseregistration.tailspintoys.ca in this environment.
Internet Access
The AD FS server will require access to the Internet in order to complete the configuration of the solution. This may be an issue if your servers are behind a proxy solution.
Certificates
Since AD FS leverages SSL, we need to have a SSL certificate. You could try three options, but only one will work:
-
Self-signed certificate
-
Certificate issued from internal PKI
-
Certificate from 3rd party public CA
Office 365 needs to see a valid Service Communication Certificate on your AD FS infrastructure, so you are going to have to buy a certificate from a public CA. Office 365 will not trust a service communication certificate that is either self-signed or from your internal CA, which results in tears. We can use self-signed certificates for the Token Decrypting and Token Signing Certificate. These are separate from the service communication cert.
Please follow the documentation from your chosen CA to request, install and complete the certificate. The steps required vary from vendor to vendor and also over time. Make sure you are not missing any updated intermediate certificates! How would you know? Follow their process!!
For the purposes of this post we shall deploy the initial AD FS server, and in the future add another AD FS server for redundancy.
If you wish to use the Device Registration Service (DRS), then add the additional name onto the certificate. Even if you are not using DRS now you may want to save the time updating certificates later on.
Installing AD FS On Windows Server 2012 R2
After starting up server manager’s add roles and features wizard, select Active Directory Federation Services, then click next.
We don’t need to add any additional features. Remember that the IIS dependency was removed in AD FS 2012 R2.
Clicking next takes us to the AD FS splash screen. Note that it helpfully tells us that the specific AD FS proxy role has been removed in Windows 2012 R2 and how to go about installing it. Shame I missed that the very first time I ran this, and could not find the old school AD FS Proxy role…
Clicking next will then install the necessary bits.
Bits are being shuffled around…
Shuffling has been completed, and the installation is complete. You can launch the AD FS configuration wizard from here, or alternatively if this window is closed it can be launched from server manager.
Before starting the AD FS configuration wizard I already installed my 3rd party certificate and tested that is was correctly installed.
Additionally a service account called ADFS-Service was also pre-created.
The wizard also states that you must have access to Domain Admin (DA) credentials!
Note that you are only given an option to either make a new AD FS farm or add this box to an existing farm. This saves the painful issue from older AD FS builds, where AD FS was not installed into a farm you were then unable to add the second AD FS server for redundancy. In that case you had to build a net new farm.
Provide your domain admin credentials.
We need to select the SSL certificate that we will use and also provide the AD FS name we selected in the design process.
In this case the name is adfs.tailspintoys.ca -- note that there is no concept of an InternalURL or ExternalURL for the AD FS namespace. Clients will use the same name on the intranet and internet to locate AD FS. Thus split DNS will make life simple!
Provide your chosen display name, and click next.
As mentioned earlier it is possible to use a GMSA as the AD FS service account. GMSA will automatically update the service account’s credentials and administrators will also be oblivious as to its password. Note that if you do want to use a GMSA, please review the required setup for this, noting the DC version requirements and the steps you must manually perform. Add-KdsRootKey
In this case a standard service account was used.
Select the database configuration as per the design.
The Tailspintoys corporation will use WID.
Review the options, and when happy pull the trigger!
For reference the PowerShell script is shown here:
#
# Windows PowerShell script for AD FS Deployment
#Import-Module ADFS
# Get the credential used for the federation service account
$serviceAccountCredential = Get-Credential -Message "Enter the credential for the Federation Service Account."Install-AdfsFarm `
-CertificateThumbprint:"5804746A7980C8682FBF408D48EF6C3B02A5ZORG" `
-FederationServiceDisplayName:"Tailspintoys STS" `
-FederationServiceName:"adfs.Tailspintoys.ca" `
-ServiceAccountCredential:$serviceAccountCredential
The AD FS pre-requisite checks are done, and we can proceed to the configuration:
One coffee later, we have a shiny new AD FS server – whoo!!
We are not quite done yet, and there a couple of additional things to do!
Next Steps
AD FS Update(s)
Update 29-5-2014: Please also review update 2948086 Update that improves AD FS proxy and STS reliability in Windows Server 2012 R2 when multiple clients sign in.
When multiple clients (over 200 clients) try to sign in by using an Active Directory Federation Services (AD FS) proxy, the AD FS proxy consumes 100% usage of the CPU. In this situation, the AD FS proxy performance is slow, and causes a delay that exceeds 10seconds. This also causes STS to work under minimal load. Therefore, STS rejects the requests or serves only 5 to 10 requests per second.
Update 11-12-2014: The above update 2948086 is now bundled in this rollup: May 2014 update rollup for Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2
Update 16-7-2014: Other updates you may want to review are at the bottom of this post.
Update 4-11-2016 And you will also want to review this list of updates and fixes: Updates for AD FS and WAP in Windows Server 2012 R2
DNS A Record
We must create the DNS record for the AD FS instance. This maps to the AD FS namespace that we previously planned. Create this A record in your internal DNS infrastructure.
Ideally you will have two AD FS servers for resiliency, in which case you will need to create a load balanced VIP for this service. Please follow the steps for your specific LB device. The DNS A record should resolve to the VIP. For testing purposes, use a hosts file on a client to check out individual AD FS servers – do not try and just use the IP address of the box.
Once the DNS record has been created and propagated, ensure that it resolves correctly.
One thing to mention here, if you create a CNAME and point that to the server hosting AD FS chances are that you will run into a never ending authentication prompt situation.
In the below example the AD FS namespace is called adfs.tailspintoys.ca and a CNAME was used to direct traffic to the AD FS server called tail-ca-sts.tailspintoys.ca. This will likely cause the client to obtain a Kerberos ticket for the incorrect name.
The easiest way to stop this is to use a regular A record, like so:
There is also an option contained in KB 911149 that some folks have mentioned.
Additional Steps
This topic covers additional steps to configure AD FS after you install the first federation server, including:
For more information about how to deploy AD FS, see How to deploy AD FS in Windows Server 2012 R2.
Verify Federation Service Metadata
Open Internet Explorer and navigate to your AD FS server’s federation metadata URL.
This will be something like the below, just change the FQ DN to match your environment.
https://adfs.tailspintoys.ca/federationmetadata/2007-06/federationmetadata.xml
https://sts.contoso.com/federationmetadata/2007-06/federationmetadata.xml
The result should show this:
Verify AD FS Sign-In Page
Browse to the AD FS sign-in page and test that you are able to authenticate.
The URL will be similar to the below, again change the FQDN to match your organisation’s.
You should see the below, and be prompted to sign in:
Depending upon how IE is configured you will either be prompted to provide credentials or be automatically signed-in.
If you want to have users be automatically signed-in then configure your browser settings to trust the federation server role by adding your federation service name (for example, https://adfs.tailspintoys.ca) to the browser’s local intranet zone. This will enable seamless sign-in using Windows Integrated Authentication.
Once we are happy that the AD FS instance is functioning appropriately we can then move onto installing the AD FS proxy role (WAP).
This will be covered in the second post in this series, to prevent this one getting too long!
Cheers,
Rhoderick
