How to really configure ADFS with Tableau

(As experienced in Server 2012 R2 and Tableau Server 10.2)

TL;DR: Follow Tableau’s guide but use SHA-1 on the ADFS side, and map SAMAccountName to the “email” Outgoing Claim Type

Looking around the web, it seems like using Microsoft’s ADFS with Tableau Server for Single Sign-On (SSO) is widespread and no big deal to setup. Sure, the steps available on Tableau’s site look a little long, but it’s all pretty straightforward. However, there are a couple things that get left out.

The first issue, which has to do with the Secure Hashing Algorithm (SHA) used to sign requests and responses, is easy to mitigate. When I read a support article from Tableau, I got the sense that Tableau should support SHA-256. However, whether I ran the recommended tabadmin command or not, I always ended up with a failed authentication attempt and the following error on the ADFS server:

SAML request is not signed with expected signature algorithm. SAML request is signed with signature algorithm . Expected signature algorithm is

Meanwhile, Tableau Server presented the following error in C:\ProgramData\Tableau\Tableau Server\data\tabsvc\logs\vizportal\vizportal-x.log:

org.opensaml.common.SAMLException: Received response has invalid status code

The fix? Tell ADFS to use SHA-1 for the Tableau relying party. You or your ADFS admin can do this with the following steps (based on Server 2012 R2):

  • Log into the ADFS server
  • Open AD FS Management
  • Go to Trust Relationships -> Relying Party Trusts
  • Double-click the Tableau Relying Party (the identifier column should match what you put in the SAML entity ID field back on your Tableau SAML config)
  • Click the Advanced tab
  • Set the Secure hash algorithm drop-down to SHA-1
  • Click OK

No ADFS restart will be necessary.

Now, of course, there are security implications with this change. SHA-1 is no longer considered secure, so you should first assess the potential risk for your organization.

Onto the second–and potentially more interesting/confounding–issue. Every guide I checked on how to configure ADFS listed the following attributes in the claims rule:

  • SAM-Account-Name -> Name ID
  • SAM-Account-Name -> username
  • (optional) Surname -> LastName
  • (optional) GivenName -> FirstName

This is definitely what ADFS had configured, but it wasn’t working. I finally turned to the previously-mentioned vizportal log and found this: Incoming SAML message has no valid value for email attribute. Please verify ServiceProvider configuration in Identity Provider.

So… Despite what the docs say, Tableau wants an email attribute? In some cases, this is no big deal. Simply edit your Issuance Transform Rules, and add an attribute that maps “E-Mail-Addresses” to the “email” outgoing claim type. Where it gets tricky is when your email address is not the same thing as your username @ your AD domain. Why would this matter? Because, even though Tableau is receiving an attribute called “username,” it tries to extract domain and username from the email address.

Say your email address is When this gets passed to Tableau, Tableau breaks it apart and tries to sign in as\jon.doe. If jon.doe is your username/SAMAccountName and your domain is known internally as, then that’s great. However, if your username is actually jdoe and your internal domain is, this is going to fail with a vizportal error like this:

