Enhancing the Security of Application Delivery in Frame

Non-Persistent Frame Accounts​

Nutanix Frame's original solution provided customers the ability to create a pool of non-persistent machines (we have since added a persistent desktop option, as well). But what does non-persistent machines mean? Well, it means that during the Frame Publishing process, Frame sets up the pool of workstations to have C: drives that do not retain changes between user sessions. You can verify this by creating a Frame account, setting Default Capacity "Max number of instances" to a greater than 0 value (I used 3) and publishing. If you are not familiar with Frame, this link describes that process.

The publish takes a few minutes, but when completed, you can create a Frame Desktop Launchpad and start a Frame session. Once in that session, you will be logged on as the local Windows admin user called "Frame" and you will be able download and install an application. I chose peazip. It should install, run fine, and even create a desktop icon.

Now, close your Frame session. This will reboot that instance which will clear all the changes you made. To confirm, you can start a new Frame session and confirm that peazip is not installed.

The non-persistence feature of the non-persistent Frame account does not prevent the user from making desktop changes or even potentially downloading some malware. It does mean that the change will only be for that session, limiting the scope of what the malicious software can affect.

Application Mode​

To provide some additional security around accidentally downloading malware, you can deploy a Frame Application Launchpad instead of a Desktop Launchpad. Frame Application Launchpads provide Frame administrators the ability to deliver direct access to a set of applications without having the user experience a full Windows Desktop. This streamlines the User Interface (UI) and can make it more difficult for users to download and install applications.

However, it does not completely prevent this. On my test account, I created an Application Launchpad that limits users to using Notepad only. Launching a Frame session provides only that Notepad application and the user can not use many of the traditional Windows desktop functions directly. A determined user can use the "File open" dialog of Notepad to find the Chrome browser executable C:\Program Files (x86)\Google\Chrome\Application and then right click and "Run as administrator" to bring up the Chrome browser.

Then they could download and install peazip, or other software.

Again, the non-persistence feature would remove the changes at next login so the risk of installing persistence malware is mitigated.

Non-Admin User​

With the new Frame Guest Agent (FGA) 8.x, a feature has been added so Launchpad users are logged into non-persistent workloads as a non-administrative user. This feature can be enabled by going into the Frame Account Dashboard and navigating to "Settings" -> "Session" -> “Advanced Server Arguments'. In that text box, you simply place -logoffuser and then save the change.

Now, if you start a session, you will be logged on as local Windows user "FrameUser". This user does not have administrative privileges and is unable to install peazip.

Note that this setting will also affect Sandbox sessions, so if you don't want that (likely since the Sandbox is where the main configuration of the image is done), you will need to navigate to the Sandbox page, click on the three dots of the top far right, and go to "Session" -> "Settings".

Toggle off "Use Account Settings" and clear the -logoffuser from the Advanced Server Arguments and click "Save".

Conclusion​

The additional feature of automatically logging in a local non-administrative Windows user enhances the existing Frame security features of non-persistent Frame Accounts and Application Launchpads where Enterprise Profiles are not used. Combining all three allows administrators to focus on the user's experience with their applications rather than implementing complex security lockdown procedures.