Guest Post - Francesco Cipollone

One of the things we're keen to do here is to share lessons learned by those who are actively implementing cloud services.  As such, I'm pleased to offer the opportunity to contribute guest articles sharing cloud security war stories to this blog. 

 Our first guest author is Francesco Cippolone of NSC42 who has kindly taken the time to write up a number of thoughts relating to identity on the Office 365 platform.  His article can be found below - thanks Francesco!

Let me start by saying that by no means am I a pure authentication expert nor a Microsoft expert. As many of you, I'm 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 lead 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; nonetheless with GDPR around the corner (May 2018) this topic is quite important.

I've done a bit of research but I haven't found a comprehensive article on the identities, where they are stored, how they are used etc. and so I've decided to put something together myself.  

In this small article, I will use interchangeably 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 from 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 365SSO – 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, but outdated, choosing O365 sign-in method (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 Azure Active Directory service (commonly referred to as AAD). Using AAD implies the creation of additional accounts inside the Microsoft cloud, however there are different methodologies with different implications. 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 synchronization 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 centralized 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 this option does not require an on premises server and could be ideal for 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 of creating 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.

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 of the on-premises identity information is replicated in the cloud (and which cloud region) and this should inform the wider decision-making process with respect to your identity model.

Figure 1 - Synchronised Identities Architecture

• In the Synchronised Identity case the controlling account resides in the cloud identity store (AAD in this specific case). The password hash of the two accounts (on-prem and AAD) is synchronised, along with other account attributes but there are two separate accounts with shared attributes. The accounts link is subject to the settings of AD Connect and AAD. It is possible to refine items like password reset and other similar settings.

Figure 2 - Federation Architecture Sketch

• In the Federated Identities case the controlling account resides on the Controlling Identity Store (Usually Active Directory), usually referred to as an Identity Provider or IdP in federated scenarios. Once a user authenticates against one of the cloud portals the request of authentication is forwarded to the IdP (Identity Provider). Hence the AAD and the authentication portal acts only as a front-end facing the user. This method also facilitates the use and re-use of on-premises security methodology like strong authentication, password policy driven by AD GPO, auditing. Moreover, the password hashes and the identities are not stored in the cloud provider – the cloud provider trusts the on-premises IdP.

• In the Isolated identity case the authentication process for On-Prem and cloud (Azure/Office 365) is completely separate.

Deployment Components:

• AD - Active Directory

• ADDC - Active Directory Domain Controllers

• ADFS - Active Directory Federation Services

• WAP - Web Application Proxy (optional component for frontend Sign On – for more info refer to Hybrid Identity Requirements)

Decide where do you want to deploy your components

• Azure/Other cloud provider Deployment

• On-Prem Deployment

Note: The recommendation from Microsoft is to deploy ADFS Servers as close as possible to the Domain Controllers

Note2: the number of TCP ports needed to be opened between the ADFS servers and the AD controllers is quite substantial. Consider, if your architecture pattern and security policy allows them, deploying the AD and ADFS in the same zone (minimum filtering between the two systems) so as not to punch a lot of holes in your firewalls.

Application Proxy Location:

The communication between the user web requests and the backend authentication is normally handled by the WAP, while "internal" requests (coming from trusted networks if you still rely on that concept) will go directly to the ADFS servers.

Below there is a deployment example followed by the authentication flow. For a full list of ports and component refer to Hybrid Identity Requirements.

Figure 3 – Federation Detailed Architecture

Figure 4 - Federation Authentication Flow

.

Additional Option - Multi Factor Authentication

Figure 5 - MFA Architecture

In addition to the methods described in the earlier section there is an additional security component that could be added to the picture – Multifactor Authentication (MFA).

The idea behind multifactor authentication is to have a physical item required as part of the authentication (for more information on multi factor authentication refer to Multi-factor authentication Wikipedia article).  

The multifactor authentication token comes in different shape and forms:

• As an SMS to the selected phone (note they tend to be a bit delayed)

• As a call to the selected phone

• As a one-time password/token generator application installed on a device  

Personal Note - I’ve found the token generator application to be the most reliable as it does work without signal.

Multifactor authentication creates an additional challenge to a potential attacker as it requires additional effort to get hold of the physical device (or the token value for the particular moment) providing the second factor.

Recent attacks, such as the reported compromise of the Deloitte e-mail service, have shown that single-factor authentication could be “easily” compromised. I’ve specifically used “easily” with quotation marks (“) as it all comes down to how much an Organization protects privileged identities and the configurations they choose to deploy.  In general, top-level accounts should be used for initial configuration purposes only and then locked away with day to day administration activities using less privileged accounts.  

MFA can be deployed for various applications:

• To strengthen Office 365 user authentication (refer to configuring MFA authentication article)

• To strengthen the Azure portal admin authentication (refer to configuring Azure MFA authentication article) – this is strongly recommended!

• To strengthen other application authentication (e.g. VPN services, refer to Advanced VPN Configuration with MFA)

Please note that the Azure Active Directory MFA (also referred as full-MFA) comes with Azure Active Directory Premium plans. In order to identify the various versions of MFA, and select which one is most applicable to the specific situation, refer to MFA plans.

Pitfalls

Below is a list of a few key points that I've noted in cloud migration projects and that, hopefully, might help you avoid the same issues:

• Simplicity vs adoption: Usually synchronisation (AD-Connect) is easier to implement than Federation/SSO (ADFS) but it requires the user to authenticate two times: once on the laptop, and another time on the o365 portals. This usually makes cloud adoption harder for an enterprise due to a sub-optimal user experience.

• Additional Component: The organization will need an additional infrastructure component, e.g. ADFS or equivalent, whether it decides to use the AD-Connect or Federation methods described above.

• Identity Resilience and Federation/Synchronisation readiness: Both ADFS and AD-Connect come as software components. If not planned carefully those two pieces of software might fail (causing an outage) or receive an overwhelming number of unplanned requests (legitimate or DDoS).

• Identification of Identity Stores: In an enterprise, identity could span across several different systems. If identity is not consolidated as much as is needed, the process of integration between the cloud Identity and Access Management (IAM) systems and the on-prem environment might result in a little nightmare of delays. Definitely better to have a single authoritative source of identity to build from.

• Use of Multi Factor Authentication (in short MFA): Depending on the enterprise security policy, strong authentication might be required. If not considered carefully this might result in a painful step. Despite the fact that Microsoft MFA Services works quite well in the basic scenario, it is  harderis harder to implement in traditional enterprise scenarios.

MFA authentication requires additional application integration that not always works with legacy software.

One example is the configuration of office clients (specifically outlook) versions prior 2016. The MFA does not talk nicely with any office client version prior 2016 that do not support modern authentication (the named component for the MFA PaaS service and office suite).

Other challenges to MFA relies on the end user and the changes in the user experience (additional step required to access resources), e.g.  with Bring Your Own Device (BYOD) the mail synchronisation usually relies on Active Sync; this component tends to conflict with the MFA.

• ADFS only works with AD: if the organisation utilises an identity store that is different from AD this might add another layer of complexity due to the need to integrate different technology components, e.g. implement a specific federation tool such as Ping to act as an intermediary.

• Adapt to Microsoft changes: AAD is a PaaS service and new features are introduced regularly. Failure to plan for them might result in being forced to adapt later (e.g. the use of classic portal vs the new Azure portal (ASM vs ARM))

• AAD is not AD: AAD has a lot of features, and Microsoft is constantly adding new ones but fundamentally AAD is not a full blown Active Directory. To summarize the key differences AD is a directory service (with structures and capabilities like OUs, GPOs, domain join, etc…) while AAD is an identity solution (stores and authenticate users). A full-blown comparison between the two directory services is outside the scope of this article (for a quick overview refer to this article) but just to cite few major points:

• AAD still lacks a modern and flexible way to manage Group Policies.

• AAD has a flat OU Structure.

• AAD is in the cloud and has different authentication methods and as such does not support methods such as Kerberos or NTLM

• Plan ahead with respect to which security features to use: Azure offers some security features that could be used in conjunction with, or to enhance, the existing security controls applied to IAM systems such as:

• MFA: authentication of users by multiple methods

• AAD Identity Protection: allows to identify vulnerable accounts (for more information refer to https://docs.microsoft.com/en-us/azure/active-directory/active-directory-identityprotection)

• OMS/Security Centre: allows you to monitor and log incidents as well as identify potential tampering (the Security centre correlation feature is a premium service)

• Windows Hello

• Windows OS Base: please note that certain features (like windows hello) work from Windows 10 onward

• Using Cloud extends the IAM perimeter: with the introduction of O365 and the AAD component the IAM perimeter is extended to the cloud and is partially outside of the company's control as AAD is a PaaS service.

Take Aways

A good planning phase is always required before moving into any kind of project (IT or other discipline).

Together with a plan it is good to have a short and long-term strategy. Some elements to consider are:

• Understand the business context and how to align the identity strategy with the overall business strategy

• Understand the key requirements from internal policy and align the AD/AAD services to the security strategy

• Identify the geographical and regulatory restrictions that apply to your business

• How will GDPR impact the AAD (not a comprehensive list):

• Geographical constraint

• Response to SAR (subject access request)

• How to track and tackle the sprawl of Identity repositories

• What flavour of AD/AAD will be used in 1/2/5 years

• What operating system base is going to be used in 1/2/5 years

• What federation/SSO system is going to be used in 1/2/5 years?

• Will you want to re-use your identities on other, non-Microsoft, cloud platforms?