Privileged Account (n) - A computer or user account that allows access to sensitive systems or data for the purposes of administration.

While Microsoft and others make the case for using standard user accounts for your day to day use and email access, there are many administrators out there who still use their administrator accounts. I am a believer in the standard user scenario; even though it is a good way to operate, it takes some getting used to.

Along with the usage of standard accounts comes the need to manage privileged accounts and keep tabs on information related to them. Knowing which services use them, when they are used, what the password is, and when it was last changed are all good things for administrators or support teams to have tucked away somewhere. Managing a list (or group of lists) containing this information is helpful, but seems a little labor intensive to me.

Enter Privileged Account Manager

NetWrix, maker of many solutions for managing and auditing Active Directory (and other applications) has created Privileged Account Manager (PAM) to help with the task(s) of keeping tabs on service accounts and other privileged accounts in Active Directory.

Note: PAM can also manage local administrator accounts, but focuses on AD.

How does PAM work?

The way PAM works is by storing gathered information about these accounts in a database and allowing administrators to view and modify the information captured. I tend to think of it as one-stop shopping for service account maintenance, but it does work for all privileged accounts.

Who should use PAM?

Any systems administrator or support team responsible for managing additional credentials for services or those responsible for account creation and delegation to other users would find PAM useful. I would not necessarily recommend that those managing one additional user account (their own administrative account) run out and use PAM as one account should be manageable; but then again, there are days when one additional user account to work with seems one too many, but that's just me.

Getting started

To get set up, you will need to specify an account for Privileged Account Manager to use that has local administrator access to all of the client machines you plan to work with. This might be a good case for an additional service account dedicated to PAM, but that is personal preference.

Figure A

Privileged Account Manager's web console (click to enlarge)

Once you have got the console configured and installed, adding accounts to manage is very fast. Select the add button at the bottom of the main console. Then specify the domain name and user name for the account you wish to add.

Once an account is added, by simply typing in the domain\username, you can specify additional information, such as systems the account is used on. If you like, there is also a wizard button (available from the Add account screen).

Figure B

Specify a user account

Specifying a system for an account allows services on these systems to log on with the account that is managed by PAM.

Figure C

Systems using PAM managed accounts
When an account is registered to be managed with Privileged Account Manager, the password is reset to match the password policy (shown in Figure D). When an account is checked out for use, the password is changed again and the check-out duration and reason are specified. Once checked out, the new password can be displayed by clicking the Show Password (and the Copy Password to Clipboard). During the check-out, the password is changed for the services using the account to the new value.

Figure D

Password policy for PAM accounts (click to enlarge)

When accounts are checked in, the password is reset again and changed for services. This way there is no password left known once the account is checked in which keeps the passwords of managed accounts very secure.

Note: In my testing I created a separate virtual machine to use as the server for PAM; you can run this application alongside other applications on an existing IIS server if you choose.

Another thing I have found is that the concept of a service account manager (which I consider PAM to be) is amazing, but for those services that have applications integrated into their management, like Backup Exec and some others, a solution that constantly changes the password will not work as expected.

In my testing, I found that Backup Exec requires the services to be recycled every time the credentials change, which is far from convenient.

Other applications — those that do not have such tight integrations — or if they do, they are okay with Windows also managing their services, seem to work quite well with Privileged Account Manager.

Other controls

To help keep track of just who is checking out accounts within the organization, PAM provides auditing and reports. The auditing for an account will show who checked it in or out along with the time stamp (shown in Figure E).

Figure E

Auditing

The preconfigured reporting allowed by PAM is very useful in determining what actions have been taking with accounts registered by PAM.

Figure F

Reporting (click to enlarge)

Managing users

Even though the idea of PAM is to keep privileged accounts secure, there must be IT personnel or staff within an organization who are allowed to use PAM. These users are able to check accounts in and out, or add accounts to be managed, or set password policy, among other things. These things are managed by roles. When a PAM user is added to a role, they can perform the functions allowed by the role. Roles are shown in Figure G.

Figure G

Roles

That is great but what does it cost?

There are two versions of Privileged Account Manager, freeware and commercial.

The freeware and commercial versions work identically, however the freeware version relies on support forums for application support and is limited to a 50-user environment. The commercial version is licensed by an administrative user who will access the console.

I like this product a lot, but found that some services just don't jive with this kind of third party control. I am working with Netwrix support to further isolate and hopefully find a way around these issues to make the application even more useful. Keeping a list of privileged user accounts and managing them separately is a thing of the past. Being able to access and work with all of the accounts at once is a lifesaver. I suppose this should be a reason to pare down the number of accounts around; that is next on my list of things to get done.

Related Topics:

About Derek Schauland

Derek Schauland has been tinkering with Windows systems since 1997. He has supported Windows NT 4, worked phone support for an ISP, and is currently the IT Manager for a manufacturing company in Wisconsin.

Full Bio

Derek Schauland has been tinkering with Windows systems since 1997. He has supported Windows NT 4, worked phone support for an ISP, and is currently the IT Manager for a manufacturing company in Wisconsin.