"Access is denied" when you attempt to start the Base Filtering Engine service, after upgrading from Windows Server 2003 to Windows Server 2008 R2

Here's an issue that appears deceptively simple. After upgrading a Windows Server 2003 based system to Windows Server 2008 R2, ping and RDP are not working. On checking, the Windows Firewall service hasn't been started because the service on which it is dependent, the Base Filtering Engine service, has not started. The Base Filtering Engine service fails to start with an "Access is denied" error.

Log Name: System
Source: Service Control Manager
Date: 19-Sep-10 11:17:56 AM
Event ID: 7023
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: Win2k8R2.contoso.com
Description:
The Base Filtering Engine service terminated with the following error:
Access is denied.

A quick web search will reveal many web pages, most of which list the cause of the issue as missing permissions on the "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\BFE\Parameters\Policy" registry key.

However, in this case, a Process Monitor log captured at the time doesn't have a single event whose result is ACCESS DENIED. Is there something wrong with Process Monitor? Not at all. Why then doesn't it have an ACCESS DENIED event for the registry key mentioned above? Because the cause of this instance of the issue is not missing permissions on the registry key, rather, something else.

The reason Process Monitor doesn’t capture the Access Denied error is because the error doesn’t occur on a File or Registry operation. Rather, the Access Denied occurs when the Base Filtering Engine service attempts to query the configuration of installed services on the computer. It does so, in alphabetical order. If the Base Filtering Engine service, which runs under the Local System security context, doesn’t have permissions to query the configuration of a service, the Base Filtering Engine service errors out with the event pasted above.

Okay, so we know the cause of the issue. How do you determine which installed service has restrictive permissions? The two options available are:

· Log a call with Microsoft Support for us to debug and determine the problem service.

· Manually examine each service, starting with non-Microsoft services.

Say you’ve decided to go it on your own. Here’s what you need to do to check the Discretionary Access Control List (DACL), or permissions, of a service.

First off, you’ve got to get the names of all installed services:

sc query > servicenames.txt

Open servicenames.txt and make a note of the SERVICE_NAME property of each service.

To list the DACL of a service, run this command:

sc sdshow <service name>

Let’s start by listing the DACL of a Microsoft service, which would have the correct permissions (Unless they’ve been manually edited).

sc sdshow Audiosrv

D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)

The resulting string of letters and special characters is the Security Descriptor (SD) in SDDL. The characters after D: make up the DACL. The characters after S: are the SACL, which we’re not interested in.

Since the Base Filtering Engine service runs in the context of the Local System account, the part of the DACL we’re interested in is (A;;CCLCSWRPWPDTLOCRRC;;;SY)

Now it’s time to get our hands dirty. Do an sc sdshow on all non-Microsoft services and check if they have (A;;CCLCSWRPWPDTLOCRRC;;;SY) . The services that are missing this Access Control Entry (ACE) are the ones that are causing the Base Filtering Engine service to terminate with “Access is denied”.

On to the most interesting part of this post. How do I fix it?

That’s easy! But first, the disclaimer.

Disclaimer: Proceed at your own risk. Incorrectly setting the DACL could result in you being locked out of modifying the service, or even accessing it.

1. Make a note of the Security Descriptor (SD) of the problem service by running this command:

sc sdshow ProblemService

D:(A;;LC;;;WD)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BO)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)

2. List the SD of a Microsoft service for comparision:

sc sdshow Audiosrv
 
D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)

3. Identify the missing Access Control Entries (ACEs). These are:

(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SO)

4. Insert the missing ACEs into the DACL of the SD of the problem service, by running this command:

Sc sdset ProblemService D:(A;;LC;;;WD)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BO)(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SO)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)

Important: Ensure that there are no spaces in the DACL string, because if there is a space in the string, the sc sdset command will only consider the portion before the space and truncate the DACL SDDL string there.

eg.

5. Lather, rinse, repeat for other non-Microsoft services that are missing the ACE for Local System.

That’s it. Start the Base Filtering Engine service and then the Windows Firewall service and you’re done.

Here are a couple of links that will demystify SDDL for you:

Parsing SDDL Strings
https://blogs.dirteam.com/blogs/jorge/archive/2008/03/26/parsing-sddl-strings.aspx

SDDL string parser - MS Israel Community
https://blogs.microsoft.co.il/files/folders/guyt/entry70399.aspx