vExpert 2015 Award

Featured image

Thanks to VMware for confirming my vExpert!

Certificate Lifecycle Management published on VMTN Blog!

My article about Certificate Lifecycle Management on vSphere 6 has been published with other articles from vExperts from all over the world on VMware VMTN Blog, so thank you VMware for the opportunity :-)

You can check all links here:

How to revert new Transparent Page Sharing behaviour

There have been a lot of blog posts around warning us that starting from vSphere 5.5 Update2d (build 2403361) TPS will be basically turned off.

Besides comments about the why and how to partially re-enable inter-VM TPS I just think in most cases it might make sense to restore the original behaviour; I have been in the process of upgrading an infrastructure where the RAM contrain represented a much bigger concearn than the specific security reason why TPS has been turned off so I decided to take a look at the shared memory metrics in vCenter just to find out that post-upgrade situation wouldn’t be exactly heavenly if all the shared memory pages would be translated into unique pages.

I found this arcicle KB2097593 where it explains the various status of the settings you can apply and one of them basically disables the new behaviour restoring the old fashion TPS:

Featured image

In other words setting the value “ShareForceSalting” to 0 will bring things back in time.

The complete procedure is as follows:

1. Log in to ESX (i)/vCenter with the VI-Client.
2. Select ESX (i) relevant host.
3. In the Configuration tab, click Advanced Settings (link) under the software section.
4. In the Advanced Settings window, click Mem.
5. Search for Mem.ShareForceSalting and set the value to 0.
6. Click OK.
7. Reboot host

vSphere 6 Certificate Lifecycle Management

Recently I’ve been fighting with a vSphere environment and CA certificates and I thought a lot about certificate management and lifecycle in a VMware vSphere environment after that and how much it needs improvement. With the SSL Certificate Automation Tool VMware made a step in the right direction and even if the tools itself is sometimes a little buggy it is still very handy in automating a long and error prone process. In vSphere 6 VMware is taking another step in the right direction to help us create, apply and manage SSL certificates in a vSphere environment, but before talking about this we need to talk a bit about what’s new in SSO and vCenter architecture in vSphere 6. Since the introduction of SSO VMware changed its architecture in every major release, starting from 5.1 to 5.5 and now to 6.0 so let’s make a little bit of history:

Featured image

The new vSphere 6 management architecture introduces two main roles that you can deploy, these are the Management Node and the Platform Service Controller (PSC); the reason behind this separation is to have a logical entity that will take care of the main management features while another entity will hold the core and security features of the solution. What is nice about this separation is that you don’t need a 1:1 ratio between Management Nodes and PSCs so you can install PSC on separate boxes and replicate between them and then have as many Management nodes as you need (as long as you are within the same SSO domain)

Featured image

For HA scenario if you install PSC on separate boxes you will still need a load balancer. Supported solutions are Big-IP F5 and NetScaler so far.

You can obviously still install everything in one box:

Featured image

You might have noticed that the HA model for SSO was active/passive in 5.1, then active/active in 5.5 and now is active/passive again; this is due to the re-engineering of the Secure Token Service (STS) which is moving to a new and more robust method of STS (known as WebSSO) which is the same already used by vCAC (or vRealize Automation if you will) and that will be used from now forward instead of the old 5.5 method (WS-Trust). Let’s see how services are spread out on each role:

Let’s take a look to the services within the Management Node and the PSC:

Featured image

In the Management Node we can find services and features that every vSphere Admin feels very comfortable and familiar with such as vCenter Server, vSphere Web Client, Syslog Collector, etc., but two of them deserve a few words:

  • Virtual Datacenter Service: this service is new and it has been introduced to help mitigate the limitation connected with the Datacenter object in vCenter as a Management boundary.
  • (Optional) vPostgres: This component is obviously referring to the vCenter Appliance (thus optional) but I believe more and more new deployments or upgrades deserve to be considered a good fit for vCSA since VMware announced complete equality of features between vCenter installed on Windows and vCSA; leave alone the fuss of dedicating Windows licenses for vCenter which might not be a huge problem I just find the process of patching ad upgrading a vCSA simply amazing and it’s not a secret that products like EVO:RAIL make extensive use of vCSA. VMware wants to move all their services deployment model towards Virtual Appliances, this is not a secret and we need to get used to it, the sooner the better, but I’m digressing…

Featured image

In the Platform Service Controller or PSC we find our old friend SSO (we have had a rough past but now we are on better terms) and quite a few new services:

  • VMware Single Sign-On
    • Secure Token Service (STS)
    • Identity Management Service (IdM)
    • Directory Service (VMDir)
  • VMware Certificate Authority (VMCA)
  • VMware Endpoint Certificate Store (VECS)
  • VMware Licensing Service
  • Authentication Framework Daemon (AFD)
  • Component Manager Service (CM)
  • HTTP Reverse Proxy

Describing all these services is out of the scope of this post but as you probably guess two of them will be our focus: the VMware Certificate Authority (or VMCA) and the VMware Endpoint Certificate Store (or VECS). But what are the roles of VMCA and VECS? The VMCA is no more or less than a CA, so you can:

  • Generate Certificates
  • Generate CRLs
  • Use the UI
  • Use the Command Line Interface to replace certificates

