One Identity Manager | Privileged Account Governance #5 | Request Session and Password

[MUSIC PLAYING] In this scenario, our user, Randy, likes to order in the One Identity Manager [INAUDIBLE] web portal just access to a Linux session. For that, we will order in the first step the Linux session. We'll get it fully granted. And at the end, we will log in to this Linux box. So the person who is doing that is Randy. We created the user in a session before. So just give him a chance to log in. So here we are. We place a new request. This time, we search from the Privileged Access Requests site. This is what we want to request. We can request the password. We can request an RDP session to a Windows box. We can as well do the same thing here with an SSH request. So we order the SSH request. And once we are doing that, the next step is that we have to select the asset. There is just one. We remember the name. It's iams10. And we need an account for. The good message is, there is only one of them, PAM asset. It's safeguard2. We remember now safeguard2 as well. So machine, iams10. User, safeguard2. So it's now done. Rest is like it should be. Save. We can enter as well a reason-- for example, system maintenance. And last but not least, we submit the request. As typical, we can now look into the request history and figure out who is responsible. We will see, this is the person who ordered. The workflow section says, these are the set of people are allowed to approve the order. As we can see, in difference to our scenario before, there is now one user more, which looks like the responsible resource owner of that specific resource. Whatever we take this user, just to do an approval. So I switch again my hat. I leave Randy and just step to this guy here. So we'll log off and log in as this user. Here we are, one pending request. As we can see, it is an SSH session request. We will have approve that. We can as well have a look into the workflow. This is the first step, compliance. There is privileged access governance. That is what we just order. I approve this now. And as we remember, in difference to the Request History, I have now to use, under my Actions, Approval History, for that this is my session request you can see there. This is the workflow. First step is just ordered. Second step is now to prove Safeguard. Is there something in addition-- a Safeguard workflow, for example-- that have to work? What happens there is that the machine itself is now querying Safeguard, asking for a workflow, and if there is a workflow, asks if the workflow is then finally approved. It looks like this is not the case, because that Safeguard step is as well done here. So now, we are waiting on the last system approval. Looks like that is done again here. It's finally granted now. That means there should be now a session for Safeguard. So we switch our head again. We leave the approver and step back to our requester, which was Randy. And our Randy, at the end, should then, by My Requests in the Request History, find this as assigned as well. Here we are. I can then, for this specific session, step to Privileged Access, for example. And I will then, he'll see, start privileged access. I have to log in into my Safeguard web portal. Remember, we created an account for Randy before. Here we are. We just step into-- we can see here our machine. We want to log in there. So just click on it, hostname. So Show. This is the token we need just to step into. So I just copy the token by clicking on Copy. I open my SSH front. I place the token. I open it. I have to agree to the certificate. Here we are. And seconds later, we are in the machine. If this is true, then I am now safeguard2. That was the user we selected. And I can as well look into the host. And wonder, wonder, it's IAMS10, the machine I want to use. With that, this scenario is done. We saw it is easy just to request-- so for example, a session in the Identity Manager to get it granted, understand the workflow, and at the end, to use it with Safeguard. Again, this is an easy out-of-the-box workflow we used. It is possible to build any other workflow as well. [MUSIC PLAYING] One last thing of interest-- as we saw, now, three approvers-- remember, we saw Target System Admin approvers first. Now we saw three approvers in the second scenario. And it might be of interest where these approvers are configured. If we step into the main data front end of the Identity Manager, which is the manager-- here we are-- and we step into the section of One Identity Manager and Administration, which are the application roles, then, we saw before, underneath of Target System, Privileged Account Management. This was our Target System Administrators, responsible for just approving new users in Safeguard. But additionally to that, if I just step now here into the Privileged Account Governance section, then I will find there asset and account owners. If I look into that, then I will see the three approvers that was in the list of approvers for that specific session request we made. Here is the third person we used. And what's to know is that if I need more of these-- I like to say roles where we just sought approvers for different assets and different request sessions and password requests-- then we can do that underneath of this specific section. And we can build out as many of these roles as we need. [MUSIC PLAYING]