Why does Active Directory continue to play a role in enterprises today?

Active Directory, spanning a quarter-century in age, might lead one to question its relevance today. However, this technology is firmly established in terms of management and maintenance. Yet, the ongoing discussion about Active Directory is driven by the critical dependencies organizations have as they move to the AWS Cloud.

Despite migrating to cloud-based services, some dependencies on directory services, such as Kerberos and LDAP authentication, continue to endure. Group policies continue to be utilized for device management, further highlighting the indispensability of Active Directory. Furthermore, PKI integration is a common occurrence, and managed Active Directory adequately supports this requirement. The need for rights management remains unchanged, and in many cases, Active Directory serves as the foundational element for workforce identity management. Active Directory often remains the primary identity repository even when identity synchronization occurs elsewhere. Because of that, Active Directory frequently assumes the primary identity store for solutions like Active Directory Federation Services (AD FS).

AWS Directory Services

AWS Directory Service offers three distinct services: AD Connector, Simple AD, and AWS Managed Microsoft AD.

AD Connector

The AD Connector serves as a proxy or gateway service, facilitating connections between AWS native services and your self-managed or even AWS-managed AD. It enables direct communication between AWS services and your Active Directory without engaging in credential caching. It's important to note that AD Connector operates on a one-to-one relationship basis. This means you require one AD Connector per AWS account. If your setup involves multiple forests, domains, or accounts, you will require multiple AD Connectors to achieve seamless integration.

AWS Managed Microsoft AD

This article will primarily focus on AWS Managed Microsoft AD, a robust solution that differs significantly from abstract or open-source implementations of Active Directory. AWS Managed Microsoft AD is a real Active Directory built on Windows Server 2019, which means you can perform all the typical Active Directory tasks. You can connect to it, manage users, groups, computer accounts, and establish connections to other domains through trust with this managed AD.

The key differentiator to note when integrating your native services with Active Directory is that with AWS Managed Microsoft AD, you only need a single instance to support multiple forests and domains and the ability to share it among multiple accounts. This flexibility extends not only within your organization but also across the organization. Therefore, if you operate in a complex environment with a multi-account strategy, AWS Managed Microsoft AD is likely an ideal choice for establishing seamless connectivity with AWS native services.

Key features of AWS Managed Microsoft AD

• When considering the choice between AWS Managed Microsoft AD and self-managed AD, one key reason for opting for AWS Managed Microsoft AD is its utilization of the actual AD on Windows Server 2019. This service operates on a single-tenant architecture and ensures that the domain controllers are not shared among multiple customers. With AWS Managed Microsoft AD, you receive a set of domain controllers distributed across two different availability zones, constituting your AD. It's important to note that this service is structured as a single-forest, single-domain structure, and this aspect should be considered when formulating your architectural decisions.
  
• AWS Managed Microsoft AD offers access to different security settings and other Active Directory functionality to the console and various APIs. This means you can easily configure essential aspects, such as the security protocols used by LDAP, by simply accessing the console. You can also set up fine-grained password policies, allowing you to tailor these settings to your specific requirements. Many of these configurations you apply to self-managed AD can also be applied to your AWS Managed Microsoft AD.
  
  
• In terms of the tools, you have the option to utilize the console for some tasks. However, you can also connect to the domain controllers and use your standard tooling, including AD users' computers, various snap-ins, and PowerShell scripts for managing users, groups, and group policies.
  
  
• The seamless domain join eliminates the need for maintaining scripts for this purpose. Using seamless domain join, you can connect via your console, API action, and the CLI to automatically join Windows and Linux EC2 instances to your domain.
  
  
• AWS Managed Microsoft AD supports multiple VPCs and accounts. To enable seamless domain join and many other native features to work, you need to establish the necessary network connectivity or share access with the relevant accounts.
  
  
• By default, AWS Managed Microsoft AD deploys to a single region. Two editions are available: the Standard Edition, suitable for smaller implementations or initial setup, supporting approximately 30,000 objects. When you select the Enterprise Edition, it can handle up to half a million objects. However, the standout feature of the Enterprise Edition is multi-region replication. With this, you can provision additional sets of domain controllers into secondary and third regions. They will appear as additional sites within the Sites and Services.
  
  
• The primary motivation for using an AWS Managed Microsoft AD over a self-managed one is that it relieves you of the operational responsibilities associated with deployments, patching, upgrades, monitoring, and remediation in case of service disruptions. AWS takes care of all these tasks on your behalf, making managing your Active Directory more convenient and efficient.

