Keep web sessions after a disconnection

• Back to the web applications page

When the RDP connection drops, the web application of a Web target can stay open on the bastion.
The next connection of the same user to the same target finds the page as it was left.
The delay is set per access policy, from 1 minute to 8 hours.

How it works

The browser of a Web target runs on the bastion, inside the RDP session.
By default, a disconnection closes the browser.
The user then signs in to the application again, and a form in progress is lost.

With the option, the bastion keeps the browser after the disconnection.
It runs without display until the delay of the policy expires.

flowchart LR
    A[RDP connection drops<br>network, sleep, client timeout] --> B[Browser kept on the bastion<br>event web_session_parked]
    B --> C{Same user, same target,<br>same policy, before the delay?}
    C -- yes --> D[Page resumed<br>event web_session_resumed]
    C -- no, delay expired --> E[Browser closed<br>event web_session_expired]

1. The RDP connection drops: network loss, laptop in sleep mode, client timeout.
2. The bastion keeps the browser of the session.
   The event web_session_parked is written.
3. The user connects again, signs in (MFA included) and chooses the same target.
4. The session shows the page as it was, at the size of the new screen.
   A line at the bottom says Session resumed (kept 12 min after the disconnection).
5. Without a new connection before the end of the delay, the browser is closed.
   The next connection starts a new browser.

When the old connection is still open on the bastion, the new one takes its place.
This is the case of a laptop in sleep mode: the bastion has not seen the disconnection yet.
The old connection closes with the message This Web session was resumed from another connection.

Who can resume a session

Only the account that left the session can resume it, after a full sign-in.
The bastion identifies the account by the identity that Active Directory returns for the sign-in.
Two members of the same AD group never share a kept session.

One session is kept per account, target and policy.
A second connection of the same account to the same target takes the page back.

The browser is not kept, and the session behaves as before, when:

• the policy does not allow it (the default),
• the identity of the account cannot be proven by the directory,
• the limit of kept sessions of the bastion is reached,
• the free memory of the bastion is too low.

Enable it on a policy

1. Open RDS Proxy » Policies and edit the policy.
2. In the section of Web targets, set Keep Web sessions after a disconnection (minutes).
   From 1 to 480 minutes.
   0 turns the option off, which is the default.
3. Save.

The delay never goes beyond the end of the time window of the policy.
A browser kept at 17:50 on a policy open until 18:00 closes at 18:00.

The same setting exists in the RDS Proxy policy of Artica Meta, on each access rule.

Limits of the bastion

Each kept browser uses memory on the bastion.
Two settings protect it, in RDS Proxy » Status » WebView:

When a limit is reached, the session closes at the disconnection, as before.
The event web_session_keep_refused says why.

See and close kept sessions

The Kept sessions tab of RDS Proxy » Status » WebView lists the sessions:
user, target, workstation address, waiting since, expiry and memory used.

The Close button ends a session at once.
It also works on a session in use: the user loses the page.
The event web_session_closed_by_admin is written.

Stopping the RDS Proxy service closes every kept session.
Saving a policy does not.

Events

When the bastion is connected to Artica SIEM, the events kept, resumed, taken over and expired are also sent in the rdp-v1 format.

When the policy changes

A kept browser keeps the rights of the policy that opened it.
If the policy changes during the delay, the kept browser is closed at the next connection.
A new browser starts with the new rights.
The event web_session_resume_failed gives the reason policy_changed.

Requirements

While one of them is older, no session is kept.
The policy window and the WebView tab say which component is missing.

A restart of the authenticator forgets the kept sessions.
Their browsers stay until the end of their delay, then close.

Security

• The browser stays signed in to the application during the whole delay.
• The network filters, the proxy and the PAC of the policy stay active while the browser waits.
• The token that links a connection to its kept browser never appears in a log or an event.