AD FS deep dive: Your comprehensive FAQ guide

Active Directory Federation Services — or AD FS — at the most basic level, allows users to have a single sign-on access to multiple web applications over the life of the same session. Let’s take a deep dive into what AD FS is and what it does.

What is AD FS?

AD FS is a secure way to share identity information across trusted business partners, also called a federation, over an extranet. For example, let’s say a user in organization A wants to access the internal application of organization B, which is one of A’s federation partners. To do this, a user doesn’t need a separate username and password, but can use A’s login credentials to access the internal application of B, provided both the parties agree to it.

The responsibility to authenticate the user and his or her identity information lies with the user’s own organization, which is A in this case, and not that of the federation partner.

Typically, the user’s organization has to authenticate the identity information and send this information in the form of “claims” to the federation partner’s organization. In turn, the partner’s system will validate this claim against the ones that are understood by its application and based on this, will make authorization decisions.

In other words, AD FS separates the process of authentication and authorization. It does this by allowing account partners to authenticate users and send these authenticated requests to resource partners, which in turn, can control the actual use of resources.

This relationship between account and resource partners is called a federated trust. Here, the word “trust” simply means a business agreement between two organizations to implement such a distributed authentication and authorization agreement.

Who developed AD FS?

AD FS was developed by Microsoft and runs on the Windows operating system. It is Microsoft’s implementation of the WS-Federation Passive Requestor Profile protocol.

What are claims?

Claims are statements about users that are understood by partners in an AD FS federation. These statements are used for authorizing users to access a particular application.

Typically, AD FS allows claims to be exchanged between trusted partners, and the receiving partner uses this information to make authorization decisions.

Are there different types of claims?

There are three different types of claims, and they are:

• Identity claims include first and last names, email, and user principal name (UPN).
• Group claims are memberships in a role or group. Examples are testers, developers, managers, and so on.
• Custom claims include custom information about a particular user such as employee ID.

At least one type of claim is essential to get an authorization token. If there is more than one type of claim, identity claims get the priority. Within it, UPN, email, and name is the order.

What is the history of AD FS?

There are five versions of AD FS. Let’s look at each version to understand its evolution over the five versions.

AD FS 1.0

• It came as a Windows feature with Windows Server 2003 R2.
• Unfortunately, it fell out of use as Microsoft stopped offering support since 2010.

AD FS 1.1

• ADFS came with Windows Server 2008 and Windows 2008 R2.
• You can install it with a Server Manager.
• This version is not in use now because many features expected by federation partners are missing in it.

AD FS 2.0

• This version was different from the previous ones as it was not included in any operating system. Rather, you’ll have to download and install it separately on your Windows Server.
• So far, ADFS 2.0 has had three update rollups, so make sure you install the latest one.

AD FS 2.1

• ADFS 2.1 went back to the Server manager installation. It comes as a part of Windows Server 2010.
• It’s also called AD FS 2010 R2.

AD FS 3.0

• It comes as a part of Windows Server 2016.
• It eliminates passwords, so the chances for someone to steal or phish is greatly reduced.

This is the history of AD FS.

Can AD FS authenticate a user by itself?

No, AD FS cannot authenticate a user by itself. It requires a domain controller to authenticate it for Active Directory. Once this authentication is done, it verifies users and issues security tokens.

What’s the difference between an Active Directory domain controller and AD FS?

A domain controller holds the database of all users and computers that are connected to the domain whereas AD FS holds no such database. Instead, it acts as an intermediary between the given domain and an external one and requests authentication for users trying to log in from the external domain.

What are the advantages of AD FS?

AD FS is a popular tool to handle identity and access management. Here are some reasons to use it.

• The biggest reason to use AD FS is the single sign-on user experience it offers. Without AD FS, users will have to maintain a separate set of credentials for accessing different applications.
• It lowers the complexity that comes with password management.
• It gives access to applications outside an organization’s firewall, without compromising on security in any way.
• Accounts of past employees can be deactivated easily. When the employer removes access for an employee, he or she can no longer access federation partners’ applications.
• Managing change is simple and easy with AD FS. Say for example, one of your partners joined hands with your rival and you want to terminate the federation relationship with it. With AD FS, you can end it with a single trust policy change instead of manually deactivating the access for every employee.

Due to this ease of use and simplicity of management, AD FS is widely implemented across many organizations.

What are the limitations of AD FS?

As with any software, AD FS also comes with its own share of limitations.

