- Can’t uninstall app: Delete or change Windows apps that have been flagged as non-removable - Thu, Mar 16 2023
- FSLogix VHDX compaction: Resize virtual disks - Thu, Dec 1 2022
- Sysinternals Process Monitor: Real-time file system, registry, and process monitoring - Fri, Oct 28 2022
On many platforms, security is now on par with user experience as the most important consideration in any infrastructure project. With the COVID-19 pandemic increasing the volume of remote working by an order of magnitude, securing the endpoint and user session has never been more important.
In any environment, but particularly so in RDSH or virtual desktop solutions, making sure that the "low-hanging fruit" of security is picked off is particularly vital. Missing basic security checkboxes can often result in data exfiltration, lateral movement, and privilege escalation, allowing attackers to gain a further foothold into networks and increase the scope of the compromise. It is very important to pay attention to the basic tenets of security to restrict an intruder's ability to penetrate deeper into the infrastructure.
There are many aspects to this "low-hanging fruit," but one of the more difficult ones to cover is how to lock a user's session after inactivity to ensure an attacker can't take advantage of an unattended workstation. This becomes even trickier in remote working scenarios, as you don't have any control of where the user is connecting from—it could be any public place with a WIFI connection. This is another example of trying to strike a balance between user experience and security—how do you manage to provide an acceptable level of protection yet ensure that users don't get interrupted in their work processes?
User profiling
First, you need to understand your users' practices. Are they leaving applications running active tasks for long periods of time? Do they open RDSH connections and then lock them before changing locations? Do they often rely on reconnecting to RDSH or VDI sessions so that they can "pick up where they left off?" Do they actually log out at the end of the day?
Software monitoring of some sort is important to help you understand this, but so is actively seeing how your users make use of the platforms they are provided. You need to routinely assess and map out how your users are operating to provide the right security settings. Now, this isn't to say that you should work around an insecure method—for instance, users leaving sessions connected for weeks on end just so they can reconnect to them is not desirable from a security or indeed from a financial standpoint—but you need to understand their behavior so you can adapt it if necessary. If you have users who routinely keep virtual sessions logged in for very long periods of time, begin to educate them in the importance of logging off at the end of a session. But also, potentially identify users who may have real business reasons to operate in this fashion. They may need to initiate long-running data tasks that could take hours or even days to complete.
It's also important to build a profile of what is executed within a user session. Especially when you have users who can stay in disconnected or idle states for long periods of time, you need to monitor what is being executed so that you can identify a potentially compromised session. If a user suddenly starts to use programs you wouldn't normally see them running, it could be an indicator of compromise. Using technologies like AppLocker can help greatly in this situation. The user will not be able to run prohibited programs, but the fact that they are attempting to run them should raise a red flag for action. This also highlights the importance of auditing and of log retention. You need to be able to step back through all of your logs and trace what has happened within the session.
There are many monitoring tools available that can look at user sessions and identify usage patterns and profiles. These include such technologies as:
- uberAgent
- ControlUp
- Goliath Technologies
- eG Innovations
- Nexthink
- Lakeside SysTrack
There are many more in this space. This is not intended to be an exhaustive list or set of recommendations, but these are products I have worked with in the past and have used to produce the detailed information required at this stage.
Configurable thresholds
The thresholds that can usually be configured as part of the user session are:
- Inactivity limit (the amount of time until a machine will lock when left unused)
- Active time limit (the amount of time a session can be active before it is disconnected or ended)
- Active but idle time limit (the amount of time an active session can be idle before it is disconnected or ended)
- Disconnection limit (the amount of time a disconnected session is maintained until it is ended)
User classification
Once you have profiled your users and understand the configurable limits, it is usually prudent to try to break your users down into user "classes" for which you have identified requirements. Here is an example:
Standard task workers
- Inactivity limit: 10 minutes
- Action on limit: Lock
- Active time limit: None
- Action on limit: N.A.
- Active but idle time limit: 60 minutes
- Action on limit: Disconnect
- Disconnection limit: 180 minutes
- Action on limit: Session end
How you select the criteria depends on input from your user profiling and the security requirements of your environment. For this generic set of users, the session will lock after ten minutes of inactivity, disconnect after 60 minutes of idle time, and end after being in a disconnected state for three hours.
Policies
There are several Group Policy Objects that can potentially help in these scenarios. However, the one you select will depend on whether you need different settings for different sets of users and whether you are using an RDSH platform or Windows client VDI.
Inactivity limit
First, there is the policy Computer Config > Windows Settings > Security Settings > Local Policies > Security Options > Interactive logon: Machine inactivity limit
Define this policy setting and simply set a time in seconds for how long it will take before an inactive session locks.
Interactive logon—machine inactivity limit
This policy is ideal if you wish EVERY user logging on to the machine to get the same lock timeout, because it is a computer configuration item and applies at the device level. Since Server 2012 and Windows 8, RDSH-based connections are considered to be "interactive" sessions, this policy will apply equally to users no matter what their connection type. If you are using Windows versions earlier than Server 2012/Windows 8, then you will not be able to use this setting. Also, bear in mind that when this policy is applied or updated, it requires the endpoint to be restarted before it takes effect.
If, however, you wish different groups of users logging on to the same machine to get different lock timeout settings, or if you are using a Windows version prior to Server 2012 or 8, you will need to use different policy settings. In this case, we can leverage the screen saver settings to create a similar end product.
Browse to User Configuration > Administrative Templates > Control Panel > Personalization and set the following:
Enable screen saver
Prevent changing screen saver
Password protect the screen saver
Screen saver timeout
Force specific screen saver
For the final setting, in the field that says, "Screen saver executable name," put this string:
%windir%\system32\rundll32.exe user32.dll,LockWorkStation
This is simply a shortcut to locking the session and will lock the screen instead of starting a screensaver.
You can set up different GPOs with different timeouts and use security filtering to apply them to different groups of users. However, be careful not to mix the screen saver timeout settings with the "machine inactivity lock" setting. The two will conflict with each other, so be sure you do not apply both these items to the same sets of devices.
One final word on the machine inactivity timeout—if you are using Windows 10 devices with Citrix Virtual Apps and Desktops, neither of these ways of enforcing an inactivity limit will work unless you apply the following registry change to the workers with the Citrix Virtual Delivery Agent on them:
- Key: HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\Graphics
- Value Name: SetDisplayRequiredMode
- Type: DWORD
- Value:00000000
Once this is applied, Citrix VDAs should apply the settings as normal (a reboot may be required for this setting to take effect).
Other session limits (active, idle, and disconnected)
If you are using RDSH, the other configurable items are driven by an interconnected set of GPOs that apply to either users or computers as required. If you are not using RDSH and are providing VDI on Windows client machines, you will need to use other third-party policy settings (see below).
RDSH connections
For RDSH, use the following policy settings (they all appear in Computer Configuration and User Configuration, so you can set them to apply to sets of devices or users as required):
Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Session Time Limits > End session when time limits are reached
End session when time limits are reached
I would recommend not using this setting as it will actually sign out an active or idle session when the time limit is reached. Generally, this would only be used in very high-security environments. Normally, the action for an active or idle session reaching the timeout is to disconnect it.
Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Session Time Limits > Set time limit for active Remote Desktop Services sessions
Set time limit for active Remote Desktop Services sessions
Again, this is something I would not configure unless in a high-security environment. This specifies the actual time that a session can have before it is disconnected or signed out (depending on the setting above), so the user could be happily working away and the session would end.
Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Session Time Limits > Set time limit for active but idle Remote Desktop Services sessions
Set time limit for active but idle Remote Desktop Services sessions
This setting means that when a session is idle (i.e., there is no input from the user), the specified timeout will be reached and the session will be disconnected (or ended, if you have configured End session when time limits are reached). This should be used but should obviously be set to a timeout more than that which is specified for the lock timeout (either the machine inactivity limit or the screen saver timeout).
Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Session Time Limits > Set time limit for disconnected sessions
Set time limit for active Remote Desktop Services sessions 1
Once a session has been disconnected (either because of the idle timer or a loss of network connectivity), another timer starts. Once this timer elapses, the session will then be logged off from the RDSH system. This should be used, but the timer should be measured carefully against the way users work. If you have users who frequently move from location to location and expect to pick up sessions where they left them, then setting this policy too aggressively may impact their way of working. On the flip side, allowing disconnected sessions to persist for a very long time or even forever (by setting this to Never) may constitute a security risk.
RDSH disconnection and timeout settings can be configured on the AD user object as well as by policy (see below), but personally, I try to avoid this as it adds another layer of management and troubleshooting.
User object timeouts
Windows client OS connections
Windows client virtual desktops (such as Windows 10) do not use RDSH and hence do not respect the above settings. Also, if you use Server OS instances in a one-to-one VDI mode (such as installing the Citrix VDA onto a Server OS using the /SERVERVDI switch), these sessions are console sessions and not RDSH; hence, they will also ignore the above settings. In these instances, you may need to leverage other methods to enforce timeouts.
If you are using Citrix, it provides equivalent policies that can be applied to Windows client devices either through GPOs or through the Citrix Studio policies. The equivalent for "Set time limit for active Remote Desktop Services sessions" is "Session connection timer interval."
Session connection timer interval
Again, I would not recommend using this unless absolutely necessary.
The equivalent for "Set time limit for active but idle Remote Desktop Services sessions" is "Session idle timer interval."
Session idle timer interval
The equivalent for "Set time limit for disconnected sessions" is "Disconnected session timer interval."
Disconnected session timer interval
Use these settings in the same way as recommended for RDSH unless you need to invoke a higher level of security. So disconnect idle sessions after the specified timeout, and then remove disconnected sessions after another appropriate timeout in line with the users' work patterns.
If you are not using Citrix but are using another virtual desktop platform to provide client OS-based systems, then you will need to find another way to enforce active, idle, and disconnection timeouts. Other vendors may have equivalent policies or configuration items you can use.
Other considerations
Once you have profiled the users, created the user classes, and activated the policies, you should now have an appropriate way of locking inactive sessions, disconnecting idle sessions, and removing disconnected sessions that is in line with your security policies and the working patterns of your user base.
There are some other peripheral considerations you may wish to consider, however.
Dynamic locking
The methods described here are fairly inflexible and still rely on static timeouts for activation, which could still potentially open up an (albeit small) security risk. Microsoft has introduced a feature in Windows 10 called Dynamic Lock that aims to address this. Windows 10 version 1703 or higher is required, and it is unclear whether this feature will migrate to RDSH Server or Windows 10 Multi-Session.
Windows 10 Dynamic Lock is configured by connecting a Bluetooth device to a client (normally a mobile phone). Dynamic Lock can then be enabled either directly by the user or through a Group Policy.
Bluetooth device connection
Dynamic Lock user configuration
To enable via GPO rather than directly on the device, use Computer Configuration > Administrative Templates > Windows Components > Windows Hello For Business > Configure dynamic lock factors
Enabling Dynamic Lock via GPO
While Dynamic Lock works on the client device, it is difficult to pass it through to the virtual desktop session itself. However, if your RDSH or VDI clients need an extra level of security in this area, consider using it or recommending it on the client devices. When the user moves away from the machine, the device is automatically locked as the signal strength of the Bluetooth device decreases.
Administrative sessions
Administrator sessions on devices represent a higher threat because of their elevated privileges. You should consider setting the timeout options more aggressively at all levels to protect these high-value sessions. Ideally, don't allow administrative sessions directly on the RDSH or VDI boxes, but insist that elevation be used instead for particular processes. If administrators need a "full" session, have it on a dedicated Privileged Access Workstation where they can connect remotely to the target devices through administrative tools instead. Also consider adding a second authentication factor to administrative elevation, such as a PIN from a separate device.
Multi-factor authentication
Multi-factor authentication (2FA) can help provide an extra layer of security as well, particularly for admin operations. Some 2FA can be configured to be required when elevating your session to an admin level (I have done this with Yubikey previously). You can also add endpoint MFA to high-value targets such as Privileged Access Workstations, so that when logging on users must provide a username and password but ALSO a code from a separate device. Making the use of MFA second nature to your users is an excellent way to improve your security posture.
Summary
So, in summary, here is how you would set up RDSH or VDI workers to have appropriate session timeout settings. The key thing is balance—understanding the working patterns of your user base and fitting appropriate timeout settings to secure this. And always remember—auditing is absolutely crucial because it's always a matter of WHEN, not IF, you suffer a breach.
