I’ve seen this question bouncing about in different forums for quite some time now. I haven’t seen any definitive answers because it always depends on the organization’s use of AD. Recently, I noticed something called AWS Managed Microsoft Active Directory. I must admit, six months ago I was not aware of AWS Managed Microsoft Active Directory, but when I started looking into this cloud-based AD solution, some connections started coming together. Since it’s not like Azure AD (Entra ID) but more like a SaaS version of old-school on-premises AD, I had questions.
Here's what I discovered: it’s Active Directory! When you utilize this offering from AWS, you run through a configuration menu that sets up AD for your organization. You will have domain controllers, sites and more that fit the logical and physical architecture and needs of your organization, but you don’t have the overhead of physical or virtual machines, patching, maintaining, etc. Any system that is dependent on AD or AD-join will connect and work perfectly (provided the network is in place, of course).
What don’t you get? Management overhead and typical vulnerabilities. More specifically, you don’t get top-level permissions or accounts. You won’t have Domain Admin, Enterprise Admin or accounts or credentials from Schema Admin and the like, but you really don’t need them. There will be an OU created for your organization’s use and you will have full control over all the objects in that OU and below, but without overriding domain-wide, highly elevated permissions. This may sound limiting but is a great way to offer a directory as a service.
Highly functional, just like on-premises AD, but more secure.
You can use this AD just like you would on-premises AD. Join machines to the domain, create and manage users, create trust relationships, authenticate and more - because it’s AD. You can even consider replacing your old on- remises AD with AWS Managed AD, provided your network connectivity is in place.
I’ve pointed out what AWS Managed AD is, so if you have an Active Directory background, I hope this connects some dots around where it would be used but managing on-premises AD (or multiple ADs) can be a management and security challenge. If you have a single AD with a few hundred users, you may not be experiencing any significant challenges in management or security. However, if you already have challenges managing permissions, delegating the exact access to AD required to accomplish specific administrative tasks or manually manipulating AD objects and attributes, adding yet another directory sounds like making a big problem worse. This is where, to mitigate those challenges, One Identity Active Roles steps in.
If you’re not already familiar with One Identity Active Roles, let me give you a brief overview. Active Roles is specifically designed to provide an exponentially deeper and dynamic delegation model to AD and Entra ID over native capabilities. Not only can it use your current OU-based delegation, but it can provide dynamic delegation capabilities outside of the OU structure, allowing organizations to group objects based on anything. For example, if all user objects are dispersed throughout AD in OUs at multiple levels, Active Roles can do things such as create a structure of “Department,” “Location,” or even “favorite ice cream flavor,” then delegate a very specific permission based on that grouping. Although delegating administration based on favorite ice cream flavor may not make sense for your organization (I hope it doesn’t), it IS possible with Active Roles, across multiple AD domains and forests, without trust relationships.
When Active Roles is used to provide administrative security to an organization’s ADs, many security-positive things can happen:
- Group memberships can be automatically populated.
- Users are granted correct access to your Windows/AD environment immediately.
- Unneeded/incorrect access/group membership is removed dynamically.
- Admins manage multiple directories, domains, and forests (trusted or not) from a single interface.
That’s the delegation side of Active Roles. Of course, this not only applies to old school on-premises AD, but also to AWS Managed AD. If you have multiple ADs, Azure AD and AWS Managed AD – you only need one interface to manage all directories.
There’s another side of Active Roles that changes how on-premises AD and AWS Managed AD work together. The Active Roles Synchronization Service provides the ability to synchronize objects between… almost anything. Within this scope is the ability to sync on-premises users and groups to AWS Managed AD. This includes AD attributes, users, group memberships and the like, but also passwords.
This changes how you can move your population into the AWS Managed AD. When they change their password in the on-premises AD, the Active Roles Sync Service will synchronize the password to AWS Managed AD. Of course, usability can impact the use of anything new, and a new directory will be subject to this rule. If users have the same or similar experience in the new directory, they will never look back.
Of course, the Active Roles Synchronization Service could be a blog topic all its own, so we’ll follow this with a more focused blog in the future. For now, just realize the Sync Service can synchronize your AD objects from source to target(s). So, using the Sync Service to speed up the onboarding of AWS Managed AD just makes sense.
