Amazon WorkSpaces Pools: our desktop business application requires its users to be member of a specific group. Virtual desktop user does not have local admin permissions.

Based on your requirements and the challenges you're facing with Amazon WorkSpaces Pools, I can provide some guidance on how to address the issue with adding users to the "Performance Monitor Users" group.

First, it's important to understand that Amazon WorkSpaces Pools provides non-persistent virtual desktops where users get a fresh desktop each time they log in. This differs from Amazon WorkSpaces Personal, which offers persistent desktops where users can retain their personalized settings and applications.

For your specific requirement of adding users to the "Performance Monitor Users" group, here are some approaches:

1. Custom Image Creation: You're on the right track with creating a custom image. With WorkSpaces Pools, you can create a custom bundle that includes your business application pre-installed and the necessary group membership configurations. This would be done during the image preparation phase, not by giving users local admin rights.

2. Group Policy Objects (GPOs): Instead of manually adding users to the group, you can use Group Policy to automatically add users to the "Performance Monitor Users" group. This would require setting up a domain environment.

3. Domain Join: Yes, joining your WorkSpaces to a domain (either AWS Directory Service or extending your on-premises domain) would give you more control over user permissions and group memberships. This would not break your SAML 2.0 federation with Azure Entra ID, as the federation is for authentication to the WorkSpaces service, while the domain join affects the Windows environment inside the WorkSpace.

4. Scripted Solution: You could implement a startup script that runs with elevated privileges to add the current user to the required group each time a session starts.

Given your requirements for a persistent experience where files are saved to the user's profile, you might want to reconsider using WorkSpaces Pools (which are non-persistent) and instead look at WorkSpaces Personal, which provides a persistent desktop experience. However, if you need to use Pools for cost or management reasons, you can enable application settings persistence for the pool, allowing users to retain certain application settings across sessions, and use external persistent storage for files.

For your specific case, I recommend creating a custom image with your business application pre-installed and using either Group Policy or a startup script to handle the group membership requirement, rather than trying to grant local admin rights to users.
Sources
Amazon WorkSpaces Pools: Cost-effective, non-persistent virtual desktops | AWS News Blog
Amazon WorkSpaces Pricing
Amazon WorkSpaces
Amazon WorkSpaces Thin Client now supports Amazon WorkSpaces Pools - AWS

Thank you for reaching out to AWS. My assumption is you are referring to Workspaces Pools not joined to Active Directory domain. For non domain joined pools the username which gets logged in is PhotonUser and it by default does not have admin rights. I would also like to clarify that Entra_ID users are only used for SAML authentication however the actual user which gets logged in is PhotonUser in case of non domain joined Pools. You can simply test this by connecting to a Pools session and in command prompt run “whoami” command.

Option1: If your goal is to make Entra_ID domain services user as local admin on Pools session you need to domain join the pool. Post this you can configure a GPO to make users as local administrators on the sessions.


Option2: If your goal is to get admin rights inside the Pools session irrespective of the username, you can keep the Pool as non domain joined and follow below action plan to give PhotonUser admin rights. You need to connect to a workspaces personal 


Steps to make PhotonUser as local administrator on Workspaces Pools:

* Connect into a Personal WorkSpace used to create the Image
* Open Computer Management
* Select Local Users and Groups and Select Groups
* Double click on the Administrators Group and Select Add
* Select Locations and Select the Local Computer
* In the Search Field, type in INTERACTIVE and Select OK
* On the List of users, a new field should show up as NT AUTHORITY\INTERACTIVE (S-1-5-4)
* Select OK
* Create a New Image
* Create a bundle with this new image.
* When this Image/bundle is used with Pools, the Streaming Session User PhotonUser will now have Local Admin rights.

Thank you for your prompt reply.

Just to clarify, reading through the WorkSpaces documentation and cross-checking with the requirements of our business application. I believe we likely don't need to have a WorkSpaces Personal solution. All the created files in our business application are sent back to our back-end infrastructure in Azure and do not need to be saved on Amazon's WorkSpace. We're currently working with the WorkSpaces Pools solution as the 'Personal' has a 50 BYOL license requirement, which is very prohibitive for our Proof of Concept. The Workspace image simply needs to have our business application installed and the Amazon WorkSpace user needs to be a member of a specific group called 'Performance Monitor Users'. The idea we had was to make a custom image of a WorkSpace Pools desktop with our business application installed and fully configured. Our users can then launch a virtual desktop which is basically generic for every end user, but simply has our business app.

Our current Amazon WorkSpaces Pools is indeed not domain joined. At the moment we would like to avoid having to domain join if it there's a solution for our issue. Our testing has made it clear that the Amazon Workspaces Pools virtual desktop Windows image is provided with the 'PhotonUser'. At the moment this is not an issue. Technically speaking we don't need to be domain joined for the business application to be functional. The user however needs to be in the aforementioned group. We are however incapable of adding the user to the required group.

Our virtual desktop users do not need 'local admin' permissions, we only require this once to add the PhotonUser to the required group, so our business application is fully functional and afterwards I'm assuming we can make an image of this model virtual desktop that will be used by all our end users.

Your provided option 2. results in 'The following error occurred while attempting to save properties for group Administrators on computer WSAMZON-L2...: Access is denied'. This happens after clicking 'OK'. This leave me no other option than to cancel the change.

Thanks in either case for confirming that domain joining our WorkSpace directory will not break the SAML 2.0 federated authentication we already set up.

I would also load procmon onto a device and start-up. Login as a standard user, start procmon, filter for the application, start the application and then look for what access is being denied. Typically it is a file or registry key that is denying access. You maybe able to give your users access to the application without giving them additional local rights.