VMware just announced VMSA-2023-0023 with a maximum CVSSv3 base score of 9.8 - which basically implies DANGER! Here is everything you need to know about this for your VCF Environments.

VMSA-2023-0023 includes two CVEs: CVE-2023-34048, CVE-2023-34056 - The severity of these issues has been evaluated to be in the Critical severity range with a maximum CVSSv3 base score of 9.8.

This VMSA affects all versions of vCenter Server, and is only limited to vCenter, not ESXi.

vCenter does not have an in-built mechanism to export and import Global Permissions.
In this post, I will describe a script that I have written - globalPermissionManager.py - that performs this export/import operations for Global Permissions.

What is globalPermissionManager.py ?

The script is available on my GitHub here.

The script is used to export ALL Global Permissions from a vCenter Server Appliance to an object file, and then re-import them as needed. The primary use case for this, that I use it for is : Cross Domain Repoints to a new SSO.

William Lam has a PowerCLI script which contains two functions New-GlobalPermission and Remove-GlobalPermission, if we need to interact with global permissions using PowerCLI : https://williamlam.com/2017/03/automating-vsphere-global-permissions-with-powercli.html

However, in my experience, having a python script that just handles everything for you and requires no input for individual users or groups, is a lot more convenient. The script uses the same underlying API as the PowerCLI script created by William Lam.

ESXiArgs seems to be all the rage right now on the interwebz, with what (in my opinion) started as a reddit post reporting attacks, and quickly spread like wild fire to everyone with a vSphere environment talking about it. What's interesting though, is that the most common vector used to exploit this vulnerability was patched out in late 2021. Sooooo, why has this picked up in early 2023 ?

In this blog post, I am going to briefly discuss what seems to be going on with environments getting hit by ESXiArgs, why this should have never happened in the first place, and finally, prevention and remediation for ESXiArgs.

Lets start with What is ESXiArgs ?

ESXiArgs is the fancy name given to a "new" set of ransomware attacks targeting unpatched and unprotected instances of the ESXi hypervisor. Key points here being "unpatched" ESXi hosts, and scenarios where attackers have direct access to the ESXi management interfaces (for example ESXi management directly exposed to the internet, or a machine that is exposed to the internet that also has direct access to ESXi)

If you are running a VMware environment with multiple vCenters in Enhanced Linked Mode, then chances are, you have inevitably taken snapshots of vCenters and caused a replication issue due to the vmdir DBs being out of sync. In previous posts, I have talked about how this replication works, and how to not break this replication.

In this post, I will explain the quickest way to repair and recover from a broken replication state and bring all the vCenters back in sync.

VMware GSS has multiple internal scripts and KBs to repair the vmdir DB replication in place. However, there is a publicly accessible utility that also lets us repair the replication. Its called cross-domain repoint.

https://blogs.vmware.com/vsphere/2019/10/repointing-vcenter-server-to-another-sso-domain.html

Given the close integration of the SDDC Manager with all the components comprising a VCF Environment, making changes to components can be a bit of a challenge. In this article, lets talk about one of the more simpler changes - Renaming components.

As a rule, making changes to any object or component that is a part of a VCF Environment should only be done through the SDDC Manager. Making changes directly on the component itself is UNSUPPORTED - as SDDC Manager will not have visibility over this change, thereby causing a discrepancy in the inventory information.

While the changes should only be made through the SDDC Manager, there is no mechanism or workflow in place that restricts one from making the changes directly via the component itself. However, as mentioned above, the change still is unsupported. If any changes are made which cause a deviation from the inventory information that the SDDC Manager holds, this can (and will) cause issues with any number of Day-2 operations and workflows (such as adding hosts and WLDs, updates/upgrades, expanding clusters)

In terms of actually renaming components in a VCF Environment, as of VCF 4.5, here are the following components that support renaming:

A recent post from VMware talked about a new malware for ESXi, based on information published by Mandiant - which is a cyber-security firm (a subsidiary of Google). You can read the VMware KB here.

The full posts from Mandiant can be found here:
https://www.mandiant.com/resources/blog/esxi-hypervisors-malware-persistence
https://www.mandiant.com/resources/blog/esxi-hypervisors-detection-hardening

In this post, I am going to discuss the key aspects of this issue.

What are Mandiant's findings?

Mandiant found malware on ESXi hosts that was basically installed using unsigned VIBs. The unsigned VIBs contain backdoors which then compromise the ESXi host. At that point, anything on the host can be considered as compromised - commands can be sent for execution on Guest VMs, files can be transferred between ESXi and the Guest VMs etc.

Since the release of VCF 4.4.0.0, there has been a lot of chatter about how we can decouple or disassociate the vRealize suite from VCF and SDDC Manager, or how it is completely externally managed.
This is quite incorrect and stems from a misunderstanding of how the vRealize Suite is linked to VCF.

In this post, I will talk about how the vRealize Suite is linked to VCF and SDDC manager, and what has changed in VCF 4.4 and above.

In February of 2022, I attempted and passed the exam for the VCAP-DCV Design 2022. This was my second attempt at a VCAP Design exam, with the first one being the VCAP-DCV 6.5 Design. In this blog post, I will talk about my preparation for the exam, what I focused on, what my experience was like, and some exam tips.

The VMware Certified Advanced Professional - Data Center Virtualization - Design 2022 (quite a mouthful, isn't it?), more often known as the VCAP-DCV 2022 Design certification, as per VMware, validates that you have advanced knowledge of end-user computing environments and components, and are able to recommend and design VMware solutions to meet specific goals and requirements.

Lets break this down further.

During upgrades of VCF components from the SDDC Manager, we often run into situations where a component upgrade bundle does not show up for a particular VCF version upgrade. This can also present itself as skipping a component through the upgrade process. In this article, I will explain what compatibility sets are, how they work, and how they affect the VCF component upgrade process.

What are Compatibility Sets?

Compatibility sets are set of version entries for the 3 primary core VCF products - namely vCenter, ESXi and NSX(T/V), which are marked as compatible with one another. Lets break it down further.

Each entry in the compatibility sets contains one version each for the vCenter, ESXi and NSX component.

For example, from the screenshot above, the final entry indicates that vCenter version 7.0.3.00300, ESXi version 7.0.3, and NSX-T version 3.1.3.7.4 are basically marked as compatible to work with each other in a VCF environment.

The VerionAlias.yml file on a SDDC Manager is referenced quite a bit across several VMware KBs, mostly in the context of "change this value here" or "add this value there" while troubleshooting VCF upgrades. There really aren't any articles online describing what this file really means or how it works. In this post, I will describe the various elements that are in a VersionAlias.yml file, and how to interpret the information available here.

Lets start with the different versions of each VCF component that we are dealing with: