In this video, I will showcase both the power and more importantly, ease in achieving automated elevated zero trust by integrating Active Roles with one or more components of these Safeguard security stack. But before we get started, I just want to do a quick level set.
When it comes to the magical world of privileged access, there really are two sides to the proverbial PAM coin, if you will. There is what I refer to as, I am me, and then there is I am you. I am me simply being the act of performing a privileged action on behalf of yourself, i.e. own user ID. Whereas I am you, is the action of performing those same activities but moonlighting as somebody else, i.e. the shared account scenario. But first, let's start with I am me.
Just like anything in this space, there are in fact fundamental underlying issues with this approach. The first being the struggle of maintaining access on a system by system basis. The manual administration of both user accounts and corresponding passwords. But as we know, that's only half the battle. Because now you still have the pain and suffering of managing who actually has the capability to elevate their access for what command or commands. So, great shock, the size of one's environment can only and will only exasperate the magnitude of this issue.
Fortunately, One Identity can solve that issue by using two components. The first being Safeguard Authentication services. By implementing SAS, you will immediately make your Unix Linux nodes citizens of Active Directory. And that, by its very nature, will allow you to authenticate in the set endpoints using your AD credentials. Thus eliminating the need for not only managing local user accounts but even having them to begin with.
Finally, couple that with the inherent ability to use AD groups, that will now further allow you to secure which systems an end user can even authenticate into to begin with. Now, bear in mind, that only solves half the problem. We still need to address the allowance or lack thereof of a user being able to have any form of elevated privileges. And that can be addressed with Safeguard for Unix Linux.
You can encapsulate the entire administration of SUDO inside what we refer to as a policy server. You can not only control elevated access based on group memberships, thus once again harnessing the native security of Active Directory, but take it a step further by restricting command execution by time of day, day of week, IP location, even favorite ice cream flavor.
Unfortunately, this still doesn't completely solve the issue. Why? Because someone or something still has to handle the management and integrity of both system access and privilege capabilities. And it's with that, that we introduce the power of integrating the prior Safeguard components with our flagship hybrid 8D management and security blanket, Active Roles.
By combining these two technologies, you can be absolutely assured that you have solved this problem 100%. As we segue into a quick demo, here is the following scenario that you will be shown. Any user which is part of the IT department will automatically be granted access to a handful of Unix systems. Bearing in mind that that user will not have any form of elevated access. This will also be shown. However, any user within that department, which either has a job title of, I don't know, DBA1 or system analyst one, will now have those special privileges. And with that, here we go.
Hi, ladies and gentlemen, the world's smallest HR flat file. All right. So, as you can see and hear that Robert is in the IT department so he will have access to the system. That's about as far as that's going to go because as he has the title of CIO, he will not have any type of admin privileges. That I'm pointing out the fact that he's also in Seattle, this is important because my tree is designed geographically. Therefore, based on the city you're in will determine the [? OHU ?] that you're account will be created in.
So, in this case, you will be in the Seattle container, which you can see right now he is not. So, to bring him in, we're going to open up the synchronization console for those that are familiar with Active Roles, do a quick import, which of course will also involve doing a pre-flight check. So, barring the end of the world everything should work out perfectly fine. Which it did, we're going to do a quick commit. Bring Robert in. Hop back over to the Active Roles web console, do a refresh, and what do you know, Robert is now here.
But I want to open him up and take a look at a couple things really quick. First and foremost, I want to point out the fact that he is now Unix enabled. Again, this is because he will be part of what's called the Unix, just a regular Unix roll group, which you can see here a Unix nodes group which I've created. Unix nodes gives you access to the box but that's as far as it is going to go. In order to have SUDO privileges, you'd all set to be part of a group called ARS Unix Admins, which he is not because he does not have the proper job title.
So, we're going to do a quick log in here, going to see he's being prompted for his Windows password, not to be confused with the local password. Do a quick who am I. So, I'm going to run a couple series of commands. The first one will do a validation check that will prove that the Unix node does in fact not see Robert as part of that ARS Unix group. He will only be part of the Unix nodes group, which going again is failing, so verification that he has no admin privileges. Just for kicks we're going to do the good old SUDO-L which is going to come back and complain.
Again, this is one more level of validation that Robert has no admin privileges. Now, that being said, we're going to hop over and we're going to make one change. Probably know what it is. We're going to give Robert the proper job title. Beautiful thing about this is it truly is real time. There's no need to like rerun another feed or rejigger anything, this truly is immediate. You can see right now it's in here. Open this account back up. Go to the groups area. And you should also see the ARS Unix admins group. This gives anybody who is a member full blown SUDO privileges, elevated privileges on that box.
So, without doing anything else again, we're going to go back, rerun those same series of commands. The first one we'll do a validation where you will see that Robert is now part of that, the box we'll see him as part of the particular group. Keep wanting to call it passive but Safeguard for Authentication Services will say, yay, he's part of the ARS admins group. Do a SUDO-L, get a list of all the commands that he is now authorized to run.
And just for sheer amusement, we are going to execute this vastool elevated command without prefacing it with SUDO just because we can. And it's going to fail. Then we're going to put SUDO in front of it and great shock it will not fail. Do that now.
We could end this part of the demo but you know the old saying, put things back the way you left them. Go back in. Probably obviously have nothing better to do today. We're going to switch this back to a different job title. Then again, just like before, the change will in fact be immediate.
Again, no need to kind of go back in and message some things because again, it's already there. Again the group's gone. Rerun the same series commands one last time because the first 15 times around it apparently wasn't good enough. Get validation. He is not part of the group. He has absolutely no SUDO capabilities and then again, bigger final shock, that when he goes to execute the command it will once again fail miserably.
Returning back to our regularly scheduled problem, I meant program. Let's now take a look at side two of the PAM coin, I am you. Just like side one, great shock, there are inherent issues with this approach as well. The first is undoubtedly the most obvious. A complete lack of accountability on who is moonlighting as who. Too many people not only know the name of the shared account, we'll call him Bubba, but worse yet, they know Bubba's password.
The second is one that unfortunately, far too many people don't really think about. And that's advertising the entire world population that a particular account actually has elevated privileges to begin with. What do I mean? Think about it. Naming conventions. How many times you see A-Bob or Billy-Admin as the name of the privileged account. Really people? Yep. See? And there you go.
Now, the good news is, I'm sure most may or may not already know, that we too can solve that aspect of the problem. Using our Safeguard for privileged passwords offering. Giving an end user the ability to quickly request or checkout access to a privileged account for a specific period of time. But again, this only solves the first piece of that puzzle. How do you solve the second? You got it. By integrating this component of our Safeguard offering with once again good old Active Roles.
We do this by taking in account one that is stripped of any possible admin privileges then adding only the required privileges during the checkout process. Once the task is complete, the rights are once again completely removed. And as an added bonus, the account is placed into a disabled state. Let us return back to the demo environment for a quick example of this.
First things first, we're going to hop into the Active Roles admin console, take a look at the user that we are going to check out, which in this case will be SG temp dom admin 1. You'll notice that the account has actually no elevated privileges, no special fancy schmancy groups, and the account is currently disabled. We are now going to hop over into the handy dandy little Safeguard client, log in with a user, preferably one that has the ability to check this guy out, which in this case to be the infamous good old Todd Lord.
Go on as Tod, do a new request. We're going to want to go against the DCL one box because anybody can go against a non domain controller. Grab the account right here. Check him out, click OK. And literally, we're going to make sure do it immediately, through the magic of television, one continuous camera shot as they say, the account you will notice has been immediately enabled. Open him up and he now has the special domain admin privileges.
We'll now go ahead and actually use his account by clicking that handy dandy play button, which will then launch an RDP session in this case. All going well, he should go right in seamlessly. Now we could have set this up to do some form of 2FA and what have you but we're not going to do that because that's not part of this mess. He's in, he can do what he needs to do, move some stuff around, delete files he shouldn't be deleting, and then he will go ahead and log off.
And like any good person, once we're done with that, we're going to go check the account back in. And you will see that upon doing so literally, again, with one continuous camera shot, the account has been magically disabled. Which you will see here, once we get past this freaking close window. And hit a little refresh button here. Come on. Doo doo doo, doo doo doo doo doo doo doo, doo doo doo doo doo. And the account has been, there we go, disabled. Open that up, take a quick look here. Memberships have disappeared, so there you go. JIT with Active Roles and Safeguard.
So, there you have it. How to successfully achieve elevated zero trust with One Identity, integrating Active Roles with legacy passer to achieve the I am me problem and Active Roles with, well the other half a Safeguard, for the I am you. Hope you enjoyed.
14:12
