Hey Andrew -
The technique you're using is the path of least resistance, but maybe not the best approach since ALL users see the same data regardless of who they are. Many admins prefer that each user see "only their stuff" in SQL Server.
Your users should be able to publish / refresh / view if they embed their standard SQL Server credentials when they publish. It's not unusual for someone to forget to choose "embedded password" when they publish, at which point they'll be prompted for their UID/PWD on execution. Refresh jobs won't work either.
You can also use two flavors of impersonation - one which uses "smoke and mirrors" to temporarily switch the connection to SQL Server over to a different user context at runtime, and another which uses "real" impersonation via Kerberos delegation.
I've never seen a reboot necessary in order to allow access to your database. Perhaps the account in question was already logged into the SQL Server from Tableau Server WHILE you changed permissions? I remember "in the old days" of AD, it was sometimes necessary to logoff/logon in order to get a new permissions token, so maybe this is what is happening.
Thanks so much for all the details here, Russell - extremely helpful!
I suspect you are correct about the account being logged into SQL Server with the existing permissions, and required a log on/off.
More interesting are your points re: the SQL Server impersonation/connection options, as I've always found them slightly confusing. Well said!
One more poke at this strategy, Russell Christopher: if we manage access to all our (SQL Server) databases via Active Directory...how can someone embed their credentials...? Isn't it always managed based on the user?
And carrying on from that, if a user built a workbook and schedule an extract refresh, won't it fail, since the Server (as a user) doesn't have the proper AD creds to be given access to that schema/database?