September 25, 2014 at 10:19 am
SQL2012:
* I have a AD login DOM1\User1 mapped to db TEST01
* Also have AD Group DOM1\Group1 of which DOM1\User1 is a member and is mapped to db TEST02.
A login attempt is made with DOM1\User1 and database specified: TEST02.
What access path will be used? the DOM1\User1?, the DOM1\Group1?
if you say DOM1\User1...wont there be a login error indicating the database can not be opened.
if the login is successful are you say the DOM1\Group1 path was used? if so, are the permissions additive and SQL automagically knows that DOM1\User1 is mapped to both TEST01 and TEST02?
Or is it a crap shoot and sometimes it users the DOM1\User1 (fails cause TEST02 not mapped) and sometimes DOM1\Group1 (succeeds cause TEST02 mapped)?
Additional complication: Does connection pooling make a difference....in that the pooled connecton is one access path and A new DOM1\User1 connection tries to join to without the database mapping generating an error?
here is an error I'm seeing consistently and want to know if its because of this "double" access path for DOM1\User1 (group and individual):
[font="Courier New"]Error: 18456, Severity: 14, State: 46
Login failed for user 'DOM1\User1'. Reason: Failed to open the database 'TEST02' configured in the login object while revalidating the login on the connection. [CLIENT: xxx.xxx.xxx.xxx]
Error: 18056, Severity: 20, State: 46.
The client was unable to reuse a session with SPID 147, which had been reset for connection pooling. The failure ID is 46. This error may have been caused by an earlier operation failing. Check the error logs for failed operations immediately before this error message.[/font]
Thanks in advance
September 25, 2014 at 11:05 am
You're overthinking it. When the user logs in, they have a superset of all permissions for all of their login paths. They don't log in as one path or the other. So the user has all permissions available to them for all login paths.
For the error, does the database have auto-close enabled?
September 25, 2014 at 1:05 pm
Can you explain this scenario? (this is a true story).
DOMAIN\User1 is a member of DOMAIN\Group1 and DOMAIN\Group2.
DOMAIN\Group1 has SELECT permissions to Database1.Table1.
At the moment the user can successfully select from the table.
Now we add DOMAIN\Group2 with permissions in master. *Exercising the memory* I think it was VIEW SERVER STATE with maybe a SELECT on a specific table.
Suddenly DOMAIN\User1 can't read from Database1.Table1 anymore. Removal of DOMAIN\Group2 solves the problem.
xp_logininfo seems to return the group with a higher priority or something like that.
Derik Hammer
@SQLHammer
www.sqlhammer.com
September 25, 2014 at 1:40 pm
Sounds like a simple case of confusing correlation with causation. Or it didn't happen. Those ar ethe only 2 possible answers. You do not get permissions for one login path only. It's really that simple.
September 25, 2014 at 2:08 pm
Robert is right (of course) your permissions are a combination of all permissions combined. Of course this includes any DENYs you have in either set. If for example you DENYed connect to that database in the group then the user wouldn't be able to connect.
There are a few properties (default database) for example that only come from one or the other. In that particular case it's the individual's login not the group login I believe.
You can try using a couple of stored procedures I put together to get a better view of what's going on.
They collect the permissions information into a single location to make it easier to review.
Once they are on your server try running these one line at a time & reviewing the output:
EXEC sp_srvpermissions @principal = 'User1'
EXEC sp_dbpermissions @dbname = 'all', @principal = 'User1'
EXEC sp_srvpermissions @principal = 'Group1'
EXEC sp_dbpermissions @dbname = 'all', @principal = 'Group1'
Pay special attention to the bottom rowset for any DENYs.
Kenneth FisherI was once offered a wizards hat but it got in the way of my dunce cap.--------------------------------------------------------------------------------For better, quicker answers on T-SQL questions, click on the following... http://www.sqlservercentral.com/articles/Best+Practices/61537/[/url]For better answers on performance questions, click on the following... http://www.sqlservercentral.com/articles/SQLServerCentral/66909/[/url]Link to my Blog Post --> www.SQLStudies.com[/url]
September 25, 2014 at 2:12 pm
Thanks for your replies.
The DENY theory could have been a factor. When this happened I ran into the problem and then my priorities were switched around on me and I had to abandon the investigation.
I will have to try and see if I can reproduce the scenario.
Thanks!
Derik
Derik Hammer
@SQLHammer
www.sqlhammer.com
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply