AWS Builder Center

Builder Center

Managing sudo permissions for Active Directory joined Linux deployments of Amazon WorkSpaces Applications

This article will show how to grant users sudo (administrator) permissions on Active Directory domain-joined Linux based WorkSpaces Applications

Series: Managing Local Administrator/Sudo Permissions on Amazon AppStream 2.0 (4 articles)

  1. 1
    Managing Administrator Privileges on Domain Joined Amazon WorkSpaces Personal and WorkSpaces Applications
  2. …
  3. 4
    Managing sudo permissions for Active Directory joined Linux deployments of Amazon WorkSpaces Applications This article

Dan Garibay

Overview

Amazon WorkSpaces Applications offers non-persistent virtual desktops as a service, including Windows and Linux based offerings. At the time of writing, WorkSpaces Applications offers RHEL 8 (Red Hat Enterprise Linux 8), Rocky 8, and Amazon Linux 2.
On Linux,  sudo  permissions are equivalent to being a member of the Local Administrators group in Windows. With Windows-based WorkSpaces Applications instances, there are two ways for customers to easily grant local administrator permissions. On Linux-based WorkSpaces Applications instances, it is slightly more challenging to grant  sudo  permissions, since there is not a GUI tool. This can be challenging for some deployments, since some end user personas, especially technical ones, might require  sudo  for their work.
When logging into a Linux-based WorkSpaces Applications Fleet that is joined to an Active Directory domain, end users will be running as under their Active Directory domain account. Their account will not have  sudo  privileges. There is not a built-in method to add  sudo  privileges to end users of WorkSpaces Applications Fleets.
This article will show you how to grant  sudo  permissions to Active Directory Security Groups. This will enable administrators to control which users have  sudo  permissions on their WorkSpaces Applications instances simply by adding them into an Active Directory Security Group, rather than needing to manage permissions within the image itself.

Scope

This article only covers domain joined WorkSpaces Applications instances (at the time of writing, RHEL 8 and Rocky 8). WorkSpaces Applications does not support Active Directory domain joins on Amazon Linux 2, so this article does not apply to Amazon Linux 2 on WorkSpaces Applications.

Important Security Consideration

When capturing an image in this configuration, be sure to note in the Description/tags that it includes the  sudo  permissions modification.
Any user who is a member of the Active Directory Security Group you grant  sudo  permissions to will be able to  sudo  on the resulting images. Be sure to keep this in mind; if you wish to revoke  sudo  access for individual users, you will need to remove them from the AD Security Group in question.

Prerequisites

For this walkthrough, you should have the following prerequisites:
  • An AWS account.
  • Pre-existing Linux WorkSpaces Applications deployment.
  • A pre-existing Active Directory Security Group whose members you wish to grant  sudo  permissions to. You will need the Security Group's name, for example,  EUC-IT-Admins .

Getting Started

To begin, you will need to launch an image builder instance.
  • If you do not already have a Linux based WorkSpaces Applications Image Builder: follow the steps at  Launch an Image Builder .
  • If you do have a pre-existing Linux image builder: you can simply Start it instead of launching a fresh Image Builder.

Creating the Sudoers Permissions File

On Linux,  sudoers  membership is determined by either the account's presence in the  /etc/sudoers  file, or else by being defined individually as a file within  /etc/sudoers.d/ . It is a best practice to add each individual user or group that requires membership to the  /etc/sudoers.d/  directory as an individual file, rather than by modifying the main  /etc/sudoers  file. 
# For an Active Directory Security Group named "EUC-IT-Admins"
echo '%EUC-IT-Admins ALL=(ALL) NOPASSWD:ALL' | sudo tee /etc/sudoers.d/20-EUC-IT-Admins > /dev/null && sudo chmod 640 /etc/sudoers.d/20-EUC-IT-Admins && sudo chown root:root /etc/sudoers.d/20-EUC-IT-Admins

