This article aims to explain how to vault passwords for individual accounts and how to retrieve vaulted passwords (whether individual or managed) so that the password value can be seen and usable. 

• Okta Privileged Access (OPA)
• Vault or Retrieve Password
• Individual Accounts

If vaulting a local server account, the password is managed by Okta Privileged Access Management
, but if wanting to log in via that account and later use sudo, there is a need to provide the password (that needs to be retrieved from Okta). 

Individual accounts (which tie to a user from UD) do not have a vaulted password. Those users are either pre-provisioned or created JIT. Then, the authentication happens using a short-lived credential that is not vaulted.
 

Okta Privileged Access's vaulting functionality on servers is specifically for shared privileged accounts such as service accounts and built-in accounts like Administrator, Root, etc. For these accounts, the Agent performs discovery, and then, at the platform level, there is a settings page where these accounts can be defined as the ones that will be onboarded and controlled. Once that setting is enabled for a specific account, the Agent will immediately perform a rotation of the password and store that password in the vault. The Agent also monitors for out-of-band password changes to these and will automatically rotate it if that is detected. We also fire an audit event for an out-of-band password change.

Currently, the vaulted credentials are not exposed to the user. When they SSH or RDP, the password is retrieved from the vault and automatically injected into the session for authentication.

In the near future, Okta will add a new policy option that administrators can use to allow users to "see" the password of a vaulted account - so that could be used in other scenarios, such as sudo or to access a host at the console which has a broken network connection.