This is for SQL Server 2005 or later, but I’d be interested to know if SQL Server 2000 works in the same way. Consider the following situation.
Two SQL Server Windows Authentication logins whose Login name is a Windows group:
MyDomain\Group1
MyDomain\Group2
A database with two users that are mapped to these logins:
USE MyDatabase
CREATE USER [User1] FOR LOGIN [MyDomain\Group1]
CREATE USER [User2] FOR LOGIN [MyDomain\Group2]
User1 and User2 are granted disjoint permissions in the database, e.g.:
GRANT SELECT ON Table1 TO User1
DENY SELECT ON Table1 TO User2
GRANT SELECT ON Table2 TO User2
DENY SELECT ON Table2 TO User1
A client connects to SQL Server using a Windows Identity that is a member of both groups MyDomain\Group1 and MyDomain\Group2.
Which database user is the client mapped to? I.e. does SELECT USER_NAME() return User1or User2?
What permissions does the client have? Is there a defined precedence which determines whether the client connects as User1 or User2? Where is this documented in BOL?
Background
This concerns a database which is currently accessed by multiple applications, each of which currently has its own SQL Server login, and has application-specific permissions on database objects.
I want to switch to using Windows Authentication to improve security, and I’d prefer to use Windows Groups rather than users for flexibility (I don’t want the DBAs to have to manage logins for all the individual users).
However a given user may use multiple applications (and hence be a member of multiple Windows Groups that map to SQL logins), hence the potential for ambiguity in the mapping of a connection to a database user.
I’ve googled and searched Books Online, and can’t find explicit information on how such ambiguity is resolved (e.g. precedence rules).
Any tips and best practices would be welcome in addition to an answer to the questions above.
That’s an interesting question.
I’d assume that your client should have no access at all to those tables, ad DENY takes precedence over GRANT. In SQL Server, there is an exception to the DENY-overrides-GRANT principle though: when a GRANT is done on column level, it will allow access even if the table as a whole has been denied access, as MSDN states.
Edit: To understand what applies it is important to notice that the Logins (to the server) are not the same as the database users. Users which logged on through the means of a Windows group membership will get an implicitly created user, and permissions will need to be applied on that. See also this blog article for more information.