The UChicago Privileged Access Management (PAM) service is designed to help secure high-level systems, services, and passwords through a central management system. You can learn more about PAM and its functions by selecting a topic from the list below.
Yes, you will need to provide BeyondTrust with an account and password to be able to rotate any account credentials that are onboarded.
Yes, although the workflow will be different. Instead of going to a bastion host such as jump.uchicago.edu, you will sign into BeyondTrust Password Safe with your CNetID, then choose your system(s) from a list. Alternatively, you can use SSH, or RDP direct connect which will also ask for your CNetID and password to connect to your systems.
Dedicated accounts are required to rotate the credentials for the functional and scanning accounts that are onboarded into the tool.
You will also use a dedicated account that will be checked out for use and checked back in when done. This will ensure that there is an audit trail of who used which account on what system and when.
Functional accounts are used to change the credentials on assets that are managed by BeyondTrust Password Safe.
Scanning accounts are used to discover users, services, ports, etc. on the target asset so that they can then be managed by Password Safe.
This service is limited to protecting accounts with elevated privileges on servers that can be connected to via SSH, RDP, or Telnet. This service can also manage privileged accounts on databases. Also, web applications and regular applications.
No, PAM is not HIPPA nor PII compliant.
They will require learning the tool's interface with this BeyondTrust user guide (PDF).
Onboarding requests, password rotation schedule changes, adding new groups for PAM, manual password rotations, issue troubleshooting, adding new assets, and removing assets.
Times are dependent on scope, systems, accounts to be vaulted, etc.
Servers need to be able to be connected to the three resource brokers, hardware, and firewall testing are needed.
The accounts that will be utilized with PAM will also need to have access to the system with appropriate permissions depending on function.
Functional account and scanning account privileges will also need to be tested to ensure that the functional account can rotate passwords on the desired systems and that the scanning accounts can discover the accounts that will be vaulted.
No. The scanner scans for open ports and enumerates system data using the IPC$ share.
Yes, it needs to do this to enumerate local users, services, etc.
No, this tool only allows specified account passwords to be managed.
No, by default no one has access to the systems after they have been onboarded. It is only after the managed accounts are assigned that groups get access to specific systems.
The session monitor can protect password fields so that the password fields will not show up in the recordings where they are detected.
Records are held for one year.
The Password Safe functionality will be unavailable until maintenance is complete. Therefore, you should have a plan for continuing operations if you need access to your assets while the Password Safe is unavailable.
You will receive a notification, in advance, from the Privileged Access Management Listserv including the expected window for downtime.
The default password rotation policy is as follows:
|
Policy |
Setting |
|
Default Password Policy |
48-50 characters with uppercase/lowercase alpha and non-alphanumeric characters" |
|
Change Password Time |
6:30 |
|
Frequency |
Every 30 Days |
|
Default release duration (default checkout time) |
2 hours |
|
Maximum release duration (max checkout time) |
2 hours |
|
Max concurrent request (how many users can check out this account at once) |
1 |
|
Password checked and reset after password check-in |
On |
|
Notification emails sent on release to |
None |
Yes. This tool supports any LDAP or Active Directory (AD) joined machines or accounts as well as local machine accounts.
The typical model for privileged account management revolves around using role-based accounts per team, environment, etc. This means that a team will utilize the same accounts in some cases, but it will not be a personal administrator account
It is best practice to create a number of accounts based on specific privileges needed. These will be assigned to the groups/systems as needed.
For Active Directory and LDAP, account names should start with an underscore (_) followed by the organization and division (e.g. _itsiamadmin01). A ticket should be opened with the Windows Server team for Active Directory or Identity and Access Management team for LDAP.