Lesson: Understanding Microsoft Entra Domain Services

Introduction: The Bridge Between Legacy and Cloud

In the early days of corporate computing, the local network was the center of the universe. Organizations relied on Active Directory Domain Services (AD DS) running on physical servers in on-premises data centers to handle user authentication, group policies, and access to internal file shares. As companies began moving to the cloud, they encountered a fundamental problem: many legacy applications, custom enterprise software, and specific infrastructure components (like virtualized desktops) require traditional LDAP, Kerberos, or NTLM authentication protocols to function. Microsoft Entra ID (formerly Azure Active Directory) is built on modern protocols like OAuth2, OIDC, and SAML, meaning it cannot natively support these older, legacy protocols.

This is where Microsoft Entra Domain Services (formerly Azure Active Directory Domain Services) comes into play. It provides a managed domain environment that offers a subset of traditional Active Directory features—such as domain join, group policy, and LDAP—without the need for you to manage the underlying domain controllers. It acts as a bridge, allowing you to lift and shift older applications to Azure while keeping the modern, cloud-native identity management of Entra ID as your primary source of truth. Understanding this service is vital for architects and administrators who need to modernize infrastructure while maintaining compatibility with older workloads.

What Exactly is Entra Domain Services?

At its core, Entra Domain Services is a Platform-as-a-Service (PaaS) offering. When you enable it, Microsoft creates two domain controllers in your Azure Virtual Network. These domain controllers are managed by Microsoft, meaning you do not have to worry about patching the operating system, managing disk space, or dealing with hardware failures. However, because it is a managed service, you do not have "Domain Admin" or "Enterprise Admin" privileges. You are provided with a specific set of permissions that allow you to manage the domain objects while Microsoft handles the underlying infrastructure stability.

It is important to clarify that this is not a full-featured replacement for an on-premises Active Directory forest. It is a standalone environment that synchronizes with your Entra ID tenant. Objects are synchronized from Entra ID to the managed domain, but changes made in the managed domain do not flow back to Entra ID. This one-way synchronization ensures that your cloud-native identity remains the primary point of control while providing the legacy-compatible environment required by your specific applications.

Callout: Entra ID vs. Entra Domain Services It is common to confuse these two services. Entra ID is a cloud-based identity provider built for modern web applications, mobile apps, and SaaS platforms using protocols like OIDC and SAML. Entra Domain Services is a managed service that provides legacy Active Directory capabilities like Kerberos and LDAP for virtual machines and older applications. You generally use Entra Domain Services only when you have a specific technical requirement that cannot be met by modern identity protocols.

Core Features and Functionality

To understand the utility of Entra Domain Services, we must look at the specific features it brings to the cloud environment. These features are designed to mimic the experience of a traditional on-premises domain controller environment.

1. Domain Join

This is perhaps the most requested feature. You can join your Azure virtual machines to the managed domain just as you would join a computer to an on-premises domain. Once joined, the machine can be managed via Group Policy, and users can log in using their domain credentials.

2. Group Policy Objects (GPO)

Entra Domain Services allows you to create and manage Group Policy Objects. You can use these to enforce security settings, manage software installations, or configure desktop environments for your virtual machines. You manage these using the standard Group Policy Management Console (GPMC) tools installed on a joined virtual machine.

3. LDAP Support

Many legacy applications rely on LDAP (Lightweight Directory Access Protocol) to query user information or authenticate users. Entra Domain Services provides a managed LDAP interface. You can even enable secure LDAP (LDAPS) to ensure that these queries are encrypted, which is a requirement for most compliance-heavy environments.

4. Kerberos and NTLM Authentication

These are the protocols that most modern cloud-native systems have moved away from. By providing Kerberos and NTLM support, Entra Domain Services allows applications that were written in the late 90s or early 2000s to function seamlessly in an Azure Virtual Network without requiring a complete rewrite of the authentication logic.

5. DNS Management

The service provides a managed DNS service. When you join a machine to the domain, it automatically registers its DNS record in the managed domain's DNS zone. This allows for seamless name resolution between servers and workstations within the virtual network.

When Should You Use Entra Domain Services?

Deciding when to use this service is a matter of architectural assessment. You should not use it simply because you are "used to" Active Directory. You should use it only when there is a clear technical barrier to using modern identity solutions.

• Lifting and Shifting Legacy Apps: If you have an application that requires Kerberos or NTLM and you are moving it to a virtual machine in Azure, this is the primary use case.
• Virtual Desktop Infrastructure (VDI): If you are running Azure Virtual Desktop or other VDI solutions that require domain-joined machines for profile management and GPO application.
• Administrative Access: When you need to manage a fleet of virtual machines using standard Windows administrative tools that rely on domain-level permissions.
• On-Premises Migration: If you are shutting down your on-premises data center and need to move your domain services to the cloud without the overhead of managing domain controller VMs.

