3

I'm trying to install a hotfix for SQL Server 2008 and failing on the Rule Check with "Setup account privileges" failed.

I am running SQL Server 2008 Standard on Windows Server 2008 R2.

Searching on Google basically led to these 2 links:

My account is included in the Manage auditing and security log policy setting (as well as the others that the article listed). After adding my account to the policy, I ran gpupdate /force. I also logged off and logged back in.

I am using the local Administrator account. I am NOT on a domain. I used accesschk.exe and SeSecurityPrivilege is NOT listed. I used PowerShell whoami /priv and SeSecurityPrivilege is listed but is set to "Disabled".

Does anyone know how to "Enable" this privilege?

2
  • Perhaps a dumb question, but did you run the install as administrator? That is, right click on the setup.exe file and choose "Run as administrator".
    – Ben Thul
    May 28 '14 at 19:43
  • @BenThul Yes I did, but it still didn't work. I had to do those steps in my answer below.
    – roartechs
    May 28 '14 at 20:31
4

So I was able to get pass the SQL Server Rule Check phase. I had to add the individual administrator account to the following policy settings:

  • Back up files and directories
  • Debug Programs
  • Manage auditing and Security log
  • Restore files and directories
  • Take ownership of files or other objects

It didn't matter that I was a member of the Administrators group and that the Administrators group was included in those settings. I had to explicitly add the individual user account. I ran gpupdate /force. Then I logged off and logged back in. Then I was able to install the hotfix.

But even after all that, when I ran the PowerShell whoami /priv command, the SeSecurityPrivilege still showed "Disabled". So I guess that didn't really matter.

0

This question came up when I ran into a similar problem and it was a little tricky to piece it all together so I will add something here. I don't intend to write a complete how-to, so I will just provide some pointers.

From what I can find, this is not really a matter of running "as administrator" or not. At least not only. Running as administrator will make more privileges available but not (necessarily) enabled.

As an example, these are the privileges I get without "as administrator":

PS H:\> whoami /priv

PRIVILEGES INFORMATION
----------------------

Privilege Name                Description                    State   
============================= ============================== ========
SeChangeNotifyPrivilege       Bypass traverse checking       Enabled 
SeIncreaseWorkingSetPrivilege Increase a process working set Disabled

Using the same account but "as administrator", I get many more available, but still mostly disabled:

PS C:\Windows\system32> whoami /priv

PRIVILEGES INFORMATION
----------------------

Privilege Name                            Description                                                        State   
========================================= ================================================================== ========
SeIncreaseQuotaPrivilege                  Adjust memory quotas for a process                                 Disabled
SeSecurityPrivilege                       Manage auditing and security log                                   Disabled
SeTakeOwnershipPrivilege                  Take ownership of files or other objects                           Disabled
SeLoadDriverPrivilege                     Load and unload device drivers                                     Disabled
SeSystemProfilePrivilege                  Profile system performance                                         Disabled
SeSystemtimePrivilege                     Change the system time                                             Disabled
[...]

In order to run something that requires a certain privilege, the privilege must also be enabled. It is not possible to enable a privilege if it is not first available to the account. Making it available is what you do by assigning permissions to groups/user and/or running "as administrator". To then also enable it, various methods needs to be called, and apparently there is no native Powershell method for this.

This is Powershell helper I found (haven't tested it) for wrapping the native calls necessary to enable privileges:

https://medium.com/@markmotig/enable-all-token-privileges-a7d21b1a4a77 https://www.leeholmes.com/adjusting-token-privileges-in-powershell/ https://github.com/fashionproof/EnableAllTokenPrivs

This Microsoft page is also interesting: Executing Privileged Operations Interestingly, as noted on that page, if you have a remote connection the privileges are always enabled:

By default, a local user on a computer can read static data from the WMI repository, write to instances supplied by providers, and execute provider methods, unless the provider enforces special security requirements of its own. Only administrators can connect to a remote computer, change security descriptors, or change static WMI repository data, such as a WMI class definition. All privileges are enabled for a remote connection. For more information, see Securing a Remote WMI Connection.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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