Notes from the field: Citrix Cloud Connector we’re having trouble signing you in

Recently I’ve encountered an issue after installing the Citrix Cloud Connector on new Windows Server 2022 machines. The configuration on my first machine went just fine until the sign-in, here my interest got peeked because I still have IE11 on my box, strange that it uses the sign-in for Citrix Cloud.

Well let’s test the second one and remove IE11 from the box and see what happens:

Oh boy, so we are depending on IE11. Installed it again and voila:

Hope it helps!

UPDATE:

After providing feedback at Citrix Cloud Updates | Cloud Connector installer support for the system default browser and getting the reply that there is an update out I’ve tested the new version and that one works as expected without IE11.

Notes from the lab: Migrating Azure AD Connect and then we cannot sync

This is a quick blog post regarding my own Azure AD Connect migration and a nasty error after trying to connect again for an initial connection and synchronisation.

A little insight in my environment, I already had the latest version running of Azure AD Connect namely 2.1.16.0 on my Windows Server 2019. See Azure AD Connect: Version release history – Microsoft Entra | Microsoft Docs

So, I spun up a new Windows Server 2022 and installed the Azure AD Connect role on it, imported my configuration file like described here How to import and export Azure AD Connect configuration settings – Microsoft Entra | Microsoft Docs

And then I got below error when trying to configure my new server:

The error put me onto the blog of Azure AD Connect – Unable to validate credentials due to an unexpected error. – .matrixpost.net but the issue mentioned wasn’t my issue, my GA account doesn’t have any expiry set and the logon was working everywhere else. The point to note is that I have only modern authentication enabled and MFA with number matching enabled in my tenant. So afterwards running the installation in context with /InteractiveAuth did resolve the issue. Afterwards closing, rebooting etc. never gave the error again and al logins are still providing the popup of modern and MFA prompt.

Strange thing is that I’ve had this enabled for a very long time now. Seems that in the latest versions perhaps there are some changes regarding the modern auth popup.

Hope it helps!

Notes from the field: VMware Horizon instant clone breaks with Kerberos armoring

On my current customer project we’ve encountered a strange issue when some stricter security policies were implemented. Kerberos armoring was enabled which effectively broke the instant clone process for Windows 10 1809/1909 releases but not for 2009 or 21H2.

It all started with a ticket that the image update process in Horizon would error out and fail constantly on the mentioned images. On the newer builds no problem at all. At first we thought it was an Microsoft update of some sorts but after some troubleshooting with colleagues Wesley Kieffer and JP Ruitenbeek it turned out to be new hardening items which got turned on.

When clearing the before setting in the image and then sealing the older images would update just fine. After reproducing the entire setup in my own lab I encountered the same issue as well. Opened up a VMware support case which still is being worked at.

The setup being used is VMware Horizon 7.13.1

The following article also describes how you can troubleshoot the internal VM which is being used for the cloning process: Troubleshooting Instant Clones in the Internal VM Debug Mode

And for some more information regarding Kerberos armoring see What’s New in Kerberos Authentication | Microsoft Docs and Compound Authentication and Active Directory Domain Services claims in Active Directory Federation Services | Microsoft Docs

Hope it helps!

UPDATE:

After a long wait from VMware support and pitching in some R&D time this resulted in an it’s going to be a feature update. Currently VMware Horizon code base isn’t aware of Kerberos armoring. It’s not just version 7.x but also 8.x which is affected. The workaround above is the solution until instant clone technology will get an update in the nearby future. This could take up to about six months. I’ll post back the update when it’s final.

Notes from the lab: Citrix ShareFile and VMware Access SSO

When configuring Citrix ShareFile for an SSO experience with your Microsoft Active Directory setup we have the following guides to use it from Citrix. See How to Configure Single Sign-On (SSO) for ShareFile (citrix.com)

Well I’m having my setup with another Identity Provider in my own lab and still want to achieve an managed SSO setup from my end. To get this to work I checked the setup from an existing integration setup like Microsoft ADFS and reverse engineered it to VMware Access instead.

The following will give you an working SSO setup with VMware Access as your Identity Provider for Citrix ShareFile:

First configure the basic settings of Citrix ShareFile with your URL’s

https://tenant-fqdn-sharefile/saml

https://tenant-fqdn-vmware

Copy paste the certificate information from your VMware Access tenant

Create the application in VMware Access

Use the explicit logon URL of your application in VMware Access in Citrix ShareFile

Use the https://tenant-fqdn-sharefile/saml/acs in VMware Access for consumption

After this make sure that an user from your corporate identity is synchronized in Citrix ShareFile and both of them match so that SSO can be achieved. Afterwards you can nicely click the icon in VMware Access from IDP point of view:

Or you can login via the SP side from the Citrix ShareFile browser landing page:

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 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

Notes from the lab: Microsoft ADFS and VMware UAG

You don’t see many configuration articles around ADFS and UAG and that’s why I would like to share my setup.

