Once you've set up Kerberos, after you input your server name you should be automatically authenticated with no need to sign in. On my Tableau Server using Kerberos, when I open Tableau Desktop I am already signed in. Have you tried clearing your saved Server sign-ins?
I did try clearing the saved Server sign-ins but it still did not work (Under "Settings & Performance" -> "Clear Saved Server Sign-ins"). I am curious if you are aware of what specific permissions a user account (that is opening up in Desktop) might need that not having would prevent Desktop SSO?
My Run As Server user seems to have no issue connecting to the SQL Servers that are configured for Kerberos and passing along user credentials appropriately - My current thought is maybe the regular Windows users don't have the right permissions to query AD - but I'd like to know what those permissions need to be before I go back to my AD team
Logging in via Kerberos to Tableau Server is authentication and having credentials passed to a SQL Server is delegation - they are set up differently under the hood. Which one are your non-Admin users having issues with? (I assumed it was the first one) You may want to open a case with Support and include your Desktop and Server logs.
You are correct in that the issue is with authentication not delegation. I was trying to illustrate that the delegation but not authentication seems to be working and I'm not sure what piece I would be missing (permissions or otherwise) to get the authentication working.
Yes I was going to open up a ticket with support but wanted to see if the community had any answers for me first.
Was this resolved? We are planning to implement Kerberos soon.
1 of 1 people found this helpful
The issue for us appeared to sit with the autogenerated script and the fact that we had a Cname alias setup for our Tableau Server.
Our solution was to edit the generated script that Tableau Server pulls for you.
We added in creating two new SPNs - the same as the originals but for the alias. So like
setspn -s HTTP/server DOMAIN\Account
setspn -s HTTP/server.domain.com DOMAIN\Account
setspn -s HTTP/alias DOMAIN\Account
setspn -s HTTP/alias.domain.com DOMAIN\Account
We then create two keytab files. First one with the original server name then the second with the alias. It's odd that this works because my understanding of ktpass is that each usage of ktpass overwrites the previous - however the only way to get it working was to run these commands in this precise order in our AD environment
Replied to original post with our solution