What changed

Every content update is versioned. Select a version to compare it with the one before.

Version 8 → 9

Update

Two new sections: access for the time of the task (standing privilege compared to requests with a time window), and Sites, which route sessions through the gateways of a location.

2 lessons updatedduration

Content update. Enrolled learners were notified.

Duration changed from 16 to 17 minutes.

What Monopam does

Monopam is Monofor's **privileged access management** platform. Its job is simple to state: people and tools that need powerful accounts get **access to a session, not to a password**. Instead of handing an administrator the root password of a server, Monopam keeps that password in its vault, opens the connection on the user's behalf and can record what happens. When the work is done, the access ends and the evidence stays. ::diagram pgs-brokered-access ### The core ideas - **Brokered access:** users connect through Monopam; the gateway injects the credential and the user does not see it. - **Policy first:** policies decide who may reach which resource, with which account and on which terms (clipboard, file transfer, recording, approval). - **Evidence:** RDP sessions are recorded as video and terminal sessions as transcripts when recording is on. Reveals, connections and requests leave audit records. ### Sign-in comes from an identity provider Monopam has no local passwords and no MFA of its own. Users sign in at an identity provider, normally **Monosign**, through an OAuth2 or OpenID Connect method configured per tenant. Credentials and MFA are therefore the identity provider's job, and the groups and permissions a user holds arrive with that sign-in. ### Access for the time of the task Many organizations give administrators powerful access once and leave it in place for years. That is **standing privilege**: the access exists whether or not anyone is using it. Monopam lets you replace it with access that is asked for when it is needed. A user sends a request, an approver decides in **Requests**, and the approved request carries the time window during which the access is allowed. When the window ends, so does the access. This is what **just-in-time access** means in practice. Example: a contractor has to patch one server on Saturday. Instead of an account that works every day, they request that server for Saturday morning. The approver sees who asks, for what and for how long, and on Monday there is nothing to clean up. > Tip: When a customer asks where to enforce MFA for privileged access, the answer is the identity provider, not a Monopam setting.

The building blocks: vault, gateway and agents

A Monopam deployment has a few parts that work together. ::diagram pgs-building-blocks ### Web console The **web application** is where you define resources, vault items and policies, decide requests and review sessions. Users open browser sessions from here. ### Vault The **vault** stores accounts and secrets: user name and password, PKI keys, secret text, OTP seeds and other item types. Secrets are encrypted, and every save becomes a **version** that an administrator can see in Password History. A **Vault Access Policy** decides who may reveal which field. Every reveal or copy is audited, and the browser clears the shown value after 30 seconds. ### Gateway The **gateway** is the proxy that talks to target systems. It opens the connection, injects the vaulted credential, streams the session to the browser and writes the recording. Gateways send a heartbeat every five seconds and are listed under **System > Gateways**. You can place gateways close to the networks they serve and group them with **Sites**. ### Agent The **Monofor agent** is optional software for Windows, Linux and macOS endpoints. It enrolls with Monopam, creates or attaches to a resource and handles local-account work: listing accounts, verifying and setting passwords, removing accounts. Check the network path by platform: - **Linux and macOS agents** dial out over the **Agent Channel** on port 443, so no inbound port is needed for it. An inbound listener on port 4482 remains as a fallback, and new macOS installs ship with it off. - **Windows agents** in the shipped MSI do not have the channel yet. They are **inbound only**: the gateway must reach the agent on port 4482. ### Sites: gateways close to the systems they serve A company with several locations usually runs a gateway in each one. A **Site** models such a location: a plant, a data center or a branch. You attach gateways and resources to it, and Monopam then chooses the gateway by location, in this order: 1. If a resource is pinned to specific gateways, the pinning always wins. 2. Otherwise a resource that belongs to a site uses that site's gateways. 3. Otherwise any gateway may be used, as it was before sites existed. Example: a manufacturer has plants in Bursa and Izmir. Each plant becomes a site with its own gateways and its own machines. A session to a machine in Izmir goes through an Izmir gateway without anyone choosing it. The **Sites** page shows gateway health for each location, and every site has an **Activity Report**. Sites are optional. An installation that never creates one behaves exactly as before. > Tip: The **Connection** badge on the **Agents** list shows `Channel` or `Inbound` for each agent, based on what is connected right now.