Otdfbt

I am implementing Okta as a single-sign on provider in an enterprise environment of about 90 users. One of Okta's features is Desktop Single Sign On - the ability for users to be authenticated with Okta simply by virtue of having logged into their machine and thereby authenticating with the domain. The user simply opens a browser, goes to the company's Okta tenant URL, and they are logged in.

Without this feature, the user would be prompted for their credentials when loading up the Okta tenant URL.

DSSO is accomplished by the browser picking up a Kerberos ticket from the OS that itself is generated when the user authenticates with the Active Directory domain. The browser then hands this ticket back to the server, and the server communicates with the Okta cloud to authenticate the user.

The authentication flow in our environment goes like this:

1. User logs into their machine. A kerberos ticket is generated upon login and authentication with the domain.


2. User opens their browser, and either tries to access an Okta-protected/integrated app, or goes directly to their Okta portal.


3. User is redirected by Okta to our load balancer, which terminates the request at the IWA web app on the web server


4. IWA web app challenges the browser for authentication


5. Browser grabs the Kerberos ticket from the OS and hands it to the load balancer, which passes it to the IWA web app


6. IWA app validates the ticket and fetches user profile from AD


7. IWA app generates and digitally signs an SSO token and sends it to the browser


8. Browser returns the tokent to Okta via HTML form POST


9. Okta completes the sign-in request and returns the user to the app with an SSO token

The process is failing on step 5, and I know this is the case because:

1. Chrome prompts the user for NTLM credentials when the Okta tenant URL is requested


2. This prompt happens before the IWA web app and the browser is configured properly for DSSO (per the documentation I linked at the beginning)


3. The prompt does not happen on Chrome, Firefox, and Internet Explorer on Windows (DSSO works on Windows with Chrome, Firefox, and IE)


4. This prompt does not happen in Safari on macOS X, but does happen with Chrome and Firefox in OS X

What I cannot figure out is why Chrome and Firefox are not picking up the Kerberos ticket from the OS in macOS X, but the same browsers in Windows are picking up the ticket without a hitch.

Steps I've tried:

1. 
   

   Setting Chrome's whitelist settings with the following terminal
   commands (recommended by Okta's documentation):

   
   
   

   $ defaults write com.google.Chrome AuthServerWhitelist
   "*.example.com"

   
   
   

   $ defaults write com.google.Chrome AuthNegotiateDelegateWhitelist
   "*.example.com"

   
   


2. Setting Chrome's whitelist settings with SimpleMDM configuration push (this method actually succeeded in pushing the settings to Chrome - proven by going to chrome://policy and seeing the settings)


3. Uninstalling anti-virus


4. Adding every possible FQDN to the list of servers whitelisted in step 2 - first just the servers we have whitelisted in Windows (because Windows actually works), and then a list of Okta servers recommended by Okta support

I still cannot get this feature to work and I am now trying to figure out if there's a way to troubleshoot the process Chrome uses to pickup the Kerberos ticket from the OS. Some kind of debugger for Chrome's Kerberos ticket pickup mechanism would be great, but I imagine no such thing is available.