Just-in-time access with Monopam
What changed
Every content update is versioned. Select a version to compare it with the one before.
Version 8 → 9
UpdateNew module on approval design: where approval is configured, how the window and the approver count work, and approvals for vendors, external users and script runs. The module now has diagrams and a closing list of what to check first.
2 lessons updatedduration
Content update. Enrolled learners were notified.
Duration changed from 20 to 21 minutes.
"Put an approval on it" can mean three different settings in Monopam. They live in different places and they behave differently, so the first design step is to name which one you need.
| You want approval before | Configure | Window the requester gets |
| --- | --- | --- |
| Anyone connects to a resource | `Approvement` on the `Advanced` tab of the resource's settings, with its approvers | A plain connect request gets a fixed 8 hours from now, and that length cannot be changed on the resource. TheA different window goes through the `Scheduled` option inof the connect window, shownwhich appears only when the resource requires approval. The request is then of the type `Scheduled Connection`, letsand its detail shows the requester ask for a chosen window instead`Requested Access Period` |
| Anyone reveals a protected vault field | Approval set to `Required` in the workflow of the Vault Access Policy | The duration the request asked for |
| A specific shell command runs | A privileged command rule with the behaviour `Requires Approval` | One run of exactly that command line, within 60 minutes |
::diagram pam-approval-places
A contractor who needs two approved hours on one server is therefore a resource with `Approvement` on, plus a `Scheduled` request for those two hours. When the window closes the access ends by itself. Nobody has to remember to remove it.
### What a late approval does to the window
A policy approval has a duration type. It decides what happens when the approver is slower than the requester hoped.
| Type | Rule | Request for 14:00 to 16:00, approved at 15:15 |
| --- | --- | --- |
| `OnRequest` | The window slides to the moment of approval and keeps its length | 15:15 to 17:15 |
| `OnSchedule` | The window stays exactly where the requester put it | 15:15 to 16:00. The delay is lost |
Use `OnSchedule` when the time itself matters, such as a change window agreed with the business. Use `OnRequest` when the person simply needs a certain amount of working time.
### How many approvers
An Approval item names approvers and says how many are needed.
| Setting | Meaning |
| --- | --- |
| `RequireAll` | Every named approver must approve |
| `MinimumApprovalCount` | Any N of the named approvers are enough |
| `RequireBySelf` | The requester is added as an approver and the needed count rises by one |
Six people named with `MinimumApprovalCount` at 3 means any three of the six. Add `RequireBySelf` and the request needs four approvals: the requester's own confirmation and three others. `RequireBySelf` is useful as a deliberate "I confirm I am asking for this" step, not as a way to reduce the number of independent approvers.
A request that names no approver does not vanish. It shows a `No approver` badge and a super administrator can decide it. Still, treat that badge as a configuration error to fix.
### Deny or approval for a command?
Both behaviours stop a command line before it reaches the shell. Choose by asking whether the command is ever legitimate.
- Never legitimate from a brokered session: `Deny`.
- Legitimate but rare and high-impact, such as restarting a production database host: `Requires Approval`. A second person witnesses each run.
- Routine: neither. Every approval costs an approver's attention, and approvers who are asked fifty times a day stop reading.
### What actually reduces standing privilege
Recording and rotation are valuable, but with them the access still exists all the time. Privilege stops being "standing" only when it is absent by default: a grant that ends on its own when its window closes, or an approval step that stands between a person and a secret each time. When someone asks which controls reduce standing privilege, those are the two kinds to name.
> Tip: when a requester complains that the approved window was shorter than what they asked for, look at the duration type before anything else. With `OnSchedule`, a late approval eats into the window by design.
Third parties are where just-in-time access earns its keep. Follow one contractor, Deniz from a maintenance supplier, through the whole life of her access.
::diagram pam-vendor-access
### 1. The invitation is itself a request
A super admin uses `Invite External User`. This does not create an account. It creates an approval request.
- Approvers are the super admins **other than the requester**. Only when there is a single super admin does that person approve their own request.
- There can be one open invitation per email address. A second invitation for the same address is refused while the first is pending.
- After approval Deniz receives an enrollment email and becomes an external user with an expiry date.
An approved invitation cannot be taken back from `Requests`, because the email has already left. If the approval was a mistake, end the access where the account lives: `Deactivate` on the `Users` page, or let it expire.
### 2. Expiry and `Extend Access`
When the access period ends, the account is disabled. `Extend Access` gives a new end date and re-enables an account that was disabled **by expiry**. It does not re-enable an account that an administrator disabled on purpose and that had not expired. A new date never overrides a deliberate decision.
### 3. The vendor's guardrails
Deniz's account belongs to a vendor organization, and the vendor carries settings that apply to all its users.
| Vendor setting | Effect | Watch out for |
| --- | --- | --- |
| `Require approval for every connection (JIT)` | Every connection by the vendor's users needs approval, on every resource | On a resource with no approval flow of its own, the request is sent to every super admin. Make sure they expect it |
| `Allowed Sites` | The vendor's users may connect only to resources in the selected sites | A resource with no site counts as **outside**. The user sees "This resource's site is not allowed for your vendor organization." even with a valid policy |
The fix for the second case is to assign the resource to the right site, not to loosen the vendor. A policy decides what a user may reach. `Allowed Sites` is a separate check made when the session is created and again when it connects.
### 4. Scripts on many servers
The Script Library has two optional gates. **Publish approval** means a new version of a script needs an approver before it can run at all. **Run approval** means a run request needs an approver. One run request can target many resources, and it is approved once for the whole batch, not once per server. Approvers should therefore read the target list as carefully as the script.
### 5. When access ends earlier than approved
If a user reports that an approved grant stopped working before its end time, there are two usual causes.
| Check | Meaning |
| --- | --- |
| The request's state is `Cancelled` | Somebody revoked the grant |
| The grant is for database queries and the request is not cancelled | Such a grant can carry a usage limit. Compare the used count with the limit: when the allowed runs are spent, the grant is over even though the clock is not |
### What to check first when a vendor user cannot connect
1. Is the account active? An expired account is disabled, and `Extend Access` brings it back. An account that was disabled on purpose stays disabled.
2. Is the resource in one of the vendor's `Allowed Sites`? A resource with no site counts as outside.
3. Is a request waiting? With `Require approval for every connection (JIT)` every connection needs an approval, and on a resource with no approval flow of its own the request waits on the super admins.