Use cases of AWS Managed Microsoft AD

Workforce Identities

Connect workforce Identities to native AWS services: Suppose a self-managed AD is running within your on-premises environment. With just a few clicks in the console or by CloudFormation or Terraform, you can deploy your managed AD to a single VPC and choose two subnets for configuration. You set up a trust, which can be either one-way or two-way. Let's assume it's a two-way trust between the AWS-managed Microsoft AD and your self-managed one.

With this trust in place, you can leverage the identities stored in your on-premises AD for AWS-hosted Windows applications. This includes a wide range of Windows applications like .NET, SharePoint, and others that rely on Kerberos and LDAP authentication. Additionally, seamless domain join is instantly enabled through that trust. It's worth noting that Amazon RDS requires an AWS-managed Microsoft AD to enable integrated Windows authentication with RDS instances. Amazon FSx, the shared file server service, is another feature that benefits from this configuration.

Furthermore, while these are just a few services available, they represent a subset of the managed services that can integrate with AWS Managed Microsoft AD. This integration enables you to leverage that trust to use your identities on-premises or EC2.

When migrating your users from self-managed to AWS Managed Microsoft AD, you can employ Azure AD Connect to synchronize your users. The process is similar to what you would do with a self-managed AD, with one exception: you don’t have access to the domain admin or enterprise admin credentials to move password hashes up to Azure. Instead, you can use pass-through authentication. This involves setting up pass-through authentication agents to connect your authentication back to the AWS Managed Microsoft AD. You can implement AD FS or other SAML authentication methods that could tie to the AWS Managed Microsoft AD in support of other applications you may already have in place, such as Oracle Database, SAP, or existing .NET applications.

An important point to note is that AWS IAM Identity Center offers native integration with AWS Managed Microsoft AD and the AD Connector. With AWS Managed Microsoft AD, you have one instance capable of synchronizing many users and groups from multiple domains and forests into the AWS IAM Identity Center. This synchronization enables the use of these identities for accessing AWS resources.

Administrative Autonomy

This revolves around the various organizational models related to administrative autonomy observed among customers.

Organizational forest model

The first model is the organizational forest model. In this setup, a two-way forest trust exists between the AWS Managed Microsoft AD and your self-managed AD. With this model, you can delegate the AWS Managed Microsoft AD administration to a team or individual within your organization but leveraging identities from your corporate AD. Because of the two-way forest trust, this can occur in both directions. This means that identities in the managed AD can access resources if they grant permission and vice versa.

Resource forest model

This model, known as the resource forest model, is commonly adopted by organizations. While it may appear similar to the organizational forest model, the main difference is the one-way forest trust instead of a two-way forest trust. In this setup, you can isolate the service administration. For example, you might have an identity team responsible for managing the self-managed AD, and this team is entirely separate from the cloud identity team. Within this context, the identity team can delegate access to the AWS Managed Microsoft AD while still using all the identities stored in the self-managed AD for AWS resources. However, all the resources themselves are separated. This includes computer accounts, users, groups, and group policies, which continue to be managed within the AWS side.

Restricted access forest model

This particular model is frequently observed in highly restricted environments. You may have confidential or very isolated workloads that require separation from the rest of your corporate domain. This model is an excellent choice for such scenarios. However, managing the additional maintenance, users, and group administration is necessary. Another common scenario where this model comes into play is when there's a need for separate environments for developers. In such cases, individual environments can spin up. Individual directories can be set up if they need a higher level of AD access.

Developer agility

In scenarios where developers need specific access to Active Directory, and you are hesitant to grant such access within your production environment, you can deploy either a resource forest model or a standalone AWS-managed Microsoft AD specifically for the developers. This allows them to have the necessary access without the burden of managing the underlying infrastructure or dealing with replication, as AWS handles these aspects.

This model is particularly common among service providers today. Instead of setting up a single sizeable Active Directory for all their customers, service providers can deploy an AWS Managed Microsoft AD as part of that individual workload. This way, each customer receives their delegated Active Directory without the associated operational overhead.

Reference:

AWS re:Inforce 2023