Page #75 (Chapter 11 - Using ActiveX DLLs from WebClasses)

	Chapter 11 - Using ActiveX DLLs from WebClasses
	Visual Basic Developers Guide to ASP and IIS
	A. Russell Jones

Copyright 1999 SYBEX Inc.

---

	Accessing ActiveX DLLs from WebClasses

	WebClasses do not participate in transactions—in other words, they don't automatically run under MTS. WebClasses don't recognize the design-time MTS-TransactionMode setting available from other VB ActiveX DLLs. Nevertheless, IIS applications (those you create via the Internet Service Manager) run under MTS whether you run them as part of the IIS root application or whether you set them up to run in an isolated process.

	The inability of WebClasses to run natively as MTS objects leads to permissions problems when you attempt to access external ActiveX DLLs from WebClasses. These are complex problems; you may want to visit the following explanation more than once.

	When a WebClass tries to create a new instance of an external ActiveX DLL, NT creates the object via distributed COM (DCOM). For security reasons, DCOM requires that each object must run in a defined context. A context in NT is the set of permissions associated with a user or an impersonation of a valid user. For example, when you sign on to your computer, you acquire the context associated with your sign-on. That context gives you permission to do certain things and access specific directories.

	Registered objects that do not explicitly write their context in the Registry run under a default context that you can set by using the program dcomcnfg.exe that comes with Windows NT. By default, users in the Administrators group, the System account, and the Interactive User account (called INTERACTIVE ) have permission to read the appropriate Registry keys and launch applications. When you install the NT 4 Option Pack with IIS 4, the installation adds the same permissions for the IUSR_MachineName and IWAM_MachineName accounts.

	The whole system works well when you're the person signed on to the NT computer. Whenever you (or a program you're running) launch an object, NT checks to see whether you have permission to launch that object, which—as the interactive, signed-on, and authenticated user—you generally do.

	Unfortunately, the system doesn't work as well for WebClasses. IIS launches an anonymous request for a WebClass in the context of IUSR_MachineName or IWAM_MachineName, depending on whether the application runs under the root application or an isolated process. But those two accounts aren't authenticated users—they belong to the Guest account. Also, although the anonymous accounts have a password, they don't have the ability to supply the password security identifier (SID) to DCOM when it tries to authenticate the launching user. This is the primary reason that many people have trouble accessing their SQL database from ASP pages and WebClasses. Therefore, when IIS allows anonymous requests, any calls made to external DLLs from a WebClass may fail.

	You never see this happen when you're developing a WebClass and running it in the VB environment. Inside VB, the WebClass runs under your context, but when you compile the WebClass DLL, it runs under the IIS default user context. When you launch an ActiveX DLL from a WebClass, DCOM asks IIS for the proper authorization credentials. When IIS is unable to supply them, the launch fails. When an object fails to launch, the WebClass method will also fail. You should check the Application event log for error messages if you see permission denied errors.