sdi_rob


I am having a problem with permissions using Windows groups. I have a database (database1) that has permissions granted via Windows groups. Two groups (group1 and group2) are members of the db_datareader role in database1, and this work fine. Do to the number of tables that get created during our work, using db_datareader is the easiest way to keep up with permissions without creating a maintenance problem. Now I have a table that I want to add to this database, but I only want group2 to have select permission on this one table which is a problem because group1 has the db_datareader role. So I thought I could create a view in this database to the restricted table that I put in database2. Then in database2 I only added group2 as a user with the permission to select from this table. Unfortunately the group membership does not seem to get interpretted correctly in database2 and no one can successfult select from the view in database1.

In other words, user1 who belongs to group1 connects to database1 and cannot select from the restricted view -- this is what I would expect. However, when user2 who belongs to group2 connects to database1 they also cannot select from the restricted view -- not the behvior I would expect. Now, if I make user2 a user in database2 with select on the restricted table then user2 can connect to database1 and successfuly get data from the restricted view. So it looks like the fact that user2 belongs to group2 is never passed to database2 via the select from the view on database1. Is this indeed the way that Windows group security is working or is meant to work in SQL Server

I realize I could solve this simplified version of the problem by creating my own role in database1 for group1 etc., but I am trying to solve a bigger problem in our environment that has hundreds of databases across numerous servers.

Thanks

Rob




Re: Permissions with Windows groups and view to other databases

Laurentiu Cristofor


Why not simply deny SELECT permission to group1 for that particular table The rule that you need to remember is that a deny will trump a grant, so the deny will take precedence over the db_datareader membership.

Thanks

Laurentiu







Re: Permissions with Windows groups and view to other databases

sdi_rob

Well, that won't quite work. The two Windows groups we are talking about have some overlapping members, but one group is not a complete subset of the other. So if I deny SELECT to group1 then some people that I want to access the data (group2) because they are in both groups and as you point out deny has a higher priority. Is there any reason group permissions are not valid in database2 when selecting from the view in database1






Re: Permissions with Windows groups and view to other databases

Raul Garcia - MS

This is the expected behavior; but it sounds like you may be trying to attempt cross-database ownership chaining (also known as CDOC, look for ¡°Using ownership chains¡± topic in BOL). CDOC is a feature that is disabled by default and we recommend against using it because of the security risks inherent from this feature. For more information on CDOC look for ¡°Using ownership chains¡± topic in BOL.

The reason why user2 is failing to access the table is that there is a separate user token for database1 and database2 (both derived from the same Windows login token). On database1 the user2 token will look similar to this:

Primary identity:

¡¤ user2, Windows user

Secondary identities:

¡¤ group2, Windows group

¡¤ db_datareader, role

When accessing the view, the permissions are checked against this token, and they will succeed, but the view is making reference to database2.<some_schema>.restricted_table, therefore it is necessary to create a token for database2.

On your first attempt (without creating a user in Database2, and granting permission to access the table) the user token creation process for database2 should have failed with a ¡°user cannot access this database¡±-type of error.

Here are a few potential workarounds that may help you:

Instead of using db_datareader you can use different schemas and grant SELECT based on the schemas to differentiate groups, for example:

GRANT SELECT ON SCHEMA::[Schema_group1] TO group1

GRANT SELECT ON SCHEMA::[Schema_group2] TO group2

GRANT SELECT ON SCHEMA::[Schema_all] TO group1, group2

That way the SELECT permission would be restricted to only the schemas you defined.

Another alternative for cross-DB access could be using signatures, similar to the one I described in the following article: http://blogs.msdn.com/raulga/archive/2006/10/30/using-a-digital-signature-as-a-secondary-identity-to-replace-cross-database-ownership-chaining.aspx

Please, let us know if any of this alternatives worked for you or if you have any additional questions.

Thanks a lot,

-Raul Garcia

SDE/T

SQL Server Engine