BUG: DCOMCNFG NT 4.0 SP4 Does Not Write .exe Name under HKCR\APPID

• Microsoft Windows NT 4.0

SYMPTOMS

Clients get an Access Denied error although the access is granted to the client using DCOMCNFG.

CAUSE

When access permissions for a DCOM server are configured using DCOMCNFG, the .exe name should be mapped to an AppID under HKEY_CLASSES_ROOT\APPID; however, it does not do this in Windows NT 4.0 Service Pack 4 (SP4).

RESOLUTION

Add a key, HKEY_CLASSES_ROOT\APPID\{exe name}, and add a named value, AppID, under this key giving it an actual AppID.

STATUS

Microsoft has confirmed this to be a problem in the Microsoft products listed at the beginning of this article.

MORE INFORMATION

AccessPermissions work as follows:

1. If the server calls CoInitializeSecurity, the ACL comes from the API.



2. If the server does not call CoInitializeSecurity, then if there is an AccessPermissions key under the server's AppID GUID, the ACL comes from this. There must be a mapping of the .exe name to the AppID in the registry. For example:

   
   REGEDIT4
   
         [HKEY_CLASSES_ROOT\AppID\sserver.exe]
         @="Simple Object Server"
         "AppID"="{5E9DDEC7-5767-11CF-BEAB-00AA006C3606}"
   
         [HKEY_CLASSES_ROOT\AppID\{5E9DDEC7-5767-11CF-BEAB-00AA006C3606}]
         @="Simple Object Server"
   
         "AccessPermission"=hex:01... 

   This is how COM maps the AppID from the server process's module name.



3. If there is no AccessPermissions key under server's AppID, then if there is a DefaultAccessPermission key under HKLM\Software\Microsoft\Ole, the ACL comes from here.



4. If there is no DefaultAccessPermission key under HKLM\Software\Microsoft\Ole, the server principal and SYSTEM are allowed to call the server; that is, if the server is running as a_domain\a_user, a client running as a_domain\a_user can call it.

Additional query words:

Keywords          : kbDCOM kbNTOS400 kbDSupport 
Version           : winnt:4.0
Platform          : winnt 
Issue type        : kbbug 

Last Reviewed: July 8, 1999