AD FS Deployment Considerations for Office 365

What does ADFS do?

ADFS provides single sign on capabilities for Office 365 users, based on a trust relationship between your AD and Microsoft Office 365. So, for customers on BPOS, this means seperate usernames and passwords will no longer be necessary between your AD and Microsoft Online. While the benefits to this are clear there are also some potential drawbacks of ADFS that we’ll also cover in this article.

Required components

In the interest of making this article as easy to understand as possible, we are going to focus our discussion around the requirements for a single site network. As we do, we will discuss the required infrastructure components and how those components work together to achieve the required identity federation.

Domain controller

There are a number of different components that must all work together to provide Active Directory federation for Office 365. The first requirement is that you must have an Active Directory with one or more domain controllers in place.

The only real requirement for the Active Directory is that all domain controllers must be running a minimum of Windows Server 2003.

When ADFS is enabled, the account policies you have in place will apply to Office 365. For example, if you allow 3 character, non-complex passwords that don’t expire, will work fine in Office 365, because your Active Directory is handling the authentication.

DNS server

If you have an AD, you already have domain name system (DNS). The important thing to note around ADFS is that clients must be able to connect to the same DNS name, both internally and externally. For example, if you use the name adfs.domain.com for your federation service name, this must resolve both inside and outside your corporate network to your ADFS or ADFS proxy servers. On the internal network, this name might resolve to your ADFS server, and on the internet this name might resolve to your ADFS proxy server.

UPN Suffixes

It is common for organizations to use maintain separate internal and external domain names. A best practice was to have your internal Active Directory domain name have a .local or a .corp suffix. With Office 365, the user principle name (UPN) suffix must match your external domain name, which you have registered and verified within Office 365. In these situations, it is necessary to add a user principle name suffix to the AD.

The reason why UPN suffixes are required is because the federated trust exists between Office 365 and your external domain name (Microsoft can’t verify whether you own a .local or .corp domain). Users must be authenticated using this external domain name. A UPN suffix adds the external domain name to the AD, so that users can log in using their username and the external domain name (For example: [email protected])

This is an important point and could pose challenges for larger organizations, especially those with existing certificate infrastructures.

To add a UPN suffix to your domain, see this article.

Another important point to consider is whether you want to use multiple UPNs. It’s fairly common that an organization has employees at different divisions with different email aliases. If you want users to sign into Office 365 using a UPN that is set to the same value as their email address, you would need to deploy multiple ADFS infrastructures as each ADFS server can only support a single domain. In scenarios like that, it’s probably best to have the UPN be different than the user’s email address.

Certificates

ADFS makes extensive use of digital certificates. It is possible to configure a Windows server to act as an Enterprise Certificate Authority, assuming all client computers trust the certificate authority. If you don’t have an existing certificate infrastructure, (and if you do in some cases) we’d recommend just purchasing a certificate from a trusted Certificate Authority. These certs will be trusted by your clients, mobile, devices, and the whole process is made much easier.

The reason why SSL certificates are required is because the client computer must be able to communicate with the Web service, the resource partner, and the account partner. The most important thing to remember about your SSL certificate is that the subject name must match the name used within the ADFS configuration. For example, if your federation server exists at https://fs.contoso.com/adfs/ls, then the certificate’s subject name must be fs.Contoso.com. Misconfigured subject names are a common problem that administrators tend to have when setting up ADFS.

The Active Directory Federation Services

As previously mentioned, the main component that makes Active Directory Federation possible is the Active Directory Federation Services (ADFS). Even though ADFS is included with Windows Server 2008 and 2008 R2, you won’t be able to use that version. Office 365 requires you to download and install the 2.0 version.

When you get ready to download ADFS 2.0, pay attention to the version that you are downloading. Microsoft provides separate downloads for Windows Server 2008 and Windows Server 2008 R2. The Windows Server 2008 R2 version provides a few R2 specific hot fixes without which ADFS will fail.

Microsoft Office 365 contains applications such as Exchange and SharePoint that are usually considered to be mission critical. It’s therefore important to deploy ADFS in such a way that you avoid the server becoming a single point of failure.

This brings us to the main weaknesses of ADFS. If your ADFS server and/or domain controllers are offline, or not functioning properly, users won’t be able to sign in to Office 365 services. Consider, for example, a small office which currently hosts 2 domain controllers on-premises. If they set up ADFS, and lose power in their office, nobody will be able to access the Office 365 services, because the domain controllers are offline and unable to authenticate users. Maybe it’s not a big deal, since users in the Office don’t have power and wouldn’t be able to work anyway, but it also means that remote users won’t be able to sign into the services. For all the frustrations that users have with BPOS passwords, there is one benefit, in that if your on-premises infrastructure fails, users could continue working remotely and access Exchange and SharePoint.

When you introduce ADFS, you create a dependency on your on-premises infrastructure being available and accessible. Another thing to note is that it is possible to disable ADFS. However, it’s not very easy to achieve, because you would have to distribute passwords to the end users, which is difficult if they can’t sign into their email.

