For more details, please refer to the ESXi Lockdown Mode documentation. Once the new administrative user has been created, you can now use this to connect to vCenter Server and everything will continue to work as before but now the root user is no longer the account that is used to add the ESXi hosts. For further protection, you can also enable ESXi Lockdown Mode and for the strict configuration, you should also update the ESXi Exception list to include the new local administrative account so it can login for debugging or troubleshooting purposes. Note: Please make sure you do NOT remove administrative privileges from the default root user UNTIL you have successfully created a new local administrative user with the same privileges as the default root user. To grant the new local administrative user with administrator role as the default root account, use the following ESXCLI command:Įsxcli system permission set -i admin321 -r Admin For Automation purposes, you may want to embed the password within a script, so that when you run the script, the only the running of the script is captured in the ESXi Shell log rather than the actual password. ![]() If you omit the password, you will be prompted and that will not be captured in the ESXi Shell logs. ![]() Note: Do not provide the credentials when creating a new account on the command-line as the password will be captured in the ESXi Shell logs (/var/log/shell.log). To create a new local administrative user, in my example I have named the account admin32 but you should select a name that is difficult to guess and use the following ESXCLI command:Įsxcli system account add -i admin321 -p -c -s true Note: While you may want to disable vpxuser ESXi Shell Access prior to adding it to vCenter Server, you can still disable this after an ESXi host has been added to vCenter Server. To disable ESXi Shell access for non-root accounts like the vpxuser and dcui account, you can use the following ESXCLI command and the new -s or -shell-access argument by running the following:Įsxcli system account set -i dcui -s falseĮsxcli system account set -i vpxuser -s false To check whether local users on an ESXi host have ESXi Shell access, the existing ESXCLI system account command has been updated to include a new column called Shell access which can be viewed by running the following command: Not only will this make it more difficult for attackers but the result of removing administrative privileges from the root user will also disable SSH access for this user automatically and also prevent login access to the ESXi Host Client or ESXi API, so you actually get three benefits by simply applying this configuration in your environment. As a result, this can lock you out of your ESXi hosts or worse, enable an attacker to encrypt your workloads, especially as the rise ransomeware attacks has been increasing.Īnother ESXi security configuration that is definitely worth applying and mentioned in the ESXi security documentation is to create a new ESXi local administrative user and then remove the administrative privileges for the default root account user, which most attackers will assume this account exists on your ESXi host. By restricting ESXi Shell access for the vpxuser, you prevent attackers, which can also be insiders who have access to vCenter Server the ability to just change the ESXi root password without knowing the original password. It turns out that users with ESXi Shell access can also modify other local users password on ESXi host including the root user. While this might sound like a pretty basic feature, applying this towards the vCenter Server service account vpxuser can help add another layer of protection for your ESXi hosts against attackers. Speaking of new ESXi security enhancements, one of the new features that was introduced in ESXi 8.0 is the ability to disable ESXi Shell access for non-root users. After answering some of the security related questions, especially on the Automation examples, I figure it would be useful to share this information more broadly so that folks are aware of some of the new and existing security enhancements along with some of their implications if you are not implementing them. In certain areas of the ESXi security documentation, I noticed that it mentions CLI and API, but it does not always provide an example that customers can then reference and use in their Automation, which is really the only guaranteed method to ensure configurations are consistent across your vSphere environment. It is definitely worth re-reviewing this section from time to time to take advantage of all the ESXi security enhancements to help protect and secure your vSphere environment. ![]() While responding to a few ESXi security configuration questions, I was referencing our ESXi Security documentation, which includes a lot of useful information and latest best practices.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |