Microsoft Cloud – Azure AD: doing it right

by greg.spyra

Introduction

Recently Microsoft introduced a fully cloud-based product suite called Microsoft Office 365. Approximately at the same time other team of MS engineers delivered other, also cloud-based suite called Microsoft Azure. While MS O365 incorporates legacy flag products (i.e. MS Office, MS Exchange, MS RMS, MS Lync and SharePoint) used by most large enterprises, the Azure suite delivers more back-end services (i.e. MS SQL, Visual Studio, MS Active Directory, AIP – old SecureIslands and other) also previously used on-premises by many large enterprises. To manage access over this new cloud-based suite some of the products still leverage Microsoft Live ID, however all of the products use strategic solution called Azure Active Directory (AAD).

On-premises to Cloud with a single step

To simplify cloud on-boarding Microsoft ships a free tool called MS Azure Active Directory Connect (AAD Connect), previously called DirSync. Considering fact organizations integrated for access management with Microsoft Active Directory Domain Services (MS AD DS) would like to immediately start using cloud services, AADConnect is a tool that quickly make a copy of legacy AD and maintains this copy in the cloud respecting ongoing AD changes. Business considering move from legacy environment could be ensured about easiness of the migration process as well as stable coexistence possibilities (hybrid scenario) of both environments.

Id-Centric Identity Management

To illustrate how the MS off-the-shelf solution works one has to look at place of Identity and Access Management (IAM) in an organization. IAM system should translate business settings for technical systems. It should reduce a custom technical configuration for an employee during joiner and leaver process or during technical target system on-boarding (e.g. Linux server or O365). IAM program aims to reduce individual technical support per employee as well as provides global unified access management that could support Single Sign-On and other modern authentication methods.

id-centric_identitymanagement

Figure 1. Id-Centric Identity Management

Considering fact that business processes should be at the beginning of any technical access provisioning, the IAM translates business processes and enforces access management in target systems context. Mature centralized Identity and Access Management highly reduces complexity of provisioning processes that exist in many organizations since late 80′.

From perspective of identity provisioning and enablement after human resources (HR) officer submits new employee on-boarding form, the process triggers IAM to provision required identities in technical target systems (e.g. MS AD DS or MS AAD) and enable access for these employees across respective target systems (e.g. O365 license assignment, Enterprise Administrative role, etc). This process is transparent for HR, however is fully employee data driven.

Process of MS Cloud identity lifecycle should look as following:

  • HR registers a new employee
  • IAM system provisions cloud MS AAD account for the new employee
  • IAM system assigns correct O365 (other) licenses

Microsoft customers who already use Microsoft Identity Manager (MIM) as a central IAM system, can fully benefit from this architecture as MIM synchronizes directly with cloud using internal meta-directory and dedicated instance of a DirSync connector. All the customers who decided to use non-Microsoft IAM system have a possibility to leverage Microsoft Active Directory and a free AADConnect tool to move into cloud as an off-the-shelf approach. This approach have obvious advantageous, however to find its weak sides company architects and engineers should be prepared for an in-deep research.

Account-Centric Identity Management

The model proposed by Microsoft to ease the cloud enablement via AADConnect decentralized identity provisioning and shifted the responsibility from IAM system to MS Active Directory (MS AD). True is that in early directory implementations MS AD and LDAP kept employee information together with technical identity information. Furthermore many companies leveraged these directories as a central identity repository or an address book. Problem arose when technical infrastructures grew and business processes became distant from systems that ought to simplify enterprise management. Nowadays there is a clear line between Identity and Access Management and directories like MS AD.

MS AD is extremely efficient as a database for technical identities, however there is still loads of information that is relevant only for legacy systems and information that from data protection perspective should not leave the organizational boundaries just to simplify a cloud migration.

MS on-premises to cloud-enabler solution actually anchors to technical directory (i.e. MS AD DS) and synchronizes all information into the cloud. Functionally all existing accounts are automatically re-provisioned in MS Azure Active Directory with a technical legacy anchor and after correct license assignment employee could start using MS Cloud services (i.e. O365, etc), however the fully managed and controlled IAM architecture is lost (see Figure 2).

account-centric_identitymanagement

Figure 2. Account-Centric Identity Management

Process of identity lifecycle and MS Cloud enablement using AADConnect is following:

  • HR registers a new employee
  • IAM system provisions MS Active Directory account for the new employee
  • IAM system starts checking every n minutes if cloud MS AAD account is synched
  • MS AADConnect within t time synchronizes new account into cloud MS AAD
  • IAM system finds new MS AAD account and assigns correct O365 (other) license

