Ensuring correct permissions

SQLServerCentral is supported by Red Gate Software Ltd.

Popular Topics

Home

Members

Calendar

Who's On

Home » SQL Server 2005 » SQL Server 2005 Security » Ensuring correct permissions

Ensuring correct permissions

Rate Topic

Display Mode

Topic Options

Author

Message

webrunner

Posted Friday, November 02, 2012 10:01 AM

SSCrazy

Group: General Forum Members
Last Login: Wednesday, May 15, 2013 3:05 PM
Points: 2,117, Visits: 2,209

Hi everyone,

I've been having some annoyances regarding SQL Server permissions lately. Specifically, it seems that although I am putting Windows logins (mostly AD but also some NT) into the correct Windows groups, and (it would seem) properly adding the permissions -- usually via db_datawriter and db_datareader roles -- for those groups in SQL Server, users claim they can't see databases etc.

Could someone suggest a way I can confirm the results of the permissions I think I'm setting, or a way to get users to verify this? It's very frustrating to believe I've set the correct permissions only to be told I apparently haven't. It would be great if there were a visual tool to see permissions, but at the very least I would like to be able to be more confident when I add someone to a group in Windows that they'll be able to access the databases properly.

Thanks for any help!

- webrunner

-------------------
"The chemistry must be respected." - Walter White

"A SQL query walks into a bar and sees two tables. He walks up to them and says 'Can I join you?'"
Ref.: http://tkyte.blogspot.com/2009/02/sql-joke.html

Post #1380479

Steve Jones - SSC Editor

Posted Friday, November 02, 2012 10:17 AM

SSC-Dedicated

Group: Administrators
Last Login: Today @ 11:02 AM
Points: 31,410, Visits: 13,725

Check that the Windows groups have logins assigned in SQL Server.

Check any other Windows groups that have logins for DENY permissions. NOTE that I hate DENY permissions for this reason.

If the Windows groups have logins, check that they are mapped to users in databases. If databases are restored, this can be broken.

Check the same thing for permissions and roles. MAke sure not DENYs exist.

fn_my_permissions allows you to check permissions. However if users cannot see databases, this is something else.

Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help

Post #1380491

webrunner

Posted Friday, November 02, 2012 10:38 AM

SSCrazy

Group: General Forum Members
Last Login: Wednesday, May 15, 2013 3:05 PM
Points: 2,117, Visits: 2,209

Steve Jones - SSC Editor (11/2/2012)

Thanks, Steve, for this help. I hadn't considered DENY or the fn_my_permissions.

Turns out the error in this case was the one described here, Error 916. I think it's because a database was set to AutoClose, which I hadn't noticed because it was a vendor-installed database. Apparently this is a bad option to enable, so I'm going to use a script to check for this setting on my other servers.
http://www.mssqltips.com/sqlservertip/2761/sql-server-management-studio-error-916/

Thanks again for your help!

- webrunner

-------------------
"The chemistry must be respected." - Walter White

"A SQL query walks into a bar and sees two tables. He walks up to them and says 'Can I join you?'"
Ref.: http://tkyte.blogspot.com/2009/02/sql-joke.html

Post #1380501

opc.three

Posted Friday, November 02, 2012 11:07 AM

SSCertifiable

Group: General Forum Members
Last Login: Today @ 11:18 AM
Points: 6,698, Visits: 11,725

I'll throw one other technique out there that I use quite a bit. It may not handle things like verifying someone can see something in Object Explorer that they think they should, but it could help with specific database or server-level permissions. Your comment at the very least I would like to be able to be more confident when I add someone to a group in Windows that they'll be able to access the databases properly is aligned with my thought process as well and is exactly why I take the extra step myself before responding to users that they have been granted a specific permission. After setting up the Login I'll run something along these lines:

EXECUTE AS LOGIN = 'domain\winodows.user';
GO
SELECT  SUSER_SNAME() AS impersonated_security_context
GO
BEGIN TRAN
-- try the operation the login is supposed to be able to perform
ROLLBACK
GO
REVERT
GO
SELECT  SUSER_SNAME() AS original_security_context
GO

__________________________________________________________________________________________________
There are no special teachers of virtue, because virtue is taught by the whole community. --Plato

Believe you can and you're halfway there. --Theodore Roosevelt

Everything Should Be Made as Simple as Possible, But Not Simpler --Albert Einstein

The significant problems we face cannot be solved at the same level of thinking we were at when we created them. --Albert Einstein

1 apple is not exactly 1/8 of 8 apples. Because there are no absolutely identical apples. --Giordy

Post #1380516

« Prev Topic | Next Topic »

Permissions