Oracle Cloud Infrastructure Documentation

Understanding Desktop User Access to a Desktop Pool

Desktop users can access a single desktop from each desktop pool contained in the compartment that their group can access. To limit a user's access, you must create separate groups and separate compartments.

Example: Two subcompartments with one desktop pool each

In this example, a Desktops compartment contains two subcompartments:

  • Windows_Desktops
  • Linux_Desktops

There are two groups:

  • Windows_Users
  • Linux_Users

Additionally:

  • The Windows_Desktops subcompartment contains a single Windows desktop pool.
  • The Linux_Desktops subcompartment contains a single Linux desktop pool.

Users can access the subcompartments based on the following policies:

Allow group Windows_Users to use published-desktops in compartment Desktops:Windows_Desktops
Allow group Linux_Users to use published-desktops in compartment Desktops:Linux_Desktops

This scenario allows the administrator to limit the desktop users access based on group. A user within the Windows_Users group can only open a single Windows desktop. Similarly, a user within the Linux_Users group can only open a single Linux desktop. A user that belongs to both the Windows_Users and Linux_Users groups can open two desktops: one from the Windows pool and one from the Linux pool.

Example with two sub-compartments each with a single desktop pool.

See also:

What's visible in the Secure Desktops interface?

The desktop user accesses their desktops through the Secure Desktops interface which is a browser application separate from the Oracle Cloud Infrastructure Console. The interface lists the desktops that the desktop user can connect to. From the desktop user's perspective, the list is composed of their assigned individual desktops. However, what is going on behind the scenes is slightly more complex. The list is actually showing the published desktops that the user has been given access to.

What is a published-desktop?

A published desktop is essentially a single desktop within a desktop pool. This is why the list that the desktop user sees shows a list of desktop pool names, not individual desktop instance details. Depending on whether the user has previously accessed a desktop determines if there are actual underlying OCI resources assigned to the user for that particular desktop.

For example, the first time the desktop user logs in to the Secure Desktops interface, they see a list of desktop pool names showing their desktop in "Available - new desktop" status. This means they have the ability to create a desktop in that pool that will be uniquely assigned to them. However, there is not currently a desktop (along with the underlying compute instance and block volume) explicitly created or assigned to the user. After initially clicking on their desktop to access it, the Secure Desktops service provisions a desktop to the user and creates the underlying OCI resources necessary to support the desktop. You, as the administrator, can then see the desktop listed within the console (see Viewing State of Desktops).

The next time the user logs into the Secure Desktops interface, they see that same published-desktop in the list. However, it is now in "Available" state. This means that there is now an actual desktop instance in that desktop pool assigned to the user and it is composed of OCI resources.

Why care about the published desktop concept?

The published desktop concept is key to understanding how the access policies work, as seen in the policy that grants a user access to a desktop:

Allow group <desktop-users> to use published-desktops in compartment <desktop-compartment>

This does not grant a user access to an entire desktop pool, but instead a single desktop instance within each pool in the specified compartment. This is why you would require a separate compartment for each desktop pool if you need to limit user access to one specific desktop.

See related: