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.

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.

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.

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. Simple vCAC deployment 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.

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.

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. The steps I want to create in this post are:

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).

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.