COM Security Frequently Asked Questions

• Microsoft Win32 Software Development Kit (SDK), on platform(s):
  • Microsoft Windows NT 4.0
  • Microsoft Windows 95

SUMMARY

The COM/DCOM security model enables the creation of secure distributed applications. COM security can be applied to both existing (legacy) COM components via external configuration as well as new COM code via the COM security APIs and interfaces. This document provides tips and techniques, as well as troubleshooting information, for developers of secure COM components.

MORE INFORMATION

Table of Contents

1. How do I enable or disable DCOM?



2. Why do I get E_OUTOFMEMORY when trying to access a remote object?



3. Why doesn't IConnectionPoint::Advise work?



4. I get E_ACCESSDENIED from CoCreateInstanceEx. Why?



5. Are there any issues with running COM servers under the "system" account?



6. Why does CoRegisterClassObject return CO_E_WRONG_SERVER_IDENTITY?



7. Does DCOM support delegate level impersonation?



8. LocalServer32 entries with UNC names cannot be remotely activated. Why?



9. Why can't my server access network resources?



10. What are the limitations of RunAs the Launching User?



11. Should I use AccessCheck or IsValidSecurityDescriptor?



12. How can I get a log of AccessCheck failures?



13. How can I troubleshoot activation problems?



14. Why do I get a "User32.dll could not be initialized" message?



15. Why do I get a "Shell32.dll could not be initialized" message?



16. How can I troubleshoot call level problems?



17. Are there any hints on impersonation problems?



18. Why does CoCreateInstance fail in my ISAPI extension?

1. Where can I get DCOM for Windows 95?



2. Can I redistribute DCOM for Windows 95?



3. What security features are in COM on Windows 95?

1. Where can I find more information on Windows NT Security?

General COM Security Issues

http://msdn.microsoft.com/library/default.htm

