The Hybrid Join Incident: Recovering the Lost PRT

Single Sign-On in modern environments can be a beautiful thing, until it isn’t. You’ve federated Entra ID to Omnissa Access, implemented Hybrid Join, and everything works perfectly when users log in with their username and password.

But then you try it externally. TrueSSO is in place to make VDI logins seamless, certificates replace passwords and suddenly the PRT never shows up. Microsoft apps (Teams v2 being the most noticeable) rely increasingly on the PRT for full Single Sign-On, and without it, seamless authentication breaks.

In this article, we’ll walk through why this happens, and the exact steps you need to restore full Single Sign-On. Including the PRT that mysteriously went missing.

The Problem

So, you federated Entra ID to Omnissa Access and implemented Hybrid Join because that’s the way to get full SSON for Teams v2. Teams pulls the username from the PRT, so without Hybrid Join there’s no seamless sign-on.

With a normal username/password login everything works as expected. A quick dsregcmd /status confirms it:

• AzureAdPrt: YES

• Credential Type: Password

  
  

  

  
  

All good.

But then your external users come into play.

Externally, we have the classic setup: UAGs in passthrough mode to Connection Servers in Workspace ONE mode with Omnissa Access.

To get single sign-on to the VDI, you also implemented TrueSSO.

And that’s where things break.

Because users log in with a TrueSSO certificate (issued by the Enrollment Server) instead of a password, the VDI never receives a PRT. Without that PRT, the user doesn’t get full SSON in Teams.

dsregcmd /status then shows:

• AzureAdPrt: NO

• HTTP error: 0x800484c0

• HTTP status: 401

We eventually figured out why: during login, the VDI attempts to authenticate with its TrueSSO certificate against the WS-Fed mixed endpoint in Omnissa Access. But that endpoint doesn’t exist in Access at all, it only exists in ADFS. Going back to ADFS is not an option.

The Sollution

I had the opportunity to work directly with Omnissa on this one.

Omnissa implemented the correct WS-Fed endpoint in Omnissa Access.

It didn’t work immediately, several calls and emails later, but the good news: the working solution is now live and available for all SaaS Access tenants.

What you need to do

The new, supported endpoint is already active on the backend in Omnissa Access.

You only need to make a few adjustments to the Microsoft 365 WS-Fed application, or you will get a 501 error.

Step 1: Export the CA certificate(s)

You need the certificate of the Certificate Authority that issues the TrueSSO certificates.

In most environments, the CA role lives directly on the Enrollment Server with only the necessary templates enabled. It can also be a separate Sub CA.

Export the Sub CA's certificate in Base64 format. Do not export the private key. You need the certificates from all CAs that issue TrueSSO certificates, typically both Enrollment Servers if they each run a CA role.

Step 2: Update the WS-Fed application in Omnissa Access

• In Omnissa Access, edit the WS-Fed web application.

  

• In Configuration, scroll down to Advanced Properties.

  

• Under Certificates for Validation, upload each exported CA certificate.

  

• Save the application.

  
  

You should now see the certificates listed under the validation section.

That’s all you need to configure!

The result

Run dsregcmd /status again and you’ll now see a PRT issued even with TrueSSO logins.

In Omnissa Access activity logs you’ll see the certificate-based flow completing successfully as well.

Happy single sign-on, everyone!

Special thanks to Gourav Mukherjee (who I started to call the G-man) and Dennis Sigmond, both from Omnissa for working with me on this issue. the right man in the wrong right place can make all the difference in the world.