Windows NT4 - DCOM is included in base install
Win9x - use DCOM98.EXE that comes with Visual Studio 6.0
See Configuring DCOM for Remote Access for DCOM configuration procedure for various OS's.
Then run DCOMCNFG.EXE to configure DCOM. Note: Same utility for both client and server.
See http://msdn.microsoft.com/library/backgrnd/html/msdn_dcomarch.htm for some screen shots of DCOMCNFG.EXE in action.
From the MSDN topic:
Protecting Distributed Components
If your application uses distributed COM, you need to secure the components you deploy and register to remote workstations. In the context of remote component deployment, security means configuring each componentís access and launch permissions and protecting the component from tampering.
Security for creating remote objects is important because of the very simplicity of distributed COM. The only thing that determines whether a client uses a local ActiveX component, or the same component running on a remote computer, is the client computerís Windows Registry entry for the component.
The default configuration of distributed COM allows only machine administrators to access and launch objects from a remote client. After you have distributed, registered, and applied NTFS file permissions to your applicationís components, you must configure the access and launch permissions.
You can configure object permissions with the DCOMC NFG utility. With DCOMCNFG you define DCOM-specific settings in the registry, specifying where the component runs and who can launch and access the object.
For More Information For an overview of security on the NTFS file system, see Protecting Files in this chapter. For more information on using DCOMCNFG to configure object access and launch permissions, search for "DCOMCNFG" in MSDN Library Visual Studio 6.0.
Here's one: If your DCOM component needs to see mapped drives, you'll need to create a login script for the user the server impersonates.-- Steven Black
Actually, Steven, that's not true - the Win32 API provides two API functions at a minimum (
WNetAddConnection3()) which can map drives providing a distinct user name and password (even a different domain name if necessary) to make the connections on the fly without resorting to impersonation. The only problem is the expense of recreating the connections before each call, and that cost is less than the cost of impersonation and a login script!
In fact, if you've the WSH available to you, the
Wscript.Network's MapNetworkDrive will take optional user name and password parameters, for example:
oWSHNet = CREATEOBJECT('Wscript.Network')
maps drive Q: to
SomeServer's AppShare share, does not update the user profile data to auto-map the drive again, using the user id "Foo" and the password "Bar", and this functionality exists in even the version 1 WSH implementation. WNetAddConnection3() is more capable, but is a bit of a PITA to implement in VFP - there's sample code showing one approach in my NETRESOURCE class on UT, and Christof Wollenhaupt wrote a STRUCT class which makes the implementation easier if you don't want to use CLSHEAP for managing the structure memory yourself. -- Ed Rauh
Thanks Ed. I'm just a little nervous with having WSH (or Excel or Word) loaded on a server that's open to the web...-- Steven Black
Ummm... Steven, if you've IIS installed, WSH is there! -- Ed Rauh
I just checked: WSH is an option, just like IIS is an option, when you install the NT4 Option Pack-- Steven Black
Why would WSH on a server open to the web be a concern? And Why use mapped drives instead of UNC? -- Rox
Rox, Over the past couple of years I've read a number of incidents with trojans that can, through COM, do all kinds of damage. With Excel and Word it's via macros. With WSH, it's straight-in, have your way with my disk. Having said that, with a site like this one, am I paranoid :-)? -- Steven Black
Source: VB6 Exam Cram by Thomas and Fox
Category Exam 70-155 Hot Topic Category C _ O _ M
Create Object Ex
( Topic last updated: 2005.02.14 01:52:59 PM )