Notes from the field: VMware Access Roles and RBAC bug

On recent projects we where configuring RBAC roles in VMware Access Cloud and stumbled across something annoying which turned out to be a bug. The issue is that when you assign the RBAC roles through super admin, read only admin and directory admin that once added you can’t delete or re-add the same group, it will error out with the following error:


It also isn’t possible to unassing the role anymore, and you might think okay well the role still works! Well no it doesn’t the role is hardcoded and can’t be removed anymore:
Deleting the complete directory and re-adding the directory doesn’t solve it either it will come back no matter what. Logged a GSS support case for this and it turns out this is indeed a bug.

If you have the same log a case and reference HW-123910 so it can get some more traction.

Hope it helps!

Notes from the lab: VMware UAG 2106 and Admin SAML

VMware introduced SAML login capabilities for the admin facing side of UAG with version 2106. See the following article: Release Notes for VMware Unified Access Gateway 2106

This quick home lab blog shows how easy it is and how to integrate this with VMware Workspace ONE Access as your entry point.

First things first, before we start you should have the IDP.xml file of your IDP in place if this is a VMware Access setup or Microsoft ADFS it doesn’t matter, the flow is exactly the same. You upload this at the identity bridging settings part of the UAG.

 

Then you go to the account settings part and select SAML Login Configuration and enable SAML authentication and select your IDP provider.

You click on Download SAML service provider metadata and select the identity provider and external hostname that resolves to the admin port of the UAG. (So yes a FQDN is needed and a valid certificate on the UAG admin facing NIC as well)

The saved XML file is used to import as a custom SAML2.0 web app in VMware Workspace ONE Access and there you can configure a custom access policy if needed.

Afterwards when saving the configuration the admin interface will reset and afterwards only SAML login will work for the admin interface.

Some points to consider:

  • There doesn’t seem to be a fallback login when SAML is configured
  • When configuring the SAML part you might think you are stuck but simply after the SP.xml is downloaded click on cancel
  • This setup should work for any other SAML IDP as well
  • The user or group that is allowed to login via SAML is an ADMIN user

Hope it helps!

Notes from the field: VMware UAG and Citrix ADC scenario’s

On a recent project we were testing some scenario’s for the usage of VMware Blast BEAT through Citrix ADC. For some more information regarding Blast see the following article: VMware Blast Extreme Optimization Guide | VMware

Normally you would see that the Citrix ADC setup is an SSL-BRIDGE vserver with accompanying UDP vserver on the same IP for the ports 443 and 8443 which are the default for BLAST and BEAT usage.

There would be situations that port 8443 cannot be used regarding company compliance or restraints that only port 443 is allowed to be used. In this case you would need to change to an SSL-Offloading setup because we can’t intercept any traffic in a SSL-BRIDGE scenario or apply WebSocket usage in a profile.

We need to create an HTTP profile which enables WebSocket connections and we can use on the new SSL-Offloading vservers

Afterwards bind this profile to the SSL-Offloading vservers

Then we need to change the service group which we use in the UDP vserver to 8443, so the frontend is 443 and the backend is 8443

Lastly the changes on the UAG need to be reflected that the firewall connections would also be 443 for TCP/UDP usage and shared services. See the following articles for more information regarding firewall port requirements and alternate setups in the UAG: Firewall Rules for DMZ-Based Unified Access Gateway Appliances (vmware.com) and Blast TCP and UDP External URL Configuration Options (vmware.com)

With this setup you can service everything for the users on port 443. Do keep in mind that port sharing in this way is an excessive CPU load which can seriously impact the setup. See the following article for some clarification: Unified Access Gateway (UAG) high CPU utilization : HTTP 503 error (78419) (vmware.com)

Hope it helps!

Notes from the lab: VMware vCenter 7u2 ADFS changes

When vCenter 7 introduced ADFS integration I jumped on the configuration part in my lab and set it up with the necessary OAUTH integrations:

Now with vCenter 7u2 there are some changes when you have it in place and are upgrading:

The trust store is changed to VECS and you need to change/add that in vCenter:

Well one would think that everything is nice and dandy after this but I completely forgot that at the time I set the whole ADFS integration part on LDAP and of course no signing requirement in place:

These are the extra changes in my environment and need to be changed in vCenter as well:


Keep in mind that you will need to add a certificate for the LDAPS configuration part, after this the whole configuration should work again.

In my setup I would see a long waiting white screen the first time I would log in, that got resolved after a reboot of the vCenter appliance.

Hope it helps!

Notes from the lab: Citrix ADC and VMware ESX 7u1/7u2

