I am currently looking at setting up a number of SSRS data sources to a warehouse but one issue I can not get around is how to define which views are available to each data source. Can someone share how to limit these down so that I can have multiple data sources acting as data marts from the single warehouse.
Currently using SQL 2008 r2.
Thanks
When you create a view you assign a permission set to the view (certain users/groups can do selects others can do selects and inserts and others have no permission on the view).
When you set up a connection through a datasource the user on the datasource will have the permissions assigned to them through the view. When you deploy the report you assign a user and password to the report (Data Source) and that user's permission will apply to what they can objects that, and the report, can see. The permissions assigned to the report allow users to see/execute the report.
Related
I've written a Crystal report that primarily works from a temporarily MDB file that is created on the fly in an Application (which I do not have access to source code for).
I need additional data, so I linked to a secondary MSSQL database where I store more information.
I was able to add tables from this SQL database to my report, and link to them with no trouble. But when I try to include views in this same SQL database in this report, I get a "Logon Error".
My first thought was that is is a permission issue, but I haven't set permissions for specific tables and views in this database, only permissions to the entire database.
Frustratingly, I don't see any errors in the SQL logs for the database.
Does anyone have ideas on what I can check to get this fixed?
Just To Clarify: I can see these views in the Crystal Report, and I can add them, add fields to the report, and create links. I can even Browse Data in fields within the view in Crystal. It's only when running these reports from the 3rd party application that I get an error.
Is SQL Server set to use NT Authentication? If so, the 3rd-party application is probably running under a user context that doesn't have permissions.
I'm looking for a way to filter the data to employees something like create a "user to Client relationship", the problem is this is after the fact,I have 100+reports that already exist and I don't want to edit each one, I use a shard Data source, can i somehow implement RLS on that source ? or maybe use ssas RLS in conjunction.
SQL server 2012 enterprise,
Thank you
One solution which comes to my mind is to add to each shared dataset a part which will filter rows based on domain user name.
This will require that:
User running SSRS report will have to have access to SQL Server
You would have to build tables to define access right (if you do not have already)
If you would be running SQL Server 2014 and onwards you could use built in RLS. You would have to define access right and create access control function. Still you have to have some kind of data store which will help you to determine what is visible to each user - more details on RLS here.
I'm working on setting up PowerBI desktop for a client where they'll import 8 specific tables from a database to work on in Power BI.
However, when I go to import the tables, every table in the database is shown and the specific tables must be selected. There are hundreds of tables imported, and a lot of scrolling to select the correct tables, which leaves room for confusion and error for the clients.
The client accesses the database using windows authentication, and I can't change their settings on SSMS as that would affect how they access data on other applications.
I was wondering if there was an simpler way to save a query in Power BI the users can quickly select when setting up a new report.
You could always use raw sql instead:
Or select "empty query" and specify it like so:
Edit: not sure if this is of any help but there's also a filter field:
I have a large reporting SharePoint site that contains about a dozen different shared data source connections, each one pointing at a different SQL server that is being utilized by the SSRS reports hosted on the site. Each data source has a cached account that is used to retrieve the data when a report runs so that report readers do not have to have read access to all of our SQL databases.
When someone with report building privileges creates a report, they are able to select one of the shared data sources hosted on the website, but then have to pass an authentication popup before they can actually write a query against the database:
The strategy currently in use is that our authors do have read access to the SQL database and use that authentication (Use the current Windows user) to create the report and then when they save the report, readers utilize the account stored in the shared data source. We then manage access to the data in the report through SharePoint security by only allowing people who should see that data to have access to the report.
This seems all very standard to me...however
I am able to query any database that any of the shared data sources have access to, regardless of my own permissions with a bit of rdl definition manipulation by following these steps:
1) Current account needs access to report builder and AD access to at least one SQL datasource (to make things easier)
2) Add a shared data source to the report that I have access to
3) Add a dataset with a query that follows this format SELECT '' as Field1 FROM DBNAME
4) Add a table to the report that simply displays Field1 from the query
5) Add one of the shared data sources that I should have no access to (there is no stopping me from adding the shared connection to the report, I simply am unable to use report builder to create a dataset using that data source)
6) Save report on the SharePoint site and then download a copy to local computer
7) Open rdl definition. Replace the data source for the SQL query with the name of the "unauthorized" data source (can delete original data source). Replace the SQL query with one that queries the database for a list of table names (SELECT name as Field1 FROM sys.Tables)
8) Upload report definition back to SharePoint and run report
The report now uses the cached account and I've bypassed the nice authorization window that using report builder would have provided. By using sys queries, I can find the databases, tables, columns and eventually the data without having to know anything about the database. I could slow this method done by preventing access to the master database so that a list of databases can't be retrieved, but that's minor and not a complete solution.
Options:
- Could enforce security at the database level, however I don't want report readers to have permission against any of my source databases. While each report could be fed from a view and then separately controlled to prevent access to anything more than what the report shows, this would be uncontrollable
- Force every report to use an embedded connection and not a shared connection. This would be hard to manage in the future when moving servers or when we need to know what reports are utilizing a specific connection (dependent items are available in the data source drop down menu)
I feel like I'm missing something obvious here as this seems to totally defeat the purpose of hosted, shared data sources.
The advantages of Shared Data Sources are administrative, in that they reduce the overhead in making changes to data source connection details such as passwords and server names. As you pointed out, using Shared Data Sources also allows you to easily identify dependent reports.
However Shared Data Sources are not a mechanism for securing data sources such as databases. Security really needs to be addressed at the database level to properly ensure only authorized people have access. If the credentials are stored in the report data source, then anyone able to access that data source or refernce it in a report is going to be able to execute queries on the connection.
I think the issue is in this step:
5) Add one of the shared data sources that I should have no access to
(there is no stopping me from adding the shared connection to the
report, I simply am unable to use report builder to create a dataset
using that data source)
There should be some way to prevent the report designers seeing shared data sources that they do not have permissions on. You might need to set individual permissions for each item, or put them in different locations to allow them to be secured with the correct permissions. I'm not a Sharepoint expert though so this is just a suggestion.
This afternoon I was reviewing the security for a user in my SQL Server, in SQL Server Management Studio. I opened the Database User's Properties dialog, and went to the Securables section.
As I was cycling through the tables and stored procedures that this particular user had access to, I noticed that one of the data tables had the the Update option checked in an intermediate state. What does that mean? You can either update a row, or you can't. There is no in-between. I've included an image for reference. I would just fully check this option and save it but I'd rather not screw with the DB if this serves a worthwhile purpose.
I believe that means that that permission has been inherited and wasn't explicitly set for that user.
The GRANT statement can assign
permissions to a group or role that
can be inherited by database users.
http://msdn.microsoft.com/en-us/library/bb669084.aspx
I'm trying to find something that specifically spells out that's what the checkbox looks like in the above situation.