Windows OS Hub
  • Windows Server
    • Windows Server 2022
    • Windows Server 2019
    • Windows Server 2016
    • Windows Server 2012 R2
    • Windows Server 2008 R2
    • SCCM
  • Active Directory
    • Active Directory Domain Services (AD DS)
    • Group Policies
  • Windows Clients
    • Windows 11
    • Windows 10
    • Windows 8
    • Windows 7
    • Windows XP
    • MS Office
    • Outlook
  • Virtualization
    • VMWare
    • Hyper-V
    • KVM
  • PowerShell
  • Exchange
  • Cloud
    • Azure
    • Microsoft 365
    • Office 365
  • Linux
    • CentOS
    • RHEL
    • Ubuntu
  • Home
  • About

Windows OS Hub

  • Windows Server
    • Windows Server 2022
    • Windows Server 2019
    • Windows Server 2016
    • Windows Server 2012 R2
    • Windows Server 2008 R2
    • SCCM
  • Active Directory
    • Active Directory Domain Services (AD DS)
    • Group Policies
  • Windows Clients
    • Windows 11
    • Windows 10
    • Windows 8
    • Windows 7
    • Windows XP
    • MS Office
    • Outlook
  • Virtualization
    • VMWare
    • Hyper-V
    • KVM
  • PowerShell
  • Exchange
  • Cloud
    • Azure
    • Microsoft 365
    • Office 365
  • Linux
    • CentOS
    • RHEL
    • Ubuntu

 Windows OS Hub / Security / How to Obtain SeDebugPrivilege when Debug Program Policy is Enabled

December 28, 2017 SecuritySQL ServerWindows 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 tools 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 https://msdn.microsoft.com/en-us/library/ms813696.aspx, https://msdn.microsoft.com/en-us/library/ms813959.aspx and https://msdn.microsoft.com/en-us/library/ms813847.aspx.

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: rom-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.

7 comments
3
Facebook Twitter Google + Pinterest
previous post
How to Clear Windows Event Logs Using PowerShell or Wevtutil
next post
How to Create the DaRT 10 Recovery Image

Related Reading

Updating PowerShell Version on Windows

April 12, 2023

Fix: Remote Desktop Services Is Currently Busy

March 15, 2023

Find and Remove Locks in Microsoft SQL Server

March 3, 2023

How to Disable NTLM Authentication in Windows Domain?

February 28, 2023

MS SQL Server Setup Stucks on Install/Uninstall

January 9, 2023

Categories

  • Active Directory
  • Group Policies
  • Exchange Server
  • Microsoft 365
  • Azure
  • Windows 11
  • Windows 10
  • Windows Server 2022
  • Windows Server 2019
  • Windows Server 2016
  • PowerShell
  • VMWare
  • Hyper-V
  • Linux
  • MS Office

Recent Posts

  • Recovering Files from BitLocker Encrypted Drive

    June 1, 2023
  • Microsoft Key Management Service (KMS) Volume Activation FAQs

    May 31, 2023
  • Configuring Event Viewer Log Size on Windows

    May 24, 2023
  • How to Detect Who Changed the File/Folder NTFS Permissions on Windows?

    May 24, 2023
  • Enable Single Sign-On (SSO) Authentication on RDS Windows Server

    May 23, 2023
  • Allow Non-admin Users RDP Access to Windows Server

    May 22, 2023
  • How to Create, Change, and Remove Local Users or Groups with PowerShell?

    May 17, 2023
  • Fix: BSOD Error 0x0000007B (INACCESSABLE_BOOT_DEVICE) on Windows

    May 16, 2023
  • View Success and Failed Local Logon Attempts on Windows

    May 2, 2023
  • Fix: “Something Went Wrong” Error When Installing Teams

    May 2, 2023

Follow us

  • Facebook
  • Twitter
  • RSS
Popular Posts
    Footer Logo

    @2014 - 2023 - Windows OS Hub. All about operating systems for sysadmins


    Back To Top