How to tell which windows group login I used when logging in via windows authentication

Windows Authentication in SQL Server doesn't work exactly like that. When you log in as a domain user who has an associated login, but also has access via a domain group that has an associated login, the access is determined by the combined DENY/GRANT permissions and SQL\DB role membership assigned to both the user login and the group login.

There is no concept of being 'logged in' as the group, the group is simply a container to provide access to a collection of domain users based on their membership in this group in Active Directory.

You can check the various access paths for a particular user by running this command:

EXEC xp_logininfo '<DOMAIN\user>', 'all'

This will list out the various access paths for a user, i.e. all the group logins and user logins this Windows account is linked to.

Windows Authentication is token-based authentication, you can read about tokens here Access token and here Token Based Authentication

The general concept behind a token-based authentication system is simple. Allow users to enter their username and password in order to obtain a token which allows them to fetch a specific resource - without using their username and password.

---

An access token is generated by the logon service when a user logs on to the system and the credentials provided by the user are authenticated against the authentication database. The authentication database contains credential information required to construct the initial token for the logon session, including its user id, primary group id, all other groups it is part of, and other information. The token is attached to the initial process created in the user session and inherited by subsequent processes created by the initial process.

So when you use Windows Authentication to logon, you present to server your Windows token.

You can see all the server principals that are part of your login token using this code:

select *
from sys.login_token
--where principal_id > 0; -- uncomment here to see only mapped principals

If you want to explore login token of another login, you should first impersonate it:

execute as login = 'some_login';

select *
from sys.login_token
where principal_id > 0;

revert;

Of course you should have IMPERSONATE permission on some_login to be able to impersonate it.

So your permissions on server are defined based on the "sum" of the permissions of all the principals that make part of your token. DENY as always has precedence on GRANT so if you are a member of two Win groups one of wich has grant and other deny on some object, you'll be denied to access it.

While there is good info in both HandyD's answer and sepupic's answer, there is still some clarification needed.

1. When you log in using Windows Authentication, your security context includes all of the Logins mapped in sys.server_principals that match your current Windows security context. This can be a Windows Login and/or one or more Windows Groups. If your Windows account is in 5 groups and 3 of those groups are registered as Logins in SQL Server, but no Login for you specifically, your security context will be just those 3 groups. If you then added a Login for your Windows account specifically, then logging in would give you a security context of your Windows Login plus all 3 of those mapped groups.

2. xp_logininfo is helpful in that it can show the matching mapped Groups and/or Login for accounts without having to log in as them or impersonate them. And it can let you see the members of a Windows Group (if the Windows Group is registered in SQL Server as a Login).

   What this system stored procedure can't show is:

   1. the rest of the security context for a particular Login / Group that determines the effective permissions. For instance-level permissions this would include Server Roles that the Login and/or Group(s) are members of. For database-level permissions this would include Database Roles in any database that the Login has a mapping for
   2. Logins that are direct to the database without having a Login at the instance-level. This is how Contained Databases work (but it's ok that xp_logininfo doesn't show anything for Contained DBs since it only works inside of them if the instance-level collation is Latin1_General_100_CI_AS_KS_WS_SC due to a bug I just discovered while testing this: xp_logininfo gets "Msg 468, Level 16, State 9: Cannot resolve the collation conflict..." when DB collation doesn't match instance collation)

3. sys.login_token is helpful for seeing the full security context, including the Windows Login (if there is one mapped) and/or any Windows Groups (if any are mapped), as well as server-level roles that the Login and/or Groups are members of. "Effective" permissions are based on ALL permissions across all security tokens, and a DENY overrides any GRANTs. So you can be granted a permission to something via membership in Group 1, but Group 2 is a member of a server-level role that has been denied that permission (or a parent permission), and so you are effectively denied that permission.

   What this DMV can't show is:

   1. any info for Logins other than the current Login
   2. members of Windows Groups

4. sys.user_token is helpful for seeing the full security context at the database-level. The security tokens can be different per each database so effective permissions are always based on the current database when this DMV is checked. This DMV is the more relevant info when directly logging into a Contained DB.