More and more often in my client projects, I need to integrate or expand Identity and Access Management. Almost always the situation is that a client, locally has an active directory in use and would like to associate this with cloud resources. As an Architect I find it very important to implement according guidelines of Microsoft and make good use of reference architectures. I want to share these reference architectures, which I use with the community, so we can all make good use of these guidelines.

Azure Active Directory (Azure AD) is a cloud based multi-tenant directory and identity service.This article describes best practices for integrating on-premises Active Directory domains and forests with Azure AD to provide cloudbased identity authentication.

Many organizations use Active Directory Domain Services (AD DS) to authenticate identities associated with users, computers,applications, or other resources that are included in a security boundary. Directory and identity services are typically hosted on-premises, but if your application is hosted partly on-premises and partly in Azure, there may be latency sending authentication requests from Azure back to on-premises. Implementing directory and identity services in Azure can reduce this latency. Azure provides two solutions for implementing directory and identity services in Azure:

1. Use Azure AD to create an Active Directory domain in the cloud and connect it to your on-premises Active Directory domain. Azure AD Connect integrates your on-premises directories with Azure AD. The Azure AD directory is not an extension of an on-premises directory. Rather, it’s a copy that contains the same objects and identities. Changes made to these items on-premises are copied to Azure AD, but changes made in Azure AD are not replicated back to the on-premises domain. You can also use Azure AD without using an on-premises directory. In this case, Azure AD acts as the primary source of all identity information, rather than containing data replicated from an on-premises directory.
2. Extend your existing on-premises Active Directory infrastructure to Azure, by deploying a VM in Azure that runs AD DS as a domain controller. This architecture is more common when the on-premises network and the Azure virtual network (VNet) are connected by a VPN or ExpressRoute connection.

This blog describes the first option, an on-premises network synchronizing with Azure AD, it focuses on the interaction between the Azure AD tenant and the Azure VNet. Typical uses for this reference architecture include:

• Web applications deployed in Azure that provide access to remote users who belong to your organization;
• Implementing self-service capabilities for end-users, such as resetting their passwords,and delegating group management. Note that this requires Azure AD Premium edition;
• Architectures in which the on-premises network and the application’s Azure VNet are not connected using a VPN tunnel or ExpressRoute circuit.

Note: Azure AD currently supports user authentication only. Some applications and services, such as SQL Server, may require computer authentication, in which case this solution is not appropriate

• Azure AD tenant. An instance of Azure AD created by your organization. It acts as a directory service for cloud applications by storing objects copied from the on-premises Active Directory and provides identity services.
• Web tier subnet. This subnet holds VMs that run a web application. Azure AD can act as an identity broker for this application.
• On-premises AD DS server. An on-premise directory and identity service.The AD DS directory can be synchronized with Azure AD to enable it to authenticate on-premise users.
• Azure AD Connect sync server. An on-premises computer that runs the Azure AD Connect sync service. This service synchronizes information held in the on-premises Active Directory to Azure AD. For example, if you provision or deprovision groups and users on-premises, these changes propagate to Azure AD.

Recommendations

The following recommendations apply for most scenarios. Follow these recommendations unless you have a specific requirement that overrides them.

Azure AD Connect sync service

The Azure AD Connect sync service ensures that identity information stored in the cloud is consistent with that held on-premises. You install this service using the Azure AD Connect software. Before implementing Azure AD Connect sync, determine the synchronization requirements of your organization. For example, what to synchronize, from which domains, and how frequently.

You can run the Azure AD Connect sync service on a VM or a computer hosted on-premises. Depending on the volatility of the information in your Active Directory directory, the load on the Azure AD Connect sync service is unlikely to be high after the initial synchronization with Azure AD. Running the service on a VM makes it easier to scale the server if needed. Monitor the activity on the VM as described in the Monitoring considerations section to determine whether scaling is necessary.

If you have multiple on-premises domains in a forest, we recommend storing and synchronizing information for the entire forest to a single Azure AD tenant. Filter information for identities that occur in more than one domain, so that each identity appears only once in Azure AD, rather than being duplicated. Duplication can lead to inconsistencies when data is synchronized. For more information, see the Topology section below.

Use filtering so that only necessary data is stored in Azure AD. For example, your organization might not want to store information about inactive accounts in Azure AD. Filtering can be group-based, domain-based, organization unit (OU)-based, or attribute-based. You can combine filters to generate more complex rules. For example, you could synchronize objects held in a domain that have a specific value in a selected attribute.

To implement high availability for the AD Connect sync service, run a secondary staging server.

Security recommendations

User password management. The Azure AD Premium editions support password write-back, enabling your on-premises users to perform self-service password resets from within the Azure portal. This feature should only be enabled after reviewing your organization’s password security policy. For example, you can restrict which users can change their passwords, and you can tailor the password management experience.

