Oh what a tangled web we weave...

This was an interesting example of how tangled some problems are. They look straightforward when you first look at them, but as you unwrap the layers it becomes more and more complex.

Overall symptoms:

Problems adding a W2k3 DC to an existing W2K FT root

Such and such a company “.. is trying to add the W2K3 DC’s to the existing fault tolerant dfs root but gets the access denied errors with both dfsutil and UI. If he blows away the existing dfs structure and then recreates it on one of the 2003 dc's it is fine.”

After adding some debug code to DFS – we could see that there was a problem in a call to the registry. The problem was that we call RegConnectRegistry, and when we call this we connect via Remote Registry services.

There is a registry key called SecurePipeServers which contains the winreg subkey, and this controls remote access to the registry

The effected machine was lacking proper permissions to these keys:

“Local Service” permissions to:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurePipeServers\winreg

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurePipeServers\winreg\AllowedExactPaths

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurePipeServers\winreg\AllowedPaths

 

But – the Local Service and other well-known security principals do not show up in UI when we tried to add them. Why was this? Due to a little known behavior in Windows Server 2003:

After you run the dcpromo.exe command on a Microsoft Windows Server 2003 computer to promote the server to a domain controller, the Local Service and other well-known security principals that are introduced with Windows Server 2003 do not appear.

You cannot resolve the well-known security principals when you try to add the well-known accounts by using NTFS file system permissions on a file or a folder. Additionally, you cannot resolve the well-known security principals when you use the ADSI Edit tool, the Group Policy Object Editor snap-in (Gpedit.msc), or Registry Editor. See https://support.microsoft.com/?kbid=827016  for more info.

Once we added the value directly (or made the ROOT Domain PDC a 2k3 DC) then the DFS problems went away.

How would you have come to this conclusion without adding debug code to the DFS component? Regmon.exe from comes to mind but I am curious how you would have done it.

Spat

Comments

• Anonymous
  February 14, 2005
  Obviously regmon would have helped, but you had the advantage of the debug code to indicate that it was registry related.
  
  We all know what the open source fans would be saying as they jumped up and down pointing their finger :)
• Anonymous
  February 14, 2005
  Which brings us to another point altogether. Is a productcomponent truly supportable (from an end user perspective) any time you need to break out the debugger?
• Anonymous
  February 15, 2005
  Although having access to source code is (for the customer anyway) better than not having it, I agree completely with the point that if you're using a debugger (let alone modifying source code) to troubleshoot IT problems such as this, something went wrong a long time ago.