{"id":7279,"date":"2021-12-06T03:31:06","date_gmt":"2021-12-06T03:31:06","guid":{"rendered":"https:\/\/www.insentragroup.com\/us\/insights\/uncategorized\/azure-ad-domain-services-replica-sets\/"},"modified":"2022-03-30T08:26:23","modified_gmt":"2022-03-30T08:26:23","slug":"azure-ad-domain-services-replica-sets","status":"publish","type":"post","link":"https:\/\/www.insentragroup.com\/us\/insights\/geek-speak\/cloud-and-modern-data-center\/azure-ad-domain-services-replica-sets\/","title":{"rendered":"Azure AD Domain Services Replica Sets"},"content":{"rendered":"\n

I wanted to do a quick blog today around an awesome feature which has just been added to Azure Active Directory Domain Services (AADDS) called Replica Sets<\/a>.<\/p>\n\n\n\n

Before I explain the benefits of Replica Sets, let me recap what AADDS is. AADDS, also known as Domain Controller-as-a-Service, is a hosted Active Directory (AD) in the Azure cloud which you don’t need to manage, configure or update. AADDS is not to be confused with Azure Active Directory (AAD), however if you are a bit perplexed, please read on.<\/p>\n\n\n\n

WHAT IS AZURE ACTIVE DIRECTORY <\/span><\/h3>\n\n\n\n

When you first describe AAD to someone, they usually think it is \u201cDomain Controllers in the Sky\u201d or something similar. This is not an accurate description of AAD. <\/p>\n\n\n\n

AAD<\/a> is an Identity-as-a-Service platform which is born in the cloud and made to support cloud applications with native web-based protocols such as OAuth2, OpenID Connect, SAML and WS-Fed. While you can join a computer to AAD (Azure AD Join), the relationship is very different from a traditional on-premises AD join of yesteryear. Also, AAD does not support any of the older protocols found in traditional AD, such as Kerberos and LDAP. The older protocols were designed to work on a local LAN and not over the public Internet. <\/p>\n\n\n\n

WHAT IS AZURE ACTIVE DIRECTORY DOMAIN SERVICES <\/span><\/h3>\n\n\n\n

AADDS offers a managed AD environment which runs in an Azure Virtual Network and includes hosted Domain Controller VMs that your Azure VMs can leverage just as they would traditional Domain Controllers. These Domain Controllers support Kerberos, LDAP and even GPOs. AADDS is, in fact, more of a \u201cDomain Controller in the Sky\u201d solution. <\/p>\n\n\n\n

Although many organizations operate\u00a0an\u00a0on-premises AD, there are other cases\u00a0where\u00a0a\u00a0full-blown\u00a0AD\u00a0running on\u00a0VMs\u00a0is not required or desired. An example of this would be a\u00a0born-in-the-cloud organization\u00a0which\u00a0has no on-premises\u00a0AD\u00a0and wants to\u00a0leverage Azure\u00a0Virtual\u00a0Desktop<\/a> (AVD).\u00a0Even though\u00a0AVD\u00a0is part of Microsoft 365, it\u00a0does have a dependency on\u00a0AD\u00a0since the\u00a0AVD\u00a0VMs\u00a0must be\u00a0AD\u00a0domain\u00a0joined\u00a0(not Azure AD Joined).\u00a0It would be crazy to ask an organization to implement\u00a0a traditional\u00a0AD\u00a0infrastructure\u00a0just to support\u00a0AVD.\u00a0In this case AADDS would be a fantastic way to achieve this\u00a0requirement with very little effort.\u00a0<\/p>\n\n\n\n

AADDS can be considered an extension of AAD, since all the user\/credentials, groups, and group memberships from AAD are synchronized into AADDS on an ongoing basis. If your AAD is synced from an on-premises AD, then AADDS could ultimately mirror your on-premises AD. If AAD is not synced with on-premises AD, then AAD would be the source of authority for AADDS since the synchronization of objects is one way, AAD to AADDS. AADDS does not write back to AAD nor, by extension, AD if there is one. <\/p>\n\n\n\n

Here is what the relationship looks like with on-premises AD —> synced to Azure AD —> synced to AADDS: <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Notice the arrow from Azure AD to the managed domain (AADDS) is a one-way relationship. Even though you can create users and groups in AADDS, they are not synced back to Azure AD and if you do have an on-premises domain synced to Azure AD (as shown in the diagram above on the far right), there is no direct communication between the on-premises AD and AADDS. The on-premises AD has no concept this AADDS managed domain even exists.<\/p>\n\n\n\n

WHAT IS CHANGING<\/span><\/h3>\n\n\n\n

One major limitation of AADDS has been its inability to support multiple regions. That means you cannot plan for any type of multi-region deployment to support geo-dispersed organizations, high availability, or disaster recovery scenarios. You could create separate AADDS instances in different regions, however they would not share directory information between them, such as computer accounts, thus limiting the benefit.<\/p>\n\n\n\n

Microsoft has now introduced the concept of Replica Sets<\/a> which allow you to create replicas of an AADDS instance in up to four additional regions. Now customers who are geo-dispersed or have a requirement for true business continuity and disaster recovery can now seriously consider AADDS over a traditional AD deployment.<\/p>\n\n\n\n

Here are some design considerations if you are planning to implement Replica Sets:<\/p>\n\n\n\n