Hello, and welcome to Unite's Deep Dive: Active Roles and Safeguard Better Together for Privileged Security discussion.
My name is Wayne Smiley. I'm the Principal Architect for the Active Roles product here at One Identity. And as I mentioned, we're going to talk about integration between Safeguard and Active Roles. Specifically, we're going to spend some time teaching you how this stuff works, how you can do this integration yourself, and what the real advantages are.
Let's start with the advantages. First of all, as we all know, anything we can do to better secure our accounts in Active Directory is certainly a great thing for all of us.
For example, there's the dreaded Pass-The-Hash. Anybody with five minutes of googling and a copy of Mimikatz can do whatever they want and start destroying your Active Directory environment. Why? Because as they can crawl through the Directory, and gain more and more privileges as they do it, they can eventually get all the way to the utopia, if you will, of the domain admin account.
The reason they can do that is something called hashes. In older versions of MTLM, which are still pretty much required for just about every environment, a hash is laid down on a machine when you log in as a user with those privileges. If somebody can get enough rights on that machine somehow, which is usually not too difficult to do, then they can use that hash and basically mimic that particular user and use those privileges to do whatever it is that they want.
So if they use that, then eventually they can get themselves enough rights. And they can find an account that will allow them, the domain admins, yada, yada, yada. We'll go through the whole process of that happening.
But the reason that this is so important is because this is how most ransomware ends up destroying organizations. They get into one machine. They do something nefarious to convince somebody with privileges to log into that machine and do something else. And then, eventually, they use those rights to take control of the environment. But if we can reset that hash or make it so that hash is effectively useless, then that entire process and that ability disappears.
And that's where this comes into play. I'm going to demo this in a minute. But the bottom line is, what we're really doing here is we're making sure that when somebody logs in as a highly privileged account, they're checking that account out through Safeguard. Which is probably what you're doing if you're using Safeguard now or doing it through a privileged session. But in either case, you're basically using an account to do it. And that account is in a group that has high privileges in most cases.
So what we're going to do is two things. Number one, we're going to disable that account, which means that the hash is no longer valid because the account won't authenticate anymore. But more importantly than that, we're also removing the rights in that account, which will do a few things. It will effectively change the hash which, again, makes it not useful.
And two, by removing it from that group, we instantly remove the rights and the privileges from that account. So even if somebody were to grab that hash in transit or whatever, they're not going to be able to do anything with it. And that's what's critical. So let's get into it and we'll show you how all this is actually done.
Let me explain to you a few things we have here. I have my bridge account. This basically is the account that's used between Safeguard to actually talk to Active Roles. Here is my domain admin account that I am checking out. Here is a group that I've nested inside of domain admins.
So we can actually see this is a member of domain admins. And the reason that I did that, and you'll see why later, is that it needed to be a dynamic group. And I obviously can't just make domain admins a dynamic group. I mean, I guess I could. But I probably don't want to.
So let's show what happens when this actually happens. So let's go over here. I'm in the Safeguard console. I'm logged in. And I have accounts I can check out. But I've just made a favorite for the one I want to check out. It's a domain admin account. We can see it right here. Yeah, it's this particular account. The one I just showed you a second ago in AD. And we're going to check it out now.
And you're going to noticed something interesting when it checks this out. We see a pending account and then available. What actually happened then is it reached out to a service in Active Roles. And you can see that service right here. And we'll go through the nuts and bolts of what happened a little bit later.
But basically what it did is it took this account-- Now you'll notice, also, that this account is enabled while it wasn't a minute ago. And it enabled the account, and it set a virtual attribute. That virtual attribute, we'll add it to this particular group. And you can see here that that's exactly what happened. It's been added to that group.
And as we know that, if I open up this user now and I go and look at Member Of, then I can see they're a member of that temp domain admins. And if I show nested groups, and we scroll down here, we see what we really care about, which is that user is a domain admin.
OK. So I go on. I do my work. And I check it back in. And see, that's going from available. And it's now gone in to check back in. And we could do, obviously, everything else in Safeguard that we need to do. But that's not a discussion for today. Today we want to see what actually happens.
So let's just refresh that Directory real quick. And we'll notice, now, that account is disabled. We will also notice that, if we go to the Member Of, they are a member of domain users, obviously, because they already always were. But they're no longer a member of domain admins or anything else related to that. So we can see that that's the case.
And if we take a look at the group, we can see that they're no longer in that group. Let's click over here. And you can see there's nobody in that group, which is exactly what I expect to happen.
So now let's take a look and see what actually happened here. It's really not that complicated. We're already alluded to some of it. But we're going to walk through this, beginning to end.
Essentially what's happened here is that Active Roles is using a few things to make this happen. The first thing we're using is just a simple virtual attribute. So if I go over here and I go to my virtual attributes, we can see that I have an attribute called EDSVA-ARSGJitAccess. This is just a binary attribute. But anyway, it's a binary attribute.
And so we can just flip that from true to false. Why do we need a virtual attribute? It seems kind of weird. Let me explain to you why.
If we go back over here and we go to the accounts, you'll see I have this dynamic group. And again, we talked about this a second ago, but now you're going to see why.
If I go to the membership rules of this dynamic group, it basically has two things. Number one, I'm looking for a particular username. And if I have multiples, then I say, Starts with, this.
But the other thing, and this is the more important one, is that that virtual attribute is, in fact, set to true. So in order to be in this particular group, you need to have that virtual attribute set to true. And you need to have a username that adheres to that particular thing. And, of course, it needs to be in this OU. Not want to edit that.
And then, of course, as I think I mentioned before, we need to know what happens to that group. And we know, in fact, that it's a member of domain admins. So obviously, by being in this dynamic group, they're effectively a domain admin.
So what actually happens? When you check an account out with Safeguard, we've put some stuff in there that will go in. And I'll show you this in a couple of minutes when we get a little bit deeper. But I'm showing the Active Roles site here for minute.
It's going to reach out to that service in Active Roles, call it via a service that we've setup that I showed you a minute ago. And it's going to say, I want you to enable that account, number one. And number two, I want you to set that virtual attribute to true. And then when you check the account back in, it does the opposite.
So let's talk about why that's so important. As I mentioned before, by disabling the account and removing it from that group, we've effectively made that hash useless. So anybody who has it and is going to try to do something nefarious with it will no longer have the ability to do that. And that's what we really want. We want to make this as secure as possible.
And this really differentiates us from a lot of our competitors. Because our competitors, maybe they can enable and disable the account, but bringing things in and out of groups is not something they generally do. Active Roles, of course, does a fantastic job of that sort of thing. And we could do a million other things if we wanted to. But we're taking care of that.
And let's talk about how Active Roles is, in fact, actually doing it. What it does is there is a policy. Actually, let's go and check that.
There's two things. There's an access template. And here we created this access template. And what this access template does is basically, it allows-- This is what the service itself is using. It can read all properties.
And it, of course, can write the mystical virtual attribute. And we can list domains and users. Because we just want to be able to. We probably don't need those, necessarily, but that's what we're doing.
So what we've done is we basically set that virtual attribute for our service account user who is way deep in there. My Just in Time user, he's my service account user. And we've set that access template over that service account OU.
The other thing we have is somewhere in here. We have a policy that makes sure that we don't do anything weird. So again, we have the access template and the virtual attribute. And between those, then we're able to basically do everything that we want to do on the Active Roles site.
So I think you have a pretty good sense of how this works on Active Roles. Let's take a quick look at how this works on the Safeguard side as well.
So it's again, like I said, just bring up Safeguard here. And we can just take a look around. And we're really not doing anything particularly special in Safeguard. What's really happening here is that that particular service that we have is logging into Safeguard from the backend.
And what you'll see is, when you set up the service itself, you tell it how to connect to Safeguard. And so it knows how to do that. And it's looking. And when it sees what it's looking for, it will make those changes inside of Active Roles.
One more thing I want to point out. This entire process will actually get considerably simpler in the near future. What you're looking at here is something that we give customers but isn't necessarily something that is documented and supported at this point.
But with the addition of the REST API, which we're talking about in a different session, we're allowing this to work much more easily and, probably, I believe, without a service or anything else. And the reason for that is everything that Safeguard does is done through REST. And now Active Roles is going to be able to do the same.
So Safeguard will just be able to make a REST call when an account is checked out and say, hey, Active Role, go do what it is that I want to do. Let Active Roles do that. And it really takes away a lot of the complexity that you've seen today.
But it was more important that we get something out now and so that our customers like you can use this and actually benefit from it today. And that's why we have this.
I hope this has been helpful. And I hope you enjoy the rest of your night. Thank you very much.
09:58