CODEWITHSUNDEEP
windowspowershellchef-infra
Ruifeng Ma
Ruifeng Ma

Reputation: 2777

Chef::Exceptions::WindowsNotAdmin: can not get the security information due to missing Administrator privileges

We were trying to deliver a solution to manage a Windows 2012 server for a client using Chef, but unfortunately chef-client run failed with Chef::Exceptions::WindowsNotAdmin: can not get the security information for <some_file> due to missing Administrator privileges exception.

This was a bit weird as we have confirmed that the domain account we used to remotely manage the server is a member of the Administrators group. And we were able to use it to manage other servers within the same domain. Besides, when we connected to the server using the domain account via Remote Desktop, started PowerShell as an administrator and initiated a chef-client run, it failed with the same exception.

Running below commands reveals that the domain account is indeed a member of the Administrators group. This can be verified by the SID of the group. 

Get-WmiObject -Class Win32_UserAccount
Get-WmiObject -Class Win32_Group
[System.Security.Principal.WindowsIdentity]::GetCurrent().Groups

Not sure what settings on the server could have caused this.

Upvotes: 3

Views: 1497

Answers (1)

Ruifeng Ma
Ruifeng Ma

Reputation: 2777

With insights provided by this thread, further digging into the code of Chef reveals that a win32 function GetNamedSecurityInfoW gets called here to determine the security information of an object (file, folder etc.). This occurs during cookbook installation where some resource files or gems need to be created on the endpoint server.

Firstly an empty file will be created, after that the file content will be updated atomically if that is an option. During file content update, the file’s security access control list needs to be checked by the function GetNamedSecurityInfoW. To call this function, the logged-on user needs to have a privilege SE_SECURITY_NAME. Chef itself also tries to handle this by adding this privilege before calling the function and revert it after the function call, but this is not always guaranteed. System settings seem to prevail.

We hacked Chef code a bit to try to print out the output of the function call on GetNamedSecurityInfoW, and it was a status code 1314, indicating a required privilege is not held by the user.

We tried to run whoami /priv on the server and found that SeSecurityPrivilege privilege is not found in the list. Below is just a sample output on a normal Windows server. 

Privilege Name              Description                           State   
========================================================================
SeLockMemoryPrivilege       Lock pages in memory                 Disabled
SeIncreaseQuotaPrivilege    Adjust memory quotas for a process   Disabled
SeSecurityPrivilege         Manage auditing and security log     Disabled
...

Note that the state column only indicates whether a privilege is being used by the user. It's existence indicates whether the user has it or not.

After adding back this privilege to the domain account, i.e. set the security setting of Manage auditing and security log to Administrators group in the Local Securtiy Policy editor, and rebooting the server, chef-client run became successful.

It seems that Chef is heavily using win32 API functions to manage Windows nodes. And these API functions seem to need various privileges to run. It's a bit strange that Chef rescued all win32 API errors and just propagated the Chef::Exceptions::WindowsNotAdmin to chef-client run log, as indicated here. It would be good to actually parse the error a bit and provide some more useful information.

Upvotes: 4

Related Questions