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

Article translations Article translations
Article ID: 216051
This article was previously published under Q216051
Expand all | Collapse all

On This Page

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

Windows NT Server or Workstation 4.0

To resolve this problem, obtain the latest service pack for Windows NT 4.0 or the individual software update. For information on obtaining the latest service pack, please go to:
  • Windows Service Pack Center -or-

  • 152734 how to obtain the latest windows nt 4.0 service pack
For information on obtaining the individual software update, contact Microsoft Product Support Services. For a complete list of Microsoft Product Support Services phone numbers and information on support costs, please go to the following address on the World Wide Web:
http://support.microsoft.com/default.aspx?scid=fh;EN-US;CNTACTMS

Windows NT Server 4.0, Terminal Server Edition

To resolve this problem, obtain the latest service pack for Windows NT Server 4.0, Terminal Server Edition. For additional information, click the following article number to view the article in the Microsoft Knowledge Base:
152734 How to Obtain the Latest Windows NT 4.0 Service Pack

STATUS

Microsoft has confirmed that this is a problem in the Microsoft products that are listed at the beginning of this article. This problem was first corrected in Windows NT Server version 4.0, Terminal Server Edition Service Pack 6.

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.

Properties

Article ID: 216051 - Last Review: June 11, 2012 - Revision: 2.0
Keywords: 
kbhotfixserver kbqfe kbbug kbdcom kbfix kboswinnt400sp5fix KB216051

Give Feedback

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com