Azure AD and the Progression of Microsoft Identity and Access Management

Defining Microsoft IDAM

The words ‘Identity and Access Management’ (IDAM) mean different things to different people – and a lot of confusion still reigns about what this area represents to an IT department. However, it’s generally agreed that a good corporate IDAM policy can drive down cost, increase security and provide significant user experience benefits to approved applications as they are introduced to an IT environment.

These improvements can broadly be categorised into the following areas:

• Single Sign On (usually abbreviated to ‘SSO’) – a user provides a single factor (99% of the time a password) and gets access to not just one application but a suite of applications after authenticating once without being prompted again for credentials.

• Same Sign On – a user provides the same single factor or credentials for each application they require access to. Generally a user gets prompted to authenticate multiple times as they login to each application individually (usually once per session).

• Account provisioning – an automated system that creates an account in an application with the appropriate permissions and access to perform a job function. Important for new job starters to get access quickly to applications upon joining that company or public service.

• Account deprovisioning – a system that removes an account quickly upon an event usually when an employee resigns from a company. This is especially important for security reasons as the majority of systems are ‘hacked’ by ex-employees. This will also be increasingly important as applications become ‘a per user, per month’ charging model as companies will seek to reclaim unused monthly licenses.

• Single Point of Truth (sometimes referred to as ‘SPOT’) – a reference to identity data quality being sourced from only systems that contain authoritative identity data. Identity data quality issues can cause significant problems in downstream systems. E.g. an incorrect phone number in Active Directory can prevent Lync’s ‘click to dial’ reaching that person’s phone. Sourcing identity data from the correct systems (e.g. sourcing a person’s email address from Exchange) ensures that the most correct, up to date data is always used.

Working with mostly Microsoft products over the last 10 years, there’s one IDAM experience that we’ve generally taken for granted – User Single Sign On (SSO) to Microsoft ‘on-premise’ products such as SharePoint, Exchange, Lync, file servers and print servers hosted on Windows Servers. In the Microsoft world, over time Single Sign On was achieved (and then forgotten about) using domain joined Windows workstations – once a user supplies their single factor to a workstation (usually username and password but sometimes smart card), that user generally wasn’t prompted for any more credentials after that initial login to any Active Directory integrated application. Companies that don’t use domain joined Windows workstations generally receive a Same Sign On experience, provided they access only Active Directory integrated applications.

As cloud services including Infrastructure as a Service (IaaS) and Software as a Service (Saas) become increasingly appealing to business in terms of functionality and cost savings, the on-premise Active Directory will quickly have to adapt to the requirements of applications living across multiple networks and operated from different providers. By not designing the associated IDAM components of a move to either Iaas or SaaS, situations may occur where users complain about having to remember yet a new identity and password to access existing or new services and drive up helpdesk costs (or end user frustration and the negative perception of an IT department). Many users may question why there is even an IT department if a company becomes exclusively SaaS application integrated and enforce a BYOD device policy.

SaaS applications will themselves will increasingly be judged for ease of use in terms of IDAM and its becoming increasingly important for SaaS vendors to ensure their applications work seamlessly ‘side by side’ with on-premise applications using both Windows workstations and BYOD devices (tablets, phones etc.).

Office 365 (April 2013) and IDAM
As of 16th April, Office 365 currently only supports two access scenarios: ‘Cloud Identity’ and ‘Federated Identity’. Kloud have worked with customers that have chosen to support one or the other access scenario, and for the most part, a Federated Identity is chosen as it centralizes a users identity to use their existing AD DS account and password, streamlining the initial takeup of the services. Other companies have chosen instead a ‘Cloud Identity’ model where they are given a new MS O365 account (with a secondary UPN of: @on.microsoftonline.com), however their passwords are ‘pushed’ from their on-premise directory (e.g. Microsoft AD DS but could be other directories like Novell or 3rd party LDAP) to Office 365. Some mature IDAM customers use a Cloud Identity strategy as it works more seamlessly with on-premise SSO or provisioning technologies such as Microsoft FIM, IBM TIM/TAM or Oracle Identity products.

Microsoft (as a SaaS provider) save companies costs in the IDAM categories listed above in the following ways using a Federated model of access:

