I have been allocated the responsibility at work of revising the current reporting services authentication process. The aim is to maintain the necessary level of security and also simplify the maintenance/configuration of granting access to the individual reports.
I do NOT have access to the domain controllers to be able to modify or create new AD groups. I have to work with the groups/users that currently exist.
In terms of authentication, it seems that I have the option of using either:
Windows authentication
SQL Server authentication.
Both the report server and the report database will reside on the same server. With this in mind, I understand that Windows authentication is probably a better solution as there is no need to maintain a separate SQL Server table of Users (and their passwords). Granting access to a report once it has been deployed on the report server, would simply involve adding the user/group to the report (load the report in a browser and access the Properties\Security option).
Using the second option of SQL Server authentication does not seem as appropriate as using Windows authentication for the reason the report server and report database are on the same box.
I am using SQL Server 2000 databases. The version of reporting services I have installed is Microsoft SQL Server 2008.
Please could someone let me know if my thinking is correct (i.e. I should go for Windows authentication). Cheers.
Jimmy
Sql Server authentication is not an option for users connecting to SSRS. It is an option for SSRS connecting to databases where it will get its data.
So bottom line, yes, you need to use Windows Authentication for user connections to SSRS. You can use special user names such as "Authenticated Users" or "Everyone" in SSRS to allow broad access.
I understand that you don't have access to AD, but managing the user accounts' membership in AD groups would be much easier than tracking and managing individual access in SSRS.
But without the AD access you can still add Windows/AD accounts to the report permissions and use those. You just create a more complex system, since you need to manage permissions for every individual separately. You can group the reports in folders and secure the folders: the reports can inherit that security.
Related
I created SQL account for an application but how do I restrict or deny the same account not to connect the database using SSMS or Azure data studio by the developers since the developers can view the user information in web.config file.
Thanks,
Sandeep
You can use Azure Active Directory to authenticate your app, so that you don't need to write the username and password in config file.
With Azure AD authentication, you can centrally manage the identities of database users and other Microsoft services in one central location.
Benefits:
It provides an alternative to SQL Server authentication.
It helps stop the proliferation of user identities across servers.
It allows password rotation in a single place.
You can read more details from this document.
Basically the answer to your question is... You can't...
There is no way to identify the client of a certain connection in Azure SQL. What you can do, for example, is restrict access to a certain server using s firewall. But if your dev env is on the same machine as your SSMS that won't work because you're then blocking the dev env as well.
In that case, the best practice is to create a dev database to which all devs have access. In that case, it doesn't matter for you everyone knows the password because it's the dev database.
For production environments, you need to treat database credentials as secrets and thus make sure they are stored in a safe place. When you're using Azure, the KeyVault may be a good place to store the password. This KeyVault has a fine grained way of allowing access to secrets for individuals as well as IT systems.
We currently use SQL 2008 with Windows Authentication disabled, we only allow SQL Mixed for accessing SQL.
We are wanting to switch our version control software to Team Foundation Server, which requires Windows Authentication.
Which ended up being a bit of a problem, I've talked to our DBA and Windows Authentication is not an option, nor is putting SQL on the server where TFS will reside.
Issue is, from what he is telling me, you are unable to just enable Windows Authentication just for a single user, its either on or off for all users.
Is this correct? What other options are there?
You need to have another talk with the DBA.
There are 2 options for authenticating to SQL Server:
Windows Authentication (only)
Both Windows Authentication and SQL Server Authentication
Yes it is true that if you turn on the latter option also known as Mixed Mode, and it applies to the server (which will now accept Windows Auth) - it does not mean that suddenly all valid Windows users will get access to SQL Server!
The Windows logins still have to be added as SQL users (SQL login != SQL user[principal]) and they can then belong to roles etc, so you would only need to add the users for TFS.
In fact, you cannot possibly disable Windows Auth - so I don't see why the DBA should be complaining about "turning on" Windows Auth.
This is probably what you need to do:
Add a new domain group "sqltfs"
Create a SQL user out of the Windows security Group "domain\sqltfs"
Grant all the access required to the new user (or indirectly through a role)
add all the TFS users into the domain group "sqltfs"
This way you can all continue to use SQL logins where it matter (existing code), while still gaining access via TFS -> SQL Server through the domain group membership
This probably belongs on superuser, but I'll take a stab at it. From my SQL 2008 R2 management console, the DB server can run in either pure Windows Auth mode, or mixed Windows auth + SQL auth. It can't run in SQL auth only.
Since you say you're in mixed mode, I can't see why he can't add another user to the DB that uses a windows domain account, rather than a local SQL server account. Mixed mode allows both.
What are the required steps to properly allow domain users access to reports via the Reporting Services web site?
What I've tried:
Added users through Reporting Services site (i.e. http://servername/Reports)
Given users access through SQL Management Studio
Result:
users are continuously prompted by the browser for their credentials and can't log in
I don't know why I didn't think of this before but I:
Added desired domain users to the "SQLServer2005ReportServerUser*$InstanceName*" group on the Windows 2008 machine running SQL Server Reporting Services
Added users to specific roles through reporting services web site (http://servername/reports)
AND now users are able to access the reporting services site!
I've been dealing with this exact issue recently. I still don't know the answer, but I think that at least part of it is to add the users to SSRS-specific groups (create them if needed through the SSRS Configuration manager).
I have some "kiosks" that run under machine specific AD accounts that I would like to deploy reports on. For security reasons I need to verify individual user credentials before allowing access to the reports. Is there a way to do this with reporting services?We are running Reporting Services 2005, but will be upgrading fairly soon.
How about using a custom security extension:
http://technet.microsoft.com/en-us/library/ms152899(SQL.90).aspx
I have built an application that uses SQL Express 2005 and I want to deploy it, but the problem is that anyone who has SQL Management Studio(or something like that) installed on his computer, can connect to my database and change it.
Is there anyway to prevent end-users from seeing or editing the content of my database, even those with the Administrator privileges?
I guess you're referring to the fact that by default SQL Server installs allow Windows and SQL Server Authentication. If you remove the Windows Authentication mode then users will have to connect via SQL Server authentication.
This from http://support.microsoft.com/kb/247931
SQL Server authentication SQL Server
authentication relies on the internal
user list maintained by the SQL Server
computer. This list does not include
Windows NT users, and is specific to
the SQL Server computer. Users are
created and configured using the SQL
Server Enterprise Manager. To use this
authentication method, perform with
the following steps:
• If you connect
through Open Database Connectivity
(ODBC), in the ODBC Administrator,
choose SQL Server authentication when
you configure the data source.
•In
the ActiveX Data Objects (ADO)
connection string, include the
parameters "UID" and "PWD" when you
use ODBC, and "User ID" and "Password"
when you use the SQLOLEDB provider.
I suppose this is not the answer you hoped for but it is unavoidable that anyone with administrative rights will be able to browse and edit information in the database.
You cannot change this.
Perhaps you could consider WHY you want to prevent this kind of access?
I expect you want to prevent tampering or accidental corruption of the data?
If that is the reason then you can go a long way to prevent corruption by adding constraints to your database. Add foreign key constraints, uniqueness constraints, everything that will help prevent data corruption.
Then an administrator would need to deliberately undo these constraints before they tamper, which would prevent most accidental corruption but of course not prevent malicious vandalism.
If you are concerned about protection of your intellectual property, you could encrypt the programmatic components (stored procedures and views and functions). This kind of encryption is not very strong but prevents casual inspection.
Encryption is added by using the
WITH ENCRYPTION
clause in your CREATE or ALTER statements.