I am working in MS SQL Server 2014. I have to send data from a certain DB (call it "DB_old") to an external application. This application reads data from DB_old via a connection that is built with a certain SQL service account. I just discovered that certain columns in tables from DB_old are not allowed to be loaded into this external application. So:
1) I removed this SQL service account's access to DB_old;
2) I created a new DB (call it "DB_new") and views on DB_new that select the permissible columns from DB_old;
3) I granted the SQL service account access to all views on DB_new
I thought that the above would resolve my data exposure problem. However, when I log into SSMS with the given SQL service account (which is successful) and try to run some simple SELECTs against the views on DB_new, I get the following error:
The server principal "SQL_service_account" is not able to access the database "DB_old" under the current security context.
I am not sure how to resolve this seeming ownership chain problem. To be clear, I am the owner of DB_new and all schemas underneath it, but I am not the owner of DB_old or any schemas underneath it. And, I cannot allow SQL_service_account to select any tables under DB_old. And, I cannot build my views on DB_old. They have to be built on DB_new.
What is the best way to resolve this ownership chain problem?
Related
I have a report that accesses sensitive data and I'm required to have the user log in to the SSRS portal and then again into the data source to make sure the data isn't viewed by the wrong staff.
I feel like I've tried everything at this point, but no matter what I try I cannot access a data source by logging in to it from an SSRS report. I've tried:
Logging in with a windows authenticated db_owner account. Produces "Cannot create a connection to data source" error without any other info.
Logging in with a SQL authenticated account with select permissions to the view used by the data source with the same result.
Using current users credentials, same result.
I've enable remote errors on SSRS, but cannot locate a log of errors and the errors produced on SSRS portal have not changed.
I've read just about every tutorial about creating logins and users and how to set them up to access data sources.
Voodoo
Psychics
Therapists
All users have access through to the data when i run a select statement in SSMS, so I'm stumped. I've messed around with giving explicit rights to Connect, Select, Authenticate for the Server, DB, view and still no luck.
Are your users in Active Directory, or are you using SQL Authentication? Because if your users are in AD you can do this easily. I think you need the SSRS in Native Mode not SharePoint mode too, but I'm not 100% certain about that.
Create an AD group to hold privileged users, I'll call it
MyOU\SSRSViewers
Put all the users who can access this sensitive data in this group
In SSRS, in the security settings for the reports, data sets, and
data sources, give this group read or read/execute permissions
In the database create stored procedures to access your sensitive
data (you can give data_reader access instead, but if you want to
lock down data then access through stored procedures is much easier
to control).
In the database, create a USER for the MyOU\SSRSViewers group. At
the server level users need PUBLIC role, this lets them see the
server at all. They probably already inherit that from elsewhere,
but if not you can tie it to this group, too.
Grant EXECUTE permission on those stored procedures to the
MyOU\SSRSViewers user (it's a group, but it looks like a user in
SSMS, don't worry)
Create or modify your report data sources to use WINDOWS
AUTHENTICATION method and data sets to call the stored procedures to
get the data instead of SELECT statements.
Make sure you don't have any explicit deny permissions on the data
in question, or if you do at least test them very carefully, because
they can mess up this access (by denying access to somebody who
should have it, not by leaking your data)
If you do all this, here's how access works - when a users first goes to SSRS to view a report, SSRS will check to see if the user has permission to see the (empty) report. If they are in the group (or have permissions another way, so this is hard for a developer to test on their own machine) they get the empty report.
SSRS then checks the data source (which has no credentials!) to see if they can use it. Again, if in the group, yes. They still don't have data, but they can get the connection details. If they can, SSRS will pass a token from their windows session to the database to see if they can actually get the data.
If they make it this far, SQL will only let them execute the stored procedure (and get the data) if they are in that group with EXECUTE permissions on that stored procedure.
The users don't see these logins, the browser is automatically forwarding their login tokens (not credentials), but authorization is checked at every step and is very secure.
A few notes:
First, your SSRS server has to be in a trusted zone for this to work smoothly, if it is then the browser will pass authentication tokens to SSRS seamlessly. If not, they'll have to "log in" to SSRS every time, which gets old fast. Set this with your Group Policy.
Second, some configurations may include 2-hop authentication, a problem for ordinary NTLM. You may need to set up Delegated Constraints to make this work smoothly.
I didn't do either of these myself, but we had to do both at my company. Neither was particularly painful (or at least the guy who did it didn't complain), but I couldn't tell you how to do either, and I may not be using the ideal descriptions/terms.
Third, this scales well, if you have 3 different types of reports, you can create 3 different groups and your users can be in any combination of groups, getting access to only the data relevant to the groups they are in.
what is the need of user with out log in in SQL Server?
There is a contained database. I have created a user who can log into the contained database.
How to port the database to another server without additional user configuration?
Is the "user with out log" is going to help in this context?
Want to know more about users with out log in
Experts..please share your views
Users that don't have a login are users that exist only at the database level and therefore you cannot log in to the server with them.
They can however be assigned permissions and can be used to sign modules within those databases.
The most common uses I see for them during my day to day work are either loginless users that are created from a certificate which is then used to sign stored procedures, this means that the user actually logging in to SQL server requires very few permissions in the database and all the work is done in the context of the loginless user, helping to increase security.
I also see loginless users that are not created from certificates, but are made owners of schemas or procedures which then execute as owner, similar to the above, this means that the user lgging in only needs execute rights on the procedure, no table access at all.
I am looking for different ways to uniquely identify an application user in SQL Server 2008.
To give some back ground to the issue:
The ASP.NET 4 web application I work with uses an SQL Server 2008 database, there is one SQL Server login and DB User for all connections from the application to database.
We are developing a reporting solution using Crystal Reports where users can write and execute their own reports through the application. The crystal reports can only return data from Views. Each application user will have their own unique login to the server.
The View then uses SELECT SYSTEM_USER() to find the logged in user and restrict data returned from the view.
Is it bad practice to create a distinct login and DB user for each application user? This would mean > 1000 users per DB, across up to 80 databases (Creation of
each log in would be handled through T-SQL, not manually)
What other ways can the user be identified in the View in the DB?
We looked at altering the connection string to include the user id in the Workstation ID, we can use SELECT HOST_NAME() to get the ID, but this seems like abuse of the Workstation ID.
Any other suggestions about how the user can be uniquely identified would be appreciated.
Many thanks
Have you considered using Windows Authentication as apposed to SQL Authentication? That would at least reduce the number of logins & users that would need to be managed.
Y can use external database,file or other resource to store user access to any data when u use msql 2008.
http://msdn.microsoft.com/en-us/library/dd392015%28v=sql.100%29.aspx
That give y change to not mix data with audit elements for performance and security reasons.
Use profiler on your sql server and in profiler is information about ( aplication , user , and host ). So that kind of information y can easy get by audit or from custom trigger on certain database objects.
Your aplication can also have own user table and share the same connection string too all users or give users with windows auth type only public privilege. And use in stored procedures run as command ( run as another user in db).
So y can log any user and give them minimal rights.
Its my firs post here and I actually learning English lol.
There were two solutions that we came up with:
Before the Crystal report is executed, in .Net we can extract the SQL the report (and sub report) will generate, execute the SQL and put the results in a dataset and generate the report from the dataset. The advantage of this is that because we have the SQL, before the SQL executes, we can supply user information to the SQL server session that can be used to identify the user when the SQL is executing.
Have a limited number of SQL Server user logins which can be dynamically assigned to application users. We will have a table which will map the SQL Server Login to an application user just before they run a Crystal report. When they query has finished executing the Login is released. Obviously this means that at busy times we may run out of Logins, but more can be added depending on usage.
In SQL Server I have a many to many relationship between items and active directory groups. I want to build a query, that based on a supplied active directory user, I would be able to query for all items associated to an active directory group if the user is a member of the group.
I went down the road of using IS_Member, but that only works for the currently connected user. The stored procedure will be called by an asp.net web app, which currently connects with a specific sql user account. I don't think I can connect using integrated authentication and impersonation in the web app, because I don't beleive our infrastructure configuration will allow delegation from the user machine, through the web server, then to the db server (3 hop issue).
What can I do here?
Write a C# or VB.NET .exe that queries AD and populates a table in the database with all the users/groups and call it from a SQL job that you execute daily. Then just use the synched up table data to do the comparisons. This way you can avoid all the other complexity of trying to do it on the fly. Group membership doesn't change that often. Even if something changed in AD you can just manually run your "sync job" and things would be ok. You can use Windows.Identity() or whatever it is from ASP.NET to check the username.
The issue you describe is a classic double-hop scenario, which can be (eventually) resolved through the painstaking process known as Kerberos configuration. A lazier workaround would involve passing the credentials from the asp.net application as a variable to a SQL query on your database.
If the SQL Server has the LDAP Server configured as a linked server, you could rewrite your stored procedures to accept the user as an input variable and check to see if the user is a member of an AD group before proceeding. Consider incorporating OPENQUERY into your stored procedures as shown below:
CREATE PROCEDURE CheckAccess
#CurrentUser varchar(max)
AS
IF #CurrentUser IN
(
SELECT CN
FROM OPENQUERY(ADSI,'<LDAP://DC=Your,DC=DomainComponent,DC=com>;(&(CN=*)
(memberOf=CN=YourADGroupName,OU=Your,OU=OrganizationalUnit,OU=Name,DC=Your,DC=DomainComponent,DC=com));CN')
)
THEN
SELECT 'Authorized User'
ELSE
SELECT 'Unauthorized User'
END
If you can, consult with your LDAP admins to make sure you get the group's correct domainComponents and organizationalUnits to tweak the OPENQUERY. One drawback to this is that it can take a while to query your AD group, obviously depending on the size of membership. It can be a pain, but as long as your app can pass the user as a variable, you can leverage OPENQUERY or even query sys.database_principals to check their access.
Background
I am in the process of creating an application (referred to as MyApp) which must read data out from a SQL Server database handled by Navision. Navision users should to be able to use my application, without modifying permissions in the database.
Navision's handling of permissions seems to be on the application layer. It performs the checking of permissions without storing them in the database.
Problem
Navision overwrites users, permissions, and other related objects in the database when synchronizing with the database, so the normal approach of creating a DB user and just using that won't work.
Possible Solution
What I think would be the most appropriate solution is to create a MyApp role in Active-Directory, which grants the necessary permissions on the DB, and add this role to all users.
I do not know how to do this, or even if it's possible. Other solutions, or proposals, are welcome, but please only suggest solutions with can be managed from within ActiveDirectory or Navision.
The server is an SQL Server 2008 server running Navison 5, and the client is Navision 6. I'm using Active Directory for Windows Server 2K8.
EDIT:
My app is a crate creating and designing application. It needs to read out the customers' names and IDs, and a few items in the items table, and that is why I need this functionality
If you use the enhanced security model in NAV, user permissions are synchronized to SQL Server. However, these SQL permissions are mapped to an app role in SQL Server, rather than the user's login. If you use the standard security model, all users map to a single SQL app role which is a super user (less secure).
If you want to access the data in SQL Server using the NAV security model (i.e. through the SQL App roles NAV creates), you should use the CFront API (installed via the SDK option). If you are using NAV 2009 web services are also an option.
If you want to access SQL Server directly, then you will have to manage the permissions yourself using SQL Server. If you create a SQL script to grant permission it is easy to restore anything which NAV might delete during Synchronize Logins.
You can't grant SQL permission from Active Directory exactly as you described. Instead you must map Active Directory groups to either SQL Server logins or NAV Windows Logins (depending on whether you decide to access SQL directly or go through a supported NAV API). Note: the permissions associated with the role are managed in SQL or NAV respectively; not in AD.
From an administration perspective, you can simply add and remove users from this Active Directory group. If you use the NAV enhanced security model each user in the AD group must also have an entry in Windows Logins, and whenever you make changes you must Synchronize Logins. This slight inconvenience is a hangover from the native database.
In general, skipping the NAV layer and reading/writing directly to the DB is not recommended at all as you're bypassing all of NAVs business logic which is stored in the table and report objects in NAV.
What does your app intend to do (broad strokes if you can't get specific) and would using a NAV add-in or dataport be feasible?