Azure AD DS Highlights

In the following document we will discuss about AZURE AD DS, the following points will be covered:

Why AZURE AD DS?

Comparison between AD DS, AZURE AD, AZURE AD DS.

Azure AD DS and self-managed AD DS.

Use Cases.

AZURE AD DS Implementation Steps.

References.

Why AZURE AD DS?

If your application is hosted partly on-premises and partly in Azure, it may be more efficient to replicate Active Directory Domain Services (AD DS) in Azure. This can reduce the latency caused by sending authentication requests from the cloud back to AD DS running on-premises.

This architecture is commonly used when the on-premises network and the Azure virtual network are connected by a VPN or ExpressRoute connection. This architecture also supports bidirectional replication, meaning changes can be made either on-premises or in the cloud, and both sources will be kept consistent. Typical uses for this architecture include hybrid applications in which functionality is distributed between on-premises and Azure, and applications and services that perform authentication using Active Directory.

Comparison between AD DS, AZURE AD, AZURE AD DS

Azure AD DS and self-managed AD DS

A managed domain that you create using Azure Active Directory Domain Services (Azure AD DS). Microsoft creates and manages the required resources.

A self-managed domain that you create and configure using traditional resources such as virtual machines (VMs), Windows Server guest OS, and Active Directory Domain Services (AD DS). You then continue to administer these resources.

With Azure AD DS, the core service components are deployed and maintained for you by Microsoft as a managed domain experience. You don't deploy, manage, patch, and secure the AD DS infrastructure for components like the VMs, Windows Server OS, or domain controllers (DCs).

Azure AD DS provides a smaller subset of features to traditional self-managed AD DS environment, which reduces some of the design and management complexity. For example, there's no AD forests, domain, sites, and replication links to design and maintain. For applications and services that run in the cloud and need access to traditional authentication mechanisms such as Kerberos or NTLM, Azure AD DS provides a managed domain experience with the minimal amount of administrative overhead.

When you deploy and run a self-managed AD DS environment, you have to maintain all of the associated infrastructure and directory components. There's additional maintenance overhead

with a self-managed AD DS environment, but you're then able to do additional tasks such as

extend the schema or create forest trusts.

Feature	Azure AD DS	Self-managed AD DS
Managed service	✓	✕
Secure deployments	✓	Administrator secures the deployment
DNS server	✓ (managed service)	✓
Domain or Enterprise administrator privileges	✕	✓
Domain join	✓	✓
Domain authentication using NTLM and Kerberos	✓	✓
Kerberos constrained delegation	Resource-based	Resource-based & account-based
Custom OU structure	✓	✓
Group Policy	✓	✓
Schema extensions	✕	✓
AD domain / forest trusts	✓ (one-way outbound forest trusts only)	✓
Secure LDAP (LDAPS)	✓	✓
LDAP read	✓	✓
LDAP write	✓ (within the managed domain)	✓
Geo-distributed deployments	✕	✓

Use Cases

SharePoint 2016 environment

AD DS Implementation Steps

AZURE AD DS

Prerequisites

To complete this Implementation, you need the following resources and privileges:

An active Azure subscription.
An Azure Active Directory tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.
You need global administrator privileges in your Azure AD tenant to enable Azure AD DS.
You need Contributor privileges in your Azure subscription to create the required Azure AD DS resources.
Site to Site VPN connection for replicating On-Premise users to AZURE AD DS