The following blog post is the result of a short consultative engagement with an HPE customer that implemented a Line of Business application in the public cloud as a cloud-first strategy. Impending changes in cyber security laws 
Microsoft Identity Management
Microsoft Identity Management, also known as Microsoft Identity Access Management, is a fundamental building block in technology. Maintaining an organisations identity in the public cloud is part of an evolution, where organisations consume Software as a Service (SaaS) applications e.g. Microsoft 365. Azure Active Directory or Azure AD then plays a part in the cloud identity access management system. Third-party applications, such as other SaaS offerings as well as in-house developed applications can also leverage Azure AD for authentication and identity management.
Current State
This HPE customer consumed Azure AD to support its Line of Business application. Azure AD is Microsoft’s multi-tenant cloud-based directory and identity management service. For the purposes of this blog, a tenant is a dedicated instance of Azure AD that an organisation owns when it signs up for Microsoft cloud-based services, such as Azure or Microsoft 365.
From two virtual workshops held in quarter one of 2021, HPE gathered the following information about the customer's implementation of Azure AD:
• The HPE customer has around 30+ Azure AD tenants
• Limits on Azure AD resources per tenant necessitate the need for the number of tenants
• There are approximately 10 million users split between these 30 Azure AD tenants
• Authentication and authorization occurs in the public cloud for those 10 million users
• All 10 million users consume Microsoft cloud-based services e.g. Microsoft Teams (part of the Microsoft 365 family of products)
• The HPE customer does not have in place today an on-premises Active Directory Domain Services (AD DS) forest
Future State
The output from the two virtual workshops provided HPE with some general design principles that needed to be considered when thinking about the future state architecture:
• User authentication and authorization must now occur on-premises
• The HPE customer would need to deploy a geographically dispersed and highly available on-premises AD DS forest. Options include a Single-forest with one or more domains or a Multi-forest environment
• Resetting users passwords were agreed as a necessary by-product of having to ensure user authentication occurs on-premises
When a new Azure AD tenant is created, the contents of the directory by default is managed independently from any on-premises AD DS forest. This means that when a new user requires an identity to be set up, an administrator must create an on-premises AD DS account and an account in Azure AD. These two accounts are separate, they can also end up with different names and passwords. Also, from an operational perspective, they need to be managed separately.
To avoid this situation, the existing Azure AD objects (Users and Groups not Devices) would need to be brought back on-premises, those original objects may need to be permanently removed from Azure AD i.e. deleted and then purged from the Azure AD Recycle Bin if selective matching of objects, that is hard or soft matching, doesn’t occur, then the newly created on-premises AD DS objects would be synchronised back to Azure AD, this would avoid the possibility of having duplicate identities or having previously deleted object reanimated and matched.
Option 1 - Azure AD Connect with Pass-through Authentication
Azure AD Connect can act as an identity bridge between the on-premises AD DS forest and Azure AD. When Azure AD Connect is in place, users can be added, updated or removed from the on-premises AD DS forest and those changes will be automatically reflected in Azure AD.
Azure AD Connect does not offer a distributed architecture for authentication, high availability is offered by running a secondary server in staging mode. Here the synchronisation service is in a ready state but does not perform any identity data exports.
Option 2 - Azure AD Connect with Active Directory Federation Services (ADFS) Authentication
Active Directory Federation Services can then act as an identity bridge between the on-premises AD DS forest and Azure AD, thereby enabling a single identity service for the HPE customer. The major benefit of leveraging ADFS is that it offers a distributed architecture for authentication.
High-level Design Decisions
How synchronisation occurs in the future state is largely dependent on the design choice for the on-premises AD DS. Options include:
- Single-forest synchronisation with Azure AD Connect and pass-through authentication
- Single-forest synchronisation with Azure AD Connect and Active Directory Federation Services (ADFS) authentication
- Multi-forest synchronisation with Azure AD Connect and Active Directory Federation Services (ADFS) authentication
When considering your Azure AD Connect design, it is worth considering reading the following Microsoft article Topologies for Azure AD Connect.
Pass-through Authentication
Azure AD Connect Pass-through Authentication allows users to sign in to both on-premises and cloud-based applications using the same passwords. When users sign in using Azure AD, this feature validates users' passwords directly against on-premises AD DS.
Active Directory Federation Services (ADFS)
ADFS provides the option to create an identity federation trust between the on-premises AD DS and Azure AD. This would allow users to have a single sign-on experience. When users sign in using Azure AD, this feature validates users' passwords directly against on-premises ADFS. Note, this option still requires Azure AD Connect.
Sample Implementation Plan
The following is a high-level implementation plan for enabling user authentication and authorization on-premises:
- The HPE customer would need to complete any remediation and preparation tasks with the existing 30 Azure AD tenants. Here HPE Advisory & Professional Service (A&PS) would be available to help with any guidance and assistance with this task.
- Design and implement a geographically dispersed and highly available on-premises Active Directory Domain Services (AD DS) environment to support the 30 Azure AD tenants.
- Design and implement a highly available Azure AD Connect infrastructure, which would include the implementation of both primary and staging servers, installation of Azure AD authentication agents for pass-through authentication and optionally, design and implementation of an Active Directory Federation Services (ADFS) farm including both ADFS and Web Application Proxy (WAP) servers in a load-balanced configuration.
- Extract existing objects and their supported attributes from Azure AD using PowerShell and import those objects into the on-premises AD DS environment.
- Tidy up the existing Azure AD tenant (if required) and complete an initial synchronisation with Azure AD.
For more information on the many ways we can help you, https://www.hpe.com/uk/en/services/pointnext.html
Patrick Lownds
Hewlett Packard Enterprise
twitter.com/HPE_TechSvcs
linkedin.com/showcase/hpe-technology-services/
hpe.com/pointnext
