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 lab: Citrix ADC Native Push OTP not working

I’ve updated my lab environment with Citrix Gateway push OTP support and had some trouble in configuring the Citrix SSO app on my iPhone. For some reason it couldn’t setup the gateway connection and it wasn’t reachable. (Well that was my bad in checking all my devices but I’ll get to that)

Before the push OTP change I’ve worked with the authenticator app behavior and put in the code myself and this worked fine. The change to push OTP isn’t too difficult, and the following articles give you plenty of how-to information:
https://docs.citrix.com/en-us/citrix-gateway/13/push-notification-otp.html
https://docs.citrix.com/en-us/citrix-adc/13/aaa-tm/native-otp-authentication/otp-encryption-tool.html
https://www.carlstalhood.com/native-one-time-passwords-otp-citrix-gateway-13/

Keep in mind that if you have setup a previous OTP setup like I had the encryption part needs to be migrated otherwise it just won’t work. Registration cannot complete if you just flip it on and be done with it. Follow the migration part or just start fresh with OTP encryption enabled by default.

After I corrected the encryption problem I still could not register through the Citrix SSO app for push OTP functionality. It kept giving me the error gateway not reachable, fully checked everything in my environment was up and working. It kept me puzzling that it works fine with the previous authenticator method and if I re-registered it that way it would work (without the push of course because that functionality sits in the Citrix SSO app)

Finally after more troubleshooting I found the problem… because I’ve upgraded and integrated ADFS 2019 in my environment my content switching server and gateway etc. also needed to be SNI aware. Remember that everything worked fine on my Windows devices (even the Citrix SSO VPN functionality which I use quite often) but just not on my iPhone. Turning off SNI was the solution, it seems that the Citrix SSO app on iOS doesn’t support SNI.

Hope it helps!

Notes from the field: Cannot access Citrix ADC or create HA set

Quite recently I was at a customer where they had an SDX setup with single instances and needed to be upgraded and converted to an HA setup.

Well easy does it I created the instances on the second SDX and started creating HA sets. Numerous went fine and then one started giving errors. Could not propagate from the primary and after checking SSH/SCP access this would fail as well. I logged in through the console of SDX/SVM and saw that the sshd daemon wasn’t starting anymore. (On a side note all of the original SDX instances were upgraded in regard to the exploit of last December)

After some troubleshooting I came across the following discussion article: https://discussions.citrix.com/topic/405628-unable-to-connect-to-adc-nsip-version-121-and-130-using-sshsftp

The discussion referred to an support article regarding false positives and an SSH vulnerability:
https://support.citrix.com/article/CTX209398

After checking the sshd_config file and commenting out the following:
#option UsePrivilegeSeparation
#MACs hmac-sha1,hmac-ripemd160

The sshd daemon started again and the HA propagation and synchronisation started instantly. I’ve had this on several other instances as well and they all needed the above commenting out of the lines.

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.