Using student accounts without admin privileges

In the version of Azure Lab Services that uses lab plans, you have the option for students to use a non-admin account on their VMs.  With a non-admin account, students don’t have full control over the VM and instead only have privileges to perform general computing tasks. We recommend that you follow the principle of least privilege by having students use a non-admin account unless they need to perform tasks that require admin privileges.  Here are a few excerpts that best describe the principle of least privilege:

 

“The principle states that all users should log on with a user account that has the absolute minimum permissions necessary to complete the current task and nothing more. Doing so provides protection against malicious code, among other attacks. This principle applies to computers and the users of those computers."

 

"Always think of security in terms of granting the least amount of privileges required to carry out the task. If an application that has too many privileges should be compromised, the attacker might be able to expand the attack beyond what it would if the application had been under the least amount of privileges possible.” 

 

Applying this principle helps to reduce the likelihood and the degree of negative impact that can occur if a student has too many privileges:

• Stop malicious software – When using a non-admin account, apps don’t automatically have access to admin privileges.  For example, this helps to prevent malware from automatically using admin privileges to infect or damage files on the VM.
• Enhance security – You can set up additional security settings and software directly on the VM to enhance security.  When students use a non-admin account, they can’t uninstall or disable these security measures.  For example, as part of the VM’s image you can install 3^rd party content filtering software, apply local group policies, configure local firewall settings, etc.  In a future blog post, we’ll share more info on how to enable these types of security measures.
• Safeguard against unintended changes – When students have full admin access, they can inadvertently make changes to their VM that gets it into an unexpected state.  Azure Labs provides the ability to reset their VM image to help; however, this often can be avoided by having students use a non-admin account.  For example, non-admins are prevented from making accidental changes that can cause their VM to stop working like deleting critical system files, changing IP address settings, blocking outbound access required by Azure, etc.

Before you decide to use a non-admin account for students, you should validate whether students need full control over their VM or if the lab’s software requires admin privileges.  Here is a general list of tasks that a non-admin account is blocked from performing:

• Installing and removing software
• Making system wide config changes, such as to the security, permission, and networking settings
• Running software that makes system wide config changes
• Creating and deleting files/subfolders that exist with other users' profile/home folder

For software or curriculums that require students to perform the above types of tasks, students will instead need to use an admin account.  If you are unsure whether your lab’s software requires admin privileges, we recommend reaching out to your IT department or the software vendor.

• IMPORTANT – If your students need to use an admin account, students must take precaution to avoid making changes that can cause their VM to stop working properly.  More details are provided on this later in the blog post.

When you set up a lab with a non-admin account, you should connect to the lab’s template VM with the non-admin account to verify that:

• All software/files that you install are accessible.
• Tasks required for the lab can be performed with non-admin privileges.

In Windows, when a non-admin account attempts to perform a task that requires admin privileges, a User Account Control (UAC) prompt is shown.  The UAC prompt blocks the task from being performed unless the user can provide the admin account’s password.  For example, if a student that is using a non-admin account attempts to install software, they will see the UAC window and installation will be blocked.  However, if a teacher/lab manager is in-person with their student, they can enter the admin account’s password to allow the task to continue with elevated privileges.

 

Figure 1 Windows User Account Control (UAC) prompt for admin account's password

 

In Linux, when a non-admin account attempts to perform a task that requires admin privileges, they will see a Permission denied message.  For example, if a non-admin account attempts to access a folder that they don’t have read permission for, they will see a Permission denied message and will be prevented from accessing the folder.

 

Figure 2 Linux permission denied message

 

In the rest of this blog post, we'll show steps on how to:

• Avoid making changes as an admin that can cause the VM to stop working
• Add a non-admin account during lab creation
• Set up and validate a Windows lab with a non-admin account
• Set up and validate a Windows nested virtualization lab with a non-admin account for scenarios like ethical hacking and networking
• Set up and validate a Linux lab with a non-admin account

Thanks,
Azure Lab Services team

 

-------------------------------------------------------------------------------------------------------

Avoid making changes as an admin that can cause the VM to stop working

You may have scenarios or software that require students to use an admin account.  When students are an admin, you’ll need to ensure that they avoid making changes that will prevent their Windows or Linux lab VMs from starting and/or working properly.  The effect of these changes is that VMs won’t start, students will lose connectivity to their lab VM, or their VM will unexpectedly shut down without the ability for them to reconnect.  Often, the only way to fix these issues is by having the student reset their VM image which will cause all data saved on the OS disk to be lost.  The list below shows the types of changes that students should avoid making.

 

1.  Don’t change networking settings

Students should be instructed not to make any changes to their VM’s network settings.  For example, changes that prevent the VM from obtaining an IP address:

• Changing the VM’s IP assignment from dynamic/automatic to static.
• Disabling the DNS assignment settings.
• Or any other related changes that disable DHCP.

