Ensuring correct permissions

  • 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

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

  • 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.

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


    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.

    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

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

  • 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

Viewing 4 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic. Login to reply