First things first. Citrix ADC at this time isn’t supporting VMware ESX 7.0.1 according to the following article: Support matrix and usage guidelines (citrix.com)

This is something that obviously will get supported in due time. But for the people who are running it just as I am in the lab you would see issues like the ADC instances would lose connectivity or will not load the appropriate network drivers at boot. This is because of the VMXNET3 interface which is causing issues.

Temporary workarounds include just reboot the dam thing until it works… or flip the network interface to E1000 and you have a solid booting/working appliance, well not entirely because the GUI seems to slow down over time to almost not working. I decided to flip it back to VMXNET3 and just do the reboot loop until it works.

Keep in mind that you need to copy/paste your MAC-address before removing the interface and readding them to keep your license etc. nice and working.

Hope it helps!

UPDATE:
ESX 7.0 update 1 build 16850804 is supported, anything above is not at this time. I’ve updated my environment to ESX 7.0 update 2 and the same issues are still present.

Notes from the field: VMware Horizon sessions disconnecting after syslog changes on UAG

On a recent project where we have VMware Horizon 7.13 and UAG 20.09 appliances for the external connections some strange behavior was observed when putting in the syslog URL entries.

After adding or removing entries here and saving the settings all the connections through the UAG will get terminated. Finding this behavior strange as to you don’t do anything that special so why disconnect these sessions.

Had some discussion on the vExpert slack channel and quickly came to light that it looks like an regression issue.

The following article describes the issue User sessions are disconnected through VMware Unified Access Gateway when the configuration settings are changed with the UAG Admin UI (56487) and this should be resolved in later versions.

The version tested here is the release that accompanies Horizon 7.13 build and that is UAG 20.09.

The versions tested by Jesper Alberts were Horizon 2012 with UAG 20.09 and the same problem.

The versions tested by Stephen Jesse were Horizon 7.10 with UAG 3.7 and 3.10 without any issues.

So to sum it up if you have the builds in question it might be a good action to log a support case.

Hope it helps!

Notes from the lab: Bye Bye VMware View Composer

I was upgrading my lab to VMware Horizon 2012 and yes shame on me I still had an composer in my setup. It was already mentioned that VMware Composer is deprecated from the 2006 release but now in 2012 it will block your upgrade when you still have it enabled. Only after disabling composer on your vcenter the upgrade will succeed and afterwards composer will be gone as an configuration item.

See the following screenshots for detailed information:

Notes from the field: Citrix StoreFront forcing connections through Citrix Gateway

On a recent customer project there was the need to migrate off of VDA TLS encryption and migrate the connections from StoreFront to Citrix Gateway.

The customer previously had StoreFront direct connections and used the VDA TLS encryption setup to provide a TLS encrypted session to the desktop or applications.

The VDA TLS encryption setup was too much engineering labor for the day 2 day operations and therefore they asked for a alternate solution but still provide the client>desktop as an TLS encrypted session.

Here we have two options, the first is to use Citrix Gateway and StoreFront as authentication but this introduces the users with a new logon screen and then delegates the credentials with json to StoreFront.

The second is forcing the connections from StoreFront through the Citrix Gateway by the means of optimal gateway routing, and we don’t have any user experience changes because the logon point is still StoreFront.

Option two was chosen and after a quick and simple deployment a seamless migration with optimal gateway routing is in place.

First all the preparation in place is creating a new Citrix Gateway DNS record and a new StoreFront load-balancer IP into the current setup will be migrated, afterwards configure the CVAD wizard on the NetScaler for a simple Citrix Gateway deployment and unbind any authentication policies because these will not be used. Afterwards configure all the necessary settings for a standard Citrix Gateway deployment and propagate these changes across the cluster. When all this is done edit the web.config file of the store that got configured under the primary StoreFront servers IIS inetpub directory and search for: optimalGatewayForFarmsCollection and make sure there is an entry with optimalGatewayForFarms enabledOnDirectAccess=”true” and save the file. Propagate the changes and after that migrate the old DNS entry to the new StoreFront ip. You will see that after logon the desktop brokering is force through Citrix Gateway.

The following reference articles where used for configuration and testing:

How to Force Connections Through NetScaler Gateway Using Optimal Gateway Feature of StoreFront (citrix.com)

How to Configure Authentication at StoreFront using NetScaler Gateway – NetScaler Configuration (citrix.com)

FAQ: Configuring Authentication at StoreFront using NetScaler Gateway (citrix.com)

SSL configuration on VDA (citrix.com)

Notes from the field: VMware Horizon Instant Clone and Imprivata OneSign

