Nobody Should Know the Admin Password

In the last post I said that managing users and groups on a host led somewhere bigger. This is where.

It started with remote control

Every vendor says their features are integrated. Most of them bolted things together after the fact, and you can tell every time you click.

While building remote control I ran into a practical problem. The Cadres agent runs as SYSTEM or root, which is fine for running jobs. When I remote into a server, though, I often need to be someone else: a domain admin, a service account, a specific local user. I don’t want to type those credentials every time, and I definitely don’t want them in a spreadsheet or a shared password manager the whole team can browse.

So what if I could check out the credential while connecting? Pick it, authenticate, and you’re in, without switching to another tool to copy and paste.

From one checkout to a vault

That idea grows quickly. If you store credentials for remote sessions, you need somewhere to organize them. Then you need to control who can use which ones, and at that point you may as well do it properly.

So we built vaults. A vault holds a group of credentials and can be scoped to a team, a customer or a project. Access uses the same role-based permissions as the rest of the platform, so there’s no separate permission model and no admin password for the password tool.

A secret can be a username and password, an SSH key, an SNMP community string, an API key or any other credential that needs storing somewhere safe. It’s all encrypted at rest, and every checkout is logged with who, when and why.

Nobody knows the password

Once host management could see local users and groups, the next step was obvious: move a local account straight into the vault.

When you do that, Cadres changes the password as part of the check-in. From then on nobody knows it, including the operator, the admin and whoever created the account. It only exists in the vault.

Someone who needs the account checks it out and gets the current password for their session. When they check it back in, Cadres rotates it again and nobody knows the new one either. Break-glass sessions always rotate on check-in, without exception.

This fixes problems every team has: shared admin passwords that haven’t changed in years, service account passwords on sticky notes, and “break glass” credentials half the team knows by heart.

One vault for all of it

The vault isn’t only for host logins. The SNMP community strings network discovery uses live there. So do API keys for third-party integrations and the service account credentials automation workflows need.

When the workflow engine needs a credential, it checks it out the same way a person does and leaves the same audit record. When the SNMP poller needs a community string to walk a switch, it gets it from the vault. Everything uses the same encryption, access rules and logs.

Why build it in

Dedicated PAM products exist, I know. They’re also separate systems, with connectors, sync jobs and often a team of their own to run them. That works for a large enterprise with a mature PAM program.

Most teams aren’t that. They’re lean, and they don’t have time to run a PAM system next to their RMM, service desk, monitoring and compliance tools. So the credentials end up in a shared password manager or a spreadsheet.

With PAM in the platform, it’s there from the first day. No integration project, no extra license and no extra console to learn. The operator who manages hosts and runs scripts already has the vaults their role allows. It’s easy enough that people use it.

Next

Vaults get more useful when you pair them with the workflow engine. Put managed credentials behind automated workflows with approval gates and people stop needing standing access to almost anything. That’s the next post.

If fewer agents, fewer tools and fewer shared passwords sounds good, start a trial.