I'm having trouble figuring out how to setup user access rights for project portals in TFS 2010.
The permissions granted to user XXXXXXX are insufficient for performing this operation (rsAccessDenied)
I've tried adding the user to the various admin groups in TFS but the problem seems to only be related to Reporting Services permissions.
I mapped this user to the RSExec role in the RS databases as well as made sure they had access to the IIS virtual directory. I've tried several of the solutions found through Google but many of them are for previous versions of TFS/RS and the options don't even apply, others don't seem to work at all.
Ideally I would like to add an entire domain group to the entire project collection so that they can access any project portal underneath it, I don't want to have to setup custom permissions on each project, let alone various web parts.
Use this tool: http://tfsadmin.codeplex.com/ to administer TFS/SharePoint/SSRS in a consolidated interface.
Related
I have inherited an SSRS environment which is a mess; Folders named only with numbers, hundreds of reports not accessed in the last 2 months (I checked ExecutionLog), etc..
I wanted to achieve two things…
Because every other day someone asks for read access to random reports, is there any way of making it “public”, meaning anyone can read and open ANY report?
I want to revoke “folder/report creation/move” access to everyone; can it be done without going folder by folder?
Related to it, the other day I found another SSRS box, that had this access?! What is that “everyone” is it a group inside my domain, or is it an SSRS feature that you can make it public so anyone can access?
That Everyone group looks like a domain account that your organisation has created. At least, I have never come across it.
To grant access to everyone that has a windows login, you can use NT AUTHORITY\Authenticated Users and set their permission to just Browser which will prevent creation or modification of Folders or Reports.
Regarding removing permissions from your items, your options are to either go item by item or bulk update the ReportServer database, which is not supported by Microsoft. You break something, you're one your own.
A big thing you will need to watch out for with opening up every report to every user is whether or not there is any confidential or sensitive information in any of the reports. Your organisation will not want low level staff looking at executive, cross company summaries nor will HR want their reports visible to anyone other than themselves.
You can export ALL permissions from SSRS using PowerShell.
I've also detailed a script that allows you to revert every folder to "inherit parent security" so you can control every folder by simply setting the home folder security. Sorry for the shameless plug but I blogged about both in April on SQLShack actually Managing SSRS Security using PowerShell
Both scripts are in that post. I hope that helps
I've been trying to figure this out and it's driving me crazy. I'm trying to restrict access to the Site Settings option on the home SSRS screen. Nothing I do as far as setting roles seems to make a difference. Everyone in the company who clicks on the link can edit the Site Settings. I am the only user as Content Manager and System Admin.
I don't know where to look next. Has anyone come across this before?
Here's a picture of what I'm talking about - http://i.imgur.com/6I8xaZg.jpg
Initially, only users who are members of the local administrators group can access a report server. A local administrator always has permission to fully manage a report server instance. So please check your company guys are in local administrators group.
See: https://msdn.microsoft.com/en-us/library/ms156014.aspx
I have a Access 2003 and lower databases. The company i work for is currently using MS Office 2007 and Access 2003 instead of Access 2007 because of issues with library references. We're currently converting the Access 2003 databases to Access 2007, but some users are already being upgraded to MS Office 2013 and Access 2013.
I am aware that Access will only change library references when design changes are made in Access 2013 which is not something we want because it will cause issues for users still using Access 2007.
My question is what constitutes a design change? For example we have some forms who's labels change based on user selection, would that be considered a design change? We do not want Access 2013 users to inadvertently make design changes.
The only way to avoid users making inadvertent changes would be to either use the Runtime instead of a full version of Access on their machine or force the database to open in Runtime mode by changing the your front-end's database extension to accdr.
Now, if your aplication relies on the standard office references, you should be ok (for most of them) as Access will use the right one for the version you have.
Any any rate, the fact that you are worried about users making inadvertent modification seems to imply that your users are sharing a front-end, which is not the recommended way to deploy an Access application: the application should be split.
Database containing the shared tables of the application remain on a network share. The Front-end, containing the UI and business code, should be deployed on the local machine of each user. The front-end only contain links to the tables in the backend.
This is a safe multi-user design since only data is shared, not the UI state.
Now if you have that design, if would not matter too much if users made accidental updates since that would only be local to their machine.
In that configuration, you can also keep sharing a specific mdb database with various front-ends for Access 2003, 2007, 2013 being deployed for different users.
Deployment is the hard part since you want that to happen automatically when there is a new version of the front-end available. There are tools like Auto FE Updater that can help.
I am an db admin on the server. I have granted the user with "SYSTEM user" on site setting, "Content Manager" on the Home folder, and also "Content Manager" on the her folder XXX.
However, she cannot deploys her report on BIDS and get this error instead:
The permissions granted to user 'WMSERVICE\xxx' are insufficient for performing this operation
I have gone through many site and most of the suggestion is to run it back as Administrator, or give her a SYSTEM Administrator privilege for the SSRS (this is the last resort that I should consider).
Any ideas?
Two things on SSRS:
SSRS has two permissions, roles and user levels. Giving someone a permssion role of admin to SSRS is not like giving them admin under Active Directory. Just to SSRS. You could always try that and see if that is the issue.
Is the user publishing to multiple locations with the:
Data Source(s)
Data Set(s)
Reports
Or are they self contained in the report itself?
They can tell by going into a Report Project and hitting properties and looking at their screen settings. If they are using 'Shared Data Sources' or 'Shared Data Sets' that adds more levels of complexity to the security issues as you have to deal with their deployment as well. If one of those report folders is different they may be getting denied. For a sub part of the total in which their deployment would tell them which object was failing and were at. Many times I have seen people NOT turn off the default for Data Sources which is root/Data Sources. SSRS can deploy a project, data source, data set, or report and it's dependencies. When in doubt give full access and verify it works, then remove access immiediately. Then trouble shoot deployments. It is probably a folder not being given rights to and then deployment is going for that folder first would be my guess.
I am developing SQL Server Reporting Services (SSRS) reports on SQL Server 2008 R2 and using Report Manager as a method to demonstrate and test reports. I am looking for a way to allow users of the same domain to connect to the Report Manager and run reports via a browser (not SharePoint) without letting the user have too much access to the data source. I currently have each user listed as db_owner for the database that the datasets and data source are associated with. I would like to limit this access and I have tried db_datareader but this level does not allow the user to run the reports and gives the user this error: “Cannot create a connection to data source 'DBname'. (rsErrorOpeningConnection)”.
My method of adding a user to The Report Manager site: I select the ‘Security’ tab under ‘Site Settings’ and then select ‘New Role Assignment’ adding the user as a ‘System User’. I then select ‘Folder Settings’ on the toolbar and again select ‘New Role Assignment’ adding the user as a ‘Browser’. I have tried adding a user as a ‘Content Manager’ but they still have the same error when it comes to the data source.
My method of adding a user to the data source: select new login from the Security tab for the server, add domain\username to ‘Login name:’, use Windows authentication and change the default database from master to the database that is the reports data source. I then select ‘User Mapping’ and put a check next to the database that is the data source. In the ‘Database role membership for: DBname’ section I choose db_owner and public is already selected. I have included screenshots below.
My question is what ‘Database role membership’ can I use for SSRS and Report Manager that would not be as broad as db_owner and would have the best security? I have tried db_datareader but then the user cannot connect to the data source when they run the report.
I have researched this question but I have not found any details accept for adding the user as a db_owner as I described. MSDN acts as if the settings in Report Manager are all that you need to set for the user/report to have access to the data source. I have tried only using the Report Manager settings with both settings for a data source, shared and imbedded with no luck.
Thank you in advance
Typically, the data sources in SSRS will be set to use a fixed account, either a Windows account or SQL authentication. This account should be given minimal privileges to the database: db_datareader is common.
Then security to the report is controlled through Report Manager as you describe above. this avoids the need for changing security on the database itself with changes in user permissions.
But the approach you describe above should work as well. The error you see when the user has db_datareader access is surprising if your query is a standard SQL query selecting from tables. If you are using Stored Procedures, you need to grant access to those as well. Use a test user account that is set to db_datareader; see if you can connect and execute your query through SQL Server Management Studio.
Depending on your security requirements, I would use a dedicated account for database access from the reports, say "ReportReader." Develop and test your reports accessing the databases as this user, and make sure the user has minimal access, read-only and/or limited to only the tables or procedures they need to execute.
The credentials used to access the database are set in the properties of the datasource. This is one reason that Shared datasources are often used, and the reports are linked to the shared datasources:
The screenshot shows a SQL server authenticated account in use. This could just as easily be a fixed Active Directory account; check the "Use as Windows credentials when..." in that case.