# For an Active Directory Security Group named "EUC IT Administrators", e.g., an example with spaces in the name
echo '%"EUC IT Administrators" ALL=(ALL) NOPASSWD:ALL' | sudo tee /etc/sudoers.d/30-EUC-IT-Administrators > /dev/null && sudo chmod 640 /etc/sudoers.d/30-EUC-IT-Administrators && sudo chown root:root /etc/sudoers.d/30-EUC-IT-Administrators
The first step is to modify the placeholder commands above to use the name of your Active Directory Security Group. You will use only one of the above 2 commands. The example on Line 2 is for groups with no spaces in the name, and the example on Line 5 is escaped with double quotes, permitting groups with spaces in the name to work.
Open a text editor on your local computer, and copy the above code block into the text editor. Modify the example commands to use your Active Directory group name.
No matter which placeholder command you modify, be sure to replace all instances of the placeholder group names - either  EUC-IT-Admins  or  EUC IT Administrators  - with the name of your Active Directory Security Group. Each example command has 4 instances of the placeholder.
As a reminder: when using WorkSpaces Applications within Chrome or Edge, copy and paste will work seamlessly. If using WorkSpaces Applications within Firefox, you will need to use the Clipboard icon in the WorkSpaces Applications toolbar to send text via copy and paste.
  1. Connect to your Linux WorkSpaces Applications Image Builder  within the AWS console .
  1. Open the Terminal window (select the Applications menu in the top left corner, and you will see the Terminal icon appear in the center left of the screen). You can also enter "Terminal" in the resulting text box.
  1. Modify one of the two commands below
At this point, you have finished making the necessary changes on the Image Builder to give users who are a member of the specified Active Directory group  sudo  permissions. If your image already contains all the required customizations/applications, and they are up to date, you can now create an image from this Image Builder and use it in your Fleet.
If you need to run any updates, install applications, or make more customizations, now is a good time to do so.

Creating the Image

When you are ready to create the image, you can do so in the same Terminal window. If you need a reminder of the syntax, you can run  AppStreamImageAssistant create-image --help  to see the command's syntax in detail. If you would like an example of a  create-image  command which includes a tag showing  sudo  permissions: 
AppStreamImageAssistant create-image --name ExampleName --use-latest-agent-version --no-enable-dynamic-app-catalog --tags Key=Sudo,Value=Yes
You do not need to use these precise arguments (for example, you may want a dynamic app catalog, required if you use Application View on your Fleet, or you might want the image pinned to the same agent version it was created on).

Placing the image into production

To use the resulting image in Production, replace it in your Fleet configuration. If you would like the changes to be rolled out as fast as possible, you will need to Stop and Start your WorkSpaces Applications Fleet. See these two documentation pages for more information:

Rollback

If you would like to remove these permissions from the image builder later, you can run  sudo ls -la /etc/sudoers.d/  to list the individual  sudoers  file. Then, you can use  sudo rm <filename>  from a terminal session on the same image builder. Since the name of your  sudoers  customization will be specific to the group you added, the  ls  command will let you specify the correct filename. For example,  sudo rm /etc/sudoers.d/20-EUC-IT-Admins .
Then, create a new image, and replace the image in your Fleet with this new image, as before.

Conclusion

You can now use this article to grant your Active Directory domain joined Linux based WorkSpaces Applications end users  sudo  permissions on your WorkSpaces Applications fleets. This enables users to perform actions they could not do otherwise, and is required for some highly technical user personas.  
# appstream2# appstream# amazon-appstream

Series: Managing Local Administrator/Sudo Permissions on Amazon AppStream 2.0 (4 articles)

  1. 1
    Managing Administrator Privileges on Domain Joined Amazon WorkSpaces Personal and WorkSpaces Applications
  2. …
  3. 4
    Managing sudo permissions for Active Directory joined Linux deployments of Amazon WorkSpaces Applications This article
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article