Hello. My name is Viktor Varga, and I work as a sales engineer at One Identity. Today, I am going to talk to you about privileged access management in Active Directory, which session was originally had together with my colleague, Frederic Courtois, in September, 2023, in Madrid on the User and Partner Conference of One Identity Unite.
We are going to talk about today the problem itself. We will set the scene of how a typical organization looks like, and we are going to talk about how the ideal world, how an ideal configuration would be built. We are going to demonstrate how is that possible with the tools in the-- we are going to talk about how it is possible to build a solution using the tools of the unified identity platform, and we are also going to talk about how you can identify privileges in Active Directory.
I came across this post the other day on LinkedIn by one of my former colleagues. So he raised the question about an actual bridge, a compromise in an Office 365 environment, in which the attackers were able to lock out the administrators and then do further damage. My colleague went through the whole article, and the article mentions the importance of multi-factor authentication. Of course, phishing-resistant MFA could also be introduced, for example, by OneLogin from One Identity.
But as going through the article, my own colleague also raised, how could the attacker be captured during the attack? But at the end, he came to the conclusion that the best solution is to take a backup. I believe it's not the best solution. It's the basic solution. But what we need to do is capture the attacker in between because what we know is that the attackers do not break in. The attackers simply log in.
So let's take a large organization as an example. They have Active Directory. They probably have more forests, not only one. They do have hundreds or maybe even thousands of AD-connected applications, and each of them is using an AD account to do their tasks. There are hundreds of thousands of users within this directory, which requires dozens, or in many cases, even more-- maybe hundreds of administrators, most probably with more privileges. Not only one account, multiple accounts.
Privileges are over shared by the nature of AD. The management tools, the delegation tools which are available are heavily limited or extremely difficult to manage, especially the bigger your directory is. What organizations do-- they implement the jump holes. They implement traditional solutions which are typically complex and costly. Meanwhile, it's just grabbing the problem at the entrance of Active Directory.
In an ideal world, what do we see on the right side? This is our world. This is heavy. This is huge. This is secure. It keeps all our values. It keeps all our secrets. There is only one way in, one way out. There are security cameras everywhere.
And that's great. I'm not saying it is not required. It is required. However, there are certain cases when it is just overkill. Just think about if there are still valuable but not as critical pieces.
Think about those deposit boxes in the banks which are available outside the vault. Yes, there may be deposit boxes inside the vault as well when you have so precious secrets, so precious value that you need to protect. What I am saying-- that in an ideal world, you do not need to have one type of solution. You do not need to put everything into those heavy, complex, and expensive vaults. You might have another option and grab the problem where it exactly should be.
For some organizations, Active Directory is really just a directory. That's it. However, we have seen cases where Active Directory took way more important place in the life in the infrastructure of the organization. It contains personal information, background information.
We have seen organizations where Active Directory attributes were managed not necessarily directly, but managed even by HR. It was the base source of truth of identities. So imagine that basic AD update tasks may not need any IT involvement. You don't need your operations team to update attributes because end users have the right to see, and in some cases, even update the basic information about themselves.
Meanwhile, business owners have specially the right to update all these info or assign the people to certain groups which are representing organizations or do other changes. Also have desk stuff-- it is a fluctuating industry. It can happen that you just get new people from your service provider who may or may not have a good expertise in Active Directory.
You don't necessarily want to give full access. You don't want to risk that something is made wrong, not to mention that there can be lots of information-- sensitive, personal, or other information stored in the directory which you don't really want to expose to any third party. Not to mention the opportunities when you can implement workflows to improve the efficiency by automating all those repetitive tasks. If there is room for doing a failure, there will be a failure. If you automate the things, then it is just happening as you expect.
But we can also talk about AD administration. Even if you are an admin, you don't necessarily need to have access to everything. You may need access to specific organizational unit. You may need access to specific object types like computers, not everything else. Also, there are specific tasks on certain objects or on certain attributes which are so sensitive that if you change them, some extra approval would be great to have.
Also, we should of course talk about the problem of leaving credentials behind. There are hashes left within the memory, and that's something you definitely should clean up all the time you are accessing Active Directory in case the attacker gets so deep that they have access. Still, you wish to recognize if there is any account theft happening. That would be ideal, isn't it?
At the same time, still, as all actions are audited, it would also be great not only to replay and review what has happened, but maybe to restore if some mistake has been done. At the end of the day, administrators would also be happier if they could take their time on more valuable works instead of just doing the repetitive tasks, which anyone can do.
Now, how does this look like in practice? So let's turn it to technology. Let the end users modify their own details through a single sign-on web portal. Similarly, for helpdesk, they should be able to fulfill change requests in Active Directory just through a simple to use web portal. Of course, since they are accessing more information and more details to enforce multifactor authentication.
As for administrative access, of course credentials should be voted and access to these credentials must be audited. The approval process to log into the system must be swift, easy to handle for even managers being on the way. The administrative accounts should only be dressed up, should only be elevated when they are in use. So let's imagine even an account is still done. It cannot do anything because it does not have the privileges. Certainly, when there is an additional, critical changes may require additional approval depending on what level of sensitivity the task has.
And last but not least, we'd not only rotate the passwords, but you have the ability to complete deactivate the account. It's there, but it has zero standing privileges. Last but not least, it would be ideal if you could just identify by a single click what privileges an account has or what outliers do you recognize in Active Directory from the typical setup.
OK. This sounds great, but it sounds complex as well. Not with One Identity. I use the phrase playground here because to me, the unified identity platform is a playground. It has all the pillars that you need. It has governance. It has access management. It has security and it has privileged access management.
So for an engineer like me, building a solution which I just described on the previous slide is something I can do. I have everything at hand. I just need to configure them to achieve success. On the following slides, we can see the different components of the unified identity platform as working together, and I am highlighting now the elements which we are going to use in today's demonstration.
The basic, the core is Active Roles, the AD management and security solution which is basically a proxy. The basis of everything is that the changes in Active Directory can only be done by the proxy account used by Active Roles. It can manage AD. It can manage Azure AD or enter ID as we call it today-- not only a single forest, but any number that you wish to.
Let's add multifactor authentication on the top. In this demonstration, we are going to use OneLogin, the SaaS-based access management solution of One Identity. We bring in Safeguard, the PAM suite of One Identity, which is going to provide us with the administrative access request workflows, session auditing capabilities, and many more, which, if we integrate with Active Roles, we can achieve through just in time allocation for the administrative accounts.
OK. We now have everything at hand, so let's just build this. On this slide, I am going to introduce how the architecture and the demo flow, the user flow looks like. On the top right, you see the three use cases which we are introducing today.
First is when an end user modifies some details via SSO. Second, when I have desk staff who fails the request-- again, through a web interface and forced MFA. And last but not least, we are going to use a true, least privileged administrative access within Active Directory.
So let's start with our end user. First of all, on the bottom of the slide you see Active Roles, which is the virtual proxy around our directories-- AD, or Azure AD. All those small rectangles, the deposit boxes may represent certain objects of attributes, organizational units, whatever tiny pieces within Active Directory which your end users or which your actors may need access to.
So if I look at the end user again, you see that light blue rectangle blinking. This is what the end user has access to. So what does the user do? Takes his web interface on his laptop, logs into Active Roles, performs the self service change, and that's it. It's fulfilled. It's so easy. You did some change without giving right. Still, you made the change within Active Directory.
The second case is our help desk user. If you look at the rectangles blinking, the help desk user, of course, has access to multiple tanks within Active Directory. Now, our user is initiating a change, but it's only possible once the verification has been done with OneLogin. The change is just initiated to Active Roles, but it's not fulfilled because the system owner is informed. And once the approval is given, then as you can see, the arrow the change is taking place within the directory itself.
Last but not least, let's talk about our administrator. As you look at his computer now, he or she is using not only a web browser, but also an RDP application as well. You will get the details why it is happening in this case, but first, let's see that our user is raising an access request towards the Safeguard fridge password vault. Of course, accessing the vault requires multifactor authentication, and an access request can only be given if it is approved by an IT manager.
Now, an IT manager might not sit in front of the computer all the time. They may be on the way. So it is very comfortable to give approval through Teams or Slack-- which messaging applications they just have on their phone, for example. And this is the time when the approval is given. This is when the machinery kicks in.
So you see a Microsoft remote app jump host on the side. You see that there is a gray icon, a gray user with the crown representing the privilege account. Right now, it is gray because this user is completely inactive in Active Directory. But once the approval is given, the vault is activating the account, shares the request details with Active Roles.
I am replaying this now, which is starting to calculate dynamic memberships, which are built according to who the user are, what he needs access to. And it is the time when actual memberships, actual entitlements are assigned to the freshly activated account. Once we have the permissions, once we have the accounts in place, our user is initiating a session. And on the jump host on this remote app device, a privileged browser is just launching and letting the user to access Active Roles-- however, impersonated using the credentials of the freshly activated account.
Now let's have a look how does it look like in action? In our first use case, we are going to introduce how easy it is for the end user to modify their own changes. Let's imagine the scenario that we are hiring a new Linux administrator called Linus. Linus is receiving a company phone, and he was told to update his phone number in the directory because there is some verification system which is tied to his phone number.
So what is he doing? He is logging into the ActiveWorlds portal given by his Manager, and he can immediately see his personal details. He does not see anything else, just his own profile. He can see his name, he can see his email address, and he can see that the phone number is a value that he can change. OK. He was requested to do so, so let's change. And that's it.
Now, Linus is a smart guy, and he is recognizing on the right side that there is something called Unix property. So as he is hired to work with Linux systems, this is something immediately raising his attention. So he's just clicking on it, and he can see that there are details here which probably should be available for him, but it's grayed out. He cannot change it. So what is he going to do? He's just going to the ticketing system and raising the request to get those privileges.
On the next video, we are going to see what happens to this request afterwards. So Dana Harmon is a member of the help desk staff and got this request from Linus. So she's trying to access Active Roles, but as having access to more tanks within Active Directory, she of course needs to verify her identity with multi-factor authentication. In this scenario, this is given and enforced by OneLogin, the access management platform of One Identity.
Now, as Dana logged in, she is immediately searching the account name, the user who raised this request. And she can double-check based upon the known information that this is the right user. She can check the email address, and she's going immediately to Unix account, to Unix attributes.
Now, Dana came from the Windows world, so she has not many things to do, does not know many things what all these attributes mean. But that's not even a problem, because she just needs to enable Unix access. And of course, since this is giving authentication access to Linus through AD bridge to all Linux systems, then this is requiring an extra approval.
Now the change has been submitted. And now let's play the role of the manager. So Susan Mangrove, the manager, the IT system owner is logging in to Active Roles. And she can see that there is a pending approval. She can see that it was raised for the user, Linus.
She sees what the change was. She can see the additional details, like if there is any delegation possible, any other approval required. But since this was agreed, and it was a simple one level approval, she's just giving accept. And if we go back to Dana's screen again and see how does the configuration look like for Linus, we can see that all details have been filled automatically by the system.
In our last video, we are going to showcase how does the administrator access Active Directory through Active Roles and the Safeguard PAM system. So the actor of this demo is Rob Usher, our administrator who has an administrative account in Active Directory. As you see on the Active Roles console, his admin account is currently disabled, and it does not have any group memberships, except the default domain users.
Now, let's have Rob accessing the Safeguard vault where he is logging in with his AD account. Of course, accessing the PAM system requires multi-factor authentication. In this case, we are using OneLogin again. And once Rob authenticated himself, he can raise a request.
Now, what he's what we see on the screen that Rob would like to access-- the Active Roles web console using his ADM account. So he's raising a request, and according to the PAM workflows, he needs to select the reason, and he needs to put a comment in. In our case, the access will be required to assign a license to the user in Office 365, which does have some financial impact to the company if such things are made.
I post the video because now we can see that there is an approval workflow started within the system itself. If we click the workflow status, we can see that our approver, again, is Susan Mangrove, who has the ability to get notified, who has who has the chance to get notified over Teams, see all details of the request, and give approval. Once it is done, the approval is given, Safeguard is just putting the request into a pending restore state.
What does that mean? If you recall to the slide about the architecture and the flow, Safeguard is basically triggering the activation of the account in Active Directory. And in the background, Active Roles is starting to configure the dynamic rules. So if we look at the console now and refresh it, the admin account is deactivated and we have a just in time dynamic group which requires the permissions required to perform this task.
Rob is just clicking the play button. The privileged browser is starting up, and we see an access with the admin account with the password injected into the session that Rob can do the administrative tasks. Rob does not have access to everything either in Active Directory, but of course, he has way more entitlements than the hard desk or the end users. He can search Linus again and see the Office 365 account. He can double check that he's working with the right account based on the UPN and just go and assign the licenses for Office 365.
Now, if you have this in many tenants-- if you have licenses, if you have changes in many tenants, of course you could do it through this single pane of glass of Active Roles. If we go back to the PAM system and check the request in, which means that role does not require the access, the permissions anymore, then while the request is closed, the account gets deactivated again. And all the permissions which have been given-- all the dynamic group memberships which the admin account had are just dropped.
But the story does not end with this because Rob's private session was audited by Safeguard for private sessions. It has an analytics module which is building a baseline of Rob's activities based on multiple behavioral attributes. It checks frequent item set. It also records when the user logs in. It checks which Windows he is using-- if it is on stage, which commands is he using. And it is also checking the mouse movement.
It applies through biometric analytics on the remote sessions. And as we see, it is not only the basic algorithms which are showing a normal score, but the mouse movement is also receiving a score of 8 out of 100, which confirms to us that there was no account theft. It was really Rob working behind this account.
Identifying privileges-- first, let's take a couple of words about what kind of privileges can we speak of. There are the built-in security group memberships, to which there can be direct or nested assignments giving harmful powerful rights for the end users. There are also ACLs on the Active Directory objects which may also give power to the user to their hand, which could be assigned directly or through an inherited manner. Within Active Roles, we provide immediate access to many of the entitlements just through the Management Console.
First, if you look on the bottom right side, there is a native security tab within the Management Console which contains information about all of the entitlements, all of the native security rights which the user is having within Active Directory. Second, there is a separate tab which shows what kind of delegations are given through Active Roles. We might not forget that Active Roles implements least privilege for Active Directory.
Without configuring these delegations, the users have no rights to anything. Of course, this gives a complete list of what the user has access to on a specific object-- on a specific attribute for example. Last but not least, there is an explicit list of all the policies which are responsible for putting those raw delegations within Active Roles in place so we do understand where the rights the user has have came from.
In addition to the Management Console, Active Roles also comes with a reporting module. It collects information from Active Directory so as from the Active Roles database, and it comes with a default set of reports on various categories. For example, you can have an immediate access to what administrative roles are assigned to the users or you can have a list of what changes have been done through Active Roles within Active Directory.
If you are interested in a specific object type or the rights around it, you can just go to Active Directory assessment and drill down into the different categories. For example, if you click to group memberships, you can get a list of memberships of the users, you can get a list of group memberships of the users, or you can see a list of the users who has administrative rights to these group memberships within the database.
Before closing, we would like to ask how do you handle pre-register and Active Directory today? We suppose that you have traditional privileged access management around, but according to our experience, many of the organizations still use static writes and static accounts within Active Directory. Based upon the information you have seen, what enhancements would you like to achieve in your infrastructure? Also, if you have any further ideas which you would be happy to apply in your Active Directory for privileged management, we would like to hear back from you. We would like to thank you for your attention and grab the opportunity to thank again to our sponsors who helped us to put One Identity Unite together. Goodbye.