Auditing Windows Groups from SQL Server

By: Amit Watwe   |   Updated: 2018-07-27   |   Comments (4)   |   Related: > Auditing and Compliance

Problem

Managing database security should be part of every DBAs job.  With SQL Server you have the ability to use either SQL Server and Windows or Windows only security.  The advantage of using Windows security for your SQL Servers is that you can take advantage of the Windows security model and security policies that have been setup on your domain.  Another advantage is that you can manage security at the domain level instead of at the SQL Server instance level. 

In addition you can use use Windows groups to manage the security buckets.  Based on the groups that are setup you can put specific Windows users in these groups and then give SQL Server access to this Windows group instead of having to create logins for every single windows user. 

The disadvantage to this is that the specific people within these groups is masked at the SQL Server level.  In your logins you can see the groups that have access, but you have no idea what users are in what groups.  So how can you get this information from within SQL Server?

Solution

SQL Server offers some insight into this issue with the xp_logininfo extended stored procedure.  This stored procedure is part SQL Server 2000 and all later versions. 

This xp takes the following parameters:

• @acctname - the windows account name or group
• @option - information to display
  • 'all' - display information for all permission paths
  • 'members' - display list of members in a group
• @privelege - this is an output variable from this command and returns 'admin', 'user' or 'null

Following is T-SQL code that loops through your logins and wherever there is a Windows Group the xp_logininfo XP is called to return information about the Windows group.

SQL Server 2000

For this example we are querying from the syslogins table where the isntgroup = 1 and status = 10.

DECLARE @LoginName sysname 
DECLARE @sql NVARCHAR (2000) 

BEGIN 
   DECLARE cur_Loginfetch CURSOR FOR 
    
   SELECT [name] FROM master.dbo.syslogins WHERE isntgroup = 1 AND status = 10  
    
   OPEN cur_Loginfetch 
    
   FETCH NEXT FROM cur_Loginfetch INTO @LoginName 
   WHILE @@FETCH_STATUS = 0 
       BEGIN 
           EXEC xp_logininfo @LoginName , 'members' 
           FETCH NEXT FROM cur_Loginfetch INTO @LoginName 
       END 
   CLOSE cur_Loginfetch 
   DEALLOCATE cur_Loginfetch 
   RETURN 
END

Here is the output from running the above code.  Here we can see the Windows users that are part of the BUILTIN\Administrators group.

SQL Server 2005, 2008, 2008R2, 2014, 2016 and 2017

For this example we are querying from the sys.server_principals catalog view where type = 'G'.

DECLARE @LoginName sysname 
DECLARE @sql NVARCHAR (2000) 

BEGIN 
   DECLARE cur_Loginfetch CURSOR FOR 
    
   SELECT [name] FROM master.sys.server_principals WHERE TYPE = 'G' 
    
   OPEN cur_Loginfetch 
    
   FETCH NEXT FROM cur_Loginfetch INTO @LoginName 
   WHILE @@FETCH_STATUS = 0 
       BEGIN 
           EXEC xp_logininfo @LoginName , 'members' 
           FETCH NEXT FROM cur_Loginfetch INTO @LoginName 
       END 
   CLOSE cur_Loginfetch 
   DEALLOCATE cur_Loginfetch 
   RETURN 
END 

Here is the output from running the above code. Here we can see the Windows users that are part of the BUILTIN\Administrators group.

This is a pretty straightforward process to get the information.  On your production servers you should be able to see a lot more information then what is provided in these examples.

Next Steps

• Use these scripts to get information about your Windows groups that have access to SQL Server.
• Add these scripts to your auditing procedures to keep on top of any potential security risks
• Write a process that captures this data on a daily basis and alerts you when there are changes.  You may not need to do this for all groups, but it would be good to monitor any group that has sysadmin rights such as the BUILTIN\Administrators account.
• Take a look at these other security related tips:
  • Who is logging in as the 'sa' login?
  • Giving and removing permissions in SQL Server
  • Auditing your SQL Server database and server permissions
• Thanks goes out to Amit Watwe from Singapore for this tip idea as well as the code sample.

About the author

Amit Watwe's bio is coming soon...

This author pledges the content of this article is based on professional experience and not AI generated.

View all my tips