First things first, I’m expecting that there is an working Horizon environment with True SSO enabled for access to the desktop. And a working ADFS environment to add a new application to test with.

My setup:
1 x ADFS for internal usage
1 x WAP for external usage
1 x UAG v3.10 – dedicated for ADFS with its own URL
1 x UAG v3.10 – dedicated for WS1 with its own URL
2 x Horizon Connection Servers
2 x Horizon Enrollment Servers

The following articles helped me in setting this up:
https://docs.vmware.com/en/Unified-Access-Gateway/3.10/com.vmware.uag-310-deploy-config.doc/GUID-E4C8B88F-C771-4829-ABBE-12F7FBF517C3.html
https://communities.vmware.com/thread/625006
https://thevirtualhorizon.com/2019/12/14/integrating-microsoft-azure-mfa-with-vmware-unified-access-gateway-3-8/
https://techzone.vmware.com/enabling-saml-20-authentication-horizon-unified-access-gateway-and-okta-vmware-horizon-operational

Setting this up starts with downloading the “/FederationMetadata/2007-06/FederationMetadata.xml” file of your ADFS setup and saving this on your configuration machine

Now go to the UAG admin appliance on the management port https://xxx:9443 and scroll down to the Identity Bridging Settings, select the gear icon of “Upload Identity Provider Metadata” and in the next screen press on the select link where you can upload the metadata file of ADFS.
Now go to the Horizon settings on the top and select the gearbox and in the next screen select more to show the auth methods to be used. For True SSO select SAML. Next select the uploaded Identity Provider which is now visible and click on the “Download SAML service provider metadata”. Save everything and close the admin portal.

Next in ADFS configure a new “Relying Party Trust” claims aware application and import the downloaded SAML service provider metadata file from UAG
When completed edit the “Claim issuance policy” for the application and create a rule with attribute store active directory selected and provide the input for “User-Principal-Name” with “Name ID” as outgoing claim type.
Edit the application and select encryption and click on remove the encryption certificate. This enabled will not give an valid SAML assertion or logon.

This is all that is needed in ADFS, the application can be assigned anyway you want. The last steps are in Horizon itself.

Go to the admin panel of the connection server and configure an SAML 2.0 Authenticator, create one and name it accordingly (don’t forget to enable True SSO on this connector) and make sure it is an static type. Copy paste the federationmetadata.xml content into the SAML Metadata screen and click OK.

Set the delegation of authentication to VMware Horizon (SAML 2.0 Authenticator) to optional or required. The latter prohibits passthrough authentication straight from the servers itself and will always require a SAML assertion.

This is it, afterwards you should see an ADFS logon possible with SSO in place.

Some extra information for any use case with ADFS/Workspace ONE combined then this procedure will not help. For Workspace ONE integration the only working and supported way is to configure VMware Horizon with VMware Access. I’ve tried it configured with VMware Access and the same UAG and you will get an access denied because the SAML configuration is in place at the Horizon Connection Servers instead of the UAG. ADFS can also be integrated with VMware Access and the SSO can be achieved in that way which is a route you would take when using Workspace ONE.

Hope it helps!

Notes from the field: Citrix FAS SSO not working with invalid CRL

Recently I got contacted by a customer who had problems performing an SSO to a newly build desktop environment.

The setup a greenfield resource domain and forest trust from an existing tenant with a two way trust. Basically everything was correct but the logon from the users would always get terminated at the desktop with invalid credentials.

After a short discussion and remote session and the error messages in the logs with an invalid CRL it was clear that was the issue. Troubleshooted the AIA/CRL locations and basically the defaults where still in play, explained that default push in AD isn’t a recommended approach. If any client can’t access the CRL it will give a deny on further actions (and other clients that don’t understand AD or are joined to AD won’t work as well).

Below screenshots depict a default ADCS installation which in turn pushes out the default legacy templates and also the CRL to LDAP which I see much too often at customers:

Resolution for the CRL error was to revoke all the certificates for usage with FAS, change the CRL/AIA location to a routable and reachable HTTP listener instead of LDAP (preferably an HA setup with a load-balancer in front of it) and push out the new CRL. Afterwards logons where using the SSO capabilities.

Hope it helps!

Notes from the lab: Windows firewall profile not correct after reboot

Just thought of leaving a quick win here. Did you ever had the firewall profile of Windows not correctly mapped after reboots etc.?

This is because after a reboot the Domain Controllers put it in e.g. public profile and this will get passed on to other servers as well. This will effect in not being able to manage machines because of firewall blocks etc.

Solution is to restart the “Network Location Awareness” service and dependent “Network List Service”.
This will reset it to domain profile and after reboots of the other machines which have this it will be updated to domain profile as well. Or restart the service as above that will also do the trick.

Hope it helps!

UPDATE:

Well after migrating to Windows Server 2022 in my homelab the above will not work anymore. Appears the restarting of the NLA service has changed. After some digging around came across the following: Domain Controller thinks its on a Public Network

My working scenario is putting it a delayed start and adding domain services dependency on the NLA service with DNS and NTDS.