1 of 2 people found this helpful
This is what I read:
...it would be great to be able to login to server as that user and see the server through their eyes.
If other words, not see it through the eyes of the admin account
Correct, my point was that as an admin we have access anyway, so allowing an admin to view things as a specific user wouldn't change the security implications.
Alex Braun wrote:
...allowing an admin to view things as a specific user wouldn't change the security implications.
This is not correct. If I login as me, a Tableau Server administrator, and I go to a HR (Human Resources) report that looks at my group membership or user ID (the User functions) to filter the data...
...the data that I see will be different compared to what I would see if I impersonated (i.e. logged in as) a manager of HR e.g. logged in as "HRMGR" instead of "TERK". I even verified this with my HR author just to make sure I'm not on crack
If I'm missing something -- which is entirely possible -- then please provide specific details.
Ok, that is different if you are choosing to use the user filters, but generally speaking, if you aren't using user filters, admins have access.
I would love to see an improvement in the way Tableau Server and Desktop pass user credentials to a Microsoft SQL Server Database.
When I work with clients who are familiar with Desktop but not Server, they are amazed that Desktop will allow them to connect with Windows Authentication (which by the way is labeled “preferred”), but when the data source is published their only authentication options are either “Server Run As Account” or “Impersonate via server Run As account”.
Both of these methods have caused client DBAs to rant and rave at me. “You want me to grant a single ID read only access to all of the tables and rely on the application administrators to ensure people don’t get access to reports with data they shouldn’t see? Yeah right”. Then from an audit standpoint, you have a single ID making all these calls to the database as an untold number of people are running reports and no easy way to track that person A didn’t accidentally gain access to protected table B.
The second option of using impersonation is only slightly better and then only if you have a small number of users where you have to create the impersonation rules.
New person joined the company…need to create another rule.
Someone left the company…another rule.
Somebody switched departments…got to change the rules.
So, if we go back to Desktop, the other option is to use a specific username and password. This at least provides you with a few more options, the first being Prompt User. On the surface this seems like it would alleviate some of the security concerns and allow the DBAs to track user connections back to the database. Unfortunately, using specific usernames/passwords requires additional manual maintenance on the database side to create those IDs. Not so bad if you have a handful of employees, not going to happen if you have thousands.
I had an account manager phrase it pretty well. “The default method for connecting to a SQL Server database is through Windows authentication. We already have database, table and row level security set up using people’s Windows credentials. My people are logging into Tableau Server using Single Sign On which is passing in their Windows ID and password. Why can't Tableau Server pass along these credentials?”
Thank you Egor for your valuable feedback on specific things we can do to make the product better. Totally acknowledge that the server installer should have options for backup/restore and config files. Love that you have the link to the idea so it can be reviewed by everyone here.
How to handle large numbers of groups? Users have to put a ticket in to request a group be imported from AD. I looked at just importing all the groups, but I imported 1k groups and my testing found it would take over 8 hours to sync all 30k of them.
Hi Aaron Beymer,
Thanks for all the great feedback and suggestions on improvements to help management backgrounder tasks. This is super valuable information to help prioritize work for the development team. Many of your suggestions are items that our on our backlog for consideration already and I have added a few additional items based on your suggestions.
One of the features you suggested will actually be available later next year. We will be adding the ability to dynamically configure some of the Tableau Server processes (including Backgrounders and VizQL Servers), so that you can script the scheduled-based configuration scenario that you described in your post without taking downtime/requiring a restart of the server. This feature will be actually available to try out soon as part Tableau Services Manager and Tableau Server on Linux Pre-Release Program, so if you are interested visit http://www.tableau.com/getbeta to sign-up!
Product Manager, Tableau Server
Hi Toby Erkson,
To answer you question here:
For example, if setting up a primary node in a multi-node environment and the primary only runs the gateway, repository, and search/browse processes then how many cores/RAM/drive space should it contain at a minimum? What if those hardware items were increased? Or when should they be increased?
We always recommend that you run with the minimum recommendations (and not just the minimum requirements) as documented here: https://onlinehelp.tableau.com/current/server/en-us/server_hardware_min.htm. This minimum recommended hardware configuration has been well tested and validated by our internal teams. Note that if you do not configure any licensed processes (See Tableau Server Processes for more details on which processes are licensed), then that server does not consume any core licenses. So in your example above, the primary with only Gateway, Repository, and Search/Browse would not count against your core licenses.
There is not rule-of-thumb on when to increase your hardware. Most generally, if you start to experience delays in viz rendering, background job processing, then you should consider increasing the size of your deployment.
Product Manager, Tableau Server
Hi Matt Francis and other who liked his post,
I want to encourage everyone to add your votes in the Ideas Forum if you haven't already. Here is the link to the idea that I think you are describing: https://community.tableau.com/ideas/6100. Also, it's been great to see all the community engagement and support on this thread!
Hi Iwona Wiktorowska - we're still in a pilot phase of these sessions and trying to get them off the ground. Happy to hear that you enjoy them, and thank you for the feedback - hopefully, in the near future, we'll be able to run them at a time that works for the APAC business hours!
In the meantime, I will post the recording tomorrow so you can watch it at a time that's convenient for you.
I love to have some kind of solution for -- 5. Clean up All Users group. if you have sync process with AD then All Users group will have all of them, even when is deleted (deactivated) from AD groups.
-add availability to clean up All Users group
We are looking for the process as well for "Clen up all Users group", especially when someone owns contents and needs to change ownership. Anyone who has implemented this or working on? We have self-service implementation where clients can publish themselves and maintain their AD group membership.
I think a common feature like a following can help system admins in an environment with large user base.
if user status is unlicensed remove from the All Users group and if owns contents need attention or reminder or some kind of notfication to group owner or adminstrator.
The Deep dive white paper is a great resource.
Following up on Toby Erkson
I was wondering, when they mention each machine is an 8 core 64gb ram... does that mean the primary machine which only acts as a controller/gatekeeper is running the same specs?
If that's the case, isnt this a waste of hardware?
Kitty Responded to this live saying they used the same 8 core 64gb ram machine for running the primary machine.
However when asked again,
For primary node configs, they noted that you can run less than the recommended 8core-64 gb they mentioned that they have run 8 core 16gb ram instead. Keep in mind that the primary node controls ziplogs, and backup processes so it'll still need hard drive space and some horse power for these processes.
"Therefore, the computers that run the primary and backup primary do not need as many cores as the ones running your worker servers. You will, however, need adequate disk space for backups because the primary computer is used during the database backup and restore processes. In addition to the amount of space needed for the backup file, you need temporary disk space roughly 10 times the size of the backup file (so if your backup is 4 GB, you should have about 40 GB of temporary disk space available)."
I would take the 10x size with a grain of salt. Our backup is over 130gb and on our single machine setup we've had just enough space for Tableau to restore backups so about 200gb free or 600gb total on the server.