The Good, the Bad, and the Ugly: Privileged Account Access Models

In the previous privileged account blog, we described the three main categories of privileged accounts: Local Accounts, Directory Accounts, and Application Accounts, as well as some of the best practices for maintaining those accounts.

In this week’s blog we will discuss the pros and cons of various privileged account access models.

For the purpose of our discussion, suppose we have a targetwindows-based server called “PrintServer01.” This server is a member of the domain and its primary function is that of a print server. Mostly the domain administrators need privileged access to this server, in order to provision new network printers or troubleshoot existing printers’ queues and drivers. There are various options for giving the domain administrators access to the server, which we will discuss from the least secure model to the most secure model.

1: Sharing the local “Administrator” password (without a PAM Solution).

Perhaps the least security-conscious model is sharing the local “Administrator” password between the various users that need to administer the machine (without a PAM Solution). As the old Benjamin Franklin quote goes “Three may keep a secret, if two of them are dead”. This solution happens often because it’s the easiest to deploy (you simply tell whoever needs access the password). Often systems, such as legacy network appliances, only have the option to have one administrative account, which forces organizations to adopt this type of solution.


  • This model is easy to implement for any system.


  • There is almost always no attribution to the actual person that is logged in as this user.
  • It can be hard to communicate the new password between multiple team members, so passwords are either not changed or changed but not following security guidelines (for example adding a simple number on the end or setting the same password on multiple systems).
  • It’s tough to keep track of password versions, especially if the last person to change it leaves the company or is not available. This can make certain administrator’s a huge liability to an organization, especially when they have the “keys” to vital servers.
  • Access logs are kept on the local system.

2: Creating individual local accounts or adding named domain users to the “Administrators” group on the target server.

The next solution that many organizations adopt is to add “named” users to the “Administrators” group on the server. If the server is on the domain, organizations “add” domain users to the “Administrators” group, otherwise they create a local user first, and then add it to the “Administrators” group. This model is certainly better than the first model we discussed, however it adds a number of security maintenance complications:


  • There is attribution to the named users that have access. If a production server unexpectedly restarted during business hours, a log would indicate who initiated the restart.


  • It can be time-consuming to set up individual users and add them to each server.
  • It can be even tougher to remove users who no longer need access from each server.
  • Passwords for the users that were created “locally” are often forgotten, and there is a need to reset them often, creating un-needed operational resource drain.
  • Users will set the same password, on their account, across multiple servers, exposing the servers to the “pass-the-hash” attack.
  • There is limited visibility as to “who” has access “where” without running specialized tools to discover access on all servers.

3: Adding domain groups to the “Administrators” group on target servers and using secondary domain accounts:

As an improvement to creating “local” users and explicitly adding domain users to the Administrator’s group, organizations typically create domain groups, such as “PrinterAdmins” and then make a member of the local Administrators group on the “PrintServer01” server. Subsequently, the domain users that require access to this server would be added to the “PrinterAdmins” group, and would thus be able to log into the “PrintServer01” server, with Administrative privileges to make the appropriate changes.

Security conscious organizations only add “secondary” domain accounts to these privileged groups, to minimize the risk of a compromised “daily” account being used as an attack vector.


  • There is attribution to the named users that have access.
  • It’s fairly easy to maintain the groups once they’re created (for example to remove access from users that no longer require it).
  • There is more visibility to who has access to the various servers, from a central (domain) view
  • The domain groups can be audited.
  • It’s relatively straightforward to identity ownership of particular servers based on group membership (to contact owners in case of a problem).


  • Access logs are kept on each server, and can potentially be wiped clean.
  • It can be time-consuming to create domain groups.

4: Shared local “Administrator” access with a PAM Solution.

In this solution which we consider being one of the best security practices, an organization has deployed a central Privileged Access Management solution, such as the CyberArk Privileged Account Security Solution. This is used to manage the local privileged accounts on each server. Account access to each server is controlled with an access-control model, such as the CyberArk “Safes”, that dictate who can see the password for the account. Users that are able to see the password can “check-out” the password to a particular system as needed. The passwords can be rotated automatically after each use and changed often, and there are options for workflows (owners of the account can grant temporary account access to users that require it). There might be additional PAM capabilities, such as the CyberArk PTA (Privileged Threat Analytics) installed, that would alert the security management of unusual user activity.


  • Access can be easily provisioned through the PAM solution.
  • There is no need to create multiple users.
  • Each target server has a unique username/password combination, preventing the pass-the-hash attack.
  • There is a central place to conduct a system-access audit.
  • A good PAM solution can be used to record user activity and trigger system alerts when suspicious behavior is detected.
  • Added benefit of built-in workflows for account access.
  • User access can be revoked from a central location.
  • Password versions are kept in a central location (for example: if there is a need to check the password for a restored Cisco device from 6 months ago).
  • Access logs are kept in a central location, and cannot be easily deleted.
  • Access history can be kept for years, long after the servers are decommissioned.


  • Can require additional local accounts, if more than one user needs to access a specific machine at a time.
  • Users get only one “desktop” on a server, which can be seen by other users.
  • Additional cost for a dedicated PAM solution.
  • Potentially additional complexity for end-users of the system.

As the organization’s security posture grows, it should constantly evaluate its Identity Management policies and procedures. CyberSheath highly recommends implementing a central PAM system as a toolset and framework for managing privileged accounts.