Missing new ESXi esxcli security feature documentation

[anders_o]

At the bottom of the VMware Docs page for 'Assigning Privileges for ESXi Hosts' (https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-security/GUID-2215AADC-D4CD-49DD-AF92-65BED243...) there is a section that says:

Starting in vSphere 8.0, you can use the API or ESXCLI to deactivate shell access for the vpxuser user and the dcui user.
[..]
For more information, see the API or ESXCLI documentation.

The problem is that I can't find the esxcli documentation for 8.0, only for 6.x or 7.0. Can anyone tell me where to find this documentation and how to use these new features?

[lamw]

In case you haven't, you can always leave a comment in the feedback on the specific VMware Documentation which makes its way back to the original authors for improvement/changes/suggestions.

I just browsed my ESXi 8.0 host and looking around the ESXCLI commands, I came across the following which is what I assume the doc is referring to:

# esxcli system account list
User ID  Description                                Shell access
-------  -----------------------------------------  ------------
root     Administrator                                      true
dcui     DCUI User                                          true
vpxuser  VMware Workstation administration account          true

# esxcli system account set
Error: Missing required parameter -i|--id

Usage: esxcli system account set [cmd options]

Description:
  set                   Modify an existing local user account.

Cmd options:
  -d|--description=<str>
                        User description, e.g. full name.
  -i|--id=<str>         User ID, e.g. "administrator". (required)
  -p|--password=<str>   User password. (secret)
                        WARNING: Providing secret values on the command line is insecure because it may be logged or preserved in history files. Instead, specify this option with no value on the command line, and enter
                        the value on the supplied prompt.
  -c|--password-confirmation=<str>
                        Password confirmation. Required if password is specified. (secret)
                        WARNING: Providing secret values on the command line is insecure because it may be logged or preserved in history files. Instead, specify this option with no value on the command line, and enter
                        the value on the supplied prompt.
  -s|--shell-access=<bool>
                        Whether the user is allowed shell access if they have the appropriate administrator privileges.

[anders_o]

Thanks for the reminder of the feedback feature. I keep forgetting that there are actual humans reading the feedback, so it's great to get reminded of that. Now I've sent them the same question that I posted here.

Regarding the new commands, I did do some digging (Googling ) and found some blog posts detailing which the new esxcli commands were, but didn't find anything there.

I guess this was a new argument/switch rather than a completely new command, so thanks for the digging! Now I'm going to do some testing. I hope I'll be able to use this to make it more difficult for an attacker moving the usual route from AD->vCenter->ESXi when deploying ransomware.

[anders_o]

I'd really like to know how to do the other part of what the Docs page described:

"You can also use the API or ESXCLI to prevent the vpxuser user from changing other users' passwords."

I've tried to figure out which command that would do this, both by looking at esxcli commands and their methods/arguments and doing web searching to find more info on this, but I can't seem to find anything.

Does anyone happen to know where I should look?

[anders_o]

FYI @lamw wrote a great blog post as a response to this question. It covers how to use these new features to disable shell access for ESXi users, but most importantly how to prevent 'vpxuser' from changing other ESXi users' passwords. This will come in very handy in preventing ransomware attacks from succeeding. Blog post coming up as soon as I have the time.

William's blog post: https://williamlam.com/2023/01/applying-additional-security-hardening-enhancements-in-esxi-8-0.html

[anders_o]

And a couple of days ago I also wrote a blog post about how this setting looks very promising as a protection for preventing vSphere ransomware attacks from succeeding:

https://www.truesec.com/hub/blog/how-to-prevent-ransomware-attackers-from-taking-over-your-esxi-8-0-...

[Kinnison]

Hi,

All very well done and interesting articles, but I wonder one thing, the documentation has a rather specific note about the user "VPXUSER":
"Do not change the vpxuser user in any way. Do not change its password. Do not change its permissions. If you do so, you might experience problems when working with hosts through vCenter Server".

Now, perhaps superficial reasoning, since denying "shell" access (or whatever it's called) to the VPXUSER account falls within the definition of "modifying its permissions", what are those things that may no longer work as intended and in case we need assistance how the support would behave. Otherwise we avoid getting hurt in one way (and we could get hurt in another.

Thanks for any response you may have,
Ferdinando

[anders_o]

That's a fair question. Spontaneously, I'd say the text you quoted is from the pre-8.0 versions and is still correct, but it hasn't been clarified to include this new 8.0 feature. Try clicking the Feedback link on that page and ask. They do read the feedback, as we could see in my case above.

Since removing the Shell Access for vpxuser is described in the Docs page it should be fully supported, and I don't see any problems with removing only Shell Access. vpxuser still has full Admin rights on the ESXi host and can read and write everything necessary to manage the ESXi host from vCenter Server.

[Kinnison]

Hi,

I also think it's a reminiscence of the past but whoever reads the documentation would have reason to be confused.
In the context of my little "homelab" the "shell" access for the user "VPXUSER" I had already disabled as soon as I figured out how to do it and for what is my usage model I honestly can't say, for now, experiencing adverse effects.

Regards,
Ferdinando