The information in this article applies to:
SUMMARYAn OLE server that is an EXE must include the IUSR_computername Internet guest account in its launch and access security permissions before it can be launched by an ISAPI extension DLL. In addition, if the server is an EXE server that is not a Win32 service, it must be configured to run under a specific user account using the RunAs registry value. MORE INFORMATIONAdding Launch and Access PermissionsIn NT 4.0, EXE OLE servers use activation security to specify the security contexts of clients that can activate the server. The server specifies this by using the HKEY_CLASSES_ROOT\AppID\{...}\LaunchPermission & AccessPermission keys or by defaulting to the default activation security for all servers on a machine specified by the HKEY_LOCAL_MACHINE\Software\Microsoft\OLE\DefaultLaunchPermission and DefaultAccessPermission keys. The values of these keys can be set using the DCOMCNFG.EXE graphical utility included in NT 4.0. Activation security is automatically applied by the Service Control Manager of a particular machine. Upon receipt of a request to activate an object from a client running in a different security context, the Service Control Manager checks the request against the Access Control List (ACL) specified by the above keys and will fail the activation if the client's security identifier is not in the ACL.The Internet Information Service (IIS) runs in the LocalSystem account. However, the IIS thread that executes an ISAPI extension DLL impersonates the IUSR_computername account, which is an Internet guest account created when IIS is installed. The default launch and access permissions of OLE servers do not give IUSR_computername permission to launch the server. As a consequence, a CoCreateInstance call from an ISAPI extension DLL will fail with E_ACCESSDENIED. This problem can be solved by adding the IUSR_computername to the OLE server's launch and access permissions using the DCOMCNFG.EXE utility. IUSR_computername need not be added to the launch and access permissions of inproc OLE servers. For inproc OLE servers, make sure that SYSTEM is listed in the DefaultAccessPermissions, and CoCreateInstance will succeed. For example, use the following steps to add to the Default Launch and Activation permissions:
Preventing USER32 Window Station/Desktop FailureWhen IIS calls OleInitialize, OLE will cache the window station and desktop that are connected to the IIS process in the LocalSystem account. The IIS thread that executes the ISAPI extension DLL impersonates the IUSR_computername account. When the extension DLL calls CoCreateInstance to create an EXE server (which is not a service and is not marked with RunAs in the registry), OLE will call CreateProcess to create the server and will pass the cached window station and desktop in the STARTUPINFO parameter. The server will be run in the client's security context (IUSR_computername) because it is not a service and not marked with RunAs. The launched server will cause the following USER32 error:CoCreateInstance will then fail with CO_E_SERVER_EXEC_FAILURE. The error occurs because the server is running in the IUSR_computername account and therefore cannot connect to the window station and desktop of the IIS process in the LocalSystem account. This USER32 failure will not occur for inprocess servers because the server runs in the IIS process and USER32 has already been initialized when the IIS process started. This problem can be solved by configuring the server using the RunAs registry value to run under a user account. This can be “Interactive User” if an interactive user will be logged on, or can be a specific user account if an interactive user will not be logged on. If “Interactive User” is specified, the server will run in the interactive user's account and will connect to the interactive desktop. If a specific user account is specified, the server will run in that account and connect to its own window station and desktop. As a consequence, the USER32 error will not occur. For example, use the following steps to configure a server to run under a user account:
Another solution to this USER32 problem is to call RevertToSelf before calling CoCreateInstance in the ISAPI extension. The thread will revert from the IUSR_computername account to the LocalSystem account and the launched server will run in the LocalSystem account. The USER32 error will not occur because the server will be able to connect to the window station and desktop of the IIS process, which also runs in the LocalSystem account. However, running a server in LocalSystem has a couple of problems:
Additional query words: OLE OLEISAPI COM DCOM
Keywords : LeTwoArc iisapi |
Last Reviewed: January 4, 2000 © 2000 Microsoft Corporation. All rights reserved. Terms of Use. |