hr = CoInitializeSecurity( NULL, //Points to security descriptor -1, //Count of entries in asAuthSvc NULL, //Array of names to register NULL, //Reserved for future use RPC_C_AUTHN_LEVEL_NONE, //The default authentication //level for proxies RPC_C_IMP_LEVEL_IMPERSONATE, //The default impersonation //level for proxies NULL, //Reserved; must be set to NULL EOAC_NONE, //Additional client or //server-side capabilities NULL //Reserved for future use );

   HRESULT CConnectionPoint::Advise(IUnknown* pUnkSink, DWORD *pdwCookie)
   {


      IUnknown* p;
      HRESULT hRes = S_OK;
      if (SUCCEEDED(pUnkSink->QueryInterface(*m_piid, (void**)&p)))
      {
         // Add p to the list of sinks;
      }
      else
      {
         hRes = CONNECT_E_CANNOTCONNECT; // ATL does this
         hRes = E_NOINTERFACE; // MFC does this
      }
      return hRes;


   } 

   HRESULT CConnectionPoint::Advise(IUnknown* pUnkSink, DWORD *pdwCookie)
   {


      IUnknown* p;
      HRESULT hRes = pUnkSink->QueryInterface(*m_piid, (void**)&p);
      if (SUCCEEDED(hRes))
      {
         // Add p to the list of sinks, maybe returning
         // CONNECT_E_ADVISELIMIT if necessary
      }
      else if (hRes == E_NOINTERFACE)
      {
         // The sink does not support *m_piid!
         return CONNECT_E_CANNOTCONNECT;
      }
      return hRes;


   } 

• This mode does not work unless both sides use local accounts, not domain accounts. For example, I could not use my Foo\MarkRy account on Machine1 and a Machine2\MarkRy account on the other machine running Windows NT Workstation. In that case, Windows NT Workstation would have to delegate to its domain controllers, which it does not do. It fails any attempts by a different MarkRy that comes from an distrusted domain (or machine running Windows NT Workstation).



• This fallback mode is implicit in Windows NT Workstation to Windows NT Workstation interactions but explicit in interactions between Windows NT Workstation and Windows NT Server. In the case where you want to give access to an machine running Windows NT Server from a Windows NT Workstation user, but the Windows NT Workstation machine itself is not part of the same domain (or of a trusted domain), you need to create a special kind of user account called a "local" user. In the User Manager for Domains, open the New User dialog box, and click Account.

• To prevent CoRegisterClassObject failure, remove the following named value:

  
  [HKEY_CLASSES_ROOT\APPID\{0bf52b15-8cab-11cf-8572-00aa00c006cf}]
     LocalService"="HelloOleServerService" 




• To prevent a IRunningObjectTable::Register(ROTFLAGS_ALLOWANYCLIENT) failure, use the following steps: 1. Remove the following named value:

  
        [HKEY_CLASSES_ROOT\APPID\{0bf52b15-8cab-11cf-8572-00aa00c006cf}]
        "LocalService"="HelloOleServerService" 

  2. Then add the following named value:

  
        [HKEY_CLASSES_ROOT\APPID\{0bf52b15-8cab-11cf-8572-00aa00c006cf}]
        "RunAs"="Interactive User" 

   \\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\ 
   Parameters\RestrictNullSessionAccess 

• The authentication level is negotiated. If you have a Windows 95 client with authentication level connect and a Windows NT server with authentication level encrypt, DCOM tries to use encrypt for calls in both directions. Since Windows 95 cannot receive calls at encrypt, the NT machine cannot call the Windows 95 machine. Thus both the client and server have to set the authentication level to the lowest value allowable for any call in any direction. Similarly if you have two processes, one with a login token and the other with an impersonation token and you set the authentication level to none in the second, it still won't be able to call the first if its authentication level is not none.



• Did the call reach the server? (Use a debugger to find out.) If the call reached the server, the error may have been returned from the server, rather then DCOM.



• Did COM return an error or did the server return an error? If the server returned an error, step through the server function to debug it. If COM returned an error because of security, then Ole32.dll prints a message to help you debug it. COM may have returned an error because the client machine couldn't reach the server or the domain controller.



• If it's the apartment model, is the server dispatching messages? This is the most common problem. Apartment model servers require a message pump. If the server doesn't dispatch messages, no calls succeed.



• If the server is not run as interactive user, does it hang displaying a pop-up on a hidden desktop? This is the most common instance of the previous problem. If the server is not running on the desktop and it displays a pop-up, the application appears to hang mysteriously. Break in with the debugger and get a stack trace. Print the parameters to the dialog box APIs to see what the pop-up is for.



• NTLMSSP prevents RunAs the Launching User from making secure network calls. See question 10, "What are the Limitations of RunAs the Launching User?" NTLMSSP is the security provider package that provides Windows NT security.



• Default access permissions are not obvious. For legacy applications, if there is no AccessPermission value under the APPID and no DefaultAccessPermission value, COM creates a security descriptor. COM finds the SID of the process token and constructs a security descriptor or IAccessControl allowing that SID and local system. Thus if you run Excel and Word from the command prompt, they can talk to each other. However they cannot talk to a process on the same machine running as someone else.

• Make sure the owner and group are set in all security descriptors. AccessCheck fails if the owner and group are not set.



• Grant access to the SYSTEM account. Rundowns and other activation calls (lazy use protseq) fail if system does not have permission.



• Impersonation nested in the apartment model. If a process receives a call, impersonates the client, and receives another call on the same thread, the new call begins with no thread token. When the new call completes, COM restores the previous call's impersonation token.



• NTLMSSP in Windows NT 4.0 does not allow delegation-level impersonation. If you set the impersonation level to delegation or anonymous on Windows NT 4.0 with NTLMSSP, CoInitializeSecurity succeeds and all your calls fail.

http://support.microsoft.com/support/kb/articles/q156/2/23.asp

COM Security on Windows 95

http://msdn.microsoft.com/library/default.htm

• Call-level security CoInitalizeSecurity, IClientSecurity, CoGetCallContext, IServerSecurity, and the related helper APIs are all fully supported. Windows 95 machines can make calls at any authentication level, but incoming calls never arrive with a higher authentication level than connect (RPC_C_AUTHN_LEVEL_NONE or RPC_C_AUTHN_LEVEL_CONNECT). Note that the first beta of DCOM for Windows 95 does not support external configuration of access permissions in the registry; all processes that do not call CoInitializeSecurity on this release will be completely insecure.



• Remote connections By default DCOM for Windows 95 does not allow remote machines to connect to running objects. The HKEY_LOCAL_MACHINE\Software\Microsoft\OLE registry key has as a named value "EnableRemoteConnect." By default this value is set to "N." To enable remote connections, change this value to "Y." You can do this in the OLE/COM Object Viewer with the File.System Configuration dialog box. Changing this value requires a reboot. If EnableRemoteConnect is not set to "Y," then all incoming calls are rejected (the caller, typically, gets an RPC_S_SERVER_UNAVAILABLE return code). Remote calls from the machine work (assuming DCOM is enabled).



• Activation All processes on Windows 95 run under the same security blanket: that of the currently logged on user. Thus it is not possible to securely launch process from another machine. DCOM on Windows 95, therefore, does not support remote activation. Processes have to be started either manually, or via some other mechanism. For example, running a COM server with the /Embedding command line switch causes the server to register its class factory objects (via CoRegisterClassObject); remote machines can then successfully connect to the running instance (for example, by calling CoCreateInstanceEx). The DefaultLaunchPermissions and LaunchPermissions registry values have no effect on Windows 95.

Windows NT Security Issues

REFERENCES

For more information, please see the following article in the Microsoft Knowledge Base:

Q156673 Helsvc.exe Implements an OLE Server in a Service

  <LINK TYPE="ARTICLE" VALUE="Q156223">Q156223</LINK>


   How To Launch OLE Servers from ISAPI Extensions 

Additional query words: FAQ COM DCOM

Keywords          : kbcode kbSecurity kbWinDNA OleTwoCom 
Version           : WINDOWS:95
Platform          : WINDOWS 
Issue type        : 

Last Reviewed: June 24, 1999