The VECS is where all certificates within the PSC are stored, with the only exception of the ESXi certificates that are stored locally on vSphere hosts, so here you can:

  • Store certificates and keys
  • Sync trusted certificates
  • Sync CRLs
  • Use the UI
  • Use the CLI to perform various actions

Since VMCA and VECS are part of the PSC, they will take advantage of the Multi-Master Replication Model which is offered by the Directory Service (VMDir) in order to achieve HA. In the past every service had its own user and required its own certificate but this is not the case anymore since we now have Solution Users (SU); since the number of services has increased significantly it would be impractical to manage the lifecycle of this many certificates so now we have 4 main SU that will hold the certificate used for a number of services.

Voila_Capture 2015-01-08_08-14-37_pm_white_background

What about use cases/scenarios in which I can implement VMCA? In what ways you can use this new tool?

Featured image

Scenario 1 and 2 are similar: the VMCA is the CA that releases certificates for all Solution Users (SU), the only difference is that in scenario 1 the VMCA is the root CA and you will need to distribute the Root CA Certificate so that all corporate browsers will trust it, while in scenario 2 the VMCA becomes part of an existing PKI as a subordinate CA and you certificate trust.

Featured image

In scenario 3 VMCA is installed but not used, CSRs are created and submitted to an external CA and VECS will be used to store certificates in PEM format.

Featured image

My favorite is scenario 2 because most enterprises I see already have a PKI (Microsoft CA usually) and all clients already trust the CA certificates, so adding the VMCA as s subordinate is a non disruptive process with a very low maintenance impact on the PKI itself, it protects investments already made to implement the current PKI and  preserves the knowledge to run the PKI.

Replacing certificates is still a CLI task (looks like Powershell will be involved) but VMCA and VECS are a very promising step toward the right direction for simplifying certificate lifecycle management in a vSphere environment.

vExpert 2014 Award

vExpert-2014-Badge

Some of you might have noticed the badge I’ve added to my Blog.

I have to thank VMware for recognizing my efforts for the community and for awarding me with this title.

Thanks to this and to Corey Romero who granted me a Blogger Pass for VMworld in Barcelona I will be able to write about the conference pretty soon.

Stay tuned!

ESXi 5.5 Update 2 build 2143827 break Citrix NetScaler

If you happen to run NetScaler and upgrade to build 2143827 of vSphere 5.5 you will run in very nasty issues.

Specifically, your NetScaler will go bonkers if you enter in the management web interface or even via SSH; in general all things that start a network increase in term of traffic directed to the NetScaler will make it crash.

When it doesn’t crash you will still experience network communication drops, hangs, connectivity issues and such and in a very random fashion too (just to add some fun).

Fortunately VMware gave us a workaround.

To work around this issue, add the line hw.em.txd=512 in loader.conf file.

To add the line hw.em.txd=512 in loader.conf file:

    1. Log in to the Citrix NetScaler virtual machine appliance as root
    2. Locate the loader.conf file on the Netscaler virtual machine appliance by running this command:find / -name loader.conf

Note: There are two loader.conf files. The two files are ./flash/boot/defaults/loader.conf and ./flash/boot/loader.conf.
Modify the first one and ensure to take a backup of the file prior to making the changes.

  1. Add this line in the loader.conf filehw.em.txd=512
  2. Save the changes
  3. Restart the NetScaler virtual machine appliance

For deeper details about the issue read KB VMware KB 2092809

Migrating NTUSER.DAT and UsrClass.DAT with Horizon Mirage

I don’t know about you but I found it to be a little weird that there is not way to tell Mirage to move NTUSER.DAT and UsrClass.DAT when performing an hardware migration.

Considering Mirage uses USMT to migrate the user state mean that this is a precise choice from VMware and not a technological limitation.

Those two files include two pretty important user settings: the user portion of the registry and the user class of the registry.

If you want to have the migrated workstation to have exactly the same look and feel, including the customization of the single applications settings, icon positioning on the desktop and so on you definitely want to apply NTUSER.DAT and UsrClass.DAT as well; I am sure there are scenarios where you don’t want this but there are also scenarios but if you want you should be able to do it.

In the Factory Defaults this is explicitly forbidden, so if you want to apply NTUSER.DAT and UsrClass.DAT too you need to follow this procedure:

  • Log in to your Mirage Management Server
  • Open a command line as administrator
  • Browse to C:\Program Files\Wanova\Mirage Server
  • Launch the Server CLI: “Wanova.Server.Cli.exe <server name/ip>” of your Mirage Management Server such as <localhost>
  • Enter: “GetFactoryPolicy c:\factorypolicy.xml” (Get the current factory policy)
  • Edit the file c:\factorypolicy.xml (e.g. with notepad,notepad++)
  • Save the file by entering: “SetFactoryPolicy c:\factorypolicy.xml”

When editing the file, you can search for “NTUSER” and “UsrClass.dat” and just remove the lines with “”.

Follow

Get every new post delivered to your Inbox.

Join 102 other followers

%d bloggers like this: