[MUSIC PLAYING] Hi. Thank you for joining us for this session on secure, seamless hybrid identity management with AWS managed Microsoft AD and One Identity Active Roles. My name is Tekena, and I'm a Solutions Architect with Amazon Web Services. And I have with me Vadim and Richard, who are going to come speak to you during the course of this presentation.
On the agenda, we will start by giving you an overview of AWS Directory service and also an overview of One Identity Active Roles. We will then talk about the integration between these two products and how they enable seamless and secure hybrid identity management for your business. And then we will give you some use cases and examples of how customers are leveraging this integration for their businesses and for their use cases. And we'll provide some next steps on how to get you started.
So hybrid identity management means having a common user identity for authentication and authorization to all resources, regardless of their location, whether on premises or in the cloud. But let's take a look at the challenges of managing hybrid identity.
The first one is complexity of integration. When you have a multi-forest, multi-domain, on-premises architecture, perhaps across-dev, test, and production environments, managing this can be complex. And the complexity can increase when you extend your identity infrastructure to the cloud and as you continue to add workloads to both environments.
Security is also a challenge. It is hard enough to have to manage security and permissions in an already complex on premises environment. You have to manage permissions for user access and application integration. Now, when you extend your identity infrastructure to the cloud, it becomes more challenging because you want to continue to ensure that only the least privileged permissions are granted for seamless user access and application integration for directory aware workloads across both on premises and in the cloud. In some cases, you will find where organizations manage two separate sets of credentials for their applications, which increases the overhead of managing security across these different platforms.
And then there is the challenge of visibility. For organizations that have identities living in different repositories, it gets challenging to have visibility into all individual identity stores. The ideal situation would be that irrespective of where the identities are stored, you are able to view everything from one place. There are other challenges like scaling, access permissions, compliance, and so on that adds to the challenge of managing hybrid identity.
Now let's talk about Active Directory on AWS. Now, there is a self-managed AD wherein you build your own self-managed AD in the cloud. You deploy an EC2 instance, deploy Active Directory on it, and use it for your business. You can do a multi AZ. You can do multi-region. These are all supported, but it is self-managed.
And then there is AWS managed Microsoft AD. And this is a fully managed Active Directory service in the cloud provided by AWS. Think of it as a standalone Active Directory as a service. It integrates with multiple AWS applications and services like QuickSight, workspaces, and so on. We will go into more details about managed AD in the coming slides, but this is another offering or another way to run Active Directory in the cloud.
And then there is AD Connector, which is a gateway or a proxy service that allows you to-- or that lets you proxy authentication requests from the cloud to your on premises to have on premises users gain access to cloud applications. So if you don't want to run Active Directory in the cloud, AD Connector can help make it possible to have your users access cloud applications.
For the purpose of this session, we are going to focus on AWS managed Microsoft AD, because this is the product that integrates with One Identity Active Roles to provide seamless hybrid identity management.
Now, let's take a look at some key features of AWS managed Microsoft AD. Firstly, it is actually based on Windows Server 2019, so it's what you are used to. Nothing different. Managed AD provides seamless domain join capabilities so that your domain or your directory aware workloads are able to join the domain at instance launch. When you launch your instances, they can join the domain at scale.
Managed AD allows you to configure your directory settings according to your infosec policies. So if, for example, you have a policy that says you have to disable SSL 2.0, you can simply do that from the directory service console. With managed AD, you can run your workloads across regions. So as you grow across regions, manage AD grows with you. Managed AD also supports multi-accounts and multi VPCs, so you can have managed AD running in one account and have directory aware workloads in other accounts leverage that managed.
And you can set up trusts between your managed AD and your self-managed AD. It can be a one way or a two way trust. So allow seamless application access from your on premise users to cloud applications. And because it is managed by AWS, you don't have to worry about patching, scaling, backups, and so on. All those are managed for you.
So let's take a look at Active Directory deployment options on AWS. The first one is that you are able to extend your existing Active Directory infrastructure on your premises to EC2. As I mentioned before, you can deploy EC2 and deploy AD there. In this case, you can then replicate that back to your on premises. Secondly, you can deploy AD connector to connect back to your on premises and allow your on premises users access cloud applications.
And the third use case is where you want to set up a trust between your self-managed AD and managed AD. And so you can leverage things like RDS, QuickSight, and other cloud applications by virtue of that trust between your self-managed AD and AWS managed AD.
And also you can have managed AD as a standalone Active Directory for your workloads. This is popular with customers who were born in the cloud or Managed Service Providers or MSPs who have Active Directory and a workload for their customers on a customer by customer account basis. So think of it as a business in a box where each of their customers have their own AD for their workload per customer. So these are the four ways deployment options you see for deploying Active Directory on AWS.
Now let's talk about application integration and how AWS managed Microsoft AD enables this. So you have your on premises Active Directory and then you deploy managed AD in the cloud. And as I mentioned before, you can set up a trust between these two. And by virtue of this trust, you can have on premises users access applications in the cloud like RDS, FSX, which is our file system solution, workspaces, and other applications you see on the screen here.
Managed AD also allows synchronization with Entra ID. Simply deploy Entra Connect and you can sync into Entra ID so that your users can use things like Office 365. You can also use managed AD with Active Directory Federation Services, ADFS. And if you have directory aware workloads living outside AWS, all you need is a line of sight between wherever they are running and your AWS managed AD. And you can have those leverage LDAP and Kerberos authentication with your managed AD. And also you can connect your managed AD with or to IAM Identity Center to enable your users, give them access to SaaS apps like Slack, Salesforce, and so on.
Now, given all that I have discussed so far, what if you have a situation where you have a multi-forest, multi-domain, on premises AD infrastructure, for example, and perhaps you have multiple managed AD add domains running in the cloud? Or maybe you have some identities stored in other identity stores. And perhaps you have some security restrictions around setting up trusts. How would you scale access to AWS cloud applications? How would you manage security of the different identity stores? How would you manage auditing and so on?
This is where One Identity Active Roles shines. And I'm going to call on Richard right now to come and speak to you, give us an overview of One Identity Active Roles. And then I'll come back to discuss use cases. Richard.
Hello. My name is Rich Lambert. I'm a pre-sales product architect for One Identity. Active Roles is the industry leading application for Active Directory management and security. Let's take a look at some of the key benefits of Active Roles.
Active Roles provides a single console for all of on premise Active Directory domains. Active Role satisfies your security and administration needs all in one tool. Active Roles is extensible to SaaS applications through integration with our Starling Connect platform. Active Roles provides a very powerful workflow engine. These workflows can respond to changes to directory data as well as run on a schedule basis.
Active Roles provides the role based delegation for your administrative accounts. These would be for your AD admins, help desk, service desk personnel. Active Roles is your foundation for Active Directory Zero Trust. And Active Roles is a very easy application to deploy, so you very quickly see a return on investment.
Let's take a look at some of the key features of Active Roles. Access templates in Active Roles provide the delegated administration capabilities. They are the mechanism by which you can say who can do what and where. Policies in Active Roles control the data that goes into Active Directory. This can be in the form of a dropdown list, attribute validation, marking attributes mandatory. Anything that has to do with the data into Active Directory is controlled by Active Roles policies.
Managed units and Active Roles can be thought a lot like the organizational units in Active Directory. Managed units in Active Roles remove the static nature of the organizational units in AD by allowing objects to be members of multiple managed units at any given time. Managed units can be statically populated or populated via query and are updated in real time.
Dynamic groups are a powerful component of Active Roles. Active Roles maintains the membership of the group via the membership rules. These membership rules can be query based or based off of other group members. All changes made through Active Roles are tracked. This can be seen in the form of change history that would be changes made to a given object, as well as user activity. What activities has a user been performing in the directory?
Workflows within Active Roles are a powerful mechanism by which to help automate a lot of actions within Active Directory. Scripting within Active Roles can be used to help complement essentially any action that occurs through Active Roles. Active Roles allows for the virtual extension of the AD schema via virtual attributes. These virtual attributes can be applied to any object type in Active Directory. These attributes present themselves through Active Roles as any other attribute would.
The sync service or synchronization service is an independently deployed component of Active Roles. It allows for integration of external data systems. These data systems can be in the form of flat files, SQL Oracle databases, other ADs, Entra ID tenants, as well as SaaS applications through integration with our Starling Connect platform. Active Roles integrates with SQL reporting services to provide interactive reports to see information related to Active Roles configuration, as well as all the audit data captured by the Active Roles management history.
Here's a high level overview of the Active Roles architecture. Here you can see we have HR systems as well as AD admins interfacing with the Active Roles security layer. It is within the security layer where the delegation is performed, policies are applied, information is formatted, and then handed off to Active Directory ADLDS instances as well as Active Directory domains hosted in AWS.
Let's take a look at some of the use cases for Active Roles within an AWS managed Microsoft AD environment.
All right. Thanks, Richard. All right. So let's discuss some use cases and customer examples of how customers are leveraging this integration between One Identity Active Roles and AWS managed Microsoft AD.
All right. So in this use case, we have where you can consolidate multiple AD domains into AWS managed AD. So for example, here we have a customer who has onprem.local on premises and also has different disparate domains running on different accounts within AWS, maybe by virtue of mergers and acquisition or something, or where you want to have project teams and have them have autonomy to manage the identity for their applications.
And here you have a managed AD where you want these users to have, or these identities from these different sources to get access to cloud applications. You can then deploy Active Roles and then connect each of these source directories with Active Roles. And then Active Roles can then sync those identities, which, by the way, you can select from each of those source identities and sync into managed AD.
Now, Active Roles doesn't have to be in the production account, as we see in this diagram. It can be anywhere else. What's important is that each of those source directories simply need to be able to connect to Active Roles to enable that sync into managed add.
So in this case, you're able to consolidate identities into AWS managed AD. It involves automated provisioning. You don't need trust. So if there is a security restriction around creating trust, you don't need that here. This scales very easily, because as you get new domains of forest to integrate, all you need is simply connect your Active Roles to that forest to sync into managed AD. And it's quite simple. And if the source is Active Directory, you're also able to sync passwords. So you don't need to manage passwords in two places.
Let's look at a different use case where you can synchronize with multiple AWS managed AD environments. Here we have a customer who has a self-managed AD running on EC2. And then they have different environments, dev, and QA sandbox. And you would like to run tests. And one way they could do this is create accounts or identities in each of these disparate accounts to run those tests. But the easier way would be to have users from the production sync into each of those environments to run those tests. So you can synchronize specific identities across all your environments within AWS. Again, connect to the prod.local as your source, and then you can sync individually into all of those disparate environments.
And then the third one is a pretty powerful feature of One Identity Active Roles, which I like so much, where you have different environments. And typically without something like One Identity Active roles, you'd have to manage permissions and policies individually across each of these environments, which can be time consuming.
Now, with One Identity Active Roles, you can simply deploy Active Roles here and then define the permissions and delegations within Active Roles and have Active Roles pass those on to all the environments all at once. So from one place, you are able to define policies and apply those to your entire environment, irrespective of where they live, whether in the cloud or on premises. So this is essentially about automation, and it greatly simplifies managing security across your multiple environments with One Identity Active Roles.
So we have a demo. I'm going to call on Richard to come back to run us through these demos. Richard.
Let's now take a look at a demonstration of these use cases. This first use case will show the consolidation of multiple on premises Active Directory domains into a single AWS managed Microsoft AD domain using Active Roles in the synchronization service.
Reviewing some user objects in the prod.local AD domain, you can see the naming standard here is first name space last name. Same account name is first name, last initial. And the synchronization service also handles group membership synchronizations. So we're going to add this user to a group to demonstrate that. Reviewing another user in the prod.local domain. Same naming standards. We're also going to add this user to a couple groups.
The other on-prem domain involved in this synchronization is corp1.local. Notice the naming standard here is last name comma first name Same account name is first initial, last name. And we'll also be adding this user to a group.
Reviewing the synchronization service, this is where the connections are created for the Active Directory domains. There's also a password sync rule. This can synchronize password changes from on-prem domains into the AWS managed domain. I've created a little PowerShell script here that stamps the current date and time into the www home page attribute whenever a password change occurs.
Within the synchronization service, there's workflows. The workflows contain the sync steps. Those are the create, update, delete steps. Here's an example of a creation step and the attribute mappings. You can also write data back to on-prem source object. And here is to set true for the user to change password at next logon.
When you run synchronization workflows in the sync service manually, you can select which workflow steps you'd like to run. They run interactively. So you can see what the sync service is processing and what it will do once the Commit button is selected.
We can take a look at the data. Here's a group membership change. All the data here is interactive. So you can see what the synchronization service would do once you click Commit. Here's the creation of users from one of on-prem domains. Here's the creation of the other users from the other on-prem domain into AWS. Once you click Commit, that's when the synchronization service transmits this data to Active Roles. And then the objects are updated accordingly in the AWS domain.
So if we review the users OU and AWS domain, you can see that the users got created. Here's Amy Dean. Naming standards. Look at the same account name. Here's Alexa Bishop from the other domain, where it was last name comma first name. Notice the new naming standards for the same account name. If you look at the groups, we can see the group memberships have also now been populated accordingly.
Because Amy had a new user created in the AWS domain, her user object in the source domain was set now to change password at next logon. So now Amy is going to log on to a workstation to change that password.
Once the password is changed, the password capture agent and the sync service will see the password change and then push that password to the AWS domain. The password update rule also had the PowerShell script to stamp the date and time in the www home page for you.
The second use case is synchronization of an on-prem AD domain into multiple non-prod AWS managed Microsoft AD domains. Again, using Active Roles in the synchronization service. Here's the same prod.local domain. The synchronization process here is group controlled. So as you add users to these groups, this will control which non-prod domain they're going to go into. We take a look here at the sandbox. This is one of the non-prod AWS hosted ADs. Here's dev domain and the other non-prod hosted AD domain and AWS.
Synchronization services, use case two. The workflow. Here's the workflow steps. Here's another creation step. Looks very similar. The attribute mappings. We're going to select all the workflow steps. Again, running these interactively is great for development and testing purposes. You can test your logic to see if you've built out the workflows and the workflow steps properly. Analyzing the groups. This also handles creation of groups. We're going to click Commit. The users are going to get created as well as the groups are going to get created.
We review the dev domain here in AWS. There's the users that got created. All the attributes are populated accordingly. And then we'll see a new group got created as well. The other non-prod AWS domain sandbox. There's the three users that got created as well as the group.
The third use case is going to show the Active Roles delegation capabilities. That is, to be able to show all environments in Active Roles, as well as delegate specific rights to a user within each domain independently.
Here we're in admin. You can see all the domains that were visible. It was more than three. We're logged on as the Active Roles web interface now as Alice, who's a delegated administrator. She's only able to see three of the domains. And within each of these domains, only select OUs. If you select a users OU, you see there's only new user. Selecting groups OU, there's only new groups. Clicking New User, we can create a new user here in this domain.
Look at the same account name standard here. First name dot last name. So if we go to prod.local. We click the group's OU. We can see we can only create new groups, create new users OU, only create new users. Again, look at the same account name here. We have to click the Generate button. That's to guarantee uniqueness. It was first name, last initial.
We take a look at the properties of a user object. We see the delegation is that the users are read only. If we take a look at this user here, this user object has a user in both on prem and AWS. If we deprovision the on-prem object, Active Roles is then automatically going to also deprovision the AWS object. This is to keep the objects in sync, especially during deprovisioning actions.
That concludes the demonstrations. Now let's see how Active Roles in the synchronization service are better together with AWS.
My name is Vadim Lyakhovich, and I'm a solution architect at AWS. And I want to talk about benefits of working together. By working together, we can achieve the following benefits to our end customers.
Layered approach to zero trust. This strategy enhanced security by implementing multiple protective layers, ensuring that access is carefully managed at each layer. Least privileged user model. Users are granted a minimum access necessary for their role and nothing more, and this helps to reduce potential security risk.
Object synchronization. We ensure compatibility and communication across different systems by integrating various environments, such as this managed by AWS. Streamline lifecycle management. This approach simplifies the process of managing user access over time. This approach makes it much more efficient. And simplifying directories. And unify security policy and interface, making it easier to manage and oversee access control.
One Identity recently published an Active Role solution to AWS Marketplace. AWS Marketplace is a curated digital store for helping companies of all sizes to find, try, buy, deploy, and manage solutions from AWS partners like One Identity.
There are quite a few benefits of using AWS Marketplace. It provides streamlined procurement, and this will help to optimize time to value contract and flexible payment option. You can test software, pay as you go, negotiate custom terms, and save with volume pricing. It will also reduce risk with centralized governance and control. You can launch third party solutions that meet your security and compliance requirements. It would also help you optimize cost. You can consolidate all of your third party spend with AWS billing. And this will help to simplify invoicing, track spending, and manage budgets.
[MUSIC PLAYING]