Authentication love story - identity and 0365

Updated: May 30, 2019



Disclaimer: this article was produced by NSC42 Ltd in association for the Cloud Security Alliance for the benefit of sharing knowledge. Please note all the picture used in the article and the material is property of NSC42 Ltd or under licence to NSC42 Ltd.


Now that the formalities are over please enjoy the article


O365 Identity Article


Let me start by saying that by no means am I a pure authentication expert nor a Microsoft expert. As many of you are, I am also on the journey to the cloud and learning as I go.


Please provide any feedback or any contribution to the article so as to make it as accurate as possible.


Identity and Access management with O365/Azure


A few weeks ago, I had a conversation with a colleague about identities in Office 365 and the discussion led to the various nuances of where the identities are located.


I have to admit, with a bit of shame, that in previous transformation projects I haven't much considered this topic but after doing some research I haven't managed to find a comprehensive article on the identities; where they are stored, how they are used etc. So I've decided to put something together myself. 


In this short article, I will interchangeably use the word identity and account.


Acronyms used:

We all hate them but we can’t live without them, for the sake of clarity I’ll list the meaning of the terms that I’m going to use in the article:

·     AAD – Azure Active Directory

·     AD – Microsoft Active Directory

·     AD Connect – Active Directory Connection services

·     ADFS – Active Directory Federation Services

·     B2B/B2C – Azure Directory Service – Business to Business and Business to Consumer

·     EU – European Union

·     EU GDPR – European Union General Data Protection Regulation (enforced since May 2018)

·     DPA/EU-DPD – Data Protection Act 1998 (following EU Data Protection Directive 1995)

·     GP/GPO – AD Group Policy/Group Policy Object

·     IAM – Identity and Access Management

·     IDaaS – IDentity as a Service

·     IdP – Identity Provider

·     MS – Microsoft

·     MFA – Multi Factor Authentication

·     O365 – Office 365

·   SSO – Single Sign On

·     SME – Small and Medium Enterprise

·     SAR – Subject Access Request (GDPR)

·     WAP – Web Application Proxy (for AD)


Accounts in the Microsoft Cloud world


Readers who are not familiar with Identities in Azure/Office 365 should please refer to the article from MS - understanding O365 Identity and the more generic choosing O365 sign-in method (it's a bit outdated but still a good overview of the identity models available when using the Microsoft cloud platform).


 The Azure and Office365 cloud services rely on a backend version of the Azure Active Directory service (commonly referred to as AAD). Using it implies the creation of additional accounts inside the Microsoft cloud, however there are different methodologies with different implications, so let's start with the basic types of identities in O365:


  • Federated Identities (AD+AAD+ADFS) - These kinds of identities are effectively located inside the on-premises identity store (e.g. Microsoft Active Directory). This technology enables the synchronisation of selected attributes of the on-premises directory object (AD accounts and others) with O365 but authentication decisions are made on-premises with the cloud environment trusting the on-premises environment. This kind of identity strategy is often integrated with some kind of Single Sign On (SSO) technology (like ADFS or another third-party tool). This approach keeps password hashes on premises, enables the centralised management of identities (as they are effectively in AD), and facilitates the re-use of existing strong authentication methods as well as traditional security controls (e.g. AD GP/GPO password policy).

  • Synchronised Identities (AD+AAD+AD-Connect) - The identity (accounts) are separate but synchronised, i.e. copied from on-premises into the cloud. The identity used in Office365/Azure is stored in AAD. The identity used on-prem will reside in the identity store used on-prem (usually Active Directory). The identity's password is one of the attributes synchronised with the cloud platform via AD-Connect. Cloud users are required to enter their credentials to access cloud services.

  • Isolated Identities (AD & AAD) - In this specific case there is no link between the identity used on-prem and the identity used in the Microsoft cloud. I've not seen many instances of this approach and usually it is a corner case. Nonetheless his option does not require an on premises server and could be ideal for an SME or start-up.

  • Special Cases B2B and B2C – The Microsoft AAD service has some additional aid to provide to applications developed in Azure (e.g. using Azure Web Service PaaS) an underlying Identity Database that could contain the Company Identities as well as external customers identities. Those special instances of AAD allow the creation/federation of external accounts in the AAD but without the need to create the account on the underlying AD. This method allows the isolation of the customer accounts in AAD and aids in the reduction of potential customer oriented regulation (like GDPR or DPA). The main difference between the B2B and B2C is that the first allows federation of the AAD with external customers while the latter allows the creation of accounts without the need of federation and with some more freedom on the username (for a comparison between B2B and B2C refer to: B2B compared to B2C). The B2C - Business to Consumer - is more oriented to consumer application where a user would want to just create an account with his e-mail address as username and does not require any federation (for more information on B2C refer to: B2C Overview). The B2B – Business to Business - instead is more oriented to Business to Business, as the name implies, type of interaction; it allows the federation between the AAD and another Directory (for more information on B2B refer to: B2B Overview). The B2B and B2C are outside the scope of this article, I’ve inserted an overview here for completeness.  

Identity location:


In each of the cases above, the identity information is stored in different locations. With geographical regulation (e.g. GDPR) the actual location and control of an account is important and with use of cloud services the identity information could end up spreading across multiple locations (on-premises and Azure AD).


For this reason, it is important to choose your preferred identity option in conjunction with a review of the key regulatory factors linked to data protection, including GDPR. An example of a factor to keep in consideration when choosing your approach could be the geo-restriction on where the identity information is stored/processed as it may be classed as personal data.


One example of a breach of identity-related personal information could be the use of an identity store for European identities located outside the EEA region (for example in America). This example highlights the fact that the chosen identity model will determine how much