Notes from the lab: VMware Horizon and Microsoft MFA NPS Extension

In my own lab environment I have a mixture of EUC components and dual factor configured accordingly, but more and more I see that customers also just use the MFA solution of Microsoft to integrate it for their environments. Why not it’s included with your license right.

So back to the techie part I’ve configured my own NPS setup on a Windows Server 2019 and configured the RADIUS setup. Installed the MFA NPS extension and had a pre-existing configuration for my Citrix ADC appliance.

I’ve configured my Horizon connection server as an RADIUS client and enabled the configuration request and network policies for it as well, configuration type NAS IPv4 Address and the IP-address of the server.

Afterwards put in the configuration part in Horizon itself pointing the RADIUS authentication to the NPS server with all the necessary fields and/or additions that you want.

Well basically all should be working instantly when logging on to the Horizon URL or client.

I did however had some issues when logging in and stuff would time-out, event entries would say that the wrong dual factor request was given. This ultimately came from the fact I didn’t have a primary authentication set in MFA, I’ve checked that I could use my yubikey, SMS or push authentication. The resolution for this was to select primary push in the authenticator app and then it worked instantly.

Reference articles:
https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-nps-extension
https://christiaanbrinkhoff.com/2017/02/17/how-to-configure-azure-mfa-for-citrix-netscaler-gateway-radius-by-using-the-new-nps-extension/

