# Accounts

> Add several accounts to a machine, decide which one each access uses and review the inventory of privileged accounts the agents find on your machines.

URL: https://docs.ironchip.com/en/pam/administracion/cuentas/

This page explains PAM accounts: which accounts the broker signs in with on each machine, and which accounts exist on your machines according to their agents. It is for whoever administers resources and wants to keep privileged accounts under control.

## A machine's accounts

Each SSH, RDP, PostgreSQL or MySQL resource has its **own account**, the one you entered when you registered it. You can also add other accounts to it, each with its own secret and rotation. That way, for example, the operations team signs in as `ops` and the database team as `dba` on the same machine.

Which account each person arrives with is decided by their [access](https://docs.ironchip.com/en/pam/administracion/accesos/), in the **Account on the machines** step:

- **Each machine's own account**: the person arrives with each machine's own account.
- **A specific account, on every machine**: the person arrives with that account on every machine the access reaches. A machine that does not have that account rejects the connection.

In both cases the session belongs to the person: it is recorded and judged as whoever opened it.

### Add an account to a machine

1. Open the resource's page and go to the **Accounts** tab.

   [Image: Accounts tab of a resource with the broker's accounts and the ones the agent finds]

2. Click **Add account**.
3. Enter the **Username** and, for SSH and RDP, the domain if it is a domain account.
4. Choose the **Method**. The default is **Managed by Ironchip**: the password is set by the machine's enforcer (if it was started with `-rotate-accounts` including the account) or, for a domain account, by the [directory](https://docs.ironchip.com/en/pam/administracion/directorio/). For a database, also enter the **Admin account** and **Admin password**.
5. Click **Add account**.

The additional account appears as one more resource named `<machine>.<account>`. It has its own page with its own **Credential** tab and follows its machine's address and site. VNC, Kubernetes and HTTP have no accounts.

**Remove** removes the account from the broker and deletes its secret. The account still exists on the machine, but the accesses that arrive with it no longer reach this machine.

## Account inventory

If the machine has the [agent](https://docs.ironchip.com/en/pam/administracion/agente/), it reports its accounts every few minutes: root and the accounts people sign in with, who administers the machine, the SSH keys used to sign in to each account and, on Windows, the services that run under each account.

Go to **PAM > Hosts > Accounts** to see every account on every machine:

[Image: Accounts page with each machine's accounts, whether they administer it, their keys and whether Ironchip manages them]

| Column               | What it shows                                                                                                                    |
| -------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
| **Account**          | The account, its `uid` and its shell, whether it is a domain account, whether it cannot sign in and which services run under it. |
| **Machine**          | The machine.                                                                                                                     |
| **Administers it**   | Whether it administers the machine: `root`, the `sudo` group or a `sudo` rule, or **no**.                                        |
| **Keys**             | The SSH keys authorized on the account.                                                                                          |
| **Last sign-in**     | The last sign-in.                                                                                                                |
| **Password changed** | The last password change.                                                                                                        |
| **Ironchip**         | The resources that sign in with it if Ironchip manages it, or **Not managed**.                                                   |

At the top are the **Machines reporting**, **Accounts**, **Administer a machine** and **Of those, not managed** counters. Select **Only those that administer a machine** and **Only those Ironchip does not manage** to see the privileged accounts you do not control yet.

### Manage a discovered account

1. In the account's row, click **Manage**.
2. Confirm with **Manage**.

The account is added to its machine's accounts with a password that Ironchip manages: the enforcer sets the first one (if `-rotate-accounts` includes the account) and then changes it every day and after every session.

**Manage** does not appear when changing the password would break something or serve no purpose: if services run under the account, if nobody can sign in with it, if it is already a domain account or if a resource already signs in with it. The machine needs an SSH or RDP resource.

## More information

- [Password rotation](https://docs.ironchip.com/en/pam/boveda/rotacion/)
- [Exposure](https://docs.ironchip.com/en/pam/administracion/exposicion/): SSH keys and sessions that bypass Ironchip.