• File shares or print servers can’t be accessed through AD FS.
• You can’t connect to servers using RDP.
• All Active Directory resources are not available for you.
• AD FS won’t authenticate you for web applications that don’t support it (typically legacy web applications).

What are the core components in an AD FS deployment?

There are three core components in any AD FS deployment, and they are:

• Federation Services (FS).
• AD FS Web Agents.
• Active Directory or AD Application Mode (ADAM) repositories.

Out of these, FS is the most important component, and there’s always one for each organization that is participating in the federation.

How does AD FS establish trust relationships?

AD FS issues X.509 certificate tools to establish trust relationships between two systems and to help them exchange data securely. All these relationships are only one way.

What are the base requirements for AD FS?

The base requirements for AD FS are:

• IIS.
• ASP.NET.
• COM+.
• Active directory.
• Windows Server 2008, 2008 R2, 2010, 2012, 2012 R2, and 2016.
• A UPN that’s publicly routable like [email protected] instead of domain.com\username.
• A database server. Windows Internal Database (WID) is the default one.

Should I choose single or multiple AD FS farms?

When you deploy AD FS, you’re only creating a single farm, which is nothing but a set of AD FS systems that communicate to the same database source. Most organizations prefer to have only a single farm because when you assign a UPN, it can authenticate to one farm only.

However, you can choose multiple farms if you want to leverage multiple UPNs or if you want to provide local authentication to many areas within a certain region.

How does the system handle AD FS and non-AD FS users?

This process of authorization and authentication begins when the user requests access to an application or service. Based on the UPN, the application determines if the user is an AD FS or a non-AD FS user. If the application identifies it as an AD FS user, then this person is referred to an address that’s already configured within the application.

On the other hand, non-AD FS users get a public IP address for AD FS servers. This address helps users to navigate to the internal AD infrastructure of the application, and from there, they can access the application.

If users are on the same private routable network as that of AD FS, then they get the internal IP address of AD FS internal servers.

How do I install AD FS?

The easiest way to install AD FS is by using the AD FS Setup Wizard, as it takes care of running prerequisites and fixing dependencies. You can even do a quiet installation by using the command “adfssetup.exe/quiet in the command line prompt.

The only exception is when you’re installing AD FS 2.0. For this, you’ll have to manually ensure that all prerequisites are in place, as the setup wizard for this version will not check for prerequisites.

Also, if you’re using AD FS 2.0 or AD FS in Windows Server 2012 R2, you’ll have to deploy web application proxies as a part of your AD FS deployment.

What network services do I need for deploying AD FS?

Network services are absolutely critical for your AD FS deployment. Here are the networks you’ll have to configure for a successful deployment.

• TCP/IP network connectivity.
• DNS.

Does AD FS support virtualization?

AD FS supports the virtualization of both federation server and federation server proxy roles. If you plan to implement virtualization, it’s best you store each AD FS virtual machine on a separate physical server.

What are some common AD FS configurations?

A popular AD FS configuration is Federated Web SSO with Forest Trust. This type of configuration is mainly used when an organization has one forest configured in the perimeter network and another one on the internal network. Such a configuration allows users, who are on the internal network, to access the perimeter network using the same login. This way, they don’t have to maintain two separate accounts for two networks.

The other common configuration is Federated Web SSO, typically used by two separate organizations that have a common agreement or are in a B2B relationship. This allows one organization to authenticate and send this information in the form of claims, and the second organization to authorize access based on this information.

When two distinct organizations are involved, it’s best to use a Federated Web SSO implementation because a Forest Trust would create a lot of confusion as it’ll give users too much access to the applications of both organizations. A possible workaround is to use Selective Authentication with Forest trust, but it’ll simply be way too much maintenance for the IT admin department of both companies.

What are the certificate requirements for AD FS?

Certificates are an essential part in any digital communication, and AD FS is no exception. Certificates help to secure communications between web proxies, web applications, federation servers, and cloud services, though the exact type would depend on your implementation.

Broadly speaking, there are two kinds of certificates used in AD FS: SSL and token-signing certificate.

SSL, which stands for Secure Socket Layer, is used for securing communication. AD FS requires a SSL for server-side authentication on every server in your federation server farm. You need both the certificate and the private key associated with it.

Token-signing certificate is a X.509 certificate used for securing all tokens issued by the federated server. AD FS generates a self-signed certificate for you by default, but you can change it through the AD FS management snap-in based on your implementation.

Photo credit: Freerange Stock