Posted on December 28, 2017 · Posted in Security, SQL Server, Windows Server 2012 R2

How to Obtain SeDebugPrivilege when Debug Program Policy is Enabled

In the previous article, we told that one of the ways to defending against mimikatz-like utilities is disabling the debug privilege for system administrators using Debug Program policy. However, recently it turned out that without the debug privilege (it is SeDebugPrivilege in Windows), a local server administrator cannot install or update Microsoft SQL Server. The matter is that when started, the SQL Server installer checks if there are the SeSecurity, SeBackup and SeDebug privileges. It needs to run the SQL Server process and get the information about the successful start of SQL Server. Here is what it looks like.

During SQL Server installation, the installer performs preliminary checks and identifies some problems with Setup account privileges.

sql server setup error: Setup account privileges failed

If you click the Failed link, you can see the following message:

Rule “Setup account privileges” failed.
The account that is running SQL Server Setup does not have one or all of the following rights: the right to back up files and directories, the right to manage auditing and the security log and the right to debug programs. To continue, use an account with both of these rights. For more information, see, and

Rule “Setup account privileges” failed.

Now open the SystemConfigurationCheck_Report.htm report.

HasSecurityBackupAndDebugPrivilegesCheck failed

As you can see, when checking the HasSecurityBackupAndDebugPrivilegesCheck rule, the installer has found that the current process hasn’t got one of the following privileges:

  • SeSecurity – managing the audit and security logs
  • SeBackup – the permissions to backup files and folders
  • SeDebug — the privilege to debug programs

There is some detailed information in the log showing that the installation process doesn’t have SeDebug flag.

(09) 2017-12-12 11:15:13 Slp: Initializing rule      : Setup account privileges
(09) 2017-12-12 11:15:13 Slp: Rule is will be executed  : True
(09) 2017-12-12 11:15:13 Slp: Init rule target object: Microsoft.SqlServer.Configuration.SetupExtension.FacetPrivilegeCheck
(09) 2017-12-12 11:15:13 Slp: Rule ‘HasSecurityBackupAndDebugPrivilegesCheck’ Result: Running process has SeSecurity privilege, has SeBackup privilege and does not have SeDebug privilege.
(09) 2017-12-12 11:15:13 Slp: Evaluating rule        : HasSecurityBackupAndDebugPrivilegesCheck
(09) 2017-12-12 11:15:13 Slp: Rule running on machine: msk-sql10
(09) 2017-12-12 11:15:13 Slp: Rule evaluation done   : Failed

I have decided to look for a workaround solution of getting SeDebugPrivilege without changing or disabling the Debug programs policy. It turned out that there is quite an easy way to bypass this policy if you have local administrator privileges on your server. The secedit tool that allows managing local security policies of the server will help us.

Check the current privileges:

whoami /priv

whoami priv

As you can see, there is no SeDebugPrivilege in the current token of the user.

Export the current user rights set by the group policies to a text file:

secedit /export /cfg secpolicy.inf /areas USER_RIGHTS

Using any text editor, open secpolicy.inf and add a string to the [Privilege Rights] section that enables Debug Programs privileges to the group of local administrators.

SeDebugPrivilege = *S-1-5-32-544

set SeDebugPrivilege for local adminis group

Note. The SID of the group of local administrators, S-1-5-32-544, may be changed to any other SID. To transform a group or user name into SID, see How to Convert SID to UserName and Vice Versa.

Save the file. Now apply the new user rights:

secedit /configure /db secedit.sdb /cfg secpolicy.inf /overwrite /areas USER_RIGHTS

Note. You have to confirm the overwriting of the current settings.

secedit overwrite USER_RIGHTS

Log off and log on again and using secpol.msc make sure that the Debug Program privileges are assigned to the group of local administrators. The same is shown in the results of whoami /priv command:

SeDebugPrivilege                Debug programs                            Enabled

Obtaining SeDebugPrivilege

Now you can run the installation or update your SQL Server. But bear in mind that SeDebugPrivilege is assigned temporarily and it will be reset at the next GPO update cycle (after the user has logged off).

You should understand that if you enable Debug programs policy it will not completely protect you from getting SeDebugPrivilege by malicious software that has already penetrated to your server with the local administrator rights, and it may compromise all user/administrator accounts working on the server.

Related Articles