Help(!) I have installed a UAG (Unified Access Gateway) and from Qualsys SSLLabs I get a Class B rating

Welcome back, and you might be reading this post because from interest perspective, or from a getting a Class R rating from Qualsys SSLLabs.

It is always best practice to check your Internet Facing products for Security / Certificate issues.

You can do this from this site:SSLLabs 

I have noticed that when installing a default UAG and not altering any settings you might get an B rating:

I’m hearing you saying : I don’t want to have a B rating, I want to have an A rating! How to fix this?

Well, that’s quite easy, but there are some things to consider :¬†SSL&TLS Best Practices

When you go to your VMware UAG Appliance, you go to Advances Settings -> System Configuration:

And then Enable “Honor Cipher Order” (set is to YES)

And change the Cipher Suites from standard :  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA



And when you click Save and to the check again on SSLLabs, you should get a A-Rating:

Happy Securing your UAG!


VMware Unified Access Gateway 3.3.2 Released

The latest version of VMware Unified Access Gateway : 3.3.2 is released since 09-10-2018.

What is new in this version?

  • Content Gateway fix to resolve an issue with service restart due to¬†smbconnector process deadlock.
  • Tunnel Proxy fix to support new iPhone hardware identifiers – Xr, Xs, Xs Max

Source :

Should I implement is the question I hear! Well, as always: It depends!

From a Horizon View perspective: before updating, take in account the

As we can see (because it’s just released), there is at this moment no support for Horizon View versions (3.3.2 not even mentioned). So, should I upgrade?

My answer would be : Only, and only if you are facing the issues noticed in the What’s New section. Keep an eye on the Interoperability Matrix and before going to production, test it in a test environment!

A common used version of Horizon view at this moment is 7.4.0, as you can see UAG 3.3.1 is not supported there. So I expect the 3.3.2 also not supported there. If this is the case, you should consider upgrading the Horizon View environment!

VMware View Security Server vs Unified Access Gateway

Just a little post about which product to choose, as I was at a customer who is running VMware Horizon View 7.4 and still using Security Servers.

While Security Server is still supported (for 7.4), why should’t you use UAG instead?

Well, this is interesting, because the story of this customer was:
– Already having Security Servers and for UAG some firewall / network changes have to be done
– Systems are already reserved for this purpose
– No knowledge of implementing UAG
– And last (and often heard of) but not least: we are familiar with Security Server, we don’t want to go to UAG

Well, the last one, I can image from a customer perspective, when it works, don’t change IT… IT might break then…

