Configuring Client Connector deployment with automated authentication with Okta

ymartin · October 2, 2020, 5:16pm

Hello everyone,

One of my clients would like to deploy Client Connector with fully automated SSO authentication while using OKTA as the IDP. I m not sure if this is possible. From the deployment guide we have the USERDOMAIN variable that says:

This install option allows users to skip the app enrollment page. (https://help.zscaler.com/z-app/customizing-zscaler-app-install-options-msi#ud2image) If SSO is enabled for your organization, users are taken right to your organization’s SSO login page. If you’ve integrated SSO with the app (i.e., using a mechanism like Integrated Windows Authentication (IWA)), users can also skip the SSO login page and are automatically enrolled with Zscaler service and logged in.

I ve found some docs explaining it is possible with ADFS or Azure but nothing really regarding Okta. Has anyone already done this config?

Thanks

mryan · October 5, 2020, 12:22pm

This is entirely possible with Okta.

The userdomain & cloudname options for ZCC triggers the automatic redirect to the IDP. It’s then an IDP function to perform the transparent SSO. The Transparent SSO function on Okta can be achieved in two ways - Agent based or DesktopSSO.

Agent Based requires an IWA install in an IIS server, so it’s the IIS server which performs the authentication and returns the user detail to Okta to complete the SAML authenticaiton.
DesktopSSO performs the Kerberos authentication directly against Okta cloud - requiring a SPN and trusted auth to Okta.
These are both documented in Okta’s help portal. In both cases, the client needs access to the KDC to retrieve the Kerberos ticket to present to the IIS Server or Okta cloud, for the transparent SSO to occur.

This video https://www.youtube.com/watch?v=CtRIjdMDchc shows the IIS implementation, and this video https://www.youtube.com/watch?v=OYR7N6bizO0 shows the desktop SSO (and how failback to FORMS authentcation works with ZPA).

ymartin · October 5, 2020, 12:31pm

Hello Mark,

This is great material!

One question, I think I understand this would work only for users when they are in known location since I see the Okta must have the gateway IPs listed, is my assumption correct? Or this could also work for road warriors?

Yanick Martin
Technical Account Manager
Zscaler, Inc.
1.408.532.5944 Ext 1483

|

|

|

|

|

| - | - | - | - |

mryan · October 5, 2020, 12:54pm

Transparent SSO would only work with Kerberos authentication, which requires a connection to the KDC. So - a known location is implied.
Okta has a concept of known location - either a fixed IP, or a fixed IP+XFF. So it’ll work through Zscaler, or bypassing Zscaler from a known location - but it must be a location because of the requirement on the KDC.

ymartin · October 5, 2020, 1:13pm

Thanks Mark,

I just found this that I think could help for remote:

https://help.okta.com/en/prod/Content/Topics/Directory/dsso-faq.htm

I guess that from our side we provide the info regarding the Z app customization install and I could provide the docs I find in Okta but they would need their Okta guy to do the bulk of this config since it s a bit out of Zscaler scope right?

Yanick Martin
Technical Account Manager
Zscaler, Inc.
1.408.532.5944 Ext 1483

|

|

|

|

|

| - | - | - | - |

mryan · October 5, 2020, 1:31pm

Yes. Those points about DesktopSSO and VPN from Okta are specifically that the Kerberos ticket becomes unavailable. However - it will fall back to FORMs based authentication which is fine.
I would sell them on user experience. Setting up the VPN would require MFA, in order to get ZCC deployed transparently. OR they could avoid VPN, for MFA to get ZCC deployed - and then use ZPA.

Regards

owio · January 19, 2021, 5:13pm

For those it may help - We are running agentless DSSO from Okta and ZCC, and ran into some gotchas. (agentless is now the recommended deployment)

Go here for an overview on agentless DSSO - https://help.okta.com/en/prod/Content/Topics/Directory/ad-dsso-about-workflow.htm

Be wary of routing rules in okta they are not “firewall like” they will choose the most specific route by the definition in the rules, not by order.
IE has URL length limitation of 2,083 characters. Currently, Agentless DSSO will do a fail over to okta, and the URL max length is reached. This can cause a problem for first time authentication with ZCC. We got around this by creating a specific routing policy for all Zscaler applications to use okta auth.