• Same Sign On and/or Single Sign On  – a user provides the same password (and username in the form of an email address or ‘UPN ‘value’ such as me@mycompany.com) when they open Outlook, Lync or SharePoint applications after logging into their clients. Microsoft originally supported ‘Single Sign On’ for ‘thick’ applications like Outlook from but has since removed this from the current Office 365 wave. All devices (Apple O/s or Microsoft) will get a Same Sign On experience to thick clients. Single Sign On is achieved to web applications for all clients using SAML cookies. This is achieved using a combination of Microsoft Federation Services (ADFS) which resides on a companies’ on-premise network, and the use of the Microsoft DirSync tool to get an account linked to the Azure Active Directory using an attribute called ‘immutable ID’.

• Account provisioning  – Office 365 provisions accounts in two actions: A user’s identity is copied to the Office 365 directory (most likely Azure Active Directory) using Microsoft DirSync (an ‘on-premise’ synchronisation server). The second action is when an Office 365 admin then activates the license against that account using the Office 365 Portal or a PowerShell script.

• Account deprovisioning  – An Admin generally removes a license from an activated user using the Office 365 admin portal or through a PowerShell script. Office 365 generally doesn’t delete an account from its directory immediately when a user’s license is removed. Office 365 flags that account to be removed in 90 days from Exchange, SharePoint and Lync systems. Email is archived after 90 days. Microsoft will also provide copies of data (such as email PST files) upon request.

• Single Point of Truth (sometimes referred to as ‘SPOT’) – Microsoft doesn’t solve any challenges of having internal systems have the correct identity data (first name & last name spelling, correct phone numbers). Microsoft DirSync will copy any identity information from its on-premise Active Directory straight to the Office 365 directory without modification. Its expected on-premise Active Directory admins will keep any identity data correct with the required
information.

Kloud understands there are roadmaps to include future access scenarios for Office 365 incorporating potentially direct Azure AD account access to Office 365 services (without requiring an Office 365 account) however Microsoft have yet to publicly release what this looks like for the next wave of Office 365 services. This may include password synchronisation from Azure AD and/or on-premise AD DS services or Azure AD Federated identity access, however the architecture of this new type of access is currently unknown.

Moving IDAM to the ‘Cloud’
Last week, Microsoft have announced that Active Directory will now be available to its customers in the cloud in the form of Azure Active Directory for Azure customers. This could be defined almost as a ‘Directory Platform as a Service’ (Paas) and a way to join multiple Azure hosted Software as a Service (SaaS) applications to use a common set of access credentials from an end-user perspective (and behind the scenes, admins use a common area to control access to a set of applications to those users). Azure AD could help Azure IaaS customers as well use a common set of Azure hosted ‘service account credentials’ to join multiple Azure VMs for server to server communications e.g. using a IIS Azure server talking to a SQL Azure server using an Azure AD service account.

Additionally, Microsoft and the Connect website have announced a ‘feature addition’ of a brand new Azure IDAM solution that can solve the business challenges mentioned above such as SSO, Federation services and provisioning. Microsoft have stated that this new Azure IDAM solution will be able to provision accounts to ‘third-party SaaS providers’ which is interesting as its really the first ‘Cloud provided’ IDAM solution from a tier 1 vendor to state they can provision from a Cloud provided PaaS directory to a third party SaaS provider. What this architecture is and how it works is currently unknown however but Microsoft are requesting testers from Microsoft Partners so I’m sure new information about this new Azure IDAM solution will come to light shortly.

What about 3rd Party Identity Providers?
According to the RCPMag website, there are a number of IDAM solution providers currently jockeying to fix companies IDAM issues as they move their services to SaaS, PaaS and IaaS providers.
This article can be found here and is an interesting read as to the current state of play outside of Tier 1 vendor provided solutions:
http://rcpmag.com/articles/2013/01/01/the-cloud-migration-of-active-directory.aspx

Authentication Mechanisms (NTLM to Kerberos to Claims)
Generally to achieve Single Sign On or Same Sign On – it’s been accepted over the years for many companies who Microsoft is a key vendor to use NTLM authentication type against an on-premise Active Directory. Microsoft achieved better security and stability by using Kerberos authentication to an on-premise Active Directory. Essentially though not much has changed, Microsoft have generally achieved SSO (or Same Sign On for BYOD devices) using NTLM or Kerberos for the past 10 years.
However, Microsoft is increasingly porting all their applications (e.g. all of their Office 365 web applications) to use Federation aware protocols such as SAML and WS-Federation (both passive and active protocols) which allows on-premise Active Directory account holders to use their current on-premise AD DS passwords to access these new SaaS applications (or on-premise SAML applications such as on-premise SharePoint).
Generally, this is fine for applications created after the year 2010 – such as Google Apps which is natively SAML aware. However, for legacy applications that use NTLM and Kerberos which will eventually be ported to IaaS providers, there is still a requirement to use an Active Directory account. IaaS providers (Azure and Amazon Web Services) allow a site-to-site network VPN connection to the IaaS backend network to access an IaaS hosted or still on-premise Active Directory for authentication.