Protect on-premises applications that can be accessed externally. Use the Azure AD Application Proxy to provide controlled access to on-premises web applications for external users through Azure AD. Only users that have valid credentials in your Azure directory have permission to use the application.

Actively monitor Azure AD for signs of suspicious activity. Consider using Azure AD Premium P2 edition, which includes Azure AD Identity Protection. Identity Protection uses adaptive machine learning algorithms and heuristics to detect anomalies and risk events that may indicate that an identity has been compromised. For example, it can detect potentially unusual activity such as irregular sign-in activities, sign-ins from unknown Topology recommendations sources or from IP addresses with suspicious activity, or sign-ins from devices that may be infected. Using this data, Identity Protection generates reports and alerts that enables you to investigate these risk events and take appropriate action.For more information, see Azure Active Directory Identity Protection. You can use the reporting feature of Azure AD in the Azure portal to monitor security-related activities occurring in your system.

Topology recommendations.

Configure Azure AD Connect to implement a topology that most closely matches the requirements of your organization. Topologies that Azure AD Connect supports include the following:

• Single forest, single Azure AD directory. In this topology, Azure AD Connect synchronizes objects and identity information from one or more domains in a single on-premises forest into a single Azure AD tenant. This is the default topology implemented by the express installation of Azure AD Connect.
• Multiple forests, single Azure AD directory. In this topology, Azure AD Connect synchronizes objects and identity information from multiple forests into a single Azure AD tenant. Use this topology if your organization has more than one on-premises forest. You can consolidate identity information so that each unique user is represented once in the Azure AD directory,even if the same user exists in more than one forest. All forests use the same Azure AD Connect sync server. The Azure AD Connect sync server does not have to be part of any domain, but it must be reachable from all forests.
• Multiple forests, separate topologies.This topology merges identity information from separate forests into a single Azure AD tenant, treating all forests as separateentities.This topology is useful if you are combining forests from different organizations and the identity information for each user is held in only one forest.
• Staging server. In this configuration,you run a second instance of the Azure AD Connect sync server in parallel with the first. This structure supports scenarios:
  • High availability.
  • Testing and deploying a new configuration of the Azure AD Connect sync server.
  • Introducing a new server and decommissioning an old configuration. In these scenarios, the second instance runs in staging mode. The server records imported objects User authentication Azure AD application proxy Object synchronization Monitoring and synchronization data in its database, but does not pass the data to Azure AD. If you disable staging mode, the server starts writing data to Azure AD,and also starts performing password write-back into the on-premises directories where appropriate.
• Multiple Azure AD directories. It is recommended that you create a single Azure AD directory for an organization, but there may be situations where you need to partition information across separate Azure AD directories. In this case, avoid synchronization and password write-back issues by ensuring that each object from the on-premises forest appears in only one Azure AD directory. To implement this scenario, configure separate Azure AD Connect sync servers for each Azure AD directory, and use filtering so that each Azure AD Connect sync server operates on a mutually exclusive set of objects.

User authentication

By default, the Azure AD Connect sync server configures password synchronization between the on-premises domain and Azure AD,and the Azure AD service assumes that users authenticate by providing the same password that they use on-premises. For many organizations, this is appropriate, but you should consider your organization’s existing policies and infrastructure. For example: The security policy of your organization might prohibit synchronizing password hashes to the cloud. You might require that user’s experience seamless single sign-on (SSO) when accessing cloud resources from domain-joined machines on the corporate network. Your organization might already have Active Directory Federation Services (AD FS) or a third-party federation provider deployed. You can configure Azure AD to use this infrastructure to implement authentication and SSO rather than by using password information held in the cloud.

Azure AD application proxy

Use Azure AD to provide access to on-premises applications. Expose your on-premises web applications using application proxy connectors managed by the Azure AD application proxy component. The application proxy connector opens an outbound network connection to the Azure AD application proxy, and remote users’ requests are routed back from Azure AD through this connection to the web apps. This removes the need to open inbound ports in the on-premises firewall and reduces the attack surface exposed by your organization.

Monitoring

Health monitoring is performed by the following agents installed on-premises:

• Azure AD Connect installs an agent that captures information about synchronization operations. Use the Azure AD Connect Health blade in the Azure portal to monitor its health and performance;
• To monitor the health of the AD DS domains and directories from Azure, install the Azure AD Connect Health for AD DS agent on a machine within the on-premises domain. Use the Azure Active Directory Connect Health blade in the Azure portal for health monitoring;
• Install the Azure AD Connect Health for AD FS agent to monitor the health of services running on on-premises, and use the Azure Active Directory Connect Health blade in the Azure portal to monitor AD FS.

Scalability considerations

The Azure AD service supports scalability based on replicas, with a single primary replica that handles write operations plus multiple read-only secondary replicas. Azure AD transparently redirects attempted writes made against secondary replicas to the primary replica and provides eventual consistency. All changes made to the primary replica are propagated to the secondary replicas. This architecture scales well because most operations against Azure AD are reads rather than writes.

