Users and Groups

At minimum, the administrators who manage and use your organization's privileged passwords and data on a regular basis will need to access your Secret Server. Secret Server users can be defined in a few ways:

  • Active Directory user accounts.
  • Local Secret Server user accounts.
  • User accounts from an Azure Active Directory tenant.
  • User accounts from another OLDAP source (Basic/Kerberos).

  • User accounts from SAML integration (often AD accounts). If local accounts are provisioned via SAML, they must correspond and match local user accounts that are within Secret Server.

    SS also has the concept of groups, which can be local (you create them in SS), AD-synced (security groups from AD), oLDAP groups, or AzureAD groups . Groups are a powerful tool for assigning and maintaining permissions to secrets, and therefore should be given careful thought and planning. Below we review the two most common account and group strategies our customers use. These same concepts can apply for other directory service accounts and groups other than Active Directory.

Local Secret Server Accounts

Local users and groups have to be created and managed manually in Secret Server, as they are not integrated with AD. The first account you create in Secret Server is an example of a local account. Local groups can include local users and AD accounts, and can have a user established as the group owner that is permitted to add or remove users to or from the group.

Active Directory Accounts

AD accounts can be added for access to Secret Server either manually (one by one) or by AD security group. When adding users by security group, you choose which groups Secret Server will synchronize with AD to update which users' access to Secret Server is enabled or disabled. AD group synchronization happens on a regular, customizable interval to keep group membership changes that happen in AD up-to-date in Secret Server as well.

Local or Active Directory Accounts?

We recommend using one of these options:

  • Only local users and groups (best security)
  • Only AD users and groups (most convenient)
  • A hybrid of AD users and local groups (balance of security and convenience)

You need to choose an option that provides the levels of security and convenience that are acceptable for your organization. Using the AD accounts option is easy for user maintenance, but it limits the security of Secret Server to the level of security of your AD. This may be fine—just be sure to consider the question of domain admin access to AD in combination with Secret Server permissions.

Only Local Users and Groups

Creating local users and groups within Secret Server provides a lot of flexibility because you can tailor permission assignment by group to your exact needs. The major benefit of local users and groups is security: users and group membership can be controlled entirely by role-based access control (RBAC) within Secret Server. However, this approach requires more maintenance because creating or deleting users and managing group membership has to be controlled in Secret Server.

Only AD Users and Groups

If you are considering using AD users and groups for Secret Server access and permissions assignment, review your teams that need access to Secret Server. Compare them to the corresponding groups in your AD. If your AD groups map to ways you want to assign access to secrets, you can synchronize your AD groups with Secret Server and start assigning permissions to secrets (and levels of those permissions—View/Edit/Owner) by group. You can then effectively manage Secret Server access and secret permissions completely from AD by changing AD group membership.

Many customers choose this option because they can maintain control in AD and do not have to worry about any user or group maintenance within Secret Server. If you want to use this option but your AD groups don't match the way you want to assign secret permissions, you will need to create new AD groups to match this, or may want to consider the hybrid approach (below), using local groups instead.

This method, while more convenient, may require additional considerations:

  • How are these AD groups being protected?
  • Are there controls in place which require elevated or high privilege accounts to modify these AD groups?
  • Are there alerts in place for when these groups are modified?
  • Is the information security team closely monitoring these groups?

Hybrid of AD Users and Local Groups

A third option is to create local groups in Secret Server and add AD users to those groups for the purpose of organizing how permissions are assigned to secrets. Many customers who use this setup will create a single AD security group (for example, SecretServerUsers) to use to synchronize their AD users with Secret Server for log on. They then create additional local groups for their users to, which gives them permissions within Secret Server, such as to their teams folder. They may also be added to other Secret Server groups that provide them with other privileges within the environment.

This approach is more secure than using only AD groups and users, but if Active Directory were compromised, intruders may still be able to reset an account password and gain log in access to Secret Server. If secrets are stored in that user's personal folder, those secrets may be compromised which may lead to lateral movement elsewhere within the organization.

Business Users

A "business user” is a non-information-technology user. Business users typically use Secret Server for vaulting credentials for access to departmental websites, applications, and personal accounts in an enterprise-grade secure vault.

At Delinea, we strive to ensure that all Secret Server Enterprise Vault users get the maximum value possible from the product. Business users do not need all vault features, but they can benefit by securing their passwords and credentials to prevent abuse or malicious use.

Business users can:

  • Access secrets: They can create, update, and delete their own secrets within Secret Server. For example, a user signing up for an online service can use our password generator to create a strong password, store that password in Secret Server, and later use Web Password Filler to access it when logging on.
  • Request and approve access to secrets: Non-privileged secrets may need approval workflows. Business users can request access to these secrets and can approve access for others. For example, if access to an organization's social media accounts required authorization from a member of the marketing team, a business user could request access to the secret, and another business user could then approve access.
  • Share secrets with other users: Business users can share non-privileged secrets with other users of  Secret Server, either IT or business users.
  • Access secrets using our mobile app: Business users can use the Delinea mobile application to access and manage their secrets.
  • Use Web Password Filler: Business users can use our Web Password Filter (WPF) for accessing websites and auto-filling credentials from their secrets.
  • View audits of their secrets: Business users can use auditing to see who accessed their shared secrets.
A "non-privileged secret" refers to any secret stored within Secret Server that does not grant elevated access rights or permissions. The most common type is regular user-account passwords.

Table: Allowed Actions for Business and IT Users

Action Business User IT User
Approve access to secrets • •
Configure password rotation   •
Configure security features for a secret   •
Create, delete, modify folders and add secrets to any folder   •
Create and delete personal folders • •
Create, update, and delete personal secrets • •
Create and manage Integrations, workflows, pipelines, discovery, sites, distributed engines, HA/DR, and more   •
Launch secrets they have access to • •
Request access to secrets • •
Share secrets • •
Use any administrative functions of Secret Server   •
Use any launcher including RAS (Platform)   •
Use Connection Manager to launch RDP or SSH sessions   •
Use the Delinea mobile app for access to secrets • •
Use the Secret Server SDK or API   •
Use Web Password Filler  For Non-IT-related tasks, websites or portals For any tasks
Use Web templates in Secret Server For Non-IT-related tasks, websites or portals For any tasks
Utilize any templates including custom templates   •
View secret audits for their own secrets • •
View user audits for their own secrets  • •

Administrators can restrict template visibility for Business Users. By default, all users have access to all templates, but business users typically need access to the following templates:

  • Bank Account
  • Combination Lock
  • Contact
  • Credit Card
  • Healthcare
  • Password
  • PIN
  • Security Alarm Code
  • Social Security Number
  • Web Password (Non-IT-related)