Securing SSRS report parameter - reporting-services

I have created an SSRS report which I am using in Asp.net website. Reports accepts server, database,user and password to create connection string dynamically. Dynamic connection string is required because user can select a database at the time of log-in and that database need to be used for SSRS.
One requirement is such that user should be able to create SSRS report himself. For the purpose I provided guideline that how to create parameters that are require data-source's dynamic connection string.
One possible problem I thought is if user do not make parameters as hidden, he will have database credential in clear text.
I thought of adding encryption at asp.net website and decryption in SSRS report but decryption function/code will be easily accessible at the time of designing.
Any idea how to overcome the situation?

I suggested that the OP should read the following documentation:
Specify Credential and Connection Information for Report Data Sources
This were the remarks made by the OP:
Prompt the user for credentials :Not possible because some users can view report with provided website user/password. He will have no idea about DB.
Store credentials: Not possible because user will see data in website as well as in report by database selected at the time of log-in. Database selection option is given at the time of log-in in website because there would be more than one database. so one report will show different data based on selected DB by the user.
Use Windows integrated security : Not possible because most of our client are not allowing use to use integrated security for database access. we need to use their provided credentials for all database access.
Use no credentials : we need to use client provided credentials for all database access. Correct me if i missed something from that article
This is my response and answer to the presented problem:
You require a user to login to your website, as soon as the user is logged in you should be able to know who this user is. This also means that you can give a user specific rights/access to your application.
So you can use the Stored Credentials and more specifically use the Integrated Security.
Type | Context for network connection | Data Source
-------------------- | -------------------------------- | -----------------
Integrated security | Impersonate the current user | For all data source types, connect using the current user account
I believe the following documentation might be exactly what you're looking for.
How to: Secure Connection Strings When Using Data Source Controls
I would strongly recommend creating a new table containing data that specifies the different access levels to then have a junction table with the user table. This will make it easy to determine which user has access to which report and allow for an easy implementatuon of the Integraded Security.

Related

SSRS - Impersonate user

I have a SSRS report for which the Datasource is connected via Database credentials. Now I wanted to restrict a parameter dropdown based on the user using the report.
I tried impersonating the user but it didnt work.
I tried getting the User!UserID within SSRS, but it didn't work.
How can I get the Windows login of the user? Is there any other way or am I missing anything?
Edit -
Not everyone in the organisation has got access to the Database, hence we use the Database user login. But we have a table which holds the AD login and using that I need to restrict the drop down lists in the parameter.
You'll have to change the credentials on the datasource to use windows authentication. If this is a shared datasource you might have to create a new datasource that use windows authentication and point your datasets to that instead.

SSRS Data Driven Subscription Data Source Credentials Configuration

I am creating a data driven subscription and that requires you to stored credentials. However, they want want a link to the report embedded in the email. If the user clicks the link then stored credentials will be what is authenticated and not the actual user.
They would like the user to be prompted for authentication when they manually execute the report. Here are a couple of things I was considering:
I think I can accomplish this by creating a copy of the report that uses a different data source configured to prompt the user for credentials and use the URL to this report to include in the data driven subscription.
I don't think I can do this, in sql update the Credential Retrieval to go from Using the Following Credentials to Prompt the User for Credentials. However, if you switch it back to use the setting Using the Following Credentials, then I will need to reapply the username and password. Not quite for sure how to do that programmatically.
Does anybody else have an idea on how to handle this?

How do you block users from accessing tables directly?