Note: If your applications support modern authentication (OAuth, OIDC, SAML), you should always prefer using Entra ID directly. Entra Domain Services introduces complexity and cost that are unnecessary if your applications are capable of modern integration.

Step-by-Step Implementation

Setting up Entra Domain Services involves several stages, from network preparation to domain configuration. Follow these steps carefully to ensure a smooth deployment.

Step 1: Network Configuration

Before creating the managed domain, you must have a dedicated subnet in your Azure Virtual Network. This subnet should not contain other resources if possible, as it makes network security group (NSG) management much easier.

Step 2: Enabling the Service

1. Navigate to the Azure portal and search for "Microsoft Entra Domain Services."
2. Click "Create" and select your subscription and resource group.
3. Choose a unique DNS domain name (e.g., corp.contoso.com). Ensure this name does not conflict with your existing on-premises domain if you plan on having a hybrid setup.
4. Select the virtual network and the dedicated subnet you created in Step 1.
5. Choose the "SKU" (Standard, Enterprise, or Premium). The SKU determines the performance and features like backup frequency.

Step 3: Synchronization

Once the service is deployed, you need to configure the synchronization. By default, all users and groups in your Entra ID tenant will be synchronized. If you want to limit this, you can configure "Scoped Synchronization," which allows you to select specific groups to be synced to the managed domain.

Step 4: Updating DNS Settings

Your virtual machines need to point their DNS settings to the IP addresses of the managed domain controllers. You can configure this at the virtual network level in Azure:

1. Go to your Virtual Network settings.
2. Select "DNS Servers."
3. Change the setting from "Default (Azure-provided)" to "Custom."
4. Enter the two IP addresses provided by the Entra Domain Services dashboard.

Practical Example: Joining a VM to the Domain

Once the service is running, joining a VM is straightforward. You will use the standard Windows interface.

1. Log in to the Windows VM as a local administrator.
2. Open the "System Properties" dialog (right-click "This PC" -> "Properties" -> "Advanced system settings").
3. Under the "Computer Name" tab, click "Change."
4. Select "Domain" and enter the DNS name you defined earlier (e.g., corp.contoso.com).
5. When prompted, provide the credentials for a user who is a member of the "AAD DC Administrators" group.

Tip: You must add your user account to the "AAD DC Administrators" group in Entra ID before you attempt to join a machine to the domain. Without this membership, you will not have the permissions required to join computers to the domain.

Security Best Practices

Security is paramount when dealing with identity services. Because Entra Domain Services acts as an identity provider, it is a high-value target for attackers.

1. Secure LDAP (LDAPS)

Never use standard LDAP (port 389) over the network. Always enable LDAPS (port 636) and use a valid certificate from a trusted Certificate Authority. This ensures that authentication traffic and directory queries are encrypted in transit.

2. Network Security Groups (NSG)

Use NSGs to restrict traffic to the domain controller subnet. Only allow the necessary ports (like 389, 636, 445, 88, 53) from your application subnets. Deny all other traffic, especially from the public internet.

3. Least Privilege for Administrators

Only add users to the "AAD DC Administrators" group if they absolutely need to perform domain-level tasks. For daily user management, use the Entra ID portal. Do not use domain administrator accounts for standard daily tasks.

4. Password Policies

Since Entra Domain Services synchronizes with Entra ID, ensure that your password complexity and rotation policies are strictly enforced in Entra ID. Because Entra Domain Services requires password hashes for Kerberos and NTLM to work, users must perform a password reset or sign in to the portal after the service is enabled to generate these hashes.

Common Pitfalls and Troubleshooting

Even with a managed service, things can go wrong. Here are the most common issues administrators face.

The "Password Hash" Problem

When you first enable Entra Domain Services, existing users cannot log in to the domain immediately. This is because the service requires specific, legacy-compatible password hashes that are not generated by default for Entra ID accounts.

• The Fix: Users must change their password or log in to the Microsoft 365/Azure portal. This action triggers the generation of the required hashes, which are then synced to the managed domain.

DNS Resolution Failures

If your VMs cannot join the domain, the most common culprit is DNS. If the VM cannot resolve the name of the domain, the join process will fail.

• The Fix: Ensure the virtual network's DNS settings are updated to point to the managed domain controller IPs. Verify connectivity using nslookup from the VM to ensure it can resolve the domain name.

Incorrect Subnet Configuration

Deploying the service into a subnet that is already crowded or has restrictive NSGs can cause the deployment to fail or the domain controllers to become unreachable.

• The Fix: Always use a clean, empty subnet for the domain controllers. Ensure no forced tunneling (UDRs) is blocking communication between the domain controller subnet and the Entra ID service endpoints.

Callout: Common Mistakes Checklist

• Forgetting to add users to the AAD DC Administrators group: This is the #1 cause of "Access Denied" errors during domain join.
• Using a non-routable DNS domain name: Use a subdomain of your public-facing domain (e.g., ad.contoso.com) to avoid internal/external naming conflicts.
• Ignoring the sync delay: Remember that synchronization is not instantaneous. After making changes in Entra ID, wait a few minutes before trying to use those objects in the managed domain.