2017-12-14 10:26:40.253 -0500 (,,,) catalina-exec-4 : INFO com.tableausoftware.domain.user.saml.SAMLExtendedProcessingFilter – Using domain extracted from email in saml response for username
2017-12-14 10:26:40.253 -0500 (,,,) catalina-exec-4 : INFO com.tableausoftware.domain.user.saml.SAMLExtendedProcessingFilter – Using fully qualified username\jon.doe from saml response
2017-12-14 10:26:40.253 -0500 (,,,) catalina-exec-4 : INFO com.tableausoftware.domain.user.saml.SAMLExtendedProcessingFilter – SAML IDP login was successful, proceeding to create session for username :\jon.doe authUserId : Optional.absent() displayName : Optional.absent() email : Optional.of( logoutSupported : true on provided target site Optional.absent()
2017-12-14 10:26:41.563 -0500 (,,,) catalina-exec-4 : ERROR com.tableausoftware.domain.user.saml.SAMLExtendedProcessingFilter – SAML Authentication Failed, please contact the administrator.

Fortunately, you still have a couple easy options. First, if your UserPrincipalName uses your standard domain, rather than something like, you could map that to the “email” attribute. Alternatively, you could just map SAMAccountName to the “email” attribute. If Tableau doesn’t see an “@” symbol in the email, it will simply pass the username along as-is. Problem solved.

I plan to raise this with Tableau support. It could be that I’ve got something wrong or need to update (yes, I do, but I haven’t seen this mentioned as a known issue/bug fix). But, if you need to move past this quickly, perhaps these tips will help. Good luck!


Redirect HTTPS Tableau Traffic to a Valid URL

You’ve heard it before: it’s past time to encrypt ALL the things! Even internal traffic should be encrypted, since you never know what rogue devices or people may be listening on an ethernet port or an unsecured hotspot. That’s why, when I inherited a Tableau server, I decided that encryption should be a priority. Especially when you consider the kind of data that can flow in and out of Tableau. And, Tableau makes it surprisingly easy to turn on TLS (or SSL, as they and so many others like me still call it). What they don’t make so easy is redirecting users over to an address that matches your cert. No big deal if your users have always accessed Tableau Server with the right alias, but until now, we only had an internal address that doesn’t match the cert we applied. The good news is Tableau Server uses Apache for its web server. With a pretty small tweak, you can redirect your users in no time.

Please note: this is not documented or supported by Tableau as far as I can tell. Be sure to test thoroughly before applying to your production environment. I also assume these settings will be overwritten by an update/upgrade, thus needing to be reapplied afterward (update: Having since gone through a few upgrades, I can confirm that these settings need to be reapplied afterward).

As I mentioned, Tableau Server uses Apache for its web server. An interesting choice since Tableau is only supported on Windows. This means a couple rewrite conditions/rules in httpd.conf will have you off and running. The first thing you need to know is where this file lives. It will be under Tableau’s data folder, which is located based on which drive Tableau was installed on. Tableau was installed on C: for us, which puts the httpd.conf file in C:\ProgramData\Tableau\Tableau Server\data\tabsvc\config (we will talk about moving your data folder to another drive in a later post). I am not entirely certain what the structure looks like if you installed on a separate drive, so you may need to do some digging.

Once you have located the httpd.conf file, the second thing you need to know is that this file is formatted for *nix line feeds and carriage returns. I.E: If you open it in Notepad, it will all be jumbled together. If you already have a tool like Notepad++ installed on the server, it should do nicely. In my case, I chose to copy the file to my local machine, edit it with Atom, and then push it back to the server. Just be sure to make a backup of the file first.

Ok, so you’ve found httpd.conf, you’ve made a backup, and opened it up in your favorite *nix-friendly text editor. If you scroll down to around line 581, you will start to see several RewriteCond and RewriteRule lines. Our rules don’t have to go here, but it seemed logical since there are already related rules in the vicinity. If you aren’t familiar with mod_rewrite rules, they basically look for certain conditions in an Apache request and rewrite/redirect (with a 301 by default) the URL sent to the server. Here is what I added after Tableau’s built-in list of rewrite rules:

RewriteCond %{HTTP_HOST} !^tableau\.mycompany\.net [NC]
RewriteCond %{HTTP_HOST} !^localhost [NC]
RewriteRule (.*)$1 [R=301,L]

What does each line mean? The first line looks for requests containing a URL that doesn’t match the address we want people to use. Replace “” with your company’s preferred address for Tableau. Of course, make sure the record actually exists in DNS and points to your Tableau server.

The second line is an AND condition (by virtue of the previous line not ending in “[OR]”) and filters out requests using the “localhost” URL. The reason for this is that Tableau Web Data Connectors (WDC) published on the server will always be refreshed using http://localhost/webdataconnectors/yourWDCname.htm. And, as I found out, Tableau won’t follow the redirect when it tries to extract, but it will seemingly ignore the certificate/server name mismatch. Adding this line makes sure we don’t break any scheduled extracts using a WDC. Side note: it seems that in Tableau 10, you can maintain a list of approved WDC’s external to Tableau (aw yeah!), which I find preferable and would make this line unnecessary.

Now, the third line. This line takes the requests that haven’t been filtered out by the two previous conditions, and rewrites them to use our preferred address. Notice that here I have added the protocol (https://), whereas it is not needed for the conditions since we want to catch HTTP and HTTPS requests. The variables at the end will keep the rest of the URL as-is, so that something like becomes, rather than redirecting to Tableau’s landing page.

Once you have updated httpd.conf with the lines above, restart Tableau Server (tabadmin restart). Now, whenever someone tries the old address, they should be redirected to the new one. This all depends on the visitor or other clients following a 301 redirect, which is pretty standard. Still, be thorough in your testing to account for all conditions.

That’s it! A lot of talking for 3 lines of text.

Get a Working Date/Time Format Using a Tableua Web Data Connector

Here’s a tip that resulted from quite a bit of frustration. It has to do with Tableau’s new-ish Web Data Connector and a difference in JavaScript date functions across browsers (particularly, Chrome and Safari). While trying to pull in JIRA data, depending on which JavaScript method I attempted, I would see either a NULL or NaN (Not a Number) in any date field. The frustrating things is that it worked perfectly in the simulator. I only ran into the problem in Tableau Desktop (on a Mac) and could not find any errors in the logs or console.

To start with, Tableau has a pretty good tutorial to help people get started writing a WDC, which I recommend you check out first if you haven’t already. Within their documentation, you can find a cheat sheet for accepted date/time formats. However, even though I referred to this cheat sheet and tried several formats, I could never get anything to produce a result other than NULL or NaN in Tableau. Again, despite the dates rendering properly using the simulator in Chrome. Writing a WDC wasn’t a high priority, so I would bang my head on it for a while, set it aside for something else, and then come back the next week to do the same thing all over again.

A breakthrough finally came when I asked myself, “Does the simulator behave the same in all browsers?” I fired it up in Firefox and saw the same valid results as I saw in Chrome. Next, I brought up the simulator in Safari. Much to my surprise, the dates produced a NULL or NaN! For my purposes, the WDC was connecting to a proxy server, which then connected to JIRA using PHP’s cUrl functions. In order to confirm my suspicion that Tableau was using Safari, I checked the access log for this proxy server. What user agent did I find when trying to connect using Tableau Desktop, rather than the simulator?


As you can see, Tableau was using Safari. A Google search lead me to this question on Stack Overflow, which made me think Safari was not quite comfortable with the date/time string provided by JIRA (e.g.:2016-07-23T05:31:15.000-0400). The accepted answer suggests trying out moment.js, which I did and found it incredibly easy to use. Just remember to include the moment.js file when you add your WDC to the server.

With moment.js in hand, the solution was simple. I included moment.js in my WDC with something like the following:

<script src="moment.js"></script>

Then, I used the following code to get the date string supplied by JIRA into a format supported by Tableau:

var dateFormat = "Y-MM-DD HH:mm:ss";

var createdDate = moment(issues[ii].fields.created).format(dateFormat);

Tableau magically rendered a real date! So, if you find yourself trying to solve the same puzzle, give moment.js a try and see if that doesn’t get you onto the next hurdle (which is getting Tableau Server to a version that is compatible with the WDC found in the tutorial/simulator).