Hardening Your PAM Environment

PAM, Priveleged Account Mamanegement, is relatively a new technology. After getting access to target system, the subsequent step is escalating privileges. Thus privileged accounts are on the target. Domain admin accounts(t0 accounts), local admin accounts(t1 accounts), Service accounts on Microsoft systems; root accounts, sudo accounts on Linux systems, Sysadmin on databases are the examples for privilege accounts. Attackers aim to use those accounts and PAM systems aim to protect those accounts.

There are a lot of companies in this area. One of the most popular one is CyberArk. The logic is similar for the others. The components are on the following:

• A user interface (PVWA in Cyberark)
• A terminal server ( used for a proxy, PSM in Cyberark)
• A vault ( Vault server in Cyberark)

also Cyberark has CPM server to interact with Vault server.

You can do some hardenings on the following on your Cyberark environment;

1. You shouldn’t include Vault on your domain environment. Vault should interact with only CPM. The IP addresses interacting with Vault can be restricted on dbparm.ini file on Vault server.
2. To connect vault, only Administrator user should be used.
3. PSM server should be exclude group policy or a special group policy should be applied. CyberArk offers PSM-specific GPOs if needed.
4. PSM server’s local users and groups is very important. PSMConnect and PSMAdminConnect are the only members of remote desktop users.
5. Domain users must not be on the Remote Desktop Users. To ease the connection, some system admins add all domain users to Remote Desktop Users group. This solution creates a vulnerability. Instead of this, you can edit local group policy on the following way.

Before that, lets understand what is shadowusers group.

The PSM Shadow users sandbox the client session. The point of the Shadow users is process isolation, so the programs launched on the same server by different vault users run under different identities, and cannot leak information between the sessions. These identities are created by the SYSTEM user and do not have any privileges.

The credentials of the shadow users are managed and changed internally by the PSM server. The PSM will change (reset) the shadow user password every time a new connection is made.

These shadow users are local users on the PSM machine. This users are created dynamically and managed by the PSM. When a user is connecting using the PSM, we still connect to the PSM machine using the PSMConnect user, but we now use the shadow-user to run the client (similar to a “run-as” approach). This creates full separation with each user having its own permissions, files, registry — making it very difficult to harm other users sessions.

Also, the hardening of the PSM Server restricts the use of these Shadow users. As these Shadow users are local users they should have the log on locally right.

6. Type Win+R on windows button. Write secpol.msc. Find “Allow Logon Locally” and add PSMShadowUsers to this group.