I have yet to be in an organization that hasn’t defaulted to something quite unwise simply because trying to maintain the institutional knowledge of that password is otherwise difficult.
Mostly – don’t. Every user that has access to a system should have their own credentials. There’s no reason for an update server to be set up this way.
Or, you sign a key/certificate for each user, add MFA
Or, you create a complex password for each user, and add MFA
Or you create a complex password, shared in a keystore that handles checkout and rotation
Worst case, if you're lazy, you create a complex password for a handful of your teammates and reset it when a team member leaves
Or if you're solarwinds, you apparently choose gross negligence
[0] https://www.yubico.com/resources/glossary/static-password/
The answer is typically “never share accounts” and therefore never share passwords.
I wouldn’t the surprised if “do not share credentials” is explicitly stated in solarwinds internal security policies.
Beyond the challenge of sharing strong passwords, there’s also the (important from compliance perspective) issue of losing the ability to audit who took what action if multiple people use the same credentials.
- Using a password manager where there is audit logging that is reviewed and the access to the passwords is segregated to those who need it - Using a privileged access monitoring tool such as CyberArk - Simply creating separate named privileged accounts for each person to use is the best alternative
We've moved to identity + role based access control, but some older core pieces still used the shared password.
We simply have a portal that authenticated users can log into it, and see the current password which is rotated monthly, with a random selection from a series of dictionary words. (which can occasionally produce giggleworthy combinations)
But as the sibling comment says; the right way is to get rid of it entirely.