We also recommend setting up a PowerShell script that runs on VM shutdown to ensure the IP address is always set to dynamic/automatic as shown in this blog post: Running a PowerShell Shutdown script on Windows Lab Services machines. - Microsoft Community Hub.

 

2.  Don’t make changes to services

The Azure VM agent relies on local services that are enabled to automatically run in the background.  Students shouldn't stop or disable these services because this can have a negative impact on their VM.  For example, the Azure VM agent relies on specific services running for the automatic shutdown settings to work properly.

 

3.  Don’t delete system files/folders

The Azure VM agent also relies on files/folders that are installed on the VM.  Deleting these files/folders can cause the VM to stop working.  For example, students should avoid making changes to any files/folders under C:\WindowsAzure.

 

4.  Don’t make firewall changes

Students should avoid making any changes to their VM’s local firewall, so that they don’t block outbound connections that are required by the Azure VM agent.  From a security perspective, teachers/IT may be interested in enabling firewall rules on VMs.  We’ll share more info on how to enable local firewall rules as a security measure in a future blog post.

 

Add a non-admin account during lab creation

First, when you create a lab, check the option to Give lab users a non-admin account on their virtual machine.  Checking this option adds two local user accounts to the lab’s VMs:

1. An admin account that a teacher or lab manager uses for full control and access to each VM.
2. A non-admin account that students should use for general computing tasks.

Figure 3 Add non-admin account during lab creation

 

The above steps are prerequisite for the following sections that show how to set up Windows and Linux labs using a non-admin account.

 

Set up a Windows lab with a non-admin account

1.  Connect to the template VM 

After you’ve created a Windows lab with both an admin and non-admin account, connect to the lab’s template VM.

a.  Use the admin account so that you have full privileges to change Windows settings, install software, etc.

b.  When you connect, you will notice that the admin account’s username is automatically populated in the RDP connection file.

Figure 4 Connect to the lab template VM using the admin account

 

2.  Update the template VM

Update the image with changes required for the lab, such as installing software and adding files.

a.  Ensure that software is available to all users on the VM.  Here are some tips:

• Check if the software has options to install for all users.  For example, OneDrive provides an "all users" switch.
• Install software under Program Files or Program Files (x86).
• Place shortcuts under C:\Users\Public\Desktop; to see this folder, you may need to show hidden items using the View->Show->Hidden items option.

 

Figure 5 Show Public\Desktop folder

 

b.  Ensure that any files needed for the lab are copied to an accessible location like the C:\Users\Public folder.

 

3.  Verify the template VM

Verify that all software and files that you install are accessible with non-admin privileges.

a.  Increase the lab’s Shut down virtual machines when users disconnect setting to at least a few minutes. 

• By default, the value is zero which can cause the VM to immediately shut down when you disconnect as the admin and attempt to reconnect as the non-admin.
• You may want to change this value back to zero after you’re done verifying the template VM.

Figure 6 Increase the shut down virtual machines when users disconnect setting

 

b.  Reconnect to the template VM using the non-admin account.

• You will need to change the user in the RDP connection file by clicking Use a different account under More choices and entering in the username and password for the non-admin.

Figure 7 Connect to the lab template VM using the non-admin account

 

c.  Verify the VM’s software and files needed for the lab are accessible using the non-admin account.  You may also want to verify some common tasks that students will perform to ensure that admin privileges aren’t required.

 

4.  Publish the template VM

After you’re done verifying the template VM, you are ready to publish to create the student VMs. When students connect to their lab VM using RDP, the non-admin account’s username is automatically populated in the RDP connection file.

 

Set up a nested virtualization lab with a non-admin account

When students are using Windows nested virtualization for ethical hacking and networking scenarios, it’s possible for them to inadvertently make changes to the host VM that can cause it to stop working properly.  You should consider having students use a non-admin account for nested virtualization scenarios to help safeguard against detrimental changes to the host VM.

 

1.  Connect to the template VM

After you’ve created a Windows lab with both an admin and non-admin account that supports nested virtualization, connect to the lab’s template VM.  Use the admin account so that you have full privileges to enable nested virtualization, install software, etc. 

 

2.  Update the template VM

Update the image with changes required to set up nested virtualization.  Here are useful resources:

• Enable nested virtualization for a lab
• Ethical hacking with Hyper-V
• Networking with GNS3

When following the above steps, there is extra configuration required for the non-admin account:

• The non-admin account must be added to the Hyper-V administrators group so that they have permissions to start/stop nested VMs, but they won’t have full permissions to use Hyper-V such as attaching a new disk.

Figure 8 Add non-admin account to Hyper-V Administrators group

• Disks and VMs must be saved to accessible location, not the default location under %programdata%.  For example, you can put these resources in the C:\Users\Public folder.

