Supporting Zero Standing privilege with Secret Server for Vaulting
See how Delinea Secret Server enables just-in-time (JIT) privileged access with approval workflows, vaulted credentials, and Remote Access—so contractors and third parties can complete their work without ever seeing passwords.
What I'm going to show here is this screen, which is the cloud admin account.
So this is my cloud admin account. We're going to have a requester, and they're going to submit a request for a just-in-time account that I set up.
I'm also going to give you a little preview of what Remote Access looks like because, again, that whole sequence is what most contractors should be using.
This use case is more for customers that have a lot of contractors coming in who only need access to certain systems or certain accounts for a specified amount of time.
So right here, as we go through, I'm just showing you around and showing you that I'm the cloud admin user.
I navigate to my Secret Server.
Again, I want to make sure that everybody understands that this is Secret Server inside the Delinea Platform.
So if it looks slightly different, you can disregard all of the extra tabs.
This is the same in Secret Server. It should all be one-to-one.
Right here are my two just-in-time accounts, and I'm just showing you what the cloud admin can see.
You can see that the recording is enabled for any launcher. Whether I'm using the native launchers or Remote Access, recording is enabled for both of these accounts.
The one we're going to be using is Just-in-Time 3. I'm clever with my naming convention.
Now we're going to switch over to my end user.
He's going to log in, and once he logs in, you're going to see that he has a very limited view.
Mine was much more advanced. I had a bunch of other tabs.
Now this is a contractor logging into Secret Server.
They're going to go to the Vault, and they're going to see the secrets they have access to.
The two, obviously, for this demo are the just-in-time accounts.
When they click Just-in-Time 3, this is what they see.
They can see the secret, but they can't do anything with it until they request approval.
Once they submit that request for approval, they can define a reason for the request.
Again, this is different from comments, which I'll cover as well.
I'm going to pause here because you can see he requested 30 minutes. That's just the default duration we configured.
The request gets submitted, and we go back to my cloud admin account.
He's one of the approvers, and I can see the request in my notifications.
I can go into the details if I'd like to change it.
Again, because I don't want him to have access for 30 minutes,
I'm going to modify it like we talked about in that workflow.
I'm only going to give him three minutes.
I'm going to put a comment in here telling him that this is only good for three minutes because this is for testing.
Obviously, you wouldn't do this to your contractors.
Now we come back here, and you can see that the request has been approved.
If I did not have Comment Required enabled, the end user would now be able to use the secret as needed.
But I also wanted to enable the Comment Required feature.
So if you don't enable approval for those secrets because you don't want to manually review every request—you know they're the owners of those secrets and should be using them—but you still want to track a comment, you can enable that on the secret template.
Now I'm just going to enter a comment here. Two birds, one stone for this demo.
I'm going to say that I'm testing it for PowerShell.
This part is important.
The reason I'm sharing this and calling it out is because I want you to notice that we're not displaying the password to this user.
My admin can see the password, but this user cannot.
All they see is the secret information.
As we move forward, my approval window is going to expire, but I launch my session with Remote Access.
I never see the password.
I click Remote Access, and what's going to happen is a web browser session is going to launch into my Windows Server using my vaulted credential.
Again, if I needed to enter this user's password because I wanted to run something and it prompted me for it, I wouldn't know it.
I'm just showing here that the user is Jade.
Because I am logged in as Jade on this system, I can elevate PowerShell and start performing the tasks I need to on this system because that's the one I have access to.
So this is my cloud admin account. We're going to have a requester, and they're going to submit a request for a just-in-time account that I set up.
I'm also going to give you a little preview of what Remote Access looks like because, again, that whole sequence is what most contractors should be using.
This use case is more for customers that have a lot of contractors coming in who only need access to certain systems or certain accounts for a specified amount of time.
So right here, as we go through, I'm just showing you around and showing you that I'm the cloud admin user.
I navigate to my Secret Server.
Again, I want to make sure that everybody understands that this is Secret Server inside the Delinea Platform.
So if it looks slightly different, you can disregard all of the extra tabs.
This is the same in Secret Server. It should all be one-to-one.
Right here are my two just-in-time accounts, and I'm just showing you what the cloud admin can see.
You can see that the recording is enabled for any launcher. Whether I'm using the native launchers or Remote Access, recording is enabled for both of these accounts.
The one we're going to be using is Just-in-Time 3. I'm clever with my naming convention.
Now we're going to switch over to my end user.
He's going to log in, and once he logs in, you're going to see that he has a very limited view.
Mine was much more advanced. I had a bunch of other tabs.
Now this is a contractor logging into Secret Server.
They're going to go to the Vault, and they're going to see the secrets they have access to.
The two, obviously, for this demo are the just-in-time accounts.
When they click Just-in-Time 3, this is what they see.
They can see the secret, but they can't do anything with it until they request approval.
Once they submit that request for approval, they can define a reason for the request.
Again, this is different from comments, which I'll cover as well.
I'm going to pause here because you can see he requested 30 minutes. That's just the default duration we configured.
The request gets submitted, and we go back to my cloud admin account.
He's one of the approvers, and I can see the request in my notifications.
I can go into the details if I'd like to change it.
Again, because I don't want him to have access for 30 minutes,
I'm going to modify it like we talked about in that workflow.
I'm only going to give him three minutes.
I'm going to put a comment in here telling him that this is only good for three minutes because this is for testing.
Obviously, you wouldn't do this to your contractors.
Now we come back here, and you can see that the request has been approved.
If I did not have Comment Required enabled, the end user would now be able to use the secret as needed.
But I also wanted to enable the Comment Required feature.
So if you don't enable approval for those secrets because you don't want to manually review every request—you know they're the owners of those secrets and should be using them—but you still want to track a comment, you can enable that on the secret template.
Now I'm just going to enter a comment here. Two birds, one stone for this demo.
I'm going to say that I'm testing it for PowerShell.
This part is important.
The reason I'm sharing this and calling it out is because I want you to notice that we're not displaying the password to this user.
My admin can see the password, but this user cannot.
All they see is the secret information.
As we move forward, my approval window is going to expire, but I launch my session with Remote Access.
I never see the password.
I click Remote Access, and what's going to happen is a web browser session is going to launch into my Windows Server using my vaulted credential.
Again, if I needed to enter this user's password because I wanted to run something and it prompted me for it, I wouldn't know it.
I'm just showing here that the user is Jade.
Because I am logged in as Jade on this system, I can elevate PowerShell and start performing the tasks I need to on this system because that's the one I have access to.