Azure Active Directory Monitoring: Domain Services

As organizations transition to the cloud "Cloud governed management" describes how organizations manage and govern their users, applications, groups, and devices from the cloud.

Each one of these IdP options can be used in cloud but require different configurations and infrastructure. Also, they offer different authentication and management options to administrators, your users, and applications.

Let’s go into the different offerings now.

Active Directory Domain Services

Active Directory Domain Services (AD DS) is a directory service that stores information about user accounts, groups, computer objects, domains, organizational units and security policies. AD DS is a critical component for any organization, thus it is an important item to monitor as a part of your Active Directory Monitoring approach. This information can be published for use by users and administrators on the network. Domain controllers store a copy of the directory and changes are replicated to other domain controllers in the domain.

AD DS is a role of Windows Server 2016, Windows Server 2012 R2, Windows Server 2012 as well as older versions of Windows server going back to Windows Server 2003. As such, it has to be installed on physical hardware or virtual machines in your organization’s network. Some organizations with existing complex directory structures choose to extend their existing AD DS into the cloud, by deploying IaaS Virtual Machines. This is illustrated in Figure 3: Extending AD DS into cloud below.

Figure 3: Extending AD DS into cloud

Figure 4: Overview of AD DS

As can be seen in above AD DS has the following main features and Figure 4: Overview of AD DS functionality and is 100% maintained and operated by the you, the organization:

- Users and Computers
- Organizational Units (OUs)
- DNS
- Group Policies
- LDAP
- Kerberos
- NTLM
- Trusts

Azure Active Directory

Azure Active Directory (AAD) is Microsoft’s cloud-based identity and access management service. If you subscribe to any Microsoft Online business service, you automatically get Azure AD with all the free features. AAD allows you to control access to apps and resources using Multi-Factor authentication for example.

AAD is a flat “directory” structure. There are no OU structures. No DNS and no Group Policies to manage users and devices. It offers very different functionality and management capability to AD DS. Azure Active Directory uses modern authentication protocols such as Oauth, SAML or OpenID Connect. The legacy authentication protocols such as NTLM and Kerberos are not available in AAD. So, applications that require these authentication protocols would not be able to use AAD as their IdP.

However, as can be seen in Figure 5: AAD Overview below, AAD offers Single Sign On (SSO), Role Based Access Control (RBAC) as well as advanced security features such as Conditional Access and machine learning threat protection.

Figure 5: AAD Overview

For a comparison of AD DS to AAD take a look at this page.

Azure Active Directory Domain Services

Azure Active Directory Domain Services (AAD DS) is Microsoft’s managed domain services offering, allowing organizations to utilize domain services such as domain join, group policies, Kerberos and NTLM authentication. Without having to deploy and maintain domain controllers. AAD DS essentially lets you run legacy applications in the cloud that can’t use the modern authentication methods or where you don’t want to connect to or extend your on-premises AD DS environment.

AAD DS does require an AAD tenant because it integrates with it and lets you synchronize users from AAD into AAD DS. This lets users sign into services and applications that are connected to the managed AAD DS domain using their existing credentials.

AAD DS is managed by Microsoft, but the connectivity to the domain controllers is provided through network interfaces which are directly injected into an Azure virtual network, so organizations will need an Azure subscription.

Additionally, because AAD can synchronize with an on-premises AD DS environment, AAD DS can extend an existing on-premises identity management to provide authentication to traditional applications that run in the cloud as part of a lift-and-shift strategy

Figure 6: AAD DS Overview

As you can see in  Figure 6: AAD DS Overview above, AAD DS provides you with most of the features and functionality available in a traditional AD DS without the need to deploy, maintain and patch Windows servers.

        - Users and Computers