3.  Verify the template VM

Like the previous section on how to verify the template VM for a Windows lab, you should verify that all software and files are accessible with non-admin privileges.  You should also ensure that nested VMs can be properly created/started and should validate tasks that students will need to perform.

 

Set up a Linux lab with a non-admin account

 

The steps to connect, update, and verify a Linux template VM with an admin/non-admin account varies depending on the:

• Distro and version
• Connection type (e.g., SSH or RDP)
• Graphical desktop environment (e.g., XFCE, MATE, etc.)
• Remote desktop server technology (e.g., RDP, X2Go, etc.)

To give you an idea of the steps involved, this section shows how to set up a lab with:

• Ubuntu Server 20.04 LTS image
• Both SSH and RDP
• XFCE GUI desktop

1.  Connect to the template VM

The steps in this section assume that you’ve created a lab with the Ubuntu Server 20.04 LTS image and have set the Enabled connection types setting to Client connection (SSH) and Client connection (RDP).  The lab should also have both a non-admin and admin account configured.

Figure 9 Enabled connection types setting during lab creation

 

Connect to the lab’s template VM:

a.  Use the admin account so that you have sudo privileges. 

b.  The first time that you connect to the template VM, you will need to use SSH so that you can set up RDP and XFCE.

c.  When you connect, you will notice that the admin account’s username is automatically included in the SSH connection string.

 

Figure 10 Admin account username in the SSH connection string

 

2.  Update the template VM

Update the image with changes required for the lab, such as installing software and adding files:

• Install XFCE
• Install RDP

By default, on Ubuntu Server 20.04 LTS, the admin user has read/execute permission to the non-admin user’s folder, but not write permission.  Write permission is required to create and copy files to the /home/*your non-admin username*/ folder.

Figure 11 Default permission for the non-admin user's folder on Ubuntu 20.04

 

You’ll need to ensure that the non-admin user has access to software and files needed for the lab.  Here are some tips:

a.  Use a package manager to install apps.  By default, apps will be available system-wide for all users.  For example, with Ubuntu use apt-get.

b.  XFCE requires that you configure the default desktop environment for the non-admin user.  However, you must have write permission to the non-admin user’s folder to run the following command:

 

 

 

 

 

sudo echo xfce4-session >/home/*your non-admin username*/.xsession

 

 

 

 

 

To obtain write permission, you can:

• Create a group and add both the admin/non-admin users.
• Give the group ownership of the /home/*your non-admin username*/ folder with rwx permissions.
• Enable all newly created subfolders and folders under /home/*your non-admin username*/ to inherit group permissions using the SGID bit.

Here is an example:

 

 

 

 

 

sudo groupadd labUsers

sudo chgrp labUsers /home/nonadminuser/

sudo chmod 770 /home/nonadminuser/

sudo chmod +s /home/nonadminuser/

sudo usermod -a -G labUsers nonadminuser

sudo usermod -a -G labUsers testadmin

 

 

 

 

 

NOTE: Other graphical desktops don’t require additional configuration steps for the non-admin user, such as GNOME.

c.  Copy or create any files needed for the lab to the non-admin user’s folder.  To obtain permission, you can reuse the same approach as above so that you can create files in the /home/*your non-admin username* folder.  Or you can create a new shared folder under /home/ and give the group ownership with rwx permission.  For example:

 

 

 

 

 

sudo mkdir /home/sharedFolder/

sudo chgrp labUsers /home/sharedFolder

sudo chmod 770 /home/sharedFolder/

 

 

 

 

 

NOTE: The default permissions to the /home/*your non-admin username* folder can vary based on the distro and version.  For example, by default, on Ubuntu Server 22.04 LTS the admin user doesn’t have read, write, or execute permissions for the /home/*your non-admin username* folder.

 

Figure 12 Default permission for the non-admin user's folder on Ubuntu 20.04

 

3.  Verify the template VM

Verify that all software and files that you install are accessible with non-admin privileges.

 

a.  As mentioned earlier in this post, increase the lab’s Shut down virtual machines when users disconnect setting to at least a few minutes. 

b.  Log out of the SSH terminal and reconnect to the template VM using the non-admin account.

• To SSH, you will need to change the admin’s username in the connection string to the non-admin’s username.

Figure 13 Change the username in the SSH connection string

 

• To RDP, you will also need to change the username to the non-admin account.

Figure 14 Change the username during RDP connection

c.  Verify the VM’s software and files using the non-admin account.  You may also want to verify some common tasks/commands that students will perform to ensure that sudo privileges aren’t required.

 

4.  Publish the template VM

After you’re done verifying the template VM, you are ready to publish to create the student VMs. When a student connects to their lab VM, the non-admin account’s username is automatically populated in the SSH connection string and during RDP connection.