ZPA App SSO Problem

I am having some trouble with AzureAD joined machines and SSO on the ZPA Client Connector App.

We have consultants that I have given access with user accounts on our domain @ourdomain.com. Their computers are AzureAD joined machines with their domain @consultant.com. When they log into the Client Connector App, they put in the user account @ourdomain.com and select the correct cloud. Normally this should send them to a Microsoft Sign on page where they can enter their account (@ourdomain.com) and password. However, since their machines are AzureAD Joined the computer is automatically passing their @consultant.com address to Microsoft login. This ends up erroring out since of course that account does not have rights nor is in my Microsoft tenant. How can I prevent the application from automatically sending @consultant.com and making it prompt for username/passsword?

I have found this (How to prevent browser SSO for AAD joined machines?) which describes the same situation, but I have not been able to find a solution.

Patrick - it appears to me that the only solution in the current configuration is to disable SSO for everyone according to the instructions in the link you included in your post, unless there is a way to enable/disable SSO for a particular group, in which case you can disable only for the contractor group. You’ll have to consult Microsoft Support to see if that is an option, otherwise, I’m afraid you’re stuck with disabling SSO for everyone, which is likely not the best option but it would resolve the issue for the contractor.

Another option to consider is to coordinate with your consultant to add their AzureAD IdP to your ZPA configuration as a second IdP (@consultant.com). Of course, the consultant organization would have to provide the XML file or their AzureAD domain for you to configure this in your ZPA instance. This approach allows the consultant organization to use their own credentials to log into ZPA, and you could maintain what resources they had access to via access policy rules by specifying the @consultant.com domain and in coordination with the consultant organization, you could also apply a group name if they wanted to limit access to a particular group from their organization that had ZPA access.

Other than the first two options, the only other option is for the consultant to completely log out of their domain and log into their workstation with the @ourdomain.com credentials. This will also likely require that you configure machine tunnels so they had access to your IdP via ZPA in order to do that, and then SSO into ZPA. Again, not the most transparent option, but I just wanted to cover every option for your consideration.

There is no option, as far as I know, that would selectively disable SSO from the ZPA IdP or the ZCC configuration.

Yeah, I am not in love with this answer. Lets also look at this from another perspective and another issue I found.

If I have an AzureAD joined machine and I am logged in as User1 to windows. User1 logs into ZPA and does not get prompted, but just automatically logged in as User1. If that user1 logs out of ZPA and Admin1 enters their account, picks the cloud ZPA will log in. It will show as logged in as Admin1, but all of the rights are for User1 and the logs in ZScaler will show User1 since the application automatically used the SSO credentials of User1. This is not now things should work.

If you didn’t love that last answer, you’re definitely going to hate this one! :grin:
So here’s the scoop, From your description of the issues it sounds like we are talking Windows workstations here and you have Windows Authentication (IWA) fully enabled, and you are implementing SSO with the ZPA app on your IdP.

If that is the case, you are not likely to find a satisfactory answer that doesn’t require a change to one of those three things - full stop. I found this discussion online that does a great job of explaining in the first few paragraphs the second issue you mentioned with a complete logout not occurring becase IWA is not using, or forcing credentials on login because it’s using the SAML token you’ve already established (same IdP and domain being used for the two logins is also my assumption here since you just mentioned “user1” and “Admin1”). Feel free to substitute ZCC (Zscaler Client Connector) in for “EFT” in this article.

The key point about IWA in this article is:
The downside to IWA is that in skipping the normal login page, the user misses out on a few of the functions accessed from that page, such as providing alternate credentials or choosing whether to load the Web Transfer Client (WTC), though an administrator may still disable WTC access for an individual user or entire Settings Template if necessary. Additionally, the user must close their browser to end the session rather than using a logout button. In an environment where SSO is a requirement, these functions may not be important or even desired.