Wait, haven’t Microsoft tried to do this with Passport and Live Accounts?
It’s true – Microsoft did originally have a goal of a ‘single identity’ to access all of its services and for the most part it worked fairly well for a lot of websites such as Hotmail, and Microsoft’s Partner Portal, both of which are still live today and integrate now with ‘@Outlook.com’ addresses. It’s generally agreed though the ‘identities’ behind this service were owned by us private people (read not employees of a company). While the service supported private people accessing private data, it never integrated with corporate identity systems or data and therefore people generally used Live accounts to keep Microsoft websites up to date with systems they signed up to personally. Microsoft have incorporated the use of ‘@Outlook.com’ addresses for ‘workgroup’ Windows 8 machines allowing self-service password reset services where previously your account was only stored locally on a workgroup machine on Windows 7 and earlier (and you risked being locked out of it if you forgot the local account password!).
In my experience, where the lines were (and continue to be blurred) is when you use your personal Live account to update your personal information in a Microsoft Partner portal which was then tied to your companies’ Microsoft accreditation. Communicating these types of access and identity scenarios to a companies’ user base is becoming increasingly complicated.

Conclusion – Where should I plan for my identities to live?
So with both 3rd party IaaS and SaaS providers jockeying to support increasingly SAML aware applications, the key IDAM architectural decision IT departments will have to make be how to support, as a minimum, authentication to these applications. Many IT departments may choose not to support Single or Same Sign On or automated provisioning (they really should though!), but our advice to customers looking to move to IaaS or SaaS providers is to consider the relative options with IDAM so a conscious decision is made and documented prior to vendors being signed up. Often its very hard to retrospectively introduce SSO or automated provisioning technologies AFTER users are issued with brand new usernames and passwords.

Customers that invest in Azure IaaS (and develop SaaS applications for third parties) will most likely choose an Azure Active Directory service to achieve a Same Sign On to multiple applications hosted on that service. The choice will be theirs then to mature their IDAM and opt in for the new Azure IDAM solution when it is released, or keep the use of Azure AD accounts simple to just support basic authentication services for users and administrators for Microsoft cloud services. Not every Office 365 customer will be an Azure customer and not every Azure customer will be an Office 365 customer, so Microsoft will support one or the other and both. Microsoft will ensure though that customers that sign up to both Office 365 and Azure AD will start to realise cost savings in the IDAM space.

Australian customers that initially invest in either Amazon Web Services or Azure IaaS (the two major vendors currently with the most market share), but still have a mix of legacy applications will at this stage choose to hedge their bets by placing a domain controller or two in their chosen IaaS provider but keep a couple of critical servers and services (such as ADFS servers and Certificate Authorities) in their on-premise network until the solution space becomes clearer. Exclusively Azure IaaS customers that have an existing on-premise AD DS service with a large user base will then analyse the requirements and cost savings of moving users out of that existing AD forest and into Azure AD for accessing both Azure VMs and rapidly evolving Microsoft hosted SaaS services such as Office 365.

Some companies we’ve talked to have even gotten to a point of not even signing up to a directory service (on-premise or hosted) and have usernames and password managed exclusively by clients or ‘reset my password’ links provided by SaaS vendors (however not all SaaS vendors provide this service). Some companies even view a company managed directory service (on-premise or Cloud service) as a point of failure for accessing applications (a mistake in my opinion). I know of one blue chip company who shall remain nameless that use scripts to manage over 80,000 user accounts directly with a SaaS provider and expect their users to use ‘password reset’ services in case a password is lost.

Over time, the picture will become clearer as Azure Active Directory is developed, Office 365 supports newer models of access and the market place reacts and new solutions emerges. Many vendors (such as Apple, Google and smaller identity only providers like ‘Okta’) may choose to become more aggressive in selling their SAML aware identity products. The fight even might come down to simple ‘trust’ as to who you choose to be your identity provider for Microsoft integrated applications.