June 13, 2009 at 4:47 am
Hi Folks,
It looks like reports, datasource, and SQL User accounts are another group of things in our world that can end up looking like a messy closet. I find numerous of these items - often not named in any way to help you figure out what or who it belongs to and if it has been orphaned.
I was thinking of creating one account simply named SSRSUser for each of our SQL servers. I would set this account up with read-only access to all databases that are hit by SSRS and then I would SQL account for all datasources that are developed. My thinking is thar report access is controlled by security in SSRS and that this would be intuitive for the programmer and report developers. Today I am faced with a number of "specialized" SQL and AD accounts created for one or two reports. A less generic but still intuitive approach would be to create a SQL and AD account for each server with the server name included. i.e. SSRS_servername_User. I end up with more names and not sure if there is a benefit.
I'm reading Microsoft SQL 2005 Reporting Services and although I get a lot out of it, they don't share best practices and I would like to bring some order to the mess I have today and keep it from growing. Any tips on you have on how to keep things organized regarding SSRS or sites/posts that deal with the same are very much appreciated.
Software Developer - Seasoned
SSRS / DBA - Capable Noob
June 13, 2009 at 9:44 am
Your plan sounds good except for the readonly account because if you expect complex reports that are generated with complex stored procedures then read only account will make SSRS reject half of your developers code, nothing is wrong with the code SSRS just decides it will not excute the code.
All shared datasources I have used run with single DBO account, you could decide not to use DBO but you need more than read only accounts.
Kind regards,
Gift Peddie
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply