Azure Active Directory Identities

This post is an introductory post in an upcoming and unfolding series regarding identity management.

Whether for Office 365, Dynamics CRM, Azure, or 3rd party apps, having an understanding of identities in Azure AD is a must have feather to have in your cap.  These different identities require some decisions early on that are rather critical and based on core requirements that should be defined by business and security policies within your organization.  The first thing to understand about Azure AD is that it is NOT a domain controller in the cloud.  In fact, it isn’t operating on Active Directory Domain Services at all.  For approaching 20 years, we have generally used “Active Directory” to mean what is now properly defined as Active Directory Domain Services (AD DS), but that was originally the proper name for the on-premise identity management service from Microsoft.  This changed rather early in Active Directory’s life with the release of Windows Server 2008 as Active Directory became an umbrella for many on-premise services.  With Windows Server 2003, Active Directory Application Mode (ADAM) was released, which was a generic LDAP implementation from Microsoft built off of the same core components of Active Directory, but without many of the adjacent components, like Kerberos, Group Policy, time services, etc.  ADAM became known as Active Directory Lightweight Directory Services (AD LDS) with the release of Windows Server 2008.  Other services include Active Directory Certificate Services (AD CS) and Active Directory Federation Services (AD FS).

Notably, it is AD LDS that is important to us in our understanding of Azure AD because it is the underlying technology upon which Azure AD is built.  Azure AD does not have Kerberos, Group Policy, or time services.  Further, Office 365 and Azure services are not joined to Azure AD; rather, they have their own AD DS forests (and many of them) to which Azure AD objects are synchronized.  One item of note: things in the cloud change like Midwestern weather, if you don’t like it, wait 5 minutes; there is a product that is early in its life known as Azure AD Domain Services, but it is not without many compromises and has a long way to go.

So, why implement Azure AD?  There are numerous reasons and they align with the reasons that organizationed implemented Active Directory in the first place.  The old story was that of consolidating identities in an era when there was plenty of “identity sprawl” on-premise.  We had largely conquered that problem, but it has resurfaced in the cloud era.  Now, we have multiple identities for various cloud services.  Managing multiple identities is a very real problem.  First, IT organizations have to create these numerous identities and manage them for all of their users; it is tedious, error prone, and requires more knowledge of security in each system.  Second, end users have to utilize and recall the identities and credentials for each system; this leads to password reuse, passwords that are too simple, and/or writing passwords down.  These are all bad practices, but if we expect our end users to live in an environment with ever growing lists of identities, we’re asking for it to happen.  While Azure AD is the core identity management platform for Microsoft cloud services, and it is the logical starting point for its implementation, Azure AD is much more than that.  So, here is a list possibilities that is far from conclusive:

1. Office 365: this is the main gateway to Azure AD consumption.  You plan to implement all or some of the services in Office 365 or perhaps even just deploy the Office 365 ProPlus software package for end users.

2. Exchange Online Protection and/or Exchange Online Archiving: perhaps you have an existing message hygeine service and you are looking to replace it with EOP, or you have the special license that gives you EOP and the Exchange Online Archiving feature.

3. Dynamics CRM: Microsoft’s customer relationship management software offered as a service.

4. Azure: Infrastructure as a Service and Platform as a Service offerings from Microsoft.

5. Azure AD Marketplace: over 3000 applications from 3rd parties already integrated for use within Azure AD, including Salesforce, ServiceNow, GoToMeeting, WebEx, Concur, Egencia, and even G Suite (formerly Google Apps) and AWS.

6. Azure AD B2C: develop your own applications that integrate into Azure AD and Microsoft Accounts (consumer accounts).

So, a fairly compelling list, especially considering that it supports competing cloud products.  What are the first things that you need to understand and decide when you have set the path to implement Azure AD?  First and foremost, there are three types of identities in Azure AD: Cloud-only, Managed (or Synchronized), and Federated.

Cloud-only: this is the simplest model to implement and requires absolutely no additional infrastructure.  An administrator logs into Azure AD and creates identities directly in Azure AD.  This is straight forward and easily implemented for smaller organizations, but it only adds another identity and does not consolidate them.  It is prone to all of the same issue we are trying to solve by consolidating identities… administrative overhead, errors, and end user problems with multiple identities.

Managed (or Synchronized): this is the most common identity type in new implementations.  It requires that a single system be deployed with AAD Connect, a free product from Microsoft for synchronizing on-premise identities to Azure AD.  You can synchronize password hashses and have same sign on (not quite the same as single sign on, but offers perhaps 80% of the benefits).  This is a prerequisite for the next type.

Federated: this provides the most robust set of features and requires the most infrastructure.  First, you must implement AAD Connect, then you install a federation infrastructure that is usually 8 systems in a minimal best practice setup that is defined by two locations with separate internet connections using two load balanced proxy servers in each location in front of two load balanced AD FS servers in each location.  The reason for this is that if your federation infrastructure is unavailable, nobody signs into Azure AD.  This price comes with some fairly compelling value for those that require it: Multi-Factor Authentication, real-time accounts disablement, real-time password updates, network location restrictions, time of day restrictions, and true single sign on (SSO).  This was initially the most popular means to implement identities in Azure AD, but over time these requirements have slowly been eroded by capabilities in AAD Connect and Azure AD Premium (which requires an additional subscription).
It is worth noting that there are numerous 3rd parties that offer competing federation solutions for Azure AD.  They have licensing fees and combined account for only 3% of all identities in Azure AD.  For a supportability and simplicity standpoint, it makes sense to implement something that more of a known quantity… you will more readily find administrators that are familiar with the Microsoft offerings and there is a significantly larger body of knowledge available online to support it.  Noteable 3rd party federation providers include: Okta, OneLogin, PingFederate, and Oracle.

Azure AD Premium is a subscription-based offering from Microsoft that offers many of the features available with federated identities without the need for a federation infrastructure, including: Multi-Factor Authentication, network location restrictions, time of day restrictions, and a self-service password reset portal.  Combined with a new feature in AAD Connect called Pass-Thru Authentication (currently in preview), one could have nearly all of the capabilities of a federated infrastructure, including SSO.

The next thing to understand is how users sign in and the surrounding best practices.  The username used in Azure AD is the UserPrincipalName (UPN); it looks like an email address.  Within AD DS, this would be like username@activedirectorydomain.  The first issue here is that many organizations have not aligned their Active Directory domain names with their public domain names, which is a requirement since we are using an internet-based service… you aren’t going to be using a “domain.local” option.  You can rectify this by implementing an Alternate UPN Suffix in Active Directory Domains and Trusts.  The ultimate best practice is to have UPNs match the primary email address of a user, because most users won’t know what a UPN is but they will know what an email address is and Microsoft has labelled the username fields as “email address.”  This is almost never an issue for organizations because UPNs are rarely utilized on-premise.

Before going down the path to implement Azure AD, it is worth executing IdFix, a free utility from Microsoft to identify common issues that should be remediated before installing AAD Connect.  Common issues includes duplicate values within your domain for fields that should be unique and invalid characters.  The tool makes a recommendation on how to remediate and can fix the issue for you, but it is worth reviewing the recommendations and findings and remediating them yourself and then execute the tool again to determine if things have been addressed.