Nutanix's Frame® desktop-as-a-service, with its ability to deliver virtual desktops and applications on non-persistent virtual machines, is a key part of the security posture of many customers. When combined with Frame application mode, which eliminates the Windows® Desktop and focuses the end user on a single set of published applications, Frame provides enterprises with a secure way to deliver Windows applications and not lose control of the underlying data. As a part of our Enterprise Profiles capability, Nutanix released a feature that allows Frame administrators to further secure their Frame environment by forcing users with Enterprise Profiles to be logged in as a non-administrative local Windows user. Recently, this feature has been turned into a setting that can be applied to any Frame account that is not using the Frame Domain Join feature.
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.
Author
More content created by
David Horvath© 2024 Dizzion, Inc. All rights reserved. Frame, the Frame logo and all Dizzio product, feature and service names mentioned herein are registered trademarks of Dizzion, Inc. in the United States and other countries. All other brand names mentioned herein are for identification purposes only and may be the trademarks of their respective holder(s). This post may contain links to external websites that are not part of Dizzion. Dizzion does not control these sites and disclaims all responsibility for the content or accuracy of any external site. Our decision to link to an external site should not be considered an endorsement of any content on such a site. Certain information contained in this post may relate to or be based on studies, publications, surveys and other data obtained from third-party sources and our own internal estimates and research. While we believe these third-party studies, publications, surveys and other data are reliable as of the date of this post, they have not independently verified, and we make no representation as to the adequacy, fairness, accuracy, or completeness of any information obtained from third-party sources.