Comparison: Feature Availability

To help you understand what you are getting, here is a quick reference comparing a traditional "Domain Controller on a VM" approach versus the managed "Entra Domain Services" approach.

Advanced Management: Using PowerShell

While the Azure portal is great for setup, automation often requires PowerShell. You can manage certain aspects of your domain using the Microsoft.Graph or AzureAD modules, though most domain-level management is done via standard Active Directory PowerShell modules on a joined machine.

Example: Connecting to the Domain via PowerShell

Once you have a machine joined to the domain, you can install the RSAT (Remote Server Administration Tools) to manage the domain.

# Install RSAT tools on a Windows Server VM
Install-WindowsFeature -Name RSAT-AD-PowerShell, RSAT-AD-AdminCenter

# Once installed, you can use standard AD commands
Get-ADUser -Identity "jdoe" -Properties MemberOf

This allows you to treat your Azure-based domain exactly like an on-premises one, providing a familiar experience for administrators who have spent years managing Windows Server environments.

Architectural Best Practices: The Hybrid Identity Model

For many organizations, Entra Domain Services is part of a hybrid identity strategy. You might have an on-premises Active Directory for local file shares and a managed domain in Azure for cloud-based virtual desktops.

Hybrid Connectivity

If you need to connect your on-premises Active Directory to your cloud environment, you should look into Azure AD Connect. This tool synchronizes your on-premises identities to Entra ID. Once those identities are in Entra ID, they can then be synchronized into Entra Domain Services. This creates a chain of identity that ensures a user has one identity across the entire enterprise.

Avoiding "Split-Brain" Scenarios

A common architectural mistake is creating two separate, unconnected domains with the same name. This leads to "split-brain" DNS and authentication issues. Always ensure that your naming strategy is cohesive. If you have an on-premises domain contoso.local, do not create an Entra Domain Services instance named contoso.local unless you have established a proper forest trust (which is an advanced and complex configuration). Instead, use a unique subdomain like cloud.contoso.com.

Scalability and Performance

Entra Domain Services scales based on the SKU you choose. As your organization grows, you may need to move from the "Standard" SKU to the "Premium" SKU.

• Standard: Suitable for small-to-medium deployments with a limited number of objects. It has lower performance and less frequent backups.
• Enterprise: Provides better performance and is designed for larger organizations.
• Premium: Offers the highest performance and the most frequent backup schedules.

When planning your deployment, start with the requirements of your applications. If you have a legacy application that performs thousands of LDAP queries per second, you will likely need the Premium SKU to ensure that the authentication service does not become a bottleneck for your application's performance.

Security Auditing and Monitoring

Because Entra Domain Services is a managed service, you cannot install third-party security agents on the domain controllers themselves. However, you can monitor the service using Azure Monitor and Log Analytics.

Enabling Diagnostic Logs

You should enable diagnostic logs for your managed domain. These logs can be sent to a Log Analytics workspace, where you can run Kusto Query Language (KQL) queries to look for suspicious activity.

// Example: Searching for failed logins in the managed domain
AADDomainServicesLog
| where OperationName == "Logon" and ResultType == "Failure"
| project TimeGenerated, UserPrincipalName, IPAddress, ResultDescription

Monitoring failed logins is a critical security practice. A spike in failed logins could indicate a brute-force attack against your domain, and having these logs in a centralized location allows your security team to respond quickly.

Key Takeaways

As we conclude this lesson on Microsoft Entra Domain Services, keep these core concepts in mind:

1. Purpose-Built Compatibility: Entra Domain Services is designed specifically to support legacy applications and workloads that rely on Kerberos, NTLM, and LDAP. It is not intended for modern, cloud-native applications.
2. Managed Convenience: It provides the functionality of traditional Active Directory domain controllers without the administrative burden of maintaining the underlying OS, hardware, or high-availability infrastructure.
3. Synchronization Flow: The service relies on a one-way synchronization from Entra ID. Changes made in the managed domain do not propagate back to your cloud-native identity provider.
4. Network Prerequisite: Proper networking is essential. You must have a dedicated subnet and correctly configured DNS settings to ensure that virtual machines can locate and join the domain.
5. Security Essentials: Always enable Secure LDAP (LDAPS) and use Network Security Groups to restrict traffic. Treat the service as a critical security asset and monitor it using Azure Monitor.
6. The Password Hash Requirement: Remember that users must perform an action (like a password reset) to generate the necessary hashes for the service to authenticate them. This is the most common point of failure for new deployments.
7. Choose the Right SKU: Performance is tied to the SKU. Scale up to Enterprise or Premium tiers as your application load increases to ensure consistent performance for your legacy workloads.

By mastering these concepts, you can effectively bridge the gap between your legacy infrastructure requirements and the modern identity landscape of Azure. You are now equipped to plan, deploy, and secure a managed domain environment that supports your organization's transition to the cloud.