通过

Event ID 560 - SharePoint Least Privilege meet DISA STIG

  • 项目

If you are following Microsoft's guidance on installing SharePoint 2007 with least privilege mode (https://technet.microsoft.com/en-us/library/cc298465(office.12).aspx),  your SharePoint farm account should not be added to the local Administrators group.  If you add this security practice with following DISA's STIG for the Microsoft Windows operating system, you are likely to see numerous Event ID 560 events filling your Security logs using the SharePoint farm account.  Note: You will see this error only if you enable logging of Object Access failures via a GPO or local security policies.  In my customer's case , the event dealt with remote access and it trying to query the status of the service.  SInce the error was occuring every minute and was associated with the Farm account, it was obviously the Timer service (SPTimerV3) that was causing this.  At the end of the error log, there was an access desired Hex code of 0x4. 

To resolve the error, we used SC.exe to modify the DACL of remoteaccess.

  1. Open a command prompt ( use an elevated command prompt if running from Windows Server 2008 or 2008 R2 ).
  2. Type the following and hit enter:
    1. sc.exe sdshow remoteacces
  3. This will output something like the follwoing
  5. Copy the output into Notepad
  6. Get the SID for the Farm account.  You can either use PSGetSid or PowerShell (https://thepowershellguy.com/blogs/posh/archive/2007/01/23/powershell-converting-accountname-to-sid-and-vice-versa.aspx)
  7. Once you have the SID for the Farm account, add the following right before S:( to the output you copied earlier
    1. (A;;0x4;;;SID of User account)
  8. Copy the output plus the text in Step 7a and type the following:
    1. sc.exe sdset remoteaccess <output string:>
    2. Press enter
  9. Verify that the DACL has been updated by running sc.exe sdshow remoteaccess.
  10. If you are seeing more than remote access errors for Event ID 560, simply replace the RemoteAccess in the sc.exe commands with the object listed in the event log. 

        

 UPDATE: I have been asked to explain some of my experience with the STIGs and have added that below.

When dealing with DISA STIGs, the category of the particular item is referred to often.  The highest category is Cat I, followed by Cat II and finishing at Cat III.  For the SharePoint installations that I have worked with, all Category I and most of the Category II items have been applied for both the Operating System and Internet Information Services (IIS). There are SQL Server STIGs as well but I have not seen them affect SharePoint operation.  When approaching a SharePoint installation, your life and time will be best spent installing and configuring a working SharePoint environment PRIOR to applying any STIG remediations. I have had instances where SharePoint will not even install when certain STIGs are applied.  The SharePoint Products and Technology Wizard performs some actions ( mainly permissions ) that a STIG can revert and it is easier to apply the STIG remediations and check if SharePoint still works rather than figuring out if it is a bad install or a STIG that is causing any errors.   As I go through the STIG items, I apply them one at a time and based on their recommended fix I will check the relevant SharePoint items.  The biggest thing to watch for is any file or registry permission restrictions.  Using PROCMON you can navigate through SharePoint ( mainly CA and the SSP ) and see what files and registry items it is hitting.  In almost all cases, the STIG has affected the Central Administration, SSP and the services like SPTimerV3 and Osearch rather than the actually SharePoint sites themselves.  The only issue I have seen with browsing the site has been caused when anonymous access has been turned on and the IUSR account ( which is a member of the Guest group ) does not have Logon locally permissions ( the DISA STIG has you remove the Guest group from this permission ). 

During your testing, run through all the operations that SharePoint performs with the STIGs applied.  Kick off a search crawl, run a profile import, even patch the server if you can with a SharePoint Cumulative Update.  Remember that the majority of the problems will come from the infrastructure side of the house and not users hitting the site.

Comments

  • Anonymous
    October 30, 2010
    This might be a perfect time to use a least privilege elevation solution like BeyondTrust PowerProker for Desktops (www.beyondtrust.com)? With a solution like PowerBroker, you can simply allow the service account to elevate for each task it needs to perform. This will keep the system protected, yet allow the service to perform its work!? Derek Melber, MVP

  • Anonymous
    January 06, 2011
    The comment has been removed

  • Anonymous
    October 24, 2012
    The bigger problem here is the DISA STIG is faulty and still has NOT included Powershell based commands to cleanly implement the items that can be automated. DISA likes to operate in isolation but for STIGS (aka hardening guides) that's not always the best route. Today my peers were implementing this very same STIG and there is clearly confusion between SharePoint 2007 and 2010 in the guides. If anyone at MS is involved with DISA, please steer them in the right direction to better automate the STIGS. @Microsoft - please provide SCAP content that is portable outside of SCCM and can be used with other SCAP approved tools.