(off topic there is an issue with 2019-NPS which I’ve encountered when configuring RADIUS-WIFI authentication, see the resolution here: https://community.ui.com/questions/FYI-Windows-Server-2019-NPS-for-RADIUS-broken-w-fix/364c7c17-b3d3-4973-8dd2-e4e701309300)

Notes from the lab: Configuring vCenter 7 with ADFS

With the release of vCenter 7 you can now integrate it with Microsof Active Directory Federation Services (ADFS)

See the following blog article for an overview:
https://blogs.vmware.com/vsphere/2020/03/vsphere-7-identity-federation.html

See the following configuration articles for a setup overview:
https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.authentication.doc/GUID-C5E998B2-1148-46DC-990E-A5DB71F93351.html
https://kb.vmware.com/s/article/78029

With this information I’ve configured my lab environment to a working SAML based login with a few minor issues.

I had my ADFS setup load balanced through a content switching setup for external access. This is working great for my simple office 365 integration point but not so much if you’re trying to do more.

Like stated in the following article don’t terminate the SSL connection:
https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/overview/ad-fs-faq

The issue I came across was that vCenter was failing with the validation of the certificate, at first I thought the missing root/intermediates was the cause of this but this was not the case. Even after uploading my internal root/intermediate and the external certificates root/intermediate the SSL validation check would fail. The chain was valid in every case though.

The resolution was to make my internal DNS entry through a SSL-BRIDGE setup to my ADFS server and afterwards I could finish the configuration part without issues.

Now when presented with vCenter logon page if you put in an account from the federated domain it will redirect you accordingly to the ADFS logon point.

Hope it helps!

Notes from the lab: Migrating Windows vCenter to VCSA 7

In my lab environment I was running Windows vCenter 6.7 and with the release of vCenter 7 a migration is needed because there is no Windows vCenter anymore.

The following articles will give you enough information on how the process works especially the how-to from Vladan Seget:
https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.upgrade.doc/GUID-9A117817-B78D-4BBE-A957-982C734F7C5F.html
https://www.starwindsoftware.com/blog/how-to-migrate-vmware-vcenter-from-windows-to-vcsa-6-7-update-1

Basically the process is the same for vCenter 7 with in my case one issue.

At first try my migration failed at the stage when the migration assistant is shutting down the Windows vCenter and the VCSA 7 is being brought up with the original IP, hence resulting in a conflict and the upgrade is in a broken state. I followed the process and saw that especially Windows Server 2016 has the annoyance to delay the shutdown for minutes, this is a known issue and happens from time to time and to my knowledge has to do when updates were installed (even after multiple reboots).

So the migration assistant is doing its job and completes the migration and is shutting down the VM, except in my case. Resolution for this is when the script is completed and windows says it’s still shutting down etc. do a hard power off and after that the migration is moving further as expected.

In summary:
1. Make sure Windows is up to date with all the updates and there are none outstanding
2. Make sure vCenter is up to date, in my case it was the latest update of 6.7
3. Make a snapshot before you start 😊 saves a lot of hassle later on
4. Force kill the Windows vCenter when it’s shutting down after the migration assistant completes

After this the migration in my case completed flawlessly.

Hope it helps!

Notes from the field: Configuring SentinelOne SSO with VMware Workspace ONE Access

SentinelOne’s configuration can be achieved after you have a valid account and support login. Afterwards its pretty easy to configure the SSO part.

In the cloud console of SentinelOne go to Settings>>Integrations>>SSO

Configure the following items for SSO usage:

IDP Redirect URL:

https://workspaceoneaccessurl:443/SAAS/API/1.0/GET/apps/launch/app/uniqueapplicationid

IssuerID:

https://workspaceoneaccessurl/SAAS/API/1.0/GET/metadata/idp.xml

Configure the rest of the items at your own requirements but don’t forget to upload the IDP public certificate of Workspace ONE Access.

Make copies of the Assertion Consumer Service URL and SP Entity ID to use in Workspace ONE Access.

For the configuration part of Workspace ONE Access just add a new manual SAML 2.0 application and provide the following information:

Single Sign On URL: This is the Assertion Consumer Service URL of SentinelOne

Recipient URL: This is the Assertion Consumer Service URL of SentinelOne

Application ID: this is the SP Entity ID URL of SentinelOne

Username Format: Unspecified

Username Value: ${user.email}

Don’t forget you only get an application id in Workspace ONE Access if you’ve created an application. So first up create the application with bogus input to get your id and update it accordingly.

Notes from the field: Configuring Autotask PSA with VMware Workspace ONE Access

Autotask PSA SSO configuration can be found at the following url: https://ww13.autotask.net/help/Content/AdminSetup/1FeaturesSettings/ResourcesUsers/Security/SSSO_OIDC.htm

For the configuration part of Workspace ONE Access SSO you can see the available API at this url: https://code.vmware.com/apis/57/idm#/

The problem is that Autotask PSA SSO doesn’t work/supports the setup of VMware Workspace ONE Access. I worked around this issue by having a federated setup to our Office 365 tenant and adding the Autotask application there and ultimately publishing the application as a custom application link and still provide the requested SSO.

Add a Web Application Link in Workspace ONE Access and provide the following as your target url:

https://myapps.microsoft.com/o365tenant/signin/applicationname/uniqueguidoftheapplication

Notes from the field: Configuring OpsGenie (without Atlassian Access) with VMware Workspace ONE Access

OpsGenie can use SAML SSO without the use of Atlassian Access, see the following url: https://docs.opsgenie.com/docs/single-sign-on-with-opsgenie

For the configuration part of Workspace ONE Access just add a new manual SAML 2.0 application and provide the following information according to above article:

  • Single Sign On URL https://app.opsgenie.com/auth/saml?id=”uniquesamlidprovided
  • Recipient URL https://app.opsgenie.com/auth/saml?id=”uniquesamlidprovided
  • Application ID https://app.opsgenie.com/auth/saml?id=”uniqesamlidprovided
  • Username Format = Unspecified

Username Value = ${user.email}

Notes from the field: Configuring Atlassian Access with Workspace ONE Access

Atlassian Access is the SSO portal being used for SSO access across Jira, Confluence etc. for the configuration part see the following url: https://confluence.atlassian.com/cloud/saml-single-sign-on-943953302.html

For the configuration part of Workspace ONE Access just add a new manual SAML 2.0 application and provide the following information according to above article:

  • Single Sign On URL https://auth.atlassian.com/login/callback?connection=saml”uniquesamlidprovided
  • Recipient URL https://auth.atlassian.com/login/callback?connection=saml”uniquesamlidprovided
  • Application ID https://auth.atlassian.com/saml/”uniqesamlidprovided
  • Username Format = Unspecified
  • Username Value = ${user.email}
  • Relay State URL = https://id.atlassian.com/login

Add the custom attribute mappings for firstname, lastname and userprincipalname.

Notes from the field: vCloud usage meter doesn’t meter NSX

A while back I had an support case with VMware support regarding NSX integration and that it wasn’t getting metered by vCloud Usage Meter in a customer deployment. Turns out that Usage meter looks for a Global Transport Zone before the discovery of a Universal Transport Zone and metering can occur. So if you are in a setup that only has Universal Global Transport Zones it is expected behavior to see no NSX monitoring hits being satisfied in Usage meter. This can be resolved by adding a Global Transport Zone as a fictive addition so that it will meter your setup.

Notes from the field: Windows 2019 Storage Replica lock-up on VMware

On one of my latest projects consisting of a new Windows Server 2019 setup on VMware and making use of Storage Replica in a server to server setup for replicating home drives and profiles I came across a random lock-up of the VM and by that inaccessible shares.

The setup was all working until the failover part. It seems there is an delay of some sort and the failover isn’t instant or takes a while to be active with the server being unresponsive and disconnecting any form of management to the VM in question(VM tools are not responding as well and console login will not work in this failover time). I’ve tried the actions again of doing a storage replica failover and I got an BSOD on the VM stating: HAL INITIALIZATION FAILED I’ve tried all of this in a separate test setup and had this working without any problems on Server 2016, and Server 2019. Only this time it gave me this strange behavior. The difference in my own setup is HW level 14 and this new one had HW level 15 and the hosts are 6.7 13981272 build and my own setup is 6.7 14320388 build (older builds have also worked fine for me)

After some troubleshooting and providing the BSOD dump findings to VMware GSS support it became clear that version 10341 of VMware tools was the troublemaker. The solution was to upgrade to the latest 10346 VMware tools. The vmm2core tool provided me with the means of creating a dump file with the VM in question.

Notes from the field: Hyper-V to VMware migrated VM’s cannot install VMware Tools

One of my last projects I needed to convert Hyper-V VM’s to VMware, this all went fine with the offline capability of vcenter converter and the migration succeeded. Only after trying to install the VMware tools this would hang on starting the VGauth services and several other dependencies. For reference the VM’s in question are a mixture of 2008R2 / 2012R2. After some troubleshooting and searching the knowledgebase I stumbled across this article: https://kb.vmware.com/s/article/55798

So for the project I didn’t had any ok to patch the servers that was out of scope for this one, the mitigation was to install older VMware tools (10.2.5 to be exact) afterwards the tools installed fine.

On a side note when finalizing the converted VM don’t forget to delete the hidden older hyper-v network adapter, this can still provide conflicts if not removed.