For the Azure AD Connect sync server, determine how many objects you are likely to synchronize from your local directory. If you have less than 100,000 objects, you can use the default SQL Server Express LocalDB software provided with Azure AD Connect. If you have a larger number of objects, you should install a production version of SQL Server and perform a custom installation of Azure AD Connect, specifying that it should use an existing instance of SQL Server.

Availability considerations

The Azure AD service is geo-distributed and runs in multiple data centers spread around the world with automated failover. If a data center becomes unavailable, Azure AD ensures that your directory data is available for instance access in at least two more regionally dispersed data centers.

The service level agreement (SLA) for Azure AD Basic and Premium services guarantees at least 99.9% availability. There is no SLA for the Free tier of Azure AD. For more information, see SLA for Azure Active Directory.

Consider provisioning a second instance of Azure AD Connect sync server in staging mode to increase availability.

If you are not using the SQL Server Express LocalDB instance that comes with Azure AD Connect, consider using SQL clustering to achieve high availability.

Solutions such as mirroring and Always On are not supported by Azure AD Connect.

For additional considerations about achieving high availability of the Azure AD Connect sync server and also how to recover after a failure, see Azure AD Connect sync: Operational tasks and considerations – Disaster Recovery.

Manageability considerations

There are two aspects to managing Azure AD:

• Administering Azure AD in the cloud.
• Maintaining the Azure AD Connect sync servers.

Azure AD provides the following options for managing domains and directories in the cloud:

• Azure Active Directory PowerShell Module. Use this module if you need to script common Azure AD administrative tasks such as user management, domain management,and configuring single sign-on;
• Azure AD management blade in the Azure portal.This blade provides an interactive management view of the directory,and enables you to control and configure most aspects of Azure AD.

Azure AD Connect installs the following tools to maintain Azure AD Connect sync services from your on-premises machines:

• Microsoft Azure Active Directory Connect console. This tool enables you to modify the configuration of the Azure AD Sync server,customize how synchronization occurs, enable or disable staging mode, and switch the user sign-in mode. Note that you can enable Active Directory FS sign-in using your on-premises infrastructure;
• Synchronization Service Manager. Use the Operations tab in this tool to manage the synchronization process and detect whether any parts of the process have failed. You can trigger synchronizations manually using this tool. The Connectors tab enables you to control the connections for the domains that the synchronization engine is attached to;
• Synchronization Rules Editor. Use this tool to customize the way objects are transformed when they are copied between an on-premises directory and Azure AD. This tool enables you to specify additional attributes and objects for synchronization, then executes filters to determine which objects should or should not be synchronized.

For more information and tips for managing Azure AD Connect, see Azure AD Connect sync: Best practices for changing the default configuration.

Security considerations

Use conditional access control to deny authentication requests from unexpected sources:

• Trigger Azure Multi-Factor Authentication (MFA) if a user attempts to connect from a non trusted location such as across the Internet instead of a trusted network;
• Use the device platform type of the user (iOS, Android,Windows Mobile,Windows) to determine access policy to applications and features;
• Record the enabled/disabled state of users’ devices, and incorporate this information into the access policy checks. For example, if a user’s phone is lost or stolen it should be recorded as disabled to prevent it from being used to gain access.
• Control user access to resources based on group membership. Use Azure AD dynamic membership rules to simplify group administration;
• Use conditional access risk policies with Azure AD Identity Protection to provide advanced protection based on unusual sign-in activities or other events.

For more information, see Azure Active Directory conditional access.

Solution deployment

A deployment for a reference architecture that implements these recommendations and considerations is available on GitHub. This reference architecture deploys a simulated on-premise network in Azure that you can use to test and experiment. The reference architecture can be deployed with either with Windows or Linux VMs by following the directions below:

Click the button below:

2. Once the link has opened in the Azure portal,you must enter values for some of the settings:

• The Resource group name is already defined in the parameter file, so select Create New and enter ra-aad-onpremise-rg in the text box.
• Select the region from the Location drop down box.
• Do not edit the Template Root Uri or the Parameter Root Uri text boxes.
• Select windows or linux in the Os Type the drop down box.
• Review the terms and conditions, then click the I agree to the terms and conditions stated above checkbox.
• Click the Purchase button

3. Wait for the deployment to complete

4. The parameter files include a hard-coded administrator user names and passwords, and it is strongly recommended that you immediately change both on all the VMs. Click each VM in the Azure Portal then click on Reset password in the Support + troubleshooting blade. Select Reset password in the Mode drop down box, then select a new User name and Password. Click the Update button to persist the new user name and password.

Next article: 

Azure Reference Architecture and best practices – extending your on-premises ADDS domain to Azure.

 

Source: Microsoft Azure Reference Architectures