Azure Active Directory Domain Services—What It Is and Why You Need It
By Kyle Yencer, Vice President of Services, MicroAge
In a separate blog, MicroAge covered the concept of having all endpoints under the control of Intune and Azure AD. Leaving On-Premises servers in another camp, you might wonder about the next steps to being an organization without On-Premise Active Directory.
So, what’s the next step to becoming a full cloud-first organization and leaving Active Directory in the dust? Azure Active Directory Domain Services (AADDS) fills the gaps by providing domain join, group policy, LDAP, and Kerberos/NTLM authentication to devices that do not natively communicate to AzureAD. AADDS typically includes servers and any devices that rely on LDAP or Kerberos/NTLM authentication. Additionally, this service provides Active Directory services within the Azure tenant for services like Virtual Machines and even Windows Virtual Desktop.
During the transition, the following diagram from Microsoft, Overview of Azure Active Directory Domain Services | Microsoft Docs, depicts what the deployment looks like:
On-Premise AD
In this transition period, On-Premise AD is still the source of truth from an identity perspective, with the eventual goal being decommissioning of On-Premise AD and moving the source of truth to Azure AD where all new users and groups are created, like so:
When it comes to AADDS there are a few key roles at play to ensure it’s the right fit for your organization. However, since AADDS is mainly designed for servers and data center infrastructure, most organizations will be alright.
- Schema Customizations are not possible – Most organizations will be okay with this. However, since this is a managed service, it is essential to note that you see what you get.
- Users will reside in a single container, AADDC Users. Moving users outside of this container is not permitted. So, any GPOs within AADDS will require item-level targeting via Groups.
- Any additional DNS zones created in AADDS and other objects that qualify for forest-level sync will need to be made at the domain level since AADDS is a managed service.
- Computers joined to On-Premise Active Directory will need to be migrated to AADDS.
- A Site-to-Site VPN or Express Route connection is required for any site or location that will need access to AADDS, and it is highly preferred. If you ask me, required that this connection has redundancy as leveraging the cloud with a single connection will leave sites and locations in the dark if network connectivity is disrupted.
Benefits of Migrating to AADDS
Now that we are past the things to be aware of, let’s talk benefits and the simplicity gained from deployment and migration to AADDS.
Key benefits include:
- Simplified deployment experience – All services are deployed within a matter of hours and are ready for prime time.
- Rich integration with Azure AD- All identity data in Azure AD is seamlessly synced to AADDS, no tools, software, or connectors are required.
- Highly available – AADDS includes multiple domain controllers and can be geographically expanded via Azure Availability Zones and Replica sets to expand beyond local zone redundancy.
- No more patching domain controllers – Since this is a managed service, IT is out of the business of patching one of the most critical infrastructures in the network. It seems like a win to me!
As one might see, the benefits are pretty significant in driving greater efficiency and resiliency for organizations of all sizes, and adoption for the small-to-medium-size business is not too daunting of a task. Basically, with a spend of under $300.00 a month, most organizations can move beyond the management of On-Premise AD and complete the journey to being a cloud-first organization.
