WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Resources
    • Nested Virtualization
  • VMware Nostalgia
  • Apple
You are here: Home / Why is there a "No access" vSphere Role?

Why is there a "No access" vSphere Role?

12.10.2013 by William Lam // 5 Comments

vSphere's (vCenter Server & ESXi) authorization system includes several pre-canned Roles such as Read-Only, Administrator and Virtual Machine Administrator as an example. One of the roles that has intrigued me for awhile which is the "No access" role. This seems to be a really odd role to have, I mean what would you do with such a role if it does not have access to anything?

In a conversation I had last week with a fellow colleague, the "No access" role made its way into the conversation and I learned that there was a specific use case for this role, however it was unclear what that might have been. This go me interested and I decided to reach out to some folks to see if I can get to the bottom of this and the use case associated with it.

It turns out there are some customers who have some very interesting requirements in which they need to separate out users who have the Administrator role and prevent them from seeing and performing operations on specific vSphere Inventory objects. An example of this would be a vCenter Server with 4 vSphere Clusters where Admin1 can only see the first two Clusters and Admin2 can only see the last two Clusters and both users have the Administrator role.

To accomplish the above example, you can leverage the "No access" role in the following manner. As the "Uber" Administrator, you would assign both Admin1 and Admin2, lets call them Alan and Cormac the Administrator role at the vCenter Server level. This will grant them full access to the entire vSphere Inventory.

Now, to prevent Alan from seeing Cluster 3 & 4, we need to go into the Cluster object and add the "No access" role to both those objects. We do the same for Cormac but for Cluster 1 & 2. If we now login as the user Alan, we will see that only Cluster 1 & 2 are visisble.

If we login with the user Cormac, we can only see Cluster 3 & 4 as expected.

Although this may not be a common request in your environment, I can see some interesting use cases for having such a setup like on-boarding a new junior admin and wanting to provide them Administrative access to particular Clusters and removing the views for others they should not have access to.

I would like to thanks Rupam from our GSS organization for sharing the reasoning behind "No access" as well as a specific use case for the feature.

More from my site

  • Programmatically accessing the Broadcom Compatibility Guide (BCG)
  • Intel NUC 9 Pro & Extreme - First "Modular" NUC
  • Supermicro E300-9D (SYS-E300-9D-8CN8TP) is a nice ESXi & vSAN kit
  • New VMware Configuration Maximum Tool
  • PowerCLI script to help correlate vCenter, ESXi & vSAN build/versions w/o manual VMware KB lookup

Categories // Uncategorized Tags // ESXi, no access, permission, role, vSphere

Comments

  1. *protectedjasonboche says

    12/16/2013 at 6:11 pm

    Alan and Cormac - those names ring a bell.

    Reply
  2. *protectedFabrizio de Luca says

    12/16/2013 at 11:55 pm

    This is what we - as VCIs - teach every week to students during ICM, FT and WN courses... =))

    Another use case is when you want to provide an external consultant with a vIPMI/vILO -like access to a single VM in case he/she messes up the VM networking connectivity.

    In this scenario you grant him/her:
    1. "No Access" role at the vCenter Server level (propagating the role to child objects).
    2. "Read Only" role at the specific VM level.

    Once logged in, the consultant will only see that specific VM and the "Read Only" role will let him/her access the VMRC in case of an emergency.

    Reply
  3. *protectedSean Dilda says

    12/17/2013 at 2:07 am

    I've used 'No Access' almost since day 1. There's a couple other use cases I've run across.

    1) Assigning roles for automation programs. If a program is only supposed to act on a single cluster, why not hide the other clusters so that you can minimize the impact of potential programming glitches? Likewise, when test and prod are sharing a vCenter and they're keying off of inventory names, 'No Access' can make sure test can't see prod's resources (and vice versa) so you know they don't trample on each other

    2) Its a good way to keep people from asking why they can't put VMs on the datastores labeled 'local' 🙂

    Reply
  4. *protectedGrant Orchard says

    12/17/2013 at 11:26 pm

    Hey William, also useful if you don't want objects to be managed by vCOps.

    Reply
  5. *protectedEmanuele says

    05/18/2015 at 1:25 pm

    Hello, can you help me with this: https://communities.vmware.com/message/2508130#2508130 ?
    Thanks,
    Emanuele

    Reply

Thanks for the comment!Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Search

Thank Author

Author

William is Distinguished Platform Engineering Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. His primary focus is helping customers and partners build, run and operate a modern Private Cloud using the VMware Cloud Foundation (VCF) platform.

Connect

  • Bluesky
  • Email
  • GitHub
  • LinkedIn
  • Mastodon
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • Programmatically accessing the Broadcom Compatibility Guide (BCG) 05/06/2025
  • Quick Tip - Validating Broadcom Download Token  05/01/2025
  • Supported chipsets for the USB Network Native Driver for ESXi Fling 04/23/2025
  • vCenter Identity Federation with Authelia 04/16/2025
  • vCenter Server Identity Federation with Kanidm 04/10/2025

Advertisment

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2025