> For the complete documentation index, see [llms.txt](https://docs.securepass.me/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.securepass.me/documentation/admin-user-guide/privileged-access-pam-setup/connecting-target-systems/manage-systems.md).

# Manage Systems

**Manage Systems** is where Windows and Linux servers are onboarded for privileged access, so users reach them through SECUREpass under a role-based policy rather than connecting directly.

This page walks through onboarding a server end to end. Databases, cloud resources and network devices follow the same four-step pattern with their own field sets, and have their own pages in this section. How the gateway sits between the user and the target is covered on *Connecting target systems*.

## The Manage Systems page

Open **Manage Resources → Manage Systems**. The page lists the systems already onboarded.

![](https://content.gitbook.com/content/W2srIAMN6RKFwvuEorV5/blobs/CRyuMM4l423L4dfe6KEY/assets/01.png)

Select **Add System**. The wizard opens with four steps: **System Details**, **Local Accounts**, **Assign Roles** and **Authentication**.

{% stepper %}
{% step %}

## System details

The fields differ by protocol. Both variants are below.

### Linux and SSH

![](https://content.gitbook.com/content/W2srIAMN6RKFwvuEorV5/blobs/HBt673fzq86voONHFvgr/assets/02.png)

| Field                 | What to enter                                |
| --------------------- | -------------------------------------------- |
| System Type           | **Linux**                                    |
| System Name           | Required. The name shown in the systems list |
| IP Address / Hostname | Required                                     |
| Type                  | Required. **SSH Server**                     |
| Port                  | Required. Defaults to 22                     |
| Status                | **Active** or inactive                       |
| Hostname / FQDN       | Optional                                     |
| Description           | Optional                                     |
| Domain Mapped         | Whether the system is joined to a domain     |

### Windows and RDP

![](https://content.gitbook.com/content/W2srIAMN6RKFwvuEorV5/blobs/7kpVYEkNRFTsjJCcqEXS/assets/03.png)

| Field                 | What to enter                                                                           |
| --------------------- | --------------------------------------------------------------------------------------- |
| System Type           | **Windows**                                                                             |
| System Name           | Required                                                                                |
| IP Address / Hostname | Required                                                                                |
| Type                  | Required. **RDP Server**                                                                |
| Port                  | Required. Defaults to 3389                                                              |
| Status                | **Active** or inactive                                                                  |
| SSH Port for Rotation | The SSH port used to rotate this system's credentials. **Leave blank to skip rotation** |
| Hostname / FQDN       | Optional                                                                                |
| Description           | Optional                                                                                |
| Domain Mapped         | Whether the system is joined to a domain                                                |

{% hint style="info" %}
**SSH Port for Rotation** appears on Windows systems because password rotation reaches the host over SSH even where the session itself is RDP. Leaving it blank means this system's credentials will not rotate automatically — acceptable for a lab, not for production.
{% endhint %}

### PAM security policy

Below the system details sits the PAM Security Policy, which governs what a session on this system is allowed to do. Some settings are common; others appear only for one protocol.

#### Common to both

![](https://content.gitbook.com/content/W2srIAMN6RKFwvuEorV5/blobs/2632zBgiOjDqaWhf11TU/assets/04.png)

| Setting                 | What it does                                                                                                                                                         |
| ----------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Clipboard Policy        | Controls copy and paste between the user's machine and the session. **Paste Only** is recommended — it allows input but stops data being copied out                  |
| Max Concurrent Sessions | Caps how many sessions can be open on this system at once                                                                                                            |
| Requires Dual Control   | A second person must approve before a session can start. Turn on for production systems                                                                              |
| Emergency (Break-Glass) | Marks this as an emergency-access system that bypasses normal approval when other paths are unavailable. Keep off unless this is specifically your break-glass route |
| File Transfer           | Allows files to move to and from the system during a session. Turn off unless transfer is genuinely required                                                         |
| Record Sessions         | Records the full session for audit playback. Turn on for any sensitive or regulated system                                                                           |
| Idle Timeout (minutes)  | Disconnects after this many minutes of inactivity. `0` means never; 15 to 30 closes abandoned sessions                                                               |

#### Windows and RDP only

![](https://content.gitbook.com/content/W2srIAMN6RKFwvuEorV5/blobs/njs4mN5UxszCisaZGaa2/assets/05.png)

| Setting                    | What it does                                                                                                                                                                 |
| -------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Recording Retention (days) | How long session recordings are kept before deletion. Set against your compliance standard — commonly 90, 180 or 365                                                         |
| File Transfer (Drive)      | The RDP form of file transfer, mapping a drive into the session                                                                                                              |
| Windows Domain             | The domain the target belongs to, for example `corp.example.com`. Optional                                                                                                   |
| Security Mode              | **NLA — Network Level Authentication** is recommended. NLA authenticates before the desktop session is created, which blocks unauthenticated connection attempts at the door |

#### Linux and SSH only

| Setting                | What it does                                                                                                       |
| ---------------------- | ------------------------------------------------------------------------------------------------------------------ |
| JIT Provisioning       | Creates the user's account on the system at session start and removes it afterwards, so no standing account exists |
| Blocked Commands (SSH) | A JSON list of commands the session refuses to execute, such as `rm -rf`                                           |
| Enable Command Logging | Records every command entered as searchable text, which is far faster to audit than video playback                 |

### Test the connection

Select **Test Connection** to confirm SECUREpass can reach the system before going further. A failure here is almost always a firewall rule or a gateway IP that has not been whitelisted.

![](https://content.gitbook.com/content/W2srIAMN6RKFwvuEorV5/blobs/NhsxPRc3oLR3uQYBOWe7/assets/06.png)

![](https://content.gitbook.com/content/W2srIAMN6RKFwvuEorV5/blobs/Io4PqHNEEzyWG6EVU7Nl/assets/12.png)

When the test succeeds, select **Next**.
{% endstep %}

{% step %}

## Local accounts

Enter the admin account details and select **Fetch Accounts**. SECUREpass discovers the local accounts on the system.

![](https://content.gitbook.com/content/W2srIAMN6RKFwvuEorV5/blobs/puJQEjsjcm3HZL4qDBRX/assets/07.png)

Open the dropdown, select the account you want to onboard, enter its password and select **Test Credentials**.

![](https://content.gitbook.com/content/W2srIAMN6RKFwvuEorV5/blobs/fnDo0y2wySE2wdcxhVDI/assets/08.png)

Once verified, select **Add to List**. The account appears in the list.

![](https://content.gitbook.com/content/W2srIAMN6RKFwvuEorV5/blobs/wvf3hMi7uKDTTLhRYoe2/assets/09.png)

Repeat for each account you want under management, then select **Next**.
{% endstep %}

{% step %}

## Assign roles

Roles are derived from the group memberships discovered against each account. They are what you attach authentication policies to in step 4.

![](https://content.gitbook.com/content/W2srIAMN6RKFwvuEorV5/blobs/qF49qB8RUlrPjWOn45Qk/assets/10.png)

Select **Next**.
{% endstep %}

{% step %}

## Authentication

Set the authentication methods for each account and enable MFA where needed. **Blocked Settings** lets you refuse access from particular IP addresses, locations, browsers or operating systems before authentication even runs.

![](https://content.gitbook.com/content/W2srIAMN6RKFwvuEorV5/blobs/S0abc11LsF9pIzfZu836/assets/11.png)

Select **Save**. The system appears in the systems list and is ready to be granted to users.

![](https://content.gitbook.com/content/W2srIAMN6RKFwvuEorV5/blobs/fFxxBqMzeD5ZtTqUi02e/assets/13.png)

{% hint style="info" %}
Onboarding a system does not give anyone access to it. Access is granted separately — see *Access Management → System access control*, where users are mapped to a privileged account on the system.
{% endhint %}
{% endstep %}
{% endstepper %}

Onboarding a system is the same four steps whichever protocol you use: describe the system, set the policy that governs sessions on it, vault the accounts, and decide how users authenticate. What changes between Windows and Linux is the field set — RDP brings a security mode and a recording retention period, SSH brings command filtering and just-in-time provisioning.