Hello, I'm Wayne Beaudin, the principal product architect here at One Identity. In this short video presentation, I'll be discussing the challenges and best practices surrounding service accounts.
So what are some of the key challenges? First of all, identifying surface accounts. What is out there? Who knows what's out there? What accounts are they running? Are the passwords for those accounts being managed? Do we know when the last time they were changed? Do we know what happens if I was to reset and restart the service? These are some of the key concerns when discussing service accounts with some of our customers. And lastly, is no auditing or notification of services being used by anyone. These are just some of the controls that concern some of our customers out there today.
So we look at best practices, ideally, we want to take control over the life cycle of the service account. We want implement a PAM solution. We want to have functionality such as account discovery, service discovery, auto provisioning and management. Lastly, once we have that account under management, we want to build the role based controls around the account, allowing users to check out the credential if necessary. These are just some of the things that Safeguard Privileged Password can help you do.
In today's demonstration, I'll be showing you the five steps to service account management with Safeguard Privilege Passwords. First step, account discovery. Second step, service discovery. Third step, assign dynamic tags to the new accounts that were recently discovered by Safeguard. Taking those new accounts, using the tags, assigning them to a dynamic group. And in turn, assigning those dynamic groups to an entitlement/access request policy.
Here's an overview of my lab configuration. It's a simple environment with when SPP, Safeguard for Privileged Password, a single domain controller, and a member server. On the member server is a Kiwi Syslog Server, running as a service, using a domain account called SVC_Kiwi.
Let's take a look at safeguard. All right, so here's my lab, already logged in to Safeguard. Also have the services.msc running. Just for shits and giggles, let's go ahead and restart the service, let's make sure it's actually up and running. Kiwi Syslog Server, so I just stopped and started. What we're going to do next is the step one. We're going to look for the account discovery. So I'm going to go ahead and select Administration Tools, highlight the domain controller itself, right mouse-click Discover Accounts. This run for a few seconds. Once it's completed, we'll go ahead and refresh the Safeguard client. So we'll go ahead and hit Refresh. You'll notice, I've discovered three accounts. At this point, if I was to restart the service on the member server, it'll fail because I've changed the actual password on the domain. But I haven't synchronize it with safeguard, yet, as far as the account discovery goes for services.
So step two is really looking at the services discovery. So I'm going to go ahead, on the member server, select just like we did with the domain controller, right mouse-click, this time going to do Discover Services. I'm just going to go out, and discover the actual Kiwi Syslog Server, make it as a dependent system. You'll see it here as dependent system. Now, if I was to go back-- Actually, even before I do that, let's go ahead and restart.
We can see it's now successful. Because not only did the discovery go and reset the password, but it also synchronized it with that of the domain controller because it's now a dependent system. So if I was to go back to the DC, one last time, just go and reset this password. So, sorry, let's go to Accounts, right mouse-click, Account Security, Change Password. I'm going to refresh the service over here. So you'll notice it's stopping, it stopped, and now, starting and running. So you can see that simply by Safeguard Privileged Passwords managing the service account on the domain controller, once the reset schedule change is done, or manually, like I'm doing today, it's going out to the member server, resetting the password, stopping and restarting the service.
So how is this accomplished? So let's take a look at safeguard. So, again, we'll just make this one a little bigger. And what we're going to do is we're going to look at the discovery rules. So you notice I have four account discoveries defined. The first one that we ran was a directory discovery. So I'm going to go ahead and just double click it, give it a name. In this example, let me go ahead and select the rule and edit the rule. So the first thing I'm doing is I'm looking for service accounts using an LDAP filter. So simply using the LDAP filter, I'm looking inside the domain controller, inside the domain, if you will, for any account called SVC_star
I'll bring that into view. I'm then selecting a default password, assigning it. And then I'm giving it a password profile called Windows Services. So this will go out, discover the account, assign the password profile called Windows Services, automatically, add those credentials to Safeguard. So that would be considered step one in the diagram.
Step two is looking for the actual services running on a target machine. So here we have another job called Find Local Services. Again, click it to edit, give it a name, Schedule. Down below, I'm looking for the option to discover the services and automatically configure dependent systems. So this is what adds the ABS or [INAUDIBLE], if you will, as a dependent system for that service account credential.
Again, double click, give it a property constraint. Basically, I'm using a regex expression to look for the service running. And then, again, same idea, assigning the password profile to Windows Services. Key point when doing the discovery, the profile must match on both the domain controller for the password, as well of that of the domain, the member server running the servers, as well. So that allows us to basically make that service dependent system of the target machine.
Step three was really assigning the dynamic tag to the account. So if I was to go under Settings, Tags, we're going to see I have a single tag name called SVC. And what this is doing is looking at the account rules. And after the accounts are discovered, it's dynamically assigning the tag name for any account that starts with SVC.
So again, if I was preview this, it's going to go out and list the three accounts that are going to assign the tags. Again, Cancel if I go back to my accounts. I'll just do refresh here. I'll see the new accounts coming in. Simply select any one of the service accounts. You'll notice at the bottom of the page and that'll have a tag called SVC. With these tags assigned, I'm then creating a dynamic account group. So let's go to Account Groups. And, again, you'll notice the SVC account group that is been dynamically assigned. Again, I'm going to double click to edit it. And looking at the account rules, now I'm seeing for any account that has a tag that equals SVC, I'm going to add that account to this dynamic group. So I'm going to pause and go under Accounts. You'll see the actual account itself.
The last step is the entitlement, step five. If we go under Entitlements and look at the SVC accounts, I can see the users that are assigned to this entitlement, the access request policies. Now if was to go into double click to edit this access request policy, we can see here that it's loaded. Most importantly, I'm going to go to the scope, and we can see that dynamic group is now assigned to this access request policy. So from an auto-discovery point of view, the minute that the account is discovered, it is put automatically under management and safeguard, it's assigned a tag to the account, the account is then assigned to the group, the group is assigned to entitlement.
So at this point, from an end user perspective, I could easily go to the home screen, New Request, select the domain controller, select the accounts. And you'll see that my service accounts are now available to be requested by the user. And again, this is all automatically dynamically assigned within safeguard. Let's go Next. I'm going to do a emergency request, simply because it bypasses the approval process. And, again, automatically made available, expand, show the password for the credential. Again, once the user is done, simply check in the user request. And that would complete the workflow from a user perspective.
Thanks for watching. I hope you've enjoyed watching this short videoclip.
09:37