SQL Security / windows logins / AD groups

I am wondering what is a solution for this issue I am having in my environment.  Currently I have sql servers that host several dbs that are being used by different applications.  I grant access via AD groups b/c I do  not want to manage access at an individual windows login level due to the number of people who access dbs on servers.

The issue I am having is that if I have a user which I have placed in an AD group, for example, ADGroupA and ADGroupA  is given access, for example, to DatabaseA, but that user is also in an AD group called  ADGroupB which does not have access to DatabaseA then the user will NOT be able to access DatabaseA UNLESS I give that AD group called ADGroupB access to DatabaseA.  However, in reality the ADGroupB should not have access to DatabaseA.  This happens all the time  b/c we are hosting mulitple dbs that are supporting multiple apps and I have users who support both apps.

I am trying to find a solution around this issue wherein we have users in multiple AD groups, but the AD groups should NOT have access to the same dbs.

I hope this has made sense and if anyone has run into this issue before and knows of a workaround or fix I would really appreciate it.
jwa082276Asked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

MrC63Commented:
This is the "triple state" syndrome.  Members of Group A must have access to certain databases, and members of Group B must have access to certain other databases.

The trick is that there are some members who should have access to both sets of databases.  So now you need a Group C, which would then be granted access to both Group A and Group B databases.

Essentially, you need a third A/D group, because you actually have three options: A, B, or Both (C) -- hence the term triple state.

The nice part is that it's easy to assign or remove a person, via A/D, into one of the three groups depending on what they should have access to.  In future, you may have to develop additional groups to accommodate further database restrictions.
0
jwa082276Author Commented:
So, do you feel that having a third AD group is really the only way around this?
0
MrC63Commented:
Yes.  

Your only other option is to place a specific user in Group A (or perhaps Group B), and then manually assign this person with specific access levels where appropriate.  You've already acknowledged, and I fully agree, that this is not efficient.

The solution is to create one, or possibly even more than one, A/D groups.  Assign the appropriate SQL access to each group, and then add the users to one or more of the appropriate groups.

In future you may find that you need to create 4 or 5 groups (or more), but with the proper group definitions you would simpler control user access by placing a user in, e.g. 2 of the 5 groups to provide the appropriate access.  If the groups and group access are defined properly, it's much easier to assign a person to a group than it is to go through a list of SQL databases.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft SQL Server 2008

From novice to tech pro — start learning today.