You're trying to figure out how to securely store secret values, yet use them in your application, and the answer, generally, is to use some sort of secrets management system.
I really like Turtles All The Way Down because it does a good job of explaining the core problem with secrets management (you have to authenticate to the system, and where do you store that password?), as well as giving an overview of the most prominent current software solutions. It's a bit of a long talk, but it's worth watching.
Personally, I like Vault a lot to handle these sorts of situations. In a nutshell, the users' passwords get stored in an encrypted datastore; your sysadmins and application can access those passwords by making an API call to Vault. These API calls are logged for later audit purposes, and are authenticated through a session-like system, where you provide a password (for example; there are a number of auth options) and get back a token that gets stored for normal use, but which will periodically expire and can be explicitly revoked. This prevents an attacker who gains access to the token from gaining permanent access, and does the same for employees when they leave the company. This is roughly how other network-based vault systems, like Keywhiz, work as well.
There's a really important caveat to the last part of the previous paragraph: an attacker can use the token to access all users' stored passwords, and then continue to use those whether or not the stolen token expires. This attack comes about because you're storing static credentials (passwords). If instead you had to request temporary credentials from the third-party sites, then you could return those instead to your internal users, which keeps them from gaining permanent access without permanent access to Vault. Vault has support for a number of systems for doing this, but you're limited here to what the other sites support.