HOW TO: Auto Re-Connect Locked RDP Sessions

[Sebastiano Alighieri]

This is not the first time a client has voiced concerns with the user-friendliness and level of productivity the PAM Client - RDP Applet affords users when the RDP session is locked due to user-inactivity.

 

When a auto-connect session is 'locked' due to user inactivity / saver timeout, users must currently disconnect and re-connect for the RDP session to auto-RE-connect to the user's previously established RDP session. A client is voicing their discontent with that product behavior, as it will cause their users to complain about having to reconnect to their RDP session every 15 minutes or whatever.

 

From a more technical standpoint, this behavior can lead to multiple check-ins/check-outs which may lead to multiple password changes for accounts (PVP-COV based) which can be problematic, especially in cases in which a domain password policy prevents account passwords from changing more than once in a 24 hr window (MinAge=1).

 

As a result, the client would like to understand if there is a way to force pam to re-inject the credentials without disconnecting the active (albeit, locked) RDP session without triggering a check-in or change-on-view?

 

 Is there a (information security) counter-argument for which clients wouldn't or shouldn't want that feature?

 

Also, they are curious as to what other clients may be doing in this case.

 

thanks in advance.

[Christian Lutz]

Hi Sebastiano,

 

There is currently no way to make PAM auto re-connect after the session is locked. I cannot think of any feasible workarounds that would make this work. If you would like to see this feature included in a future release I would recommend creating an Idea (enhancement request) here on the PAM community.

 

For now, I would suggest considering disabling the automatic lock timer for the RDP server you are connecting to. From a security standpoint, if this server is only accessed via RDP (no physical console to worry about) this should not be any security concern because ideally the end user's workstation should be locked. By properly locking the end user's workstation anything they were doing on PAM will be secured by the workstation lock. If disabling isn't acceptable then you could consider extending the lock out timer instead, this way at least there would be less occurrences of this problem.

 

If you do choose to keep any lock timer enabled then you could consider changing the Applet timeout in PAM to end BEFORE the lock out would. This way the user should get kicked out of the session by PAM before it would be possible to run into this situation.

 

Regards,

Christian Lutz

Support Engineer 3

Broadcom (CA) - ESD Support