Hello @Rich C
Some Best Practices when using Password Safe to access resources.
Avoid Direct Use of Privileged Credentials. Admins should never see or manually enter passwords when possible. They request access to use a privileged credential through the PWS interface.
Use Password Safe for Session Management. Instead of logging in manually use Password Safe for your RDP, SSH and Application sessions using a privileged managed account. This ensures secure, audited access without exposing credentials. In addition privileged sessions can be recorded and monitored in real time.
Automatically rotate passwords after each use or on a schedule and after each use to prevent reuse and reduces risk from leaked credentials.
Typical Workflow with BeyondTrust Password Safe.
- Admin logs into PWS portal using their regular account (with MFA).
- Requests access to a privileged account or system.
- Admin launches the session (e.g., SSH, RDP) using privileged credentials.
- Admin performs tasks on system.
- Session is recorded and logged for auditing.
- When session ends privileged credentials are rotated automatically to prevent credential reuse.
Regards,
John
This would fall under corporate policy. Unless you are a security architect responsible for defining policy, you don’t worry about this type of thing. Your corporate policy will dictate how you RDP to a server.
However, that being said, you NEVER want someone RDP’ing to a server with an account that has email access, internet access, etc. that can spread malware. This is exactly why we have elevated accounts.
BeyondTrust will allow an end user account to launch an RDP session over a non-standard port so BeyondTrust can inject an elevated account into the logon process. The admin doesn’t need the elevated account password, just click the RDP button. A temporary session is created on the BeyondTrust server, the credentials pulled from the database and injected into the RDP session so you can log in securely.
When the session is over, you can check in your elevated account to optionally force a password change. If you wanted to, you can even remove the ability to retrieve your elevated account password which would force admins to use BeyondTrust for all their RDP needs by not giving them the password for the account so external RDP apps won’t work.
If you really want to go down this path of overkill, and I don’t know your business so you might, we have 3 account types for users. primary accounts, user manages the password, it is rotated every 90 days by the user and the password is usually something like “P@ssWord!”. It is used to read email, surf the web, download malware, etc.
Account 2 is the local admin account on the users workstation. This account is only used on the workstation, nothing else. We do not allow email for this account but we are not managing the password either. We call this the LA account for Local Admin.
and then we have the elevated rights account for servers. Protected and managed in BeyondTrust, password rotated every night unless you use it, if you do use it, it is rotated when you check in the request.
You could always have a primary account, a non-privileged account for server logons and an elevated rights account for server work that requires admin rights so you can install software, fix issues, etc. but again, you are asking for enough work just managing all that to justify more hiring.
Since you should never be surfing the web for anything on a server, your admin account doesn’t have access to email, the password is managed in BeyondTrust, monitored by your SOC, etc. the risk is much lower and you’ve mitigated a lot of the risks associated with a primary account.
This will make you more safe than allowing primary accounts to log into the servers directly for any reason. The only reason a primary account should ever log into a server is if it is an RDS server with a business requirement. Maybe you have a PCI requirement so you have RDS jump servers for some folks to get to the PCI data on an isolated network. Those will be primary accounts with no elevated rights at all.
