Security

So the other day my Skype account was briefly compromised, a successful login from Russia (after digging through activity logs) and this was after many attempts from IP addresses all around the world (China, Korea, Argentina the list goes on). You can see from the picture below the successful login attempt.

My initial reaction was stress and panic, as I didn’t know precisely where I had been compromised I ran scans on my local machines while resetting passwords a plenty. Once I had calmed down a bit and reviewed where I had gone wrong I set about uping my game.

Those of you used to using vSphere on a regular basis will already be aware of the hardening guide for ESXi and vSphere but what about vROps?

If the vROps appliance needs to be hardened there is already a VMware provided guide and tool to accommodate.

Secure configuration guide - http://pubs.vmware.com/vrealizeoperationsmanager-61/topic/com.vmware.ICbase/PDF/vrealize-operations-manager-61-secure-configuration-guide.pdf

“The documentation for Secure Configuration is intended to serve as a secure baseline for the deployment of vRealize Operations Manager.”

vRealize Log Insight 2.5 improves on the clustering in previous versions with an Integrated Load Balancer (ILB) which allows you to distribute load across your cluster of Log Insight instances without actually needing an external load balancer. The advantage of this over an external load balancer is that the source IP is maintained which allows for easier analysis.

The minimum number of nodes in a cluster is three, the first node becomes the Master node and the other two become Worker nodes. The maximum number of nodes supported is six, though acording to Mr Log Insight himself, Steve Flanders , the hard limit is more:

It is with great relief that I can announce I have passed my VCP NV (Network Virtualisation) having been caught out by the difficulty of the exam and failing previously.

Exam Preparation

I was fortunate to attend a VMware internal bootcamp (roughly equivalent to the ICM course) for NSX and have had experience deploying production NSX environments, so that is by far the best preparation. As always, the exam blueprint is crucial, you *have* to know all areas covered there. I’ve also been reading the documentation and design and deploy guides published by VMware, and completed the basic and advanced hands on labs that are also freely available. On top of that there is the official practice exam which I strongly suggest you do as it reflects the real exam well, and there are a series of fantastic practice tests by Paul McSharry available while provide a decent test of knowledge.

The NSX Edge Gateway comes pre-armed with the ability to provide an SSL VPN for remote access into your network. This isn’t a new feature (SSL VPN was available in vCloud Networking and Security), but it’s worth a run through. I’m configuring remote access to my Lab, since it’s often useful to access it when on a client site, but traditional VPN connections are often blocked on corporate networks where HTTPS isn’t.

This is the first article in a series about how to build-out a simple vCAC 6 installation to a distributed model.

In a simple installation you have the Identity Appliance, the vCAC appliance (which includes a vPostgres DB and vCenter Orchestrator instance) and an IaaS server. The distributed model still has a single Identity Appliance but clusters 2 or more vCAC appliances behind a load balancer, backed by a separate vPostgres database appliance. The IaaS components are installed on 2 or more IaaS Windows servers and are load balanced, backed by an external MSSQL database. Additionally, the vCenter Orchestrator appliance is used in a failover cluster, backed by the external vPostgres database appliance.

In my previous post Backing up ESXi 5.5 host configurations with vCenter Orchestrator (vCO) – Workflow design walkthrough I showed how to create a workflow to back up host configurations, but it was limited to one host at a time. For this post I’m going to show how to create a new workflow that calls the previous one on multiple hosts using a ForEach loop to run it against each one. This was actually easier than I had anticipated (having read posts on previous versions of vCO that involved created the loops manually).

As a little learning project, I thought I’d take on Simon’s previous post about backing up ESXi configurations and extend it to vCenter Orchestrator (vCO), and document how I go about building up a workflow. I’m learning more and more about vCO all the time, but I found it has a really steep entry point, and finding use cases is hard if you haven’t explored capabilities.

I’m fairly new to SRM, but even so this one seemed like a real head-scratcher! If you happen to be using CA signed certificates on your “protected site” vCenter and “recovery site” vCenter servers, when you come to linking the two SRM sites you encounter SSLHandShake errors – basically SRM assumes you want to use certificates for authentication because you’re using signed certificates. If you use the default self-signed certificates, SRM will default to using password authentication (see SRM Authentication). Where the process fails is during the “configure connection” stage, if either one of your vCenter servers does not have CA signed and the other does (throws an error that they are using different authentication methods) or that you are using self-signed certificates for either SRM installation (throws an error that the certificate or CA could not be trusted).

In my post yesterday (vexpert.me/hS) I talked about how to recover from an expired default SSO administrator password – this prompted a discussion on twitter with Anthony Spiteri (@anthonyspiteri) and Grant Orchard (@grantorchard) about the defaults for expiration and how to mitigate the risk.

The first solution is to modify the password expiration policy for SSO. I’m not advocating this necessarily – I think that expiring passwords ensure that you change them regularly and increase the overall security of your SSO solution. However, I can envisage situations (similar to mine) when the SSO administrator account is not used for a long time and expired – that causes headaches.