Identity and access control

Up until now, we have focused on the assessment and business justification side of your cloud migration projects, primarily from an application and data solutions perspective, but another important aspect to discuss is how you manage your identity and access control in the cloud. This is important for both end users and administrators.

Identity is the core component of all Azure cloud security: whenever any administrator wants to "do" something in the Azure platform, they need to authenticate and get authorization. No matter whether they are using the Azure portal, Azure command-line tools such as PowerShell or the Azure CLI, or using REST APIs. End users can also greatly benefit from Azure Active Directory. Solutions such as self-service password reset, Azure AD domain join for device management, conditional access, user risk, and many more will heavily optimize how users log on to cloud applications and how secure this log on is.

Azure Active Directory as a cloud identity solution

From an identity perspective, there is no way around Azure Active Directory. This cloud identity solution comes in different flavors:

• Azure Active Directory: The core identity component in Azure, offering cloud users, groups, applications, and service principal objects
• Azure Active Directory Domain Services: An emulated Active Directory service, offering Kerberos and NTLM, similar to your on-premises Active Directory domain controllers
• Azure Active Directory B2B: Business-to-business concept, whereby organizations can invite users from each other's Azure AD tenant
• Azure Active Directory B2C: Business-to-consumer concept, whereby organizations allow user authentication from social media identity providers (such as Facebook, Twitter, LinkedIn, and so on)

Besides the different flavors mentioned here, Azure Active Directory itself also comes in different editions:

Table 1: Azure Active Directory tiers

Just based on the rich feature set and advanced security features that come with it, any organization should consider Azure AD Premium P1 for most of their cloud-enabled users, extended with Azure AD Premium P2 for key users such as C-level management, administrators, security officers, and other key persons within the organization with high visibility.

Cloud authentication with Azure Active Directory

Most organizations already have an identity solution in place in their on-premises datacenter, often being Microsoft Active Directory. In this scenario, the recommended topology would be building out a hybrid identity architecture, starting from your Active Directory source environment. Azure AD Connect synchronizes the user and group objects (all or select ones based on filters you define). As such, a user account with the User Principal Name (UPN) peter@company.com from the on-premises Active Directory will authenticate with the same alias in Azure Active Directory.

However, there are three distinct authentication scenarios:

• Azure AD Password Hash Sync (PHS)
• Azure AD Federation using ADFS or third-party federation (ADFS)
• Azure AD Pass-through Authentication (PTA)

The easiest (and most recommended) approach is Azure AD PTA. In this scenario, your Active Directory objects are synchronized to Azure AD using AD Connect, including the domain's password hash. This allows users to log on to cloud apps using their Azure AD credentials, which are identical to the on-premises credentials.

Unfortunately, storing passwords (or the password hash) is a no-go for a lot of organizations, who want to keep control of the credentials from an on-premises perspective. In this scenario, you need to deploy a federation infrastructure, which can be Active Directory Federation Service (ADFS) or a non-Microsoft alternative (Okta is a popular one). While you still need to synchronize AD objects to Azure AD, the password is never stored in the cloud directory. Upon user authentication, Azure AD forwards the request to the ADFS infrastructure, which is typically running in the on-premises datacenter. ADFS sends the received credentials to Active Directory for validation. If these are accepted, the user can authenticate.

Whereas ADFS is the "typical" design to follow when deploying identity in a hybrid cloud model, it also comes with some drawbacks. ADFS servers run on-premises, which means there is a dependency on internet connectivity, as a highly available topology is needed to guarantee that users can always log on to cloud apps whenever needed. ADFS is also complex to manage, and your ADFS proxy server in the DMZ is public internet-facing all the time.

To accommodate the strengths and ease of use of password hash sync, together with the need to keep credentials management in the on-premises Active Directory, Microsoft came up with a third scenario, PTA. Again, you start by synchronizing users and groups with AD Connect. Next, instead of deploying a complex ADFS infrastructure, you deploy Passthrough Agents on your on-premises Active Directory Domain Controllers. These listen on port 443, but only to Azure AD services endpoints public IP addresses. Other requests will be denied. When a user logs on to Azure AD, the request gets passed on to the PTA agent, who sends along the credentials to the on-premises Active Directory, which is still responsible for validating the credentials.

Have a look at the following link for all details on Azure identity and access management documentation:

https://azure.microsoft.com/en-us/product-categories/identity/