3

I am on a SQL Server 2008 where I login with DOMAIN\USER_A

On my database I can see this login is mapped to the user dbo of that database. What I don't understand is that DOMAIN\USER_A is nowhere to be found in the SQL Servers Security Logins.

CURRENT_USER reports dbo SYSTEM_USER reports DOMAIN\USER_A as do SUSER_NAME

I can't find DOMAIN\USER_A in the sys.syslogins? What is going on? Can a database user have its own login circumventing the SQL Server?

2

2 Answers 2

4

The only way a login has rights to a server is if those rights have been granted. The question is likely: How did these rights get granted?

If DOMAIN\USER_A is a member of some Windows group, then through the rights granted to the group the DOMAIN\USER_A login exists in the server. This is true even if there is no individual entry in sys.database_principals or sys.server_principals for that login.

You can look for the permission paths used by a login as follows:

EXEC xp_logininfo 'DOMAIN\USER_A', 'all'

You might find several permission paths for a login.

3
  • I dont have the rights to execute the that stored procedure :(
    – Jeppe
    Commented Aug 26, 2013 at 16:15
  • I will mark your answer as correct since it pointed me in the right direction and figured out the problem. I will have to play around a little on my company network i think to fully understand it.
    – Jeppe
    Commented Aug 26, 2013 at 16:17
  • Thank you i understand it now :) gpresult /R shows me my group memberships and i was in a group mapped to a SQL login.
    – Jeppe
    Commented Aug 26, 2013 at 16:40
4

Please stop looking at syslogins. This is a deprecated system table that is now a backward compatibility view and is only there for that purpose (to prevent breaking old code).

The user is dbo probably because they created the database.

You should be able to find the login the user is associated with using:

SELECT login_name = sp.name, user_name = dp.name
  FROM that_database.sys.database_principals AS dp
  INNER JOIN sys.server_principals AS sp
  ON dp.[sid] = sp.[sid];

Now, it may be that the user doesn't have its own login, and has been granted access to the instance via a Windows group.

2
  • Yields no result as the login do not exist on the SQL Server.
    – Jeppe
    Commented Aug 26, 2013 at 16:15
  • @Jeppe probably because, as I said in the next sentence, the login got in via a Windows group. Commented Aug 26, 2013 at 16:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.