When configuring vRealize Log Insight 4.5 to use vRealize Automation 7.3 embedded VMware Identity Manager (per this blog post), I ran into an issue with password complexity.
I specified a tenant name and provided valid tenant administrator credentials to register with vIDM. However, the web interface indicated an error when clicking Test Connection, related either to bad username/password or unknown response. I resolved this by using what I’d characterize as less “special” complex characters in the the local tenant administrator user account password, then running Test Connection again. Success!
Investigating the log files on the vRealize Log Insight system, I found a useful entry in one of the log files:
[2017-07-12 21:40:59.665+0000] ["https-jsse-nio-443-exec-2"/10.30.31.11 INFO]
[com.vmware.loginsight.web.actions.settings.AuthConfigurationActionBean] [Unable to login to VMware Identity Manager]
com.vmware.loginsight.aaa.vidm.exception.LoginException: Request body has invalid content
- bad json format or 'issue token' field is missing. :: Request data is not acceptable.
- Unrecognized character escape '8' (code 56)
at [Source: java.io.PushbackInputStream@8983c9b; line: 1, column: 64]
at [Source: java.io.PushbackInputStream@8983c9b; line: 1, column: 48] (through reference chain:
com.vmware.horizon.service.controller.auth.model.Login["password"]) Received unexpected response
from VMware Identity Manager instance. Domain :
For posterity, the steps to change a vRA 7.3 tenant local user account password are:
- Log in to vRA as the default administrator
- Navigate to Tenants -> Your Tenant Name -> Local Users
- Click the local user account to manage
- Click Edit
- Change the password
So, this is the same issue we’ve seen in a few different places and products. My recommendation is to always use passwords with a high degree of entropy, but in some cases you need to be careful of special characters that can be misinterpreted by some of the product line. Fun times. Hope this helps.
EDIT – Today (7/5), VMware GSS confirmed this is a bug that will be addressed in the next patch release.
Setting up a simple vSphere 6.5 (vCenter build 5178943) environment, using percentage-based HA we have been seeing the following Configuration Issue flag on the cluster (note, it is NOT an alarm!):
Insufficient configured resources to satisfy the desired vSphere HA failover level on the cluster …
You can see the alarms have Acknowledge/Reset options, this is a Configuration Issue message instead.
Doing some research I’ve collected the following things people said resolved this:
- Turn on, or turn off Proactive HA and then disable HA on the cluster, then re-enable HA
- Verify no firewall is interfering with HA
- Use various methods to reset FDM on the hosts – disconnect/reconnect, move into another cluster, so on…
- Set AC percentage to a different, low value (10% CPU/Memory)
In our case, for 3 clusters across 3 vCenters, none of those options worked. Instead:
- Disable “Override calculated failover capacity.”
That worked, as a workaround. Unfortunately, setting ANY value (1%, 10%, 33%, 100%) for percentage based AC causes the config issue. When I disable Override, the calculated value is 33% as expected. So, it has to do with manually specifying a value, rather than the particular value specified.
Working Configuration, for a 3-node cluster:
This throws a configuration issue:
Hope that helps.
I had a situation that required ferrying large files off an old VCSA 6.0 VM, as the system could not be connected to the network. These steps worked for me to get the temporary transit drive recognized by the VCSA. Note I had already prepared a temporary VMDK drive, formatted with FAT32 for compatibility with a Windows VM:
- Boot VCSA offline from the network
- Add the existing “transit” VMDK drive as a hard drive to the VM
- Open the VCSA VM console, CTRL+ALT+F1 to switch to shell console, log in as root
- Run this to rescan the scsi bus and detect new devices (note this was the required option combination that worked for me):
rescan-scsi-bus.sh -a -c -w
- Run this to see the added device:
At this point, you can mount the device, copy your files, and then umount/disconnect hard drive / connect to your network connected VM.
vSphere 6.5 Security Configuration guide and Mike’s blog post about it. In particular, he writes:
I’d like to take this opportunity to remind folks what the vSphere Hardening Guide and/or the vSphere Security Configuration Guide is and is not. It is not meant to be used as a “compliance” tool nor a set of boxes to check. It is not a set of mandates. Blanket application of ANY changes to a system should be carefully reviewed before being made. It is a set of guidelines that attempts to explain risk and start a risk management conversation between IT and security and “guide” both teams into setting up the product in a secure fashion.
I’ve definitely seen this used as a “we must set all the settings to the hardening guide,” which just causes operations issues, thus generating workarounds, and certainly does not automatically improve your security stance.
Here’s the article:
VMware recently responded to the pwn2own security exploit against VMware Workstation. Patches have been released for ESXi, Fusion, and Workstation. VMware says they are not aware of the exploit being used in the wild.
Here’s VMware’s response:
The security advice boils down to following general best practices:
- Depth in defense
- Apply vendor patches
From the article:
As offensive security evolves, so does defensive security. With vSphere 6.5, VMware began deploying sandboxing technology around virtual machines to prevent a single arbitrary code execution from spreading across a host – a technique we have adapted from studying how web browsers and cell phones have evolved to defend against offensive security research. We are proactively disabling or removing legacy features – the loss in compatibility is increasingly outweighed by the reduction in attack surface. And we are investing deeply in ease-of-upgrade, recognizing that prompt security patches do little good if they cannot be deployed to production in time.
When VMware models threats, we consider three categories of actor. The “nation-state” actor has vast resources but generally employs them against limited targets; such an actor will find a way to breach security, whether by technical means or something simpler (money, ideology). The “professional” actor has more limited resources, and tends to look for the softest and most profitable target; defending against this actor amounts to staying on or ahead of the security research curve. And the “script kiddie” uses off-the-shelf resources and previously-known issues; defending here generally requires little more than staying up to date, and the biggest risk is installations which fail to deploy existing patches. The Pwn2Own competition shows that the difficulty of hypervisor attacks is moving from the “nation-state” category to the upper end of the “professional” category. This is a trend we have been expecting for a while, as security research tools become more powerful.
Be sure to prioritize security focus appropriately. Using low entropy passwords or allowing direct access to the management network are probably greater risks to your infrastructure security than more difficult to exploit issues such as this (YMMV and IMHO).