After applying KB3045999, or any patch that supersedes KB3045999, users see HTTP 403 error browsing to SharePoint sites. Nothing specific appeared in the ULS logs. However, a specific error did appear in the Event Viewer:
Event ID: 8305
Task Category: Claims Authentication
An exception occurred when trying to establish endpoint for context: An error occurred creating the configuration section handler for system.serviceModel/extensions: Could not load file or assembly
'System.WorkflowServices, Version=126.96.36.199, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. Access is denied. (C:\Windows\Microsoft.NET\Framework64\v2.0.50727\Config\machine.config line 167).
With this information I opened a MS support case.
Below is a summary of this case:
After installing the KB3045999 or any KB patch that superseded it, sites are inaccessible with errors referencing permissions on local machine files.
This case will be considered resolved and ready for archive when the sites remain accessible after installing KB3045999 and the superseding updates.
- SharePoint 2010: 14.0.7162.5000
Gathered initial details on the case and related service requests that were worked in the past.
- Gathered ULS logs.
- Reviewed local security policy and groups.
- Attempted some steps to correct the behavior following the install of the KB3045999, found these to be affective only for KB3045999 and not the superseding updates.
- Identified a known issu3 related to these updates and found that a registry key can be used to resolve this behavior. Cause of the behavior detailed below:
- From security fix 3045999, the updated windows DLL ntdll in passes a new object attribute flag in calls to NtOpenFile/NtQueryAttributesFile made by LoadLibrary. The registry key UseImpersonatedDeviceMap is set if an application is allowed to call Kernel services with Impersonation. If the key doesn't exist (by default), then it is forbidden.
- In a normal situation, because SharePoint service account has the permission to load dlls, it should be fine even if impersonation is disabled for kernel calls. But it seems when some 3rd party AV exists, the behavior is changed and the impersonation must be enabled for it to work. Perhaps the AV cleared the original security context of the service account. This can explain why the issue only happens in very few environments. (We received few cases worldwide about the same issue and the environment are all installed with Anti-virus.)
Before or after applying the problem update, create the following item in the registry.
- Find: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\w3wp.exe
- If the key for "w3wp.exe" does not already exist under Image File Execution Options, then create it.
- Inside "w3wp.exe" key, create the DWORD: UseImpersonatedDeviceMap
- Set the DWORD value to 1
- Perform an IISreset