How to Expand Identity Beyond Your Environment
One of the most important decisions an organization will make after deciding to embrace cloud technologies is how to manage the multitude of identities needed. This may mean consolidation of directories, migration of directories or building a greenfield environment for specific identities.
Before we talk about the complexities, let’s talk about the needs.
Taking a trip back down memory lane, in years past we had (in many cases) a single directory – this meant applications installed on-premise would easily tie back into this directory. Fast forward a few years and we first start to see some enterprise-grade cloud apps, or Software-As-A-Service (SaaS) applications. Each of these would require an administrator to upload an import list of usernames and the software would generate an export of passwords or individually email the users their passwords. This was great, but meant that as organizations faced a growing number of SaaS applications, the more of an administrative nightmare it became for IT staff.
This lead to several SaaS application vendors allowing synchronization of directories and passwords. While this meant the end users could be onboarded faster and passwords and changes were updated in near real-time, administrators had to learn multiple directory types, navigate the synchronization application or engine configuration, and manage each one. So, while you still have a single directory as the source of authority, you have multiple engines syncing and an ever-growing landscape of identity synchronization infrastructure.
For example, both Office 365 and Google Apps are commonly deployed in some development organizations and education facilities. Previously, when you had both applications, a common configuration was to install the Google Active Directory Synchronization Engine (Active Directory to Google) as well as on a different server (due to application dependency issues) to install the Office 365 Directory Synchronization engine (Active Directory to Office 365).
Newer features now offer the ability to manage this identity from a single directory. There are several options for reducing the complexity and required infrastructure, but before we dive into the architecture of such, let’s define identity.
An Identity can be made up of an entity, such as a person or object, which is tied to an identity, such as a user account/username, which has specific attributes. An entity may have a single identity or multiple identities. Each identity will have attributes, such as First Name, Last Name, Type, Username, etc. Some of these attributes may have required or unique attributes across all of the directories.
Now that we now what an identity is, we can understand that an identity also grants access to specific resources, such as SaaS applications. This is very familiar to any organization running Active Directory. User accounts are created within the directory and contain attribute values.
Ok, back to today. We need to understand how to feed from our existing directories into our new SaaS applications. What’s wrong with the approach of having a unique directory synchronization engine for each SaaS application, you ask? Well, nothing – if you want to continue to add infrastructure, manage the infrastructure required for each of those, and keep up with patch management. However, there are also valid reasons you may need to have multiple engines – these could be for anything from configuration-specific changes in the synchronization engine or restrictions with the specific SaaS application.
In order to take advantage of the feature-rich components of Office 365’s underlying identity, Azure Active Directory, a single directory can be fed into Office 365 via the free toolset, ADConnect. This toolset lets an organization synchronize not only to Office 365, but in some scenarios, back on-premise from Office 365. To get started, we will dive into a few identity options:
Method One: On-premise Active Directory to Azure Active Directory
This is one of the most common types of synchronization. This uses ADConnect, a free tool from Microsoft, to synchronize your Active Directory into Office 365.
Method Two: Multiple Active Directory to Azure Active Directory
There are several ways to accomplish this – the simplest is installing multiple ADConnect (one per domain or forest) to synchronize these directories to a single tenant.
Method Three: Selective Active Directory to Azure Active Directory
It is very common for an organization to only need to synchronize specific content, like a specific domain (but not all domains) within Active Directory, a specific set of Organizational Units or even specific attributes within the directory. Again, this can be easily completed with the ADConnect tool.
Method Four: Non-Synchronized Active Directory
Office 365 supports the ability to create identities directly within the platform without the need for an identity to be synchronized. It also supports the ability to have some identities synchronized while others are not. This feature is often used for administrative, vendor or temporary accounts, or accounts that do not need to follow the standardized onboarding or on-premise workflow.
Method Five: Non-Active Directory to Azure Active Directory
There are many directory systems outside of Active Directory that you may be running. examples may be a student information system, a human resource information system, Novell, open source, etc. These directories can be synchronized through tools and connectors available as part of the Microsoft Identity Manager Suite.
Technologies to support the synchronization
Several technologies support the capabilities to synchronize these identities. We’ve previously discussed two Microsoft technologies – ADConnect and Microsoft Identity Manager.
Additionally, Microsoft includes Graph API, a platform for adding, deleting, updating, and changing accounts, which can be leveraged by an organization to extend their existing Identity Management automation or workflow. Outside of the Graph API, Microsoft offers several PowerShell commandlets to support the same adding, deleting, updating, and changing of accounts. These do not provide synchronization, but rather the ability to create non-synchronized accounts, referred to as “In-Cloud” accounts.
Third parties also can leverage these same technologies to deliver identity creation in Office 365. Those each would have their own support methods, and may require additional infrastructure and could potentially cause additional points of failure.
Synchronizing with Azure Active Directory
SaaS applications may allow synchronization directly to their applications, but if you were to use each SaaS application’s synchronization engine (ie: ADConnect for Office 365, GADS for GSuite Synch), you could end up with a complex web of synchronizations. When performing updates to users, you’re making changes in several places. This also makes offboarding users significantly more complicated when you have multiple engines to check.
Identity Sync Best Practice
Since Office 365 utilizes Azure Active Directory, we recommend synchronizing all of your data to Azure Active Directory and re-using that identity for multiple uses. Leveraging Azure Active Directory allows for simplified end user management and support.