Privileged Account Management Strategy

It is important to have a privileged account management (PAM) strategy that helps you determine which types of features to leverage for your various accounts and sensitive data you will be storing. Below are some suggested guidelines for creating a strategic plan. We recommend reading all sections of the guide for a comprehensive look at ways you can secure your Secret Server. However, these guidelines will also link to other parts of the guide so you can choose to jump to a specific section for more detail about a particular topic.

Identify Data at Risk

Consider all the types of sensitive data your team needs to be securely stored and managed. Where are the biggest risks and pain points in your current password management strategy? Data at risk also often includes more than just passwords.

To get started, think through these key accounts and principles:

• All shared privileged accounts: these are accounts that don't identify an individual (for example: administrator, root, enable, service accounts). All of these should have randomized passwords that are changed frequently.
• Do your users have individual privileged accounts? Maybe each user has—separate AD account for domain admin rights?
• Every password in your organization should be different.
• Do your users have individual privileged accounts? Maybe each user has—separate AD account for domain admin rights?
• What passwords could be needed in an emergency, outside of regular business hours, or when someone is on vacation?

Typical account passwords and sensitive data being stored in Secret Server:

• Active Directory domain administrator accounts
• Active Directory service accounts
• Application passwords (such as SAP and, custom apps)
• Cloud Administrative or Privileged Accounts
• Database accounts (such as MS SQL, Oracle, or MySQL)
• Network equipment passwords (such as router, switches, firewalls, phones, and appliances)
• Sensitive files (such as private key files, SSL certificates, and network documentation info)
• Software license keys, serial numbers, personnel data, and Wi-Fi passwords
• UNIX, Linux, Mac root, and local user accounts
• Website passwords (cloud services, DNS, Amazon AWS, vendors)
• Windows local administrator accounts

Who Accesses Secret Server?

After determining the data you will store in Secret Server, the next step is to decide who will use Secret Server to access and manage that data. A common approach is to begin by focusing on one group of users and the passwords they use on a regular basis, later expanding to other teams once a good strategy has been put in place. However, you may find it more beneficial to organize Secret Server for use by all of your users/teams at once so you can design an effective overall folder and policy structure that will work well across all teams.

What Privilege Levels Are Necessary?

Giving a user access to an account in Secret Server can entail different levels of privilege. Do you want a user to be able to edit the username, machine, or password of a secret, or only view the secret? Should they be able to share the secret with other users? Once you incorporate use of the Launcher into your users' workflow for authenticating to an application, do they really need to know a password, or can you mask it? The Workflow Security section can help you determine and implement key measures to ensure users have least privilege necessary.

What are your Password Requirements?

It's unlikely that all your accounts will have the same password complexity requirements and rotation schedule. In fact, for best security, you should have some variation. You can create sets of password requirements to control password length, characters, and complexity, then apply those to various account types using secret templates. Secret templates also allow you to set a default expiration period, which can translate to how often an account password will be changed automatically.

Evaluate your Existing Setup

While transitioning to using a new tool for managing your passwords, it is important to take into account how accounts are currently used in your environment. The following questions can help evaluate this:

• Do some of your users have their own, individual AD domain admin accounts, or are there only a few shared domain accounts?
• Do users use local administrator accounts or privileged domain accounts for admin access to systems?
• Are permissions to resources (such as servers and applications) controlled using AD group policy?

Define Your Core PAM Strategy

There are a few different strategies that typically work best in Secret Server. Other methods of password management may work but require a more significant amount of time and effort to configure and maintain. The most commonly-used strategies are defined below.

Individual Privileged Domain Accounts

In this scenario, IT team members have their own domain admin accounts that are tied to their identity. They use these accounts to gain elevated privileges to resources such as production servers. Permissions to the various resources they're permitted to access are controlled by AD.

To implement this in Secret Server, each account is stored as its own AD account secret. Only the user tied to that account is granted permissions to the secret. A security setting such as check out (one-time password) or hide launcher password is enabled so the user depends upon Secret Server to use the account. Therefore, all access to that account will be audited. When the IT admin needs elevated privilege to a box, they check out or view the secret and then use the launcher to access the machine.

A benefit of this strategy is that there is not conflict with multiple users trying to use the same account for access to one machine. This strategy provides great accountability—the security team knows the exact user accessing an account and the machine being accessed. The password is not shared among multiple users, and all privileged access is audited by Secret Server.

A pitfall of this strategy can be that there is more management of permissions required in AD. While machines could be access or deny listed to force users to use the Secret Server launcher, thus controlling machine access through Secret Server, this can be tedious.

It is more secure, less work, and simpler to organize permissions for access to domain resources in AD. This strategy works best for organizations that already use AD heavily to control permissions of individual privileged users to domain resources. Ongoing maintenance will rely on updating permissions to resources in AD and ensuring that all new individuals' privileged accounts are being added for management under Secret Server.

Shared Privileged Domain Accounts

You may choose to have your users use shared privileged accounts to access resources. This strategy involves creating a few service accounts that have permissions to OUs or groups of computers. In Secret Server, these accounts can be limited with the Launcher so they can only be used to Launch to certain computers. This means you can limit the number of domain accounts created and set permissions more broadly (such as at OU level). These passwords could be changed on a schedule or, where possible, used with Check Out to change the password after each use. Using this setup, accounts can be designated for team or function and can have varying Check Out intervals set to ensure that only one person at a time is using each account.

A benefit of this strategy is if individuals do not already have their own privileged domain accounts in AD, then giving them access to shared accounts means less setup in AD while still maintaining accountability for who uses which account, and which machine they access.

A pitfall of this strategy can be that if the team (or function-specific accounts) cover a broad number of machines that can be accessed, it may be a lot of work to set up launcher allow/deny lists to control access through Secret Server. However, if these permissions are set only through AD, it will be difficult to have the visibility into these limitations for an auditor.

Hybrid of Individual and Shared Accounts

Sometimes, your employees' roles may require longer, more specialized access. For those accounts, you can have individual privileged domain accounts, and for the other regular users you can use a few shared privileged domain accounts. All of these can be stored in Secret Server, but with different settings governing their usage. For example, the shared accounts would still have check out enabled, while the individual privileged accounts will simply have permissions limited to an individual user, possibly with the password hidden using hide launcher password.

What Is the Highest Risk?

Implementing a comprehensive PAM policy should eventually cover all of your privileged/shared accounts, but this can take some time. When looking at where to start, it is important to consider the areas of risk—where are the areas that need more immediate attention:

• Is it local Windows admin accounts all sharing the same password?
• Pass-the-hash vulnerability?
• Protecting your network equipment passwords?
• Avoiding fines for not meeting compliance mandates?
• Password misuse and auditing employee access to accounts?

Choose a starting point that gives your organization the most value, and then branch out from there.