The proper way to provide scalability and fault tolerance is to create an ADFS farm. When you install ADFS, the setup wizard asks you if you want to create a standalone ADFS server or an ADFS farm.

When you create an ADFS farm, the first server becomes the primary ADFS server. This primary ADFS server has a read/write configuration database. Any additional ADFS servers that are brought into the farm are designated as secondary servers, and contain read only configuration databases. When changes are made to the ADFS configuration, those changes are written to the database on the primary ADFS server, and are then replicated to any secondary server that may exist. You should always deploy ADFS in a farm. Even if you plan on having a single server, just install it as a farm in case you want to add to it in future.

If the primary ADFS server fails, then the secondary servers will continue to process requests, but no configuration changes can be made to the ADFS database until the primary server is brought back online.

This is really the second weakness of ADFS; The amount of on-premises hardware required to implement it. Larger organizations will want at least:

• 1 Directory Sync Server
• 2 AD FS Servers
• 2 AD FS Proxy Servers

In smaller organizations, you can install the ADFS roles on existing servers, but it’s still on-premises software that you need manage.

As far as requirements, ADFS must be installed on Windows 2008 or Windows 2008 R2 servers. It can coexist with other services for example, you could install the ADFS Server on existing domain controllers, and install ADFS proxies on existing web servers in the DMZ.

The directory synchronization server

Even though the ADFS server is able to provide Active Directory federation to Office 365 users, it cannot do the job by itself. That’s because the Office 365 applications reside within an entirely separate Active Directory forest that exists solely on Microsoft’s servers. As is the case with any other Active Directory environment, users must have an account within the Active Directory domain before they will be able to access any domain resources.

The Office 365 administrative interface provides a mechanism for setting up user accounts, but it’s is impractical for large organizations to try to manually create an Office 365 account for each of your AD users. Instead, Microsoft advises the use of a directory synchronization server.

A directory synchronization server is a server that synchronizes your AD accounts with the Microsoft Office 365 environments. Any accounts, groups, and contacts that exist within your domain are automatically created in Office 365.

Although the directory synchronization process is completely automated, there are a few important things that you need to know about the server.

• The initial directory synchronization server configuration requires that you provide the credentials for an enterprise administrator account and for your Office 365 administrator account
• The directory synchronization software (which is downloadable from the Office 365 administration console) must be installed on a 32-bit server (Windows Server 2003 or Windows Server 2008) that is configured as a domain member. There is presently no 64-bit version of the software available, and the synchronization software cannot be installed onto a domain controller. Also, you should not have SQL or SQL Express installed on the system
• Directory synchronization is not something that can be enabled and disabled on a whim. By synchronizing your directory, you are essentially committing to a long term coexistence with Office 365.

The directory synchronization server can synchronize up to 10,000 objects and may take up to 24 hours to complete. If you need to synchronize more than 10,000 objects, you’ll need to contact support and have them increase the limit.

How Active Directory Federation works

Now that you are familiar with the basic components of the process, let’s provide you with an overview of how the federation process works.

When a user on your network attempts to access an Office 365 application, the user’s computer connects to Microsoft’s online services. When the connection is established, the Microsoft servers will prompt the client computer for a service token. A valid service token is the mechanism that actually grants access to the web service (in this case Microsoft Office 365).

At this point the client does not yet have a valid service token because it has not been authenticated by Microsoft’s online services. That being the case, the service will redirect the client to Microsoft’s Federation Gateway, which in turn will send the client to the ADFS server on the client’s on-premises network.

The on-premises ADFS server needs to be able to verify the user’s identity. It does this by asking for the user’s AD credentials. However, the user never receives a prompt for these credentials, because the user has already authenticated into the Active Directory at this point, so the user’s computer is able to provide the ADFS server with a set of cached credentials.

At this point, the ADFS server validates the user’s credentials. After doing so, the server performs an LDAP query of the Active Directory to retrieve the user’s UPN. The UPN is mechanism for identifying the user both on the local network and in the cloud. It usually consists of the user’s login name and the user’s domain name. Often the UPN is the same as the user’s E-mail address, but this is not always the case.

Upon retrieving the user’s UPN (and any other required information) from the Active Directory, the ADFS server embeds it into an encrypted login token that only the Microsoft Federated Gateway is able to decrypt. This token is sent to the Microsoft Federation Gateway, which decrypts and validates the token, and then issues a signed service token. The client computer then sends this service token to the Microsoft Online Service servers, and is granted access to the services that are specified within the token.

Conclusion

As you can see, there are a number of requirements that must be met in order to achieve Active Directory Federation in a way that facilitates single sign on to Office 365. You can read more about these requirements.

For small organizations it probably doesn’t make much sense to deploy. There is no doubt it’s a nice feature, but many small organizations will likely find the added hardware requirements, complexity, and reliance on the on-premises active directory and ADFS not worth the benefits received from it.

Have a question or need help? The experts at MessageOps are ready to assist you! Contact us today to learn more, and see if you qualify for free implementation or migration assistance.