First, I'm not a MS Access developer. However I've got a new job and have to do some MS Access development. I'll be working with another developer who has experience at this; at least more than I have.
One thing he showed me is that users will get into this MS Access application, which goes into the forms, do whatever it is they do there and then bang out of the forms application to get direct access to the tables of the database. (The Access application is a front end to a SQL Server 2005 database.) Since the end users have direct access to the SQL tables, well you can just imagine what sort of mischief they can get into. (The Access application was written by a contractor who left with the application unfinished.)
So my question is this: how can we prevent end users from getting out of the Access application to directly interact with the SQL tables? I would think this is possible, but like I said I'm not an Office developer so I've no idea how it would be done, nor even what sort of things I'd look for.
The Access application is written in MS Access 2007.
#rod
Generally the level of security MS Access is providing is not very impressive. But it gives you some sort of security preventing novice users accessing unwanted information.
look for:
Compiling the database to ACCDE, MDE
provide custom ribbon with your own buttons
Disable the "Navigation" pane : http://www.access-programmers.co.uk/forums/showthread.php?t=187697
Disable the settings via right click.
Use AutoExe function to check if NavigationPAne is deactivated, and reboot database if necessary
Disable the "bypass startup option" key: http://www.access-programmers.co.uk/forums/showthread.php?t=91984
prevent database to load if the DB is not in .accde or .mde format. Again this is within the AutoEXE function to check.
Some useful research/investment would be.
Custom ribbon creator for MS access which will help you to provide your own buttons/ribbons (I used ribboncreator)
Providing membership/user account. since you already have dedicated SQL server you can save user credentials in the back-end tables hiding from front-end. Check user has access by writing stored procedures/functions.
Write function to gather errors, activities and uploads to a LOG table and monitor activities. use web-services + MSXML2.XMLHTTP + async for this task.}
Create a UI for the users to navigate your application. The most basic thing is just a form that has buttons to open all other forms the users need to access in your application.
Then use the ribbon to navigate to "File" -> "Options" -> "Current Database".
Select the form from the step above as "Display form" for the application and then uncheck all the following options "Use Access Special Keys", "Display Navigation Pane", "Allow Full Menus", "Allow Default Shortcut Menus".
This will start you Access application and show the selected form without any of the standard UI for working with tables or the design of other objects in your application.
But please be aware that this is just protection against normal users making accidental mistakes by changing stuff they are not supposed to change. This will not deter a malicious and knowledgeable attacker.
If you want open your application for development, hold down the SHIFT-Key while opening the file.
Another option outside of Access is to deny an AD group with read/write access to your SQL tables the DELETE permission. I was able to do this successfully using Access 2013 and Microsoft SQL Server Management Studio 2012. This post discusses the command.
DENY DELETE ON tablename to [DOMAIN\groupname];
Users in the AD group are able to modify and delete data through the UI we have created, but unable to open the table, select a line, and hit the delete key. They receive the following error: "ODBC--delete on a linked table 'tablename' failed....The DELETE permission was denied on the object ...."

SQL Server - Scripting CREATE USER WITHOUT LOGIN

I have a SQL Server instance using SQL Authentication only. I will have only two users and one database on this instance. The SA has a user name of XX. I have another user and lets say that user is X. And, in my create scripts, I am adding X as a user on the server and then on the one database that is there.
If XX is the SA (created when installing SQL Server) there is no need for me to explicitly map XX to any database, correct?
I am a little confused over the CREATE USER WITHOUT LOGIN. If the above is true would I ever need to script the addition of X to the one database WITHOUT LOGIN? What is the significance of WITHOUT LOGIN? Under what conditions would anyone what to do that?
Thank you.
Users without login were added to replace application roles.
Loginless users are usefull for impersonation, in order to gain necessary permissions. They allow users to authenticate to the instance with their own credentials, therefore making SQL Server able to audit activity to their login, while impersonating the loginless user on the database context.
Simple impersonation example:
SELECT SUSER_NAME(), USER_NAME();
GO
CREATE USER loginless_user_4test
WITHOUT LOGIN
GO
EXECUTE AS USER = 'loginless_user_4test'
GO
SELECT SUSER_NAME(), USER_NAME();
GO
REVERT --as long as you haven't issued "EXECUTE AS ... WITH NO REVERT", you can go back to previous context
GO

SSRS report subscriptions cannot be created

I am not able to create subscriptions for SSRS reports as it gives the following error:
Subscriptions cannot be created because the credentials used to run
the report are not stored, or if a linked report, the link is no
longer valid.
My set up is as following:
ServerA - Database Server
ServerB - Report Server
MachineC - Internet explorer to view the reports
So I am viewing reports on Machine C, IE, and ServerB connects to ServerA for Datasource.
The problem sounds like the report expects the user to provide credentials when it is viewed. When you create a subscription, it does not have the credentials to execute the report.
Go to the report, click the properties tab, then choose Data Sources in the left pane.
Are you using a shared data source? Is it using Windows integrated security? If so, can you change it to use a service account made just to run these reports? You may need to view these properties by viewing the data source itself.
If it is a custom data source is the option "Credentials supplied by the user running the report" selected? If so, can you change it to "Credentials stored securely in the report server"?
Either way, if you want to set up a subscription, I have made it work by providing credentials in the data source rather than have the user input them.
If you are worried about security, I would suggest managing that on the report level rather than the data source level.
What the error does not make clear is, in order to be able to subscribe to a report not only must the data source be set to "Credentials stored securely in the report server" you must also not select the option "Impersonate the authenticated user after a connection has been made to the data source".
The way I did was to create a new data source in the report builder and explicitly provided the username and password there to be used.
Then, used that username password with the new data source with the report and voila it worked.
I faced same issue as you, and i found its solution, as #richard said already that it is related to credential of data source you use for your deployed report.
To resolve it Follow these steps:
1. Right click on your shared Data source which you use in your deployed report.
2. Click On Edit Button.
3. a new window will open click on Credential from left pane, Select Use this user name and password then click ok.
4. Check on Save these credential option you get on to previous screen.
5. Test connection and if succeed click ok and deploy your project on report server.
For reference plese look at screen shot given below:
Thanks.