But, there are a lot of advantaged of using UAG against the Security:
– No need for pairing Security Servers with Connection Servers (so, current customer can decommission 2 Security Servers and 2 Connection Servers), that’s not entirely true, because for the Security Server we deploy UAG’s, so only less Connection Servers are needed.
– Security Server is in DMZ, Security Server is a Windows Machine…do I need to say more? Something with hardening, security etc. With UAG, you have a hardened Linux Appliance! Way more secure!
– Easy to implement! UAG installation is way more easy instead of deploying a security server, the UAG versions have a nice GUI, so installation is way more easy.
– UAG is secure out of the box! (just remember to change the password though ūüôā )
– It is possible to separate traffic, you can have a UAG with 1 NIC, 2 NIC’s or 3 NICS, where with 1 NIC it is the same situation with a Security Server. 2 NIC’s you separate DMZ Internet with DMZ Internal Traffic (where internal/management traffic is over 1 Interface (NIC). And 3 NIC’s where every part has its own network, 1 NIC for DMZ Internet, 1 NIC for DMZ Internal Traffic and 1 Interface for DMZ Internal Management Traffic. So every part is separated and thus more secure!
– When you have the UAG up and running, you export the configuration. Whenever the appliance breaks due to mistakes, security breaches or whatever, you deploy a new UAG, import the Configuration and you’re done! (Against a full installation of a Security Server)
– Installation of the UAG is scriptable! So this easies the installation proces and speeds up the deployment time.
– When you need to upgrade the appliance, you can do an in-place-upgrade, or just roll-out a new version and import the configuration! Easy as that!

So, I guess there are no reasons for customers to stay with Security Server, and soon upgrade to a UAG (unless there is a specific very good reason for keep using the Security Server)

In the next blog I will go through the Installation&Configuration proces of a UAG!

VMware IDM 3.0 with ADFS 3.0 – Single Sign On to Portal Configuration

Welcome to this Blog Article, which explains the configuration of Single Sign On to the VMware IDM 3.0 portal with the use of ADFS (version 3.0).

Why should I use ADFS for SSO integration to VMware IDM? Well, there is one scenario which will force you to do so, SSO to IDM is a standard functionality and this works great, but there is only one caveat : multi-domain configuration.

In the current project we encountered this problem, because in a single-domain configuration, SSO works great! But when we enable more domains, then every time you go to the portal, you get the question “Hey, who are you? Please identify yourself!” And then you need to supply you’re credentials (only Username / User Principal Name) password is being passed through then.

The “lack” of functionality in multi-domain will be implemented in the future for VMware IDM. But at this moment, there is no possible way to get it done…is it? Well, there is one (working) solution to get it working though! Here comes AD FS (Active Directory Federation Services)¬† in place, with AD FS as a third party identity provider it is possible to use SSO (through ADFS) with VMware IDM, also in a multi-domain configuration!

Great! How?

Well, I will explain this configuration in this blog. There is documentation from VMware  which helps you through the installation/configuration, but you really need to check things and there is some description about certificates what is not very clear which causes the problems, so I hope this blog helps you through the whole proces without pain.

This article is based on a already configured – up-and-running- ADFS 3.0 and VIDM 3.0 Installation.
This article only described the way of creating an Identity Provider in VMware IDM and creating a Relying Party within ADFS 3.0

Unfortunately, this does not work for Horizon 6.x, you need to have Horizon 7.x at minimum! You need to use True SSO for this to work and that only works with vIDM 2.6 or higher and Horizon 7.x

Part One – Directory Configuration

VMware Identity Manager 3.0 Configuration.
We assume that Identity Manager is installed already, and this blog assumes / requires you to have version 2.6 at minimum is installed. (Identity Manager 2.6 is the minimum, in this guide I used IDM 3.0)

First, go to the Identity Manager portal <https://<idm-portal>/SAAS/login/0

Go to Identity&Access Management -> Directories:

Click “Add Directory”

Click “Add Directory over LDAP/IWA”

Give the Directory a logical name. I called it like my top-level domain : top.local
Select the appropriate Active Directory (in my case IWA)
I use UserPrincipalName for Directory Search Attribute

Fill in the Join Domain Details and click Save & Next

Select the domains which need to be added and click Next

Select the User Attributes which need to be mapped (I leave them default) and click Next:

Select the Groups (if needed) and click Next:

Select the Users to sync and Click Next:

I use the DNs from all domains, click Save&Sync

Part Two – Identity Provider

The Next item is to add the third-party-identity Provider : AD FS. In order to do this, go to Manage -> Identity Providers:

Click “Add Provider” -> “Create Third Party IDP”:

In the Create Third Party IDP Screen, give the Identity Provider a name, for example : ADFS and fill in the SAML Metadata URL from ADFS, example : https://<ADFS-FQDN>/FederationMetadata/2007-06/FederationMetadata.xml and click Process IdP Metadata:


After Clicking on Process IdP Metadata, the SAML information is retrieved from AD FS:

The only thing is, this information above is not needed, so we alter the first entry and change it to : urn:oasis:names:tc:SAML:1.1:name-id-format:unspecified and with Name ID Value : userPrincipalName

The other two values, we just remove.

This will result in the following:

Name ID Policy in SAML Request (Optional) is not needed to be altered.

Just in Time User Provisioning we do not use at this point, so I did not enable it.
Users must be selected ofcourse and the Network Range(s) from which this IdP can be accessed from:

In the Authentication Methods section, we need to define authentication Methods to be used by IdM to authenticate the user with. Give the Authentication Methods logical names as these are needed in the Policy Section from IdM. In the Policy Settings you define which of these settings are being used to authenticate the user with.

I have created two authentication Methods, one is still a password :
ADFS-Test-Password : urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport

ADFS-Test-UPN : urn:federation:authentication:windows

Single Sign Out Configuration I did not configure. This will be done in a later post, so I leave it as is : Not enabled :

The last part is for the AD FS Configuration, you can click the SAML Metadata link in order to use in the AD FS Configuration

You can open the link, copy the content and use it in AD FS, or you can copy the URL of the Metadata from IdP and use the URL in AD FS

And the last step in the configuration of the Connector is to save the information, click Add to (save) add the connector to the IDM configuration:

Part Three : AD FS Configuration

AD FS Configuration.
We begin with the configuration of AD FS. We assume you have AD FS Configured already.

First, open AD FS and go to Trust Relationships -> Relying Party Trusts:

Right-Click and select “Add Relying Party Trust…”:

In the Welcome to the Add Relying Party Trust Wizard, click Start to begin

In the Select Data Source, select the preferable way to add IDM to AD FS, in my Lab I used the previously downloaded sp.xml file from IDM. Click Next to continue.

In the Specify Display Name screen, give a Display Name for IDM, in my lab I used “IDM 3.0”:

In the Configure Multi-factor Authentication Now screen, leave the default and click Next to continue:

In the Choose Issuance Authorization Rules screen, Leave the Permit all users to access this relying party selected and click Next to continue:

In the Ready to Add Trust screen, nothing has to be changed, so click Next to Continue:

In the Finish Screen, untag the Open the Edit Claim Rules dialog for this relying party trust when the wizard closes… we do the Claim Rules later. Click Close to continue:

In the AD FS Main screen, right click the relying party trust IDM 3.0 and click “Properties” :

In the Properties screen, go to “Encryption” Tab and click “Remove”
The Certificate needs to be removed in order to function correctly with IDM, without doing this step, IDM cannot communicate with AD FS, because the data is encrypted from AD FS to IDM.

When requested to remove the certificate, choose “Yes”

After removing the Certificate, the screen should look like this:
Click “Apply”

When this setting is applied (certificate removed) click OK to close this dialog

The next step is to create the Claim Rules for passing the User Principal Name to IDM.

Right Click the Relying Party Trust “IDM 3.0” and click Edit Claim Rules…

There should be no claim rules defined. To start, click Add Rule:

Select Send LDAP Attributes as Claims and click Next

Give the Claim Rule a name, for instance UPN (in this case, we specifically use UPN)
Select Attribute Store : Active Directory
Choose for Mapping of LDAP Attribute : User-Principal Name
Choose for Mapping Outgoing Claim Type : UPN

Click Finish to create the rule

In the Edit Claim Rules screen, the just created rule is visble, at this point, we need to create a custom transform rule to translate the information from Active Directory to SAML for use in the IDM Portal. Click Add Rule…

Select in the Choose Rule Type screen : Send Claims Using a Custom Rule.
Click Next:

Give the Claim rule a logic name, in my Lab I called this Rule : UPN Transform Rule.

In the Custom Rule Text Box, you need to enter the rule which translates from Active Directory to SAML language

c:[Type == “”]
=> issue(Type = “”, Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType, Properties[“”] = “urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified”, Properties[“”] = “<IDM-Portal-URL>“);

Replace <IDM-Portal-URL> for the URL used for IDM , in my lab it is :

And click Finish to save the information.

We should have a screen like this:

We are finished now for configuring AD FS!

Part Four – IdM Policies

Now the Directory, Identity Provider, AD FS have been configured, it is time to configure the policies in order to let the user logon with AD FS Single Sign On.
In the VMware IDM Portal, go to Identity & Access Management -> Policies.

The is the default_access_policy_set, click on that to edit the default policy:

For your own administration give the policy a description.
To edit the policy, click the first rule (Web Browser) The Authentication Method : Password (Local Directory) (in blue)

Edit the Policy rule according to the¬† needs …

…and select the corresponding Authentication Methods, created earlier in the Identity Provider ADFS

I have selected the First Authentication Method : ADFS-Test-UPS
The Backup Authentication Method : ADFS-Test-Password:

Click OK when Done

And Click Save to Save the new Policy:

Now everything is set from an ADFS / vIDM perspective to enable Single Sign On for use with VMware Horizon 7.x, don’t forget to check that True SSO is Enabled in Horizon (!)

Thanks for reading and till the next Blog!

Tips&Trics #1

I would like to post some tips&trics / tweaks for example in vSphere environments, to begin with… there is a little sort of bug within vSphere that can cause (in a vSan environment) that a host is not reporting any information anymore.

With this “trick” / “workaround” you are able to prevent this issue from happening.

What is going on? Well, at a certain point (no triggers) it is possible that the localcli proces for cleaning up mounting/unmounting luns in esx.conf comes in a hanging state, resulting in that the host is not reporting health data to the cluster. Is this a problem? Well, not really….everything stays working (production / vm’s), but you don’t have any information anymore for the health of that particular host.

This trick disables the proces from running. In fact, it is a script called from Cron, so the solution is to disable this Cron Job, that’s it!

Should I use it?
Well…depends… there is a slight chance this issue will occur and you will be affected, from my own experience, this one popped up in a 10 node vSAN cluster which is running 85 day’s without issues. So out the blue this one popped up.

There is a VMware KB which describes this issue : VMware KB2146548

So, when do I need to do this?
When you are not daily adding/removing LUN’s to your cluster, if you do, be careful with this one as it might mess up your esx.conf file.

Perform the following steps on every host in your cluster:

  1. Log in to ESXi host through SSH and root credentials.Note: There will be no impact to the environment if you are not creating/unmapping a large cluster of LUNs periodically.
  2. Navigate to the /var/spool/cron/crontabs/ folder.
  3. Backup the root file with this command:
    cp root ./root.bak
  4. Open the root file using a text editor:
    vi root
  5. Comment the line:
    00   1    *   *   *   localcli storage core device purgeThe line should look similar to:

    #00   1    *   *   *   localcli storage core device purge

  6. Save and close the file.

Reboot is not needed as Cron won’t start the proces again.

In case of a hanging localcli, please reboot the host (outside business hours ofcourse) and perform these actions afterwards.

VMware vSAN Sparse Swap

Sparse Swap you say? Well, yes! Sparse Swap!
With Sparse Swap enabled, you thin provision Swap Objects. This can reduce significantly you’re disk space!
It is always important to have available disk space for swapping purposes (and other reasons), but normally, there is no need for dedicated Swap Space (unless you over provision and make a lot of use of swap space).

To disabled Sparse Swap on VM Objects, you need to alter it per host. Not on vCenter level, but on host level.

This is especially for vSAN 6.2.

To enable Sparse Swap, log into the console of you’re ESXi host(s) (every host needs to be done)

And  do the following:

esxcfg-advcfg -s 1 /VSAN/SwapThickProvisionDisabled


To disable Sparse Swap:

esxcfg-advcfg -s 0 /VSAN/SwapThickProvisionDisabled

Be sure to turn off and turn on the VM’s in order to have Sparse Swap activated for those machines! And be sure to do this setting on every host.

I would recommend to do this as a best practice in a new environment (but, be carful… based on what the requirements are! If you are planning to over provision and use a lot of swap data, don’t turn this option off!)

In a typical environment we had before the change:

after the change:

This is not entirely representative because we rebuild the whole vSAN. There was a lot of “trash” on it, but. stil, the difference is big!

vRA 7.3 – Part 2

Part 2 : Configuring vRA

In part 2 I will go through the configuration of vRA after successfully deploying the vRA OVF Template.

Power on the Deployed Template:

After turning on the Appliance, wait a few minutes and go to the appliance IP address entered before, in my case :

Log in with the root account and password entered before:

Next, the Welcome to the vRealize Automation Installation Wizard occurs:

Click Next to proceed with the wizard.

Accept the Terms of agreement and click Next

In the next screen, select the Deployment type.
In my home lab I will use Minimal deployment, which is enough for a demo or Proof of Concept

Click Next to Continue.

In the next screen, the installation prerequisites are shown

Before we can proceed, we need to install the vCAC-IaaSManagementAgent-Setup.msi on the IaaS Windows System. We need to download this file, transfer it to the IaaS Machine and install it there.

Go to the IaaS Server and enter the vRA URL, proceed to the step as above and click the link to download the file.
Once downloaded, click on the file to install

When a security warning occurs, click Run

When the Setup Wizard starts, click Next to Continue:

In the End User License Agreement, tick the I accept the terms of this agreement and click Next

In the next screen, select the destination folder where the Management Agent needs to be installed (in my lab, I leave it default)

Click Next to continue

In the next screen, the information for the Management Site Service needs to be filled in, fill in the vRA Appliance Address, in my case :
The Root Username is : root and the password is which is entered before.
The Management Site Service certificate needs to be loaded, click on Load to load it. It will be filled in automatically, after that, tick the I confirm the fingerprint matches the Management Site Service SSL certificate.

When everything is OK, click next to continue.

In the next screen, fill in the user name and password for an account with administrative privileges for the local Windows Machine, in my case the local account is already filled in. I only need to fill in the password.

In the last screen before installation, click Install to continue

When the installation is finished. Click Finish to close the installer:

When finished, return to the vRA Installation Wizard and notice that the IaaS host is discovered:

At this point it is possible to continue with the installation and click Next to proceed.

In the next screen, the Prerequisites Checker is shown, click Run to check all the prerequisites of the IaaS Machine:

There are in my lab several prerequisites which are not OK for installation:

Click on Fix in order to try to fix them automatically

When the Prerequisites Checker is finished, everything should be OK, when everything is OK, click Next to proceed to the next step.

In the next screen, enter the vRealize Automation Host.
You can tick the Resolve Automatically to automatically resolve the vRealize hostname. I did this In my environment

Click next for the next step

In the next screen, enter a password to assign system administrator credentials for the default tenant account

In the next screen, fill in the information for the IaaS Host

Fill in the IaaS Web Address, in my case :
Username, password and Database Security PassPhrase, I used a simple passphrase : IaaSInstall

The next step is creating a SQL Database, select the server name and leave the database name default.

When validation is successful:

Click Next to proceed

In the Distributed Execution Managers screen, leave all items default, they should be OK and click Validate to validate all settings. When all Parameters are valid, click OK to continue.

In the Agents screen, leave all items default, they should be OK and click Validate to validate all settings. When all Parameters are valid, click OK to continue.

In the next screen, create a vRealize Appliance Certificate. For my lab, I use Generated Certificate. Fill in Organization, Organizational Unit and Country Code and click on Save Generated Certificate

When the Certificate is Created, click Next to proceed to the Next step.

For the Web Certificate, the same story as above, for my lab I will do with self signed certificates. I fill in Organization, Organizational Unit&Country Code and after that, Click Save Generated Certificate

When the certificate is generated, click Next to proceed to the next step

In the next screen, validation needs to be done, validation can take up to 30 minutes, so please be patient. Click Validate to validate the configuration

When validation is successful, click Next to proceed to the next step

Advice is to create a snapshot of the vRA Appliance in order to revert back when the installation would fail

In the Installation Details Screen, click on Install to install vRA.

Monitor the installation status:

Installation half way:

When the installation is complete, click Next to proceed to the next step

In the next screen, enter a license key to continue

When the license key is correct, Click Next to continue

In the next screen, choose to participate in the Customer Experience Improvement Program

Click next to proceed to the last step of the installation of vRealize Automation

For a normal installation, Continue is fine, for a proof of concept, Request initial content can be used to evaluate a proof of concept vRealize Automation deployment

I did the Initial Content Configuration, the username is configurationadmin and the password needs to be defined.

Click Create Initial Content to start the proces.

Monitor the proces of Content Creation…

When the proces is completed, click on Next to close the installation Wizard

When the installation is finished, click Finish to close the installer

At this point, the vRealize Automation Installation is finished.

vRealize Automation 7.3 POC Deployment – Part 1

In order to test a vRealize Automation, you can create a minimum (or POC) deployment for testing and demo purposes.

In this Blog I will go through the installation of vRA 7.3 Step by step.

I already have a Domain Controller and a system ready for the IaaS Part (just Windows Server OS ready to install the components)

The first part, Part 1 : Deploying vRA Template

Start with downloading the vRealize OVF File from the website from VMware

In vCenter select Deploy OVF Template…

In the Select template screen, click Local File and browse to the location where the OVF is saved

Select the file to use (In this case VMware-vR-Appliance-

And click on Open, after that, click on Next

In the next screen, give the Appliance a name (or leave it default), select the datacenter (or folder) and click Next

In the next screen, select a resource where to run the deployed template.
In my demo I use -> vRA7.3 (is a resource pool)
And click Next to continue

In the next screen review the details of the deployment and verify if everything is correct. If everything is correct, click Next to continue

In the next screen, accept the license agreement by clicking Accept and then click Next

In the next screen, select the storage for the files for the deployed template.
Because of my Home Lab, I will use Thin Provisioning (in order to save some storage), I also do not select a VM Storage Policy, in my lab it has no use at this point. I leave the selected (and correct) datastore and click Next to continue

In the next screen, select the correct network for the appliance, I leave it default because in my case, VM Network is the correct network to connect to.
Click next to continue

In the next screen, we need to customize the template, here we need to enter all the settings for the vRealize Appliance

After I filled in all the settings, it looks like this:

When all the settings are correct, click Next to continue

In the next screen, review if everything is correct, and if so, click on Finish to continue

After clicking Finish, the OVF with the settings above will be deployed:

When the deployment is finished, continue reading at Part 2 : Configuring vRA Appliance