That is a strange behavior. Please clarify the exact steps you're taking to publish, and when exactly you get taken to the web portal.
I.E In Tableau Desktop > Server > Publish workbook > etc....
do you also use the F5 within your non-prod environment? You may need to configure the reverse proxy settings. This seems vaguely familiar as we have a similar setup and doing the following helped.
tabadmin set gateway.public.host "DNS entry" that belongs to F5 and forwards traffic to TS
tabadmin set gateway.trusted "IP address of F5"
Yes the non-production environments are configured the same as production with a proxy and F5. I have compared the values for the gateway.public.host, gateway. Trusted and gateway.trusted_hosts and they have the same corresponding values in the non-prod and production environments. The public.host is referencing the dns name, the gateway.trusted is referencing the ip of the proxy (not the f5). But as I mentioned this is the same in the non prod and prod and there is no issue publishing from desktop to the non prod server, so I’m not sure if it is worth adding the ip of the F5 since this is working without it in non-prod.
One additional finding: I recently set the following wgserver.authentication.desktop_nosaml to true, and connected to the server from desktop works ok when not going through saml. So I am now am wondering if it is something with the IdP set up.
Any additional thoughts on that?
It sounds like you have the proper setup. And I don't know about SAML, so can't help you there, but it's a possibility.
Also, did you already do a tabadmin config and then a tabadmin restart within prod after you set the gateway config? This is the only other thing I can think of at this point. You may not actually need a tabadmin config, the restart might automatically handle it.
Were you able to fix the issue?
I am double checking our department's settings also because some local users are getting this localhost error on Tableau desktop. Unable to Connect to Published Data Sources When Opening a Workbook Downloaded from Tableau Server | Tableau Software .
I am in the process of comparing our Tableau Dev, QA and Prod server's configuration to make sure they are correct. And seeing if the F5 is setup the same way for them all.
Have you tried publishing from another computer?
Have you tried publishing from another location?
Have you tried enabling VPN and then publishing from Tableau Desktop?
Have you tried switching to hard wired LAN or changing the Wifi that it connects to?
What port are you using for Tableau Desktop? Is it the default one or custom?
Are you allowing that port traffic on the newly built Tableau server?
What subnet is your computer on in relation to the new Tableau server?
In relation to the old Non-production servers?
Is the new Tableau Production server in a different or new Security zone?
wgserver options start to be deprecated in newer versions but consider these also:
-Do you have the F5 address and the self ip of that f5 in wgserver.trusted_hosts?
To rule out or troubleshoot network/ firewall issues try these steps after opening Accessories --> Command Prompt from your Windows machine or Terminal from you Mac box:
- Can you ping the ip address of your Tableau Prod server( the Windows server address)?
- Can you ping the ip address of the F5 address for the server?
- Can you TRACERT or traceroute your F5 address and/or the Windows server address?
Does it reach these Ok? Does it miss any hops?
When you load and use the Tableau server in the web browser do you get any cert errors?
Random shot in the dark...you said this doesn't repro in Dev, right? Is this intermittent between users? Any chance the SAML config was just copied over directly from Dev and the return address for the IdP wasn't changed to the Prod server? I'm guessing some users are being authenticated in Dev and then when they try to log into Prod, they are getting some confusing SAML responses and logging in the users before presenting the authentication window. This feels like a trusted ticket issue.
The issue ended up being an issue with the prod idp instance. We were using siteminder and for some reason it was not maintaining the relay state. A patch was applied to the siteminder prod and it resolved the issue.