Evening,
I would like some practical confirmation in relation to an issue we are having.
We have a K2/SourceCode solution that turns upon the successful use of EXECUTE AS with Sql Server 2008 R2.
We have no direct control over how this solution is implemented, i.e. we cannot modify the queries that are submitted to the Sql Server engine. We can, of course, capture them using Profiler, and they tend to follow this pattern:
DECLARE #cookie VARBINARY(100);
EXECUTE AS LOGIN = 'DOMAIN\username' WITH COOKIE INTO #cookie;
SELECT #cookie;
exec [dbo].[SomeStoredProcedure] /* ... various params ...*/
exec sp_executesql N'REVERT WITH COOKIE = #cookie;',N'#cookie varbinary(100)',#cookie=/* some cookie value */
So what is happening is that [SomeStoredProcedure] is being executed in the security context of the user [Domain\username], with the service (application) account impersonating that user. Again, I emphasise that we have no control over this pattern. That's what the app does.
Outwardly this behaviour is perfectly-desirable, because we want things arranged in such a way that the stored procedure is effectively executed by whichever user is at the front-end of the application at the time.
However, these queries were consistently failing, and our investigation eventually led us to this, from the Sql Server documentation (my emphasis):
Specifying a User or Login Name
The user or login name specified in EXECUTE AS must exist as a principal in
sys.database_principals or sys.server_principals, respectively, or the
EXECUTE AS statement fails. Additionally, IMPERSONATE permissions
must be granted on the principal. Unless the caller is the database
owner, or is a member of the sysadmin fixed server role, the principal
must exist even when the user is accessing the database or instance of
SQL Server through a Windows group membership. For example, assume the
following conditions: CompanyDomain\SQLUsers group has access to the
Sales database. CompanyDomain\SqlUser1 is a member of SQLUsers and,
therefore, has implicit access to the Sales database. Although
CompanyDomain\SqlUser1 has access to the database through membership
in the SQLUsers group, the statement EXECUTE AS USER =
'CompanyDomain\SqlUser1' fails because CompanyDomain\SqlUser1 does not
exist as a principal in the database. If the user is orphaned (the
associated login no longer exists), and the user was not created with
WITHOUT LOGIN, EXECUTE AS will fail for the user.
We have a group of around 30 end users who need to be able to use this application, and the requirement is that the application security account must be able to impersonate any one of those users for the execution of these stored procedures. This requirement is fixed and non-negotiable.
The above documentation seems to preclude the possibility of meeting this requirement by adding all 30 users to an AD group, adding that group as a SQL Server login, and granting the group adequate permissions. And our practical testing results support this - EXECUTE AS fails.
Take one of those Users and give them their own, individual AD login on the Sql Server and the solution will work successfully for that user. EXECUTE AS succeeds, and the necessary permissions do not need to be assigned to the individual account because they have already been assigned by way of the AD group.
So, at this point, I am reasonably confident that I know what I am going to have to do. The requirement will be that every user has to have their AD account added as an individual Sql Server Windows login.
However, before I proceed with the rigmarole of implementing this, I wanted to ask the question publicly: is there something I am missing here?
It's instructive to imagine a similar scenario on an Enterprise-scale application - this model would somewhat fall apart, because of the need to add hundreds of individual, Windows-authenticated, Sql Server logins. Setting aside the possibility of automating this process, and the administrative burden that would ultimately result, I'm just finding it a bit of a stretch to imagine that this is the only way.
I would be grateful for confirmation and/or comments.
Thanks
Robert
As no-one has responded to the contrary (or indeed at all) we have assumed that BOL is accurate, and that there is no alternative resolution.
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.
We have MS SQL Server 2012 in production use and MS AD.
Let me explain in short what our concept of assigning user permissions is like.
For certain user group that has some access to a certain application we create AD group and assign AD users to it. Since this application needs to access data in other DB, we add that group to that DB as well and set access/execute rights to needed objects (either specific object or schemas).
Since certain people use other applications and DBs, they are added to other AD groups as well. Those groups, by no surprise, need to access some objects to second database too.
So we have situation when certain users are in few different AD groups with different accesses to the same objects in a DB. That causes lots of "strange" behaviors when, all of a sudden, some user gets denied access to objects in DB.
My questions are:
Is there any way to find out with which privileges (through which AD group) some user got access/denial for certain sql query that was triggered from application?
Can someone explain how sql server handles privileges in such environment?
I'm open for any suggestions on how to handle/set accesses differently altogether but not involving reprogramming applications (only DBA site).
Thank you.
Assuming that you're an admin, you can look at sys.login_token, sys.user_token, and sys.fn_my_permissions() while impersonating the user in question to get some idea. Something like:
execute as login='yourDom\User1';
select * from sys.login_token;
select * from sys.user_token;
select * from sys.fn_my_permission('dbo.someObject', 'OBJECT');
revert;
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 trying to figure out what SQL Server Login gets used when I connect to SQL Server, in code, via a connection string that specifies Integrated Security=No and then specifies a user and password.
Note that I don't mean the user I'm specifying (I do know that of course), but the login that user maps to. I'm just now reading about logins vs users in SQL Server, and one point that is hammered home is that you always, always, always need a login to connect, and then a user per database that login needs to access. So I am looking in SSMS for the login that maps to the user I always specify on the databases I care about, but I see no such login.
Fyi, the reason I am asking, is I need to permission a new legacy app for this database, and the app is coded to use SQL Server authentication. I am trying to determine if I simply need users on the necessary database, or if I need to create a login. But now I've gotten myself curious about the general question itself.
Edit - a quick query of syslogins shows only 2 logins. So, my theory that SQLS was maintaining trivial '1 per user' logins but SSMS was hiding them, appears not to be the case
Edit - Querying syslogins, or sys.server_principals, appears to be misleading. On a database for which I have 2 different working SQLS (not Win) logins, I logged in as each and did select * from sys.server_principals. Two different answers: each time I got sa and the login I was logged in as. I would not see the 'other' login, though it was clearly there. I am guessing this may have something to do with schemas, which I also know little about. In any case, I am guessing that generally, logins do in fact exist for all users, though I will not see all these logins when I connect to SSMS as any one login. Does this sound right?
Solved (sort of)
From playing around, on a database on which I have sa, it is clear that SSMS only shows you all logins if you are sa, or perhaps have that specific permission. Otherwise, your view of logins is restricted. Therefore there is no real mystery as to why I was not seeing logins I was expecting. Apparently SSMS hides them. I say 'sort of' and 'apparently' because I never came across anything documenting this. It is just an observation.
Thanks to all for your help.
It is a server-level login unless you are connecting to a contained database. If you mean the database user that the server-level login maps to, you can find out using:
SELECT u.name
FROM sys.server_principals AS l
INNER JOIN sys.database_principals AS u
ON l.sid = u.sid
WHERE l.name = 'user id in your connection string';
If you are not using a contained database, this is how you would provision your user:
USE master;
GO
CREATE LOGIN your_login_name
WITH PASSWORD = 'f00b#r!', CHECK_POLICY = OFF;
GO
USE your_database;
GO
CREATE USER your_login_name -- doesn't have to match, but should for sanity
FROM LOGIN [your_login_name];
GO
-- then apply permissions of course.
In general logins maps to a database user
So for instance if by some unfortunate circumstance the app expected database owner access
You'd create this here login on the server (if it's not already there) and then map it to the dbo user in the database in question.
If it's not a built in user, then you are going to have to look at a db that this legacy app can already access, find out which user it's mapped to
Create that user on your new DB, set the required permission roles etc
Then map the login to it.
There are some subtle differences between sql server versions, so it's hard to do a step by step
If the user the apps login maps to is a custom one, then you are going to have to figure out an equivalent in the new database. Doesn't have to have the same name though (unless the app is using that) and it could even have more permissions.
We use merge replication in one of our programs and I would like to allow our users to force synchronization of their laptops with the publisher on an as-needed basis (we are using push subscriptions). I got this working using REPLMERG.EXE (see my previous question).
However, when the users trid to run the script they received the following error message:
Only members of the sysadmin or db_owner roles can perform this operation.
...
exec sp_MSreplcheck_subscribe
...
If I add the users' group login as a db_owner on their local subscription database then the script works correctly. The problem is that they also end up with full access to every table in their local database, which is not something we can live with.
Allowing users in a merge replication topology to synchronize their local push subscriptions on-demand without giving them full-blown control of the db seems like a pretty straightforward use case, but I can't get it working.
From Replication Agent Security Model:
Merge Agent for a pull subscription
The Windows account under which the
agent runs is used when it makes
connections to the Subscriber. This
account must at minimum be a member of the db_owner fixed database role in
the subscription database.
The account that is used to connect to the Publisher and Distributor must:
Be a member of the PAL.
Be a login associated with a user in the publication database.
Be a login associated with a user in the distribution database. The
user can be the Guest user.
Have read permissions on the snapshot share.
Therefore is a documented requirement of Merge replication that the account running the replication agent (replmerge.exe) be member of db_owner. If you this does not work for you situation, then Merge replication is not the right technology to use, since it has a requirement you cannot fill.
Now int theory an application can do whatever REPLMERGE does from another application, and you can leverage the power of code signing to run a set of wrapper procedures that are granted dbo privileges via code signing, thus not needing the elevated login, but that's just theory since the replication procedures are not exactly easy to use nor are they documented at the level one needs to re-implement the agents...
The suscriber must have the right to replicate data definition instructions sent on the publisher. Some of these instructions might even lead to the reinitialisation of the subscriber, which requires the right to a drop\recreate the corresponding database. In these conditions, security requirements as set by Microsoft sound quite sensible.
As Remus and Philippe have pointed out, db_owner on the subscription db is a hard requirement for synchronizing a merge push subscription. However, we really wanted to allow our users to synchronize their own laptop without giving them full db_owner rights to the database.
Our solution was to enable mixed mode authentication on the subscribers and add a SQL Server user whose sole purpose was to enable our end users to synchronize their laptops. The SQL Server user, 'syncuser', was given the db_owner role on the local subscription database. Then, when we called replmerg.exe from within the program, we specified the following switches:
-SubscriberSecurityMode 0 -SubscriberLogin syncuser -SubscriberPassword 4w3$0m3_P4$$w0Rd