In today’s business environment, it’s likely that your company’s clients, partners or vendors need to access your environment. They may need to work with equipment and resources that cross organizational boundaries. However, without a system of trust, providing secure access to them isn’t always easy. Traditionally, there are two ways they can get access to your environment:
- Create an account in your domain to allow access to a user of the other organization
- Set up an Active Directory trust relationship between the AD Domains of your and your partner’s organization
The first method requires manually creating and deleting accounts. Setting up the AD trust is complicated in itself because of the port requirements. Both methods are a pain—either to set up or to manage—and have other security-related concerns, which I will not go into detail on now. Nevertheless, the responsibility of account management always remains.
What if you could shift this burden of account management to your clients, vendors or whoever it is that uses your application? Imagine if you never have to create user accounts or reset passwords for those employees anymore. Or that the people using the application never even have to log into the application using an extra set of credentials anymore.
This is where Active Directory Federation Services (ADFS) comes in. ADFS addresses the above issues. If the IT departments of your and your partner’s company could come to some type of trustworthy agreement it would be extremely beneficial. Your company could trust certain Active Directory accounts from another company (or vice versa) to access its application with its own credentials—without requiring a local account.
What is ADFS?
Active Directory Federation Services is a feature and web service in the Windows Server Operating System that allows sharing of identity information outside a company’s network. It authenticates users with their usernames and passwords. Users can access some applications (i.e. Microsoft Office apps, Salesforce.com, etc.) without being prompted to provide login credentials again. These applications can be local, on the cloud, or even hosted by other companies. Below is a diagram to explain the concept. It doesn’t matter where these applications live or who owns them. These user accounts can be maintained by the administrator from a single place, namely Active Directory.
The idea is that it allows sharing of identity information between trusted partners beyond the boundary of an organization, called Federation.
Why do you need ADFS?
Active Directory Federation Services provides a means for managing online identities and providing single sign-on capabilities. This is becoming important because of the transition being made from running applications on-premises to running applications in the cloud.
When applications are run on-premises, access rights to them can be granted to Active Directory objects (users and groups). Once users log into Active Directory they are recognized regardless of which servers they’re connecting to access applications and other resources.
This model has been used for a long time but has limitations for cloud-based applications.
Another example of how it works: when you log into your computer in the morning using AD credentials, your identity is established after your credentials are verified. The same credentials will then be used when you want to access any local resource throughout the organization.
Now, if you want to access Netflix, it won’t recognize you automatically because Netflix is technically a cloud-based application. No matter whether you are logged in with your AD Domain account, there is no trust between Netflix and your domain. Netflix manages their own user accounts, so you have to provide credentials specifically for that site.
The same goes for corporate environments. Your company could have an application running in the cloud. Just like Netflix, this application would require a unique set of credentials. It’s simple to remember the password for Netflix, but this concept doesn’t scale well in corporate environments.
For example, you could also have an Amazon account. Netflix and Amazon have nothing to do with each other, so they require two different sets of credentials. Imagine this same concept in a corporate environment. If your company subscribes to 10 different cloud-based applications, you would have to remember 20 different sets of credentials. Except for regular users, this would be a nightmare for support staff that will need to set up these many different accounts for every user and as well as for managing password resets.
It is these types of challenges that led ADFS to become so important and so widely adopted. One example of a widely implemented ADFS is from Microsoft for customers who want to move some services to Microsoft 365.
ADFS with Microsoft 365
Microsoft 365 consists of various services like Microsoft Exchange, SharePoint, and Lync. Since Microsoft servers are running in the cloud, you cannot join their servers to your domain directly.
Since Microsoft 365 requires Active Directory environment, Microsoft creates a dedicated domain in the cloud for your subscription. ADFS can be used instead by setting up directory synchronization (using DirSyc tool) that will automatically create accounts in Microsoft’s domain that match the accounts within your local domain. You can even choose which accounts should be synchronized in case you do not want all accounts in your AD to have Microsoft 365 services. For these synced accounts, some passwords associated with them could be an issue and here Active Directory Federation Services comes into play.
As shown above, when a user attempts to access Office 365, a claim is submitted to Microsoft servers by ADFS. This claim contains the identity information of the user. Microsoft’s servers extract the account information and validate if the claim is authentic. Once verified, the user is automatically logged into their account within the Microsoft domain.
What can you do with ADFS?
You may have noticed the use of the word “trust” between companies/partners before, called Federated Identity Management (FIM). It’s the core concept behind ADFS. The concept of FIM is integrated with Windows using Active Directory. Since Active Directory stores the information of all users (accounts and passwords), it acts as the base identity store. ADFS uses all of this identity information in AD, and makes it available externally, outside your network. This information can then be used by other organizations and applications.
ADFS is an identity access solution that supports the following scenarios:
- Single sign-on (SSO): It provides client computers (internal or external to your network) with seamless single sign-on (SSO) access to internet-facing applications or services. These user accounts and applications could be located in completely different networks or organizations.
- Identity federation (identity management): The concept of a centralized or linked electronic identity is known as federated identity. Identity management is the process of managing information about the identity of users and control access to resources. The goal of identity management is to improve productivity and security while lowering costs associated with managing users, their identities and credentials.
Due to the rising number of applications and services a centralized login system has become a necessity. It is not only simple to manage but also convenient for the user.
Single sign-on (SSO)
Where your environment has multiple applications or web services running, every application/service requires some kind of authentication to access its features and contents. It would need its own login credentials. You can set the credentials to be the same for every user but that would need manual intervention, and every time a password expires, it would need to be addressed. What’s more, you will also need to enter the credentials every time you try to access these services.
Also, where you attempt to access the application or service in a different network than your user account, you will again be prompted for secondary credentials. These secondary credentials are your identity in the network where that application or service resides. These credentials are required by the web server that hosts this application or service for authorization.
With ADFS, organizations can bypass requests for secondary credentials by providing trust relationships (federation trusts). This trust is used to project a user’s digital identity and access rights to trusted partners. In a federated environment, this means a user from one organization can use its own credentials to log into resources in another organization. Each organization continues to manage its own identities (users, accounts, passwords), but they can also securely project and accept identities from other organizations.
This is implemented by using forms-based authentication and giving users a single sign-on session cookie in their browsers. The users will log in once they access to the first web application, and then this cookie will be used to answer any future credential challenges by other resources in the domain. This removes the need for repeatedly requesting user credentials.
Although single sign-on is convenient, it presents risks to enterprise security. An attacker who gains control over a user’s SSO credentials will be granted access to every application the user has rights to. This increases the amount of potential damage. In order to avoid malicious access, it’s important for SSO implementation to be coupled with identity governance. You can also use two-factor authentications or multifactor authentication (MFA) with SSO to improve security.
Imagine that you travel from one place to another, and check in at the airport. Passing the security counter, you’re expected to show your passport because an airport security officer doesn’t know you. There’s no way for them to trust you when you say who you are. But they do trust relevant government agencies or authorities to verify your identity before they issue you with a passport.
Things work in a similar way with the Active Directory Federation Services. The end-user doesn’t authenticate directly with the service provider. A user’s credentials are always stored only with a “home” organization (the “identity provider”) Active Directory. When the user logs into an application/service, the service provider trusts the identity provider to validate the credentials. So the user never provides credentials directly to anyone but the identity provider.
This is exactly how you can log in to various services on the internet using your Google and Facebook accounts. You provide your credentials only for Google or Facebook, who, in turn, have federated with other services.
What are the components of ADFS?
Active Directory Federation Services consists of four major components:
- Active Directory: This is where all the identity information is stored to be used by ADFS.
- Federation server: Contains the tools needed to manage federated trusts between business partners, and hosts the “Federation Service” role service of ADFS. It routes requests that come in from external users and also hosts a security token service that issues tokens for claims based on verification of credentials from AD.
- Federation server proxy: Hosts the Federation Service Proxy role service of ADFS. External clients connect to this proxy server when requesting the security token. It’s deployed in your organization’s perimeter network (DMZ or extranet). This is done because the federation server is not exposed directly to the internet as it is heavily dependent on the AD—doing so would be a major security risk. So the proxy server forwards the requests from the outside world to the federation server.
- ADFS web server: Hosts either the claims-aware or the Windows token-based ADFS Web Agent role service. This web agent manages security tokens and authentication cookies that are sent to the web server for authenticating external users.
In ADFS, identity federation is established between two organizations by establishing trust between them. The high-level diagram below shows the location of services in internal and external networks.
How does ADFS work?
ADFS uses a claims-based access control authorization model to maintain application security and implement federated identity.
Claims-based authentication is the process of authenticating a user based on a set of claims about its identity contained in a trusted token.
A federation server in the user’s network authenticates the user through the standard means in Active Directory Domain Services. It then issues a token containing a series of claims about the user, including its identity. This token is sent to the federation server on the resources/services side (the external network the user is trying to access). The other federation server validates the token for being trustworthy. It then issues another token for its local servers to accept the claimed identity. This allows a system to provide controlled access to its resources or services to a user that belongs to another network without requiring the user to authenticate directly to the system and without the two systems sharing a database of user identities or passwords.
The image below outlines the steps involved and the workflow when a request is made by a user to access a service.
Despite all the benefits of ADFS discussed from an infrastructure standpoint, there are some downsides:
- It does not allow access to share files or print servers
- It does not access Active Directory resources
- It does not allow connection to servers using Remote Desktop
- It does not authenticate “older” web applications
- Although quite straightforward, ADFS seems rather complex for novices; organizations need to invest in acquiring ADFS skills
- In the progressive culture of BYOD (bring your own device), ADFS has a requirement of having AD Domain accounts, which would work only on domain-joined devices