With organizations moving workloads to the cloud, they no longer have the traditional network security boundaries to manage access to applications and data. Therefore, identity is now the primary control plane in the cloud. This means that organizations control capabilities based on either the user identity or the device identity or a combination of both, using controls such as conditional access policies, compliance policies, self-service, single sign-on and automatic account provisioning and deprovisioning to cloud software as a services (SaaS).
Changing the authentication method requires planning, testing and potentially downtime. Choosing the right authentication method is critical in controlling access to all cloud data and resources. It is not a decision to be taken lightly. So, authentication should be the first decision an organization makes after deciding to move to the cloud.
Authentication is the foundation of all other advanced security and user experience features.
Now that we’ve introduced the importance of authentication, there are some options as to which identity provider (IdP) you can use. Microsoft offers the following options:
1. Active Directory Domain ServicesAs 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 (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 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 ComputersAzure 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 (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 ComputersThe 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.
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.
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 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)Don’t take our word for it. Start your free trial today!