Design Considerations

Identity Management for O365

Microsoft introduced completely new set of APIs to unleash the real power of its new cloud based suite. Complete identity and access management could be handled with Microsoft Azure Graph API. New identity could be provisioned with only required attributes what does align with data protection directives. Identity could be moved to recycle bin at the end of identity-lifecycle process. Engineers may decide to keep the identities after deletion without any identifiable attributes. Account names could be anonymized and renamed to unique GUID known only to IAM system.

To completely remove identities in Azure AD, the neither Microsoft Graph nor Azure Graph APIs  provide complete control over the recycle bin. Currently only MSOL PowerShell Module can automate recycle bin clean up.

Identity could be also provisioned with Microsoft Graph API the second interface that covers not only identity related operations but also O365 suite management.

Claim-based authentication with on-premises MS AD

Cloud services access could be controlled with authentication against an on-premises Microsoft Active Directory. Passwords and other credentials do not have to be stored directly in the cloud, furthermore Graph API could set all the attributes (i.e. immutableId) required for on-premises password verification. By default any authentication proxy, e.g. Microsoft Active Directory Federation Services (MS AD FS) could respond to MS Cloud claim using simple SAML token.

Azure AD and Messaging

From Exchange Online perspective the only attribute that could be controlled via Azure Graph API is a mail address but also not directly. It could be set upon provisioning using mailNickname (Alias) attribute. mailNickname is used to generate a new email address just after Exchange Online license is assigned to Azure AD account.

Azure Graph API and Microsoft Graph API at its current stage do not offer any Exchange Online related support. Although Microsoft Graph API Beta should provide support for proxyAddresses and mail attributes.

Remote PowerShell for Exchange Online opens all the settings that are still not fully available in Graph APIs. Remote PowerShell could be easily integrated into complete solution either with .Net or with Java code. The main and only bottle neck of Remote PoSH is that Microsoft introduced throttling limitation. However with a proper code design all logic could be handled on the core code side and PoSH could be used only at the end to execute simple (CRUD) commands. Each PowerShell pipe is counted towards throttling limitation so simple requests with a shared global Remote Exchange PowerShell session could suffice large number of requests executed within milliseconds after each other.

Worth mentioning that entire Exchange Online forwarding goes through Azure AD rather than dedicated Exchange Online directory partition.

Microsoft Cloud Insights

Microsoft Cloud is a set of products that were previously offered on-premises as a standalone installation. These products maintained own meta-directory for application meta-data using either Microsoft Active Directory (MS AD) or Microsoft Active Directory Lightweight Directory Services (MS AD LDS). Behind Exchange Online or Skype for Business resides fully operational MS AD infrastructure while Microsoft Azure Active Directory (MS AAD) leverages legendary MS AD LDS.  All the directories including Azure Active Directory (MS AAD) are interconnected under Multi-Master model with a quite buggy sync service. Using MS Cloud for a small enterprise this might be a minor issue to consider, however for larger enterprise fact that identity attributes are synced and might remain inconsistent across directories (e.g. ExternalEmailAddress changed in Exchange to a different value than PrimarySmtpAddress is overwritten by sync from Azure AD to mailAddress value; after second try it works) becomes a major problem.

Words from Author

Prior to writing this short post I completed an architectural design and development of Identity and Access Management connector between non-Microsoft IAM system and Microsoft Azure AD, and Exchange Online. Having around 70k employees (internal/external) that will use Microsoft Cloud it was simply impossible to make any compromises reducing quality of existing identity lifecycle processes.  We (my team and I) had a hard time with MS consultants and PFEs. It seemed that in Europe no one wanted to support this architectural approach for cloud enablement and Exchange migration. We spent hours explaining this solution to MS specialists having only one answer, “it’s not going to work!”. After the first successful pilot release we talked to MS developers and engineers behind Azure AD and Graph happy to hear from them that this approach is nothing Microsoft would discourage and that this is a 100% valid approach.

Note, that making the right architectural decision now might be easier as more and more people experience and describe various issues with wrongly chosen design for cloud enablement.

Apendixes

Useful links

Azure AD Graph API reference

Azure AD API Graph Explorer

Microsoft Graph

Calling the Microsoft Graph API

Microsoft Graph API Explorer

Exchange 2016 cmdlets

Documentation for the Microsoft Graph REST API

Advertisements