This month, Microsoft has announced (with much fanfare) their new Office 365 cloud services technology officially available and ready for purchase. Office 365 provides Microsoft-managed versions of Exchange, SharePoint and Lync (formerly known as Office Communications Server). With this announcement, Microsoft is seriously competing against…Microsoft. Attempting to disrupt the legacy PC client / server model, Microsoft is betting that many enterprises would like to reduce cost, move reduced cost from capital expense to operating expense and re-assign IT staff to more strategic projects for their business than ‘commodities’ like e-mail. The journey to cloud services will be undertaken by organizations at different paces, but a critical question remains. How will Identity be managed in these cloud services? What about provisioning and de-provisioning of accounts? Access control, Accounting and Authorization (often referred to as AAA) live on-premises in Active Directory today (for most organizations) – migrating this “to the cloud” might get messy. What should my company do?
Active Directory Federation Services (ADFS)
Microsoft is urging customers to consider adopting Active Directory Federation Services (ADFS) 2.0 in conjunction with an Office 365 deployment. ADFS can also be useful in federating directories between your organization and another organization to reduce Identity and Access Management headaches.
Prior to ADFS (or its previous incarnations), many organizations deployed a ‘separate’ Active Directory implementation, perhaps in their DMZ for less-trusted systems or to act as an extranet authentication and authorization for third parties that are coming in to consume services. The big challenge here is becoming an accounts administrator for extranet users (which may start as a “small 100 user pilot” that rapidly expands, as we’ve all experienced); when they need their password reset, when they have a new employee to be added, they have to call you to get it done. The other big concern here is around de-provisioning of users; do all of your extranet partners call you when they terminate an employee? You could potentially have a nasty security incident on your hands if a disgruntled employee still has access via the extranet.
Active Directory Federation Services does what it sounds like – it federates Directory A with Directory B to allow for mutually agreed upon authorization, authentication and access control decisions to be made. It allows for a more seamless experience for the user; they are able to manage (and remember) one set of credentials for access to multiple systems. This is also a lot easier on the administrator(s) as they can easily control access and set ACLs based on one set of credentials without getting lost in the overly complex task of managing users and groups, mapping which users should belong to which groups and which account (there may be several per person in different directory instances) the person is authenticating with.
Federation Terminology and Design Decisions
When architecting a federation solution, there are many decisions to be considered and terminology to be familiarized with. One of the great things about ADFS is that it supports open standards such as SAML (Security Assertion Markup Language). This allows it to align with third party solutions such as IBM’s Tivoli Federated Identity Manager (TIM) or even to a cloud service directory like the Active Directory instance running in Windows Azure. A list of some integration solution guides that have been published for quick reference has been made available by Microsoft here. Reading through these allows for a general understanding of what’s possible with ADFS in some complex and customized scenarios.
Most organizations will use ADFS for one of two relatively simple activities; federating with a partner organization and federating with a cloud service like Office 365. Let’s dive into these two scenarios and explore what’s required
Scenario 1: Federating with a partner organization (or extending AD to be claims-aware)
In many cases, ADFS is simply a requirement to allow a federated connection between two Active Directory using organizations, shown in Figure 1. Since no schema update is required in Active Directory to leverage ADFS, this is a fairly straightforward process to configure and set up.
ADFS servers are set up in each organization’s environment, most likely in the DMZ. The deployment may also be used for an internal application that you’d like to extend to be claims-aware. A claim is a statement about a user that is used for authorization purposes in an application. ADFS supports three different types of claims:
- Identity claims (User Principal name, E-mail and a Common Name)
- Group claims (a user’s membership of a group or a role in the organization)
- Custom claim (contains a custom attribute about a user, such as phone number or badge number).
Claims-based authentication may exchange any or all of these attributes between the two organizations in order to allow for a seamless identity integration experience for the end user. A claims-aware application is a .NET application that is able to take advantage of the ADFS library extensions.
Figure 1: Basic ADFS trust relationship between two organizations.
ADFS trust configuration is fairly straightforward. The ADFS role can be added to your server via the usual role configuration process in Windows Server. There is a serious of configuration processes that can be followed to ensure that nothing is missed helpfully published by Microsoft and available at this link. In the author’s experience, the most difficult part of the configuration was creating the claims rules for a claims provider trust. These claims rules must be aligned between the two organizations and ensuring you’re both speaking the same language on what’s authorized is critical; it’s recommended that you do desktop sharing during the configuration process with the other organization to make sure there are no mismatches.
Scenario 2: Federating with Office 365
If an organization is planning to move e-mail or collaboration services to the cloud, reinventing the wheel with another Active Directory simply isn’t feasible. Luckily, there’s a step by step guide on federating an on-premises ADFS implementation with the Office 365 service, shown in Figure 2. Please note that ADFS 2.0 must be used with Office 365 – earlier versions are not supported. The big differentiator for ADFS configuration in an Office 365 environment is that ADFS federation proxies must be used to allow clients to connect from outside the corporate network. Also, Microsoft recommends multiple servers in the ADFS configuration making up what’s referred to as an ADFS farm. As a best practice, Microsoft also recommends publishing the ADFS 2.0 infrastructure to the internet using Unified Access Gateway. Due to testing limitations, this author was not able to validate this configuration but would definitely recommend it in a production environment.
Figure 2: On-premises / Office 365 identity exchange via ADFS.
ADFS is a very flexible tool capable of extending authentication and authorization services to other applications or between two different organizations; it’s integrated into Windows Server, so the price is certainly right. If you’re looking to easily extend AD outside of your environment and want to reduce account administration hassles while providing claims-aware federation, definitely consider ADFS as part of the solution. If you’re transitioning to Office 365 as an organization, ADFS is almost a required component – it’s best to learn it now and be proactive with an implementation that’s ready to go when you are.