• • Users are synchronized into one single OU (AADDC Users). You can't make changes to user attributes, user passwords, or group memberships within a managed domain.
  • You can also manually create accounts directly in the managed domain.
  • Computers (VMs) can be domain joined in the same way they can be joined to an AD DS domain.
  
  - OUs
  • OUs are pre-created and are mostly read-only, however you are able to create custom OUs and store users, groups and computer objects in your custom OUs.
  
  - Group Policies
  • Group policies can be created and applied to any OU. There are however some read only domain wide group policies pre-created.
  
  - DNS
  • AAD DS has a managed DNS zone, which you connect to and query, but you can also create conditional forwarders to any existing DNS zones in your organization to provide full DNS resolution.
  
  - LDAP
  • Since AAD DS is a managed version of AD DS, it provides a Lightweight Directory Service (LDS) directory and communication with the directory uses the LDAP protocol by default.
  • LDAP isn’t encrypted by default so one can configure and use secure LDAP (LDAPS) or LDAP over SSL/TLS.
  
  - Legacy Authentication
  • Kerberos is used by default where available
  • NTLM is used in protocols that don’t support Kerberos such as RDP (NTLM over CredSSP)
  • NTLM v1 should be disabled as part of securing AAD DS.
  
  - Trusts
  • Trusts can be created to other domains; however, it requires a special type of AAD DS to have been deployed called a “resource forest”.

The managed domain is created as a separate domain to any existing on-premises domain or AAD tenant. So, the DNS namespace needs to be unique and routable.

AAD DS is highly available because it is deployed onto a minimum of two domain controllers and into availability zones in regions where available. In addition, replica sets, which is currently in preview, allows you to deploy up to four replica sets (of two domain controllers each) into other regions in order to provide resilience to Azure regional failure.

Figure 7: AAD DS Replica Sets below is an illustration of two replica sets deployed into region A and region B to provide regional failure resilience. Virtual network peering is required and will be created between the regional vNets if it doesn’t exist already.

Figure 7: AAD DS Replica Sets

Managing AAD DS is done using familiar tools that are used to manage AD DS, such as Active Directory Users and Computers, DNS Server, Group Policy Management Console, Active Directory Administrative Center and Active Directory PowerShell module for examples which are part of Remote Server Administration Tools (RAT). See Figure 8: AD Administrative Tools Below.

Figure 8: AD Administrative Tools Below

As AAD DS is a managed service, there are some administrative tasks that you can't perform, such as using remote desktop protocol (RDP) to connect to the domain controllers.

A special administrative group named AAD DC Administrators is used for management of the Azure AD DS domain. Members of this group are granted administrative permissions on VMs that are domain-joined to the managed domain. The AAD DC Administrators group lets you perform some privileged operations.

You don't have Domain Administrator or Enterprise Administrator permissions on a managed domain using AAD DS. These permissions are reserved by the service and aren't made available to users within the tenant.

Backups are performed automatically every 1 to 14 days, now this does seem a bit vague, but what they are saying is according to the service level agreement (SLA) of AAD DS, backups should happen daily, but if you see the last backup was performed more than 1 day ago, it could be due to the number of objects in the managed domain that need to be backed up causing the backup to run for a long time. If the backup has not been performed after 14 days, then there is an issue and Microsoft will get involved to resolve it. There are monitoring and health metrics that update hourly and Microsoft will alert you via email as well as in the Azure Portal, should there be something unhealthy about your managed domain.

So why would an organization go from AD DS to AAD and then to AAD DS? This identity strategy is part of the journey to remove on-premises AD footprint but still support apps that need LDAP/Kerberos. Eventually you can remove the on-premises AD.

If you are “cloud first” you would remain purely AAD, unless you need to deploy applications that require legacy authentication protocols, then you would also deploy AAD DS.

In conclusion, there are a couple of ways to provide identity and authentication in the cloud, it is possible to stick with what you already have, but it’s also a good opportunity to assess what is required in the cloud from an authentication perspective, and consider your options carefully, because there are limitations in all each of the offerings.

---

Active Directory Monitoring with ENow

Active Directory as the foundation of your network, and the structure that controls access to some of the most critical resources in your organization. ENow uncovers cracks in your Active Directory that can cause a security breach or poor end user experience. In particular, ENow enables you to:

- Report on highly privileged groups (domain admins)
- AD replication errors
- Identify Expensive LDAP queries
- DNS and name resolution problems
- Troubleshoot poor Exchange performance caused by Active Directory

Don’t take our word for it. Start your free trial today!