1 2 Previous Next 16 Replies Latest reply on Oct 6, 2018 9:57 AM by Toby Erkson

    Embedded password changes and how to handle them

    Bryan Sheasby

      I am the publisher for the vast majority of dashboards and I embed the password into all the workbooks when publishing. Where I work there is a 90 day password change policy that is not able to be over-ridden for any reason. When I change passwords, would I have to re-publish every individual dashboard (there are a lot of them) or is there a way to update my credentials in all of them at one time?

        • 1. Re: Embedded password changes and how to handle them
          Bryan Sheasby

          I am more confused today then I was on Friday. I came into work and it seems that the embedded password seems to have auto-updated on some workbooks and not on others. I keep getting a message when viewing the view on the Tableau Web Server that the connection is broken and an option to reset the view.

          • 2. Re: Embedded password changes and how to handle them
            Jim McNulty

            I have the same question.  I'd really like to embed passwords so we can use the subscription feature, but not if I have to manually change the password on every workbook every time the password changes.  Have you gotten an answer from anywhere else, Bryan?

            • 3. Re: Embedded password changes and how to handle them
              Ramon Martinez

              Hi Bryan,

               

              I don't think that using your own user account to authenticate to the data source is a good practice. Imagine, what will happen when you leave your work and your user account will be blocked or cancelled?

               

              I think you can avoid the situation you've described by controlling the security/accessibility to the data source at database level. I mean, creating a user account in the database with read-only rights to access the tables/views that are exposed to data analysts for reporting, visualizations, dashboards and analysis. That is the account you will embed when you publish a workbook to tableau Server.

               

              As that account is at database level, I'm almost sure it can be out of the 90 days password change policy that it is managed and controlled, in many institutions, by Active Directory.

               

              I hope this idea help you.

               

              Best,

              Ramon   

              • 4. Re: Embedded password changes and how to handle them
                Toby Erkson

                Ramon has it exactly right.  We call it a "service account"; I've also known it as a "faceless account" and a "shared account".  It is an account that not owned by any one person and the password never expires.  It's also a good way to implement [yet another level of] security.

                 

                < edit > It can also be known as an "application account" or "non-expiring password account"...the latter being the most obviously descriptive for anyone involved

                • 5. Re: Embedded password changes and how to handle them
                  Ramon Martinez

                  Thanks Toby, your comment complementing the terminology of this type of account is appreciated.

                   

                  Best,

                  Ramon

                  • 6. Re: Embedded password changes and how to handle them
                    Jim McNulty

                    I hadn't seen those terms before, but we use a "service account" as well.  Even so, there will be times when the password needs to change.  Maybe a security breach, maybe an unpleasant firing.  No password is permanent.  So when the password changes, what happens?  Is there a way to update the password that doesn't break all existing subscriptions?  Is it possible to create some kind of server script that would run through all the worksheets and update the password without having to touch each one manually?

                    • 7. Re: Embedded password changes and how to handle them
                      Toby Erkson

                      Good, valid questions.  If no one has any suggestions then maybe present your question to support and let us know what they say.

                      • 8. Re: Embedded password changes and how to handle them
                        Tamas Foldi

                        You can change the password at data source level (especially if you are using published data source which is more than a must in enterprise environments).

                         

                        You can automate the password replacement with a simple tabcmd script for multiple data sources as well.

                        • 9. Re: Embedded password changes and how to handle them
                          Jim McNulty

                          That is a great answer, Tamas!  We haven't tried publishing data sources yet, but I'll make that a top priority.  I knew tabcmd existed, but I have no idea what can be done with it.  Sounds like it is a powerful feature.

                           

                          Thank you. 

                          • 10. Re: Embedded password changes and how to handle them
                            Toby Erkson

                            Tamas, I'm guessing "tabcmd publish" would be used?

                            • 11. Re: Embedded password changes and how to handle them
                              Tamas Foldi

                              Yes, publish would be the option where you can override the previously defined database password in the command line. Theoretically you save your datastores in tds files and then republish them with the new db password without the need to change the tds files contents. Very theoretically as the data sources usually evolves - but in that case you "get" the latest one from the server with tabcmd then publish back with new passwords

                              • 12. Re: Embedded password changes and how to handle them
                                Stephen Lavery

                                Hi Toby Erkson

                                 

                                If you follow Bryan's approach, when publishing a workbook there is only either "Prompt user" or "Embedded password". The embedded password option here is the publisher credentials, which are subject to change as discussed in this thread. There is no "Embedded password of the service account" option as mentioned. Can you explain a little more how this setup would be configured? Thanks

                                 

                                • 13. Re: Embedded password changes and how to handle them
                                  Toby Erkson

                                  Stephen, you use "Embedded password", it's just that the credentials used typically should be a service account.  Tableau does not know nor care the type of credential (personal or service) used, just that there is one it can save [Embedded password] or not [Prompt user].

                                  • 14. Re: Embedded password changes and how to handle them
                                    Donna Coles

                                    Hmmm... this is an interesting thread and very relevant to me (even though it's a pretty old thread originally)...

                                     

                                    We're currently (still) on v10.1, so not entirely sure if anything has changed in later versions....

                                     

                                    So we embed credentials for extracted published data sources and workbooks which have a need to extract the data further.  We do embed the user credentials, but a change in password does not appear to cause these extract refreshes to fail.  We too have a 90 day password policy and Tableau Server is authenticated via the AD.  I've never really got my head round why this is the case. I'm assuming what actually gets embedded is some other 'key' or 'token' that gets associated with the user account, but is independent of the user's actual AD password....

                                     

                                    Extracts do fail to refresh when the user does leave the business (as expected).  We typically try to manage a change in ownership before the user leaves, but sometimes things get missed.

                                     

                                    Due to a recent issue, I need to revisit this concept of using a service account, but not sure how secure/manageable it would really be...

                                     

                                    1) I think Stephen Lavery question above, is how to 'input' the service acocunt credentials in the first place ... we're AD authentication, and when I open up Desktop I'm automatically logged in as myself, so my credentials get embedded... how would you change them to be a 'service account'

                                    2) We have multiple Desktop users who develop workbooks and may choose to extract and so 'embed credentials' to allow the workbooks to refresh on a schedule... if we figured out how to use a service account, would this mean we'd need to be sharing those credentials around to everyone who may need to extract.... doesn't feel right...

                                     

                                    Here's an example

                                     

                                    The Contracts & Warranties - Potential is a published data source. It connects to a SQL Server database but has been extracted due to the size to help performance.  I created that data source and published it, with the authentication set to 'Server - run as account', so when it refreshes, it runs as the service account, and the authentication online indicates its not embedded. - all good... I'm assuming if I left, the data source would continue to refresh.

                                     

                                    I then have a workbook that uses this published datasource, but due to the way it's been built, the data source has been further extracted into the workbook, and the workbook is on a refresh schedule.  The  authentication on the data sources at publish time is set to 'Allow Refresh Access' which embeds credentials.  On server there is no ability to 'edit connection' - option greyed out.

                                    This workbook refreshes fine, even if my AD password changes.  If I left though and my AD account was disabled/removed, it would fail.  When this happens, new 'owners' have to download the workbook, reapply the extract and republish, so embedding their credentials...

                                     

                                    Any insight appreciated.  This is one of those things I should have understood a long time ago, but hasn't been so necessary to get to the top of my 'to do' list :-)

                                     

                                    Donna

                                    1 2 Previous Next