On a recent project consisting of an VMware Horizon instant clone setup and Imprivata OneSign in the desktop for SSO capabilities I’ve encountered some strange timing issues.

Normal logins through the horizon client via connection server would be ok with the OneSign agent online, logins through the UAG without TrueSSO would also be okay. (so it seemed)

TrueSSO enabled because the total solution is a Workspace ONE deployment and we want to use one login of course regarding credentials introduced a problem. The login process would work just fine but the agent of Imprivata would stay offline only to be online after a reconnect to the desktop.

A long troubleshooting process started with the team and also a support case opened with Imprivata pointed us in the direction that there was an issue all along with the base setup as well.

Logging in to the VMware console of an desktop without the UAG or TrueSSO in place would provide the same result, an offline OneSign agent and the second logon or disconnect/reconnect even in the console would resolve it.

Long story short after that finding we did an test to restart the OneSign agent before logon of any user (tested this through Ivanti AM) and then let the user logon and presto no more issue.

We then created a script to be used in ClonePrep so that we don’t have to rely on Ivanti AM and after that issue is also resolved.

But now comes the kicker. The solution at the time was an Horizon 7.10.x ESB release and for customer requirements and lifecycle management to be future ready we needed to go to the 7.13 release of Horizon (not perfectly documented but this is the new ESB release as well and last significant release of Horizon 7)

After this update to the connection servers the ClonePrep scripts would time-out and not function correctly anymore. Removing that from the pool did blow my mind because after that the complete issue was gone and the OneSign agent would be online all the time no matter what.

Tested this with an old image and the 7.10.x release of Horizon installed with the 7.13 connection server as backend and indeed no more issues and everything fine. The root cause seems to be “something” in instant clones that got fixed/changed in 7.13

To summarize, the fix for an 7.10.x release is to use any means of restarting the OneSign service before any user will logon and for the 7.13 release it’s no issue at all. (I’m betting this will also be the case for Horizon 8 but haven’t tested that with Imprivata)

Some reference articles:
The Imprivata URL’s you will need an active account at Imprivata to view them

How to enable Imprivata Agent trace

Does Imprivata support VmWare Instant Clone for VM Desktops?

Configuring Kerberos Authentication (imprivata.com)

Configuring Support for VMware True SSO (imprivata.com)

Information on Horizon 7 Extended Service Branch (ESB) (52845) (vmware.com)

VMware Horizon 7 version 7.13 Support Plan (81189)

ClonePrep Guest Customization (vmware.com)

Notes from the field: Citrix FAS request not supported

On a recent Citrix FAS deployment I’ve encountered the following error: “Request not supported” when logging in to a published application or desktop.
Article https://support.citrix.com/article/CTX218941 explains that re-enrollment of the domain controller authentication template or another custom template for Kerberos usage should resolve the error.

A little bit of a background on the environment, an already working Microsoft ADCS environment was in play and in use for other services. From a design/security perspective it was designed that two dedicated Microsoft ADCS servers would be used and two Citrix FAS servers connecting these new servers. The setup was working as expected but only above error would keep coming when trying to access an application or desktop.

We tried re-enrolling the domain controller authentication certificate and this didn’t do the trick, then we decided to let the Domain Controllers get the certificate from the new dedicated Microsoft ADCS servers for Citrix FAS and this did do the trick but with a side effect the chain is changed and other services would be negatively impacted so a rollback was needed.

With this information a Microsoft support case was created and ultimately they confirmed that what is mentioned in the Citrix support article should do the trick. Ok we got confirmation and yes it indeed does work when using the new ADCS servers but the issue of the original ADCS environment was still a mystery.

So next up we decided to repoint the Citrix FAS servers to the existing Microsoft ADCS server to root out any chain or other issues that might be in play. The result was exactly the same and a not supported request as the end result.

Digging deeper in the Microsoft ADCS environment it was after checking the “NTAuthCertificates” store that the existing server wasn’t there and the new servers were. This explained the smartcard logon not working when using the existing environment because an requirement for smartcard logon is that the “NTAuthCertificates” store has the issuing certificate authority propagated. After adding the certificate and waiting for replication and a reboot everything was working as expected, also when moving to the new Microsoft ADCS environment for certificate issuing.

See the following screenshot of the Enterprise PKI snap in MMC in which you can check and/or add the missing certificate:

See the following articles for extra information:
https://docs.microsoft.com/en-us/troubleshoot/windows-server/windows-security/import-third-party-ca-to-enterprise-ntauth-store
https://support.microsoft.com/en-za/help/281245/guidelines-for-enabling-smart-card-logon-with-third-party-certificatio