4 Replies Latest reply on Sep 13, 2017 6:53 AM by Brandyn Moody

    tabcmd createusers in 10.2

    Laura Romanschi

      I have a PowerShell script that adds users to Tableau Server using tabcmd createusers utility and it worked since version 8.


      Now we've upgraded to Tableau Server 10.2 and when I run the command built inside the script:


      .\tabcmd createusers "D:\Tableau Maintenance\Ongoing User Creation\users.csv" --no-certcheck


      It stops exactly at 4 errors.


      Number of errors: 4

      Error details:

      line 1 for user <XXXX>: Update of local site users requires empty or matching password <errorCode =10055>


      line 3 for user'null":Too many error encountered in CSV file <errorCode=10072>


      All new users are the last entries in the .csv file that gets transferred daily from an SFTP server. We are using SAML authentication with OpenIdm single-sign on.

      Basically the errors thrown above are for existing users when checking the password field, but this field is required for new users. Like I mentioned, the script runs in Production version 10.1 even with the errors above and adds only new users.


      Any input is much appreciated.

        • 1. Re: tabcmd createusers in 10.2
          Jeff Strauss

          Hi Laura.  One option is to append --no-complete onto the end of your tabcmd createusers.  This allows completion of all rows and will only process valid rows.



          • 2. Re: tabcmd createusers in 10.2
            Brandyn Moody

            Heya Laura!


            You are running in to a security improvement that was implemented in version 10.2.


            In certain circumstances (which I will not list here, so as not to encourage neer-do-wells), you can use TabCMD .CSV import to probe Tableau Server security.  Theoretically, if nobody noticed what you were doing for a long while, it could be used to gain a foothold working towards an eventual Tableau Server security breach.  So we closed this loophole in 10.2.


            Going forward, you will either need to remove existing users from the import list (since they don't need to be added anyway), or provide valid passwords for all currently-existent users.


            In most cases, the "--no-complete" switch that Jeff mentioned would get TabCMD to ignore errors and continue with whatever job you asked it to do.  But this behavior was the root cause of the security failure, an attacker would be watching to see which of their thousands of attempts did not return an error.  So now TabCMD will honor the "--no-complete" switch except for where it would compromise security.  This .CSV import process is one of those that will no longer tolerate errors.  Like the "Too many error encountered" message says, if you hit 4 errors during the import process, the process is immediately ended, and the error is logged.


            As an alternative, you may want to move towards a REST API driven approach, instead of a TabCMD approach.  This will allow you to add some logic to your import script.  Something along the lines of "IF user has been imported before, THEN skip user import".  If you didn't want to store information locally about whether a user has been imported before, you could use REST API to query Tableau Server, asking if a user already exists.  This could be done with the Query User on Site command.  If the query returns a "Error 404002 - User not found", then the Add User to Site command could be called.


            Hope this helps!

            1 of 1 people found this helpful
            • 3. Re: tabcmd createusers in 10.2
              Jeff D

              Hi Brandyn, adding an opinion to the discussion: creating a text file containing unencrypted passwords doesn't seem like an appropriate solution for anyone concerned about security. I would never recommend this as a solution.  It would be better to use one of the other approaches you mentioned.

              1 of 1 people found this helpful
              • 4. Re: tabcmd createusers in 10.2
                Brandyn Moody

                Heya Jeff,


                I think this is a great addition to the thread, I completely agree with you.  +1 to what Jeff said. 


                Just to reinforce what Jeff is saying, it is NEVER best practice to keep user passwords unencrypted.  This bears repeating.  It is a terrible idea to keep a storehouse of all your users' passwords in an unencrypted file, no matter what format the file is, or where it is stored.


                There are secure methods to achieve this "need to provide valid passwords" requirement, but all of those methods are much more complicated than just creating a REST API script to handle user import.