> For the complete documentation index, see [llms.txt](https://wiki.datadike.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wiki.datadike.com/pam/get-started/first-managed-asset.md).

# Onboard your first managed asset

The end-to-end path from an empty instance to a recorded session: register an asset, choose its platform, register the account, write the authorization, connect, and find the recording in the audit tr

This is the whole product in one exercise. By the end you will have an asset the solution manages, a credential it holds and never shows, a rule that grants one person the use of it, and a session in the audit trail that can be replayed.

Each step below links to the page that covers it properly. Read this page for the **order and the decisions**; read the linked pages for the fields.

{% hint style="info" %}
Choose the simplest possible first asset: a Linux host the solution can already reach over SSH, with a local account whose password you know. Prove the chain on that, then repeat it on the awkward cases. Onboarding a segmented Windows host behind a broker as your first exercise means debugging four things at once.
{% endhint %}

If the words *asset*, *platform*, *account* and *authorization* are not yet distinct in your mind, read [Core concepts](/pam/get-started/core-concepts.md) first — this page uses all four.

## Before you start

* A role that gives you the **Sysadmin** area. See [Roles and permissions](/pam/administration/identities/roles.md).
* A **second user** with no privileges beyond Cockpit, to receive the authorization. Granting it to yourself works, but testing with someone who starts with nothing is what actually proves the rule is doing the granting.
* The target's **address** and a **credential** on it — username and password, or an SSH key.
* Network reachability from the solution to the asset, on the protocol's port. If there is none, step 1 is where you deal with it.

{% hint style="warning" %}
**Import the licence first.** Until the licence is imported, functions are disabled, and the symptom is features that appear to exist and do nothing. Licensing lives in **System settings**.
{% endhint %}

{% hint style="warning" %}
**Check the server's clock and time zone before anything else.** One-time passwords are second-precision, so a drifted clock produces `OTP code invalid, or server time error` at login and blocks you out of the console for reasons that look nothing like a clock problem.
{% endhint %}

## Steps

### 1. Decide the network path

Do this first, because the asset's registration makes you commit to it.

| Situation                                              | What you configure                                                                                                                                                        |
| ------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| The solution has a route to the asset itself           | Nothing. This is the case to choose for your first asset                                                                                                                  |
| Only one machine of the target network is reachable    | A [Proxy](/pam/administration/connectivity/proxy.md) — the zone — with the jump machine registered inside it as a [Gateway](/pam/administration/connectivity/gateways.md) |
| No route at all, or no inbound connection is permitted | A [Broker](/pam/administration/connectivity/broker.md), which the remote side dials out to                                                                                |

{% hint style="warning" %}
An asset uses **a proxy or a broker gateway, never both**. Proxy and gateway are two halves of one mechanism — the zone and the machine inside it — not two alternatives.
{% endhint %}

### 2. Choose the platform

The platform is what tells the solution which protocols the asset accepts and on which ports, so it has to be right before the asset is registered. Open **Environment › Platforms** and find the built-in one that matches the technology — *Linux*, with SSH on 22, for a Linux host.

Built-in platforms cannot be edited, only **duplicated**. If you need a variant, duplicate it and change the copy. See [Platforms](/pam/administration/assets/platforms.md).

{% hint style="info" %}
The port on a platform is the **default inherited** by assets registered against it afterwards. Changing it later does not move assets already registered — that needs **Sync protocols to assets**.
{% endhint %}

### 3. Register the asset

In **Environment › Assets**, create the asset with its name, its address, and the platform from the previous step. File it in a folder while you are there — reorganizing later is much more work than filing now.

Then run **Test Connection** on the card. Registering an asset and being able to reach it are different things, and the card looks identical either way. See [Asset inventory](/pam/administration/assets/inventory.md).

For a network segment with many hosts, register the first one by hand and then use [Discover](/pam/administration/assets/discovery.md) for the rest.

### 4. Register the account

In **Accounts › Accounts**, create the account against the asset you just registered: the username, the secret, and two decisions that are easy to skip and awkward to fix later —

* mark it **Privileged** if it holds administrative rights on the target;
* set **su/sudo** if the account must elevate after logging in.

Save, then use **Test selected** to confirm the credential actually authenticates. See [Managed accounts](/pam/administration/accounts/managed-accounts.md).

{% hint style="info" %}
If the same credential exists on many assets, do not register it repeatedly — use an [account template](/pam/administration/accounts/account-templates.md). And if the accounts already exist on the target and you do not know all of them, collect them from the asset instead of typing them in.
{% endhint %}

### 5. Write the authorization

This is the step that grants access. Everything before it only made the asset manageable.

In **Policies › Authorization**, create a rule that joins the three sides:

* **Who** — the test user, or better, a group they belong to.
* **What** — the asset (or the folder it sits in) and the account you registered.
* **How** — the protocol, at minimum the **Connect** action, and a validity period.

Name the rule so that it says who gets what: the name is the first thing an auditor reads. See [Authorizations](/pam/administration/access/authorizations.md).

{% hint style="warning" %}
A rule can save cleanly and still grant nothing, because it is inactive or outside its validity window. Check the **Valid** column, not the fact that the rule exists.
{% endhint %}

### 6. Open the session

Sign in as the granted user and open **Access** in the **Cockpit** area. The asset must be listed there; if it is not, the rule is not reaching that user and there is no point connecting.

Connect with **Web CLI** for SSH. You will not be asked for the target's password — the solution injects it. Run two or three harmless commands (`hostname`, `id`, `uptime`) so the recording has something in it.

Other methods — the browser desktop, a native client, a database client — are covered in [Connection methods](/pam/administration/sessions/connection-methods.md).

### 7. Find it in the audit trail

Back in an administrator or auditor session, open **Audit › Console › Session records**. The session you just ran is there, with its user, asset, account, protocol, start and end times and duration, and a button that replays it. See [Audit trail](/pam/administration/audit/audit-trail.md).

## What you should see

* The asset as a card under the folder you filed it in, badged `ACTIVE`, with the effective protocols and ports of its platform.
* The account listed against that asset, with the date of its last update.
* The authorization in the rule list with **Valid** showing that it is in force.
* The asset present in the granted user's **Access** list, and absent from the list of a user with no rule.
* One entry in **Audit › Console › Session records** for the session you opened.

## How to verify it worked

**The recorded session in the audit trail is the verification.** Nothing before step 7 proves the chain — an asset can be registered and unreachable, an account can be stored and wrong, a rule can exist and grant nothing.

1. Open **Audit › Console › Session records** and find the session by user and time.
2. Check the three columns that matter: the **user** is the person who connected, not a shared identity; the **asset** is yours; the **account** is the one you registered. Together they are the proof that attribution and credential injection both worked.
3. Play the **recording**. The commands you ran must be visible in it. See [Session recordings](/pam/administration/audit/recordings.md).
4. For SSH or Telnet, open **Audit › Sessions › Keylogger** and confirm those same commands are listed individually, with timestamps.
5. As a negative check, set the authorization **Active** off and reload the granted user's **Access** list. The asset must disappear. That is what confirms the authorization is granting the access, and not something else you configured along the way.

If the session record is there but the replay is not, the chain worked and the problem is recording or storage, not access.

## Common errors

| Symptom                                                                     | Cause                                                                                      | Fix                                                                                     |
| --------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------- |
| Screens are present but features do nothing                                 | The licence has not been imported                                                          | Import it under **System settings**                                                     |
| `OTP code invalid, or server time error` at login                           | The server clock has drifted; OTP is second-precision                                      | Correct the time and time zone on the node, and keep it synchronized                    |
| The asset saves but **Test Connection** fails, though the host answers ping | Wrong effective port, or no account yet to test with                                       | Compare **Protocols** under the asset's **Basic** tab against the host                  |
| The session is refused over a protocol you expected                         | The platform does not offer it                                                             | The platform is wrong, not the asset. Check **Environment › Platforms**                 |
| The account saves but authentication fails on the target                    | The stored secret does not match the target                                                | Nothing in the registration reveals this. Only **Test selected** or a real session does |
| The granted user sees no assets at all                                      | The rule reaches neither the user nor a group they belong to, or it is inactive or expired | Check the rule's subject, then its **Valid** column                                     |
| The asset appears but the session is refused                                | The protocol is not in the rule's protocol list, or the account selection excludes it      | Fix the rule, not the asset                                                             |
| The asset appears but no connection method is offered                       | A connect method rule denies every method for that user                                    | Review **Policies › Connect method**                                                    |
| The session record exists with no replay                                    | Recording was off for that asset, or retention has passed                                  | Check the recording configuration and **System settings › Retention**                   |

## Where to go next

Once one asset works end to end, the rest of the environment is repetition plus policy:

* Register the remaining assets in bulk with [Discover](/pam/administration/assets/discovery.md), and file them with [folders and tags](/pam/administration/assets/folders-and-tags.md).
* Stop typing credentials one by one with [account templates](/pam/administration/accounts/account-templates.md), and put them on a schedule with [rotation](/pam/administration/accounts/rotation.md).
* Restrict what may be run inside a granted session with [command inspection](/pam/administration/access/command-filtering.md).
* Replace standing grants with [just-in-time access](/pam/administration/access/just-in-time.md) where the access is occasional.
* Bring the people in from your directory with [LDAP and Active Directory](/pam/administration/identities/ldap-and-ad.md) and require [MFA](/pam/administration/identities/mfa.md).

## Related pages

* [Core concepts](/pam/get-started/core-concepts.md) — the four objects this page chains together
* [Asset inventory](/pam/administration/assets/inventory.md) and [Platforms](/pam/administration/assets/platforms.md)
* [Managed accounts](/pam/administration/accounts/managed-accounts.md)
* [Authorizations](/pam/administration/access/authorizations.md)
* [Audit trail](/pam/administration/audit/audit-trail.md)