On this page

• Why privileged access is hard
• The Console Portal
• The Session Portal
• Access outside ManageLM
• Recorded and replayable
• What you stop running

Why privileged access is hard

Privileged access is the part of an infrastructure nobody enjoys owning. The keys get copied. The bastion is itself a server that has to be patched, watched and paid for. The VPN is a permanent opening with a password in front of it. And the honest answer to "who is on the production database server right now" is usually a guess followed by a grep.

ManageLM takes the opposite route. The agent already installed on each server holds an outbound connection to the portal, so an administrator reaches a machine through the platform rather than through the network. Every session is therefore something the platform opened: it knows who asked, it checked they were allowed, it can record it, and it can end it.

Two pages carry the whole idea. The Console Portal is what your operators use. The Session Portal is what you watch.

The Console Portal

A page of its own at /consoles: every server you are allowed to open, and nothing else. It is built to be bookmarked and left in a tab. Open the bookmark, sign in if your session has expired, pick a host. Unlike a link to one particular shell it keeps working when a server is rebuilt, and when today's problem is on a different machine.

Access is granted per server, not per network

The list shows what you may open, and it is the same test the console itself applies: the Console permission, plus your assignment to that server. It is a shortcut to access you already have, never a way to acquire some. Revoke the permission and any window that person already had open closes within a minute.

Compare that with a network-level answer. A VPN or a jump host grants a segment; the moment somebody is on it, what they can reach is a routing question rather than a policy one. Here the unit is the server, and the grant is checked again every time a session opens.

A passkey at the start of every session

Signing in to the portal is not enough to open a root shell. A passkey is confirmed at the moment the session opens, every time, on terminals, file browsers and desktops alike. That is what stops a borrowed laptop or a stolen browser session from becoming access to production, and there is no way to skip it: an account with no passkey enrolled cannot open a console at all.

Sessions then lock themselves when they go idle, after a number you set from five minutes to an hour. A terminal covers its screen and stops accepting input while your work keeps running behind it. A desktop closes and can be resumed exactly where it was. Walking away from a machine stops being the same thing as leaving the door open.

The Session Portal

Who is connected to your servers, and how. A page of its own at /sessions, meant to be left open on a second screen. People are drawn down one side, servers down the other, and a line joins them wherever somebody is connected. It is the question every access review asks after the fact, answered while it is still happening.

It draws sessions, not your fleet. A server nobody is on does not appear at all, so four people working across five hundred servers draw four lines. The picture stays the size of what is happening rather than the size of what you own, which is what makes it readable at a glance from across a room.

Each person's card carries a badge per kind of connection with a count: terminals, file browsers, desktops and host logins. Hover a card or a line to see every session behind it, including what kind it is, how long it has been open, where it came from and when it started. Click to pin the panel open while you read it.

Two kinds of connection appear here that ManageLM did not open: somebody signed in over SSH, and on Windows somebody connected by RDP or at the console. A Windows session whose client has disconnected but is still signed in is shown as idle, a distinction the usual Linux tooling cannot make.

Access outside ManageLM

Most privileged access products tell you about the sessions they opened. The interesting ones are the others: the key an engineer added by hand two years ago, the password login on a machine that predates your policy, the service credential in a script nobody has read since. Those sessions are not recorded, the idle lock cannot reach them, and until now they were invisible.

ManageLM shows them anyway. A login that did not arrive through a key it manages is marked with a warning on the person's card and counted in the header of the page, so "how much of my privileged access is outside my control" becomes a number on a screen rather than a project. It is also the honest measure of how far a key migration has actually got.

You can be emailed when one appears. Unmanaged Access is off by default, on purpose: until every key on a fleet has been moved into ManageLM this fires for every ordinary login, and a notification that is noise on day one is one nobody reads on day ninety. Switch it on the day unmanaged access becomes a finding on your fleet rather than a description of it.

Recorded and replayable

Recording is decided per server, or set on a group to cover every server in it. A group can only switch it on, which is what makes it usable as a policy rather than a preference. Servers being recorded carry a badge in the list and the operator sees one in the window, so nobody is recorded without knowing.

For the portal's own sessions nothing is installed on the server to make this work: the portal already relays every byte, so it records what it is already carrying. Direct SSH logins are recorded by the agent on the host itself, since those never pass through ManageLM at all.

1. Your bucket, your keys
   Recordings are encrypted before they leave your infrastructure and written to your own S3 storage. The bucket holds nothing readable and ManageLM keeps no copy.

2. Replay in place
   Play, pause, scrub and change speed. A timeline beside the player lists the moments worth jumping to: when the screen locked, what the assistant proposed and whether it ran, and every file that moved.

3. Hand it to an auditor
   Download a terminal session as an asciinema cast that plays on any machine and needs nothing from us. A desktop session downloads as a Guacamole stream that converts to an ordinary video.

4. Retention you set
   Recordings are deleted from your bucket automatically after a period you choose, capped by your audit log retention so a recording never outlives the entry saying who opened it.

What you stop running

The business case is mostly subtraction. Every row below is a component you no longer buy, patch, monitor, renew or explain to an auditor: