We've seen how regular COM objects can be made to work across a network using DCOM simply by altering a registry configuration. This is done by design to allow the crop of existing COM components to participate in the DCOM world immediately. You don't even need to recompile these components to make them work across the network. Specifically, the following registry keys are essential in letting the SCM know that the server is located on another machine:
\HKEY_CLASSES_ROOT\AppID\<the object’s CLSID>\RemoteServerName = “ip address of server node”
\HKEY_CLASSES_ROOT\AppID\<the object’s CLSID>\RunAs = “Interactive User”
These settings will make the SCM look for the remote class on the server node, and run with the security principal and identity of the current user
In addition, we need to make sure that the following keys in the registry are removed:
\HKEY_CLASSES_ROOT\CLSID\<the object’s CLSID>\InProcServer32
\HKEY_CLASSES_ROOT\CLSID\<the object’s CLSID>\LocalServer32
otherwise the SCM will use either the in-proc or local server versions of the object to create the instance of the object, as the mechanism is more efficient.
This approach works well when only one externally created class can be created by the remote executable. In the case where there are multiple classes corresponding to the same remote executable, we'll need to create a registry key called
at each AppID
entry. The \HKEY_CLASSES_ROOT\CLSID\<the object's CLSID>
key should contain a GUID that refers back to the entry under AppID
. For example:\HKEY_CLASSES_ROOT\AppID\<GUID>
\HKEY_CLASSES_ROOT\CLSID\{A023F6A0-F4C1-11CE-8EAF-00608C85E107}\AppID = {208D2C60-3AEA-1069-A2D7-08002B30309D}
\HKEY_CLASSES_ROOT\CLSID\{B10CBD8E-F9B6-11CF-9B38-0080AD11B667}\AppID = {208D2C60-3AEA-1069-A2D7-08002B30309D}
\HKEY_CLASSES_ROOT\AppID\{208D2C60-3AEA-1069-A2D7-08002B30309D}\RemoteServerName = “192.168.0.1”
\HKEY_CLASSES_ROOT\AppID\{208D2C60-3AEA-1069-A2D7-08002B30309D}\RunAs = “Interactive User”
In this example, we can see that objects with CLSIDs
and {A023F6A0-F4C1-11CE-8EAF-00608C85E107}
can both be created using a server on the node {B10CBD8E-F9B6-11CF-9B38-0080AD11B667}
. The SCM will use this information to decide where to go and create instances for these two classes.192.168.0.1
We're running as the
(under DCOM for Windows 95, there exists really no other choice) in these cases in order to avoid complications due to security constraints on Windows NT based systems. Interactive User means the user who is currently logged on at the particular PC. Under Windows 95, all currently active processes 'belong' to the system that is currently logged on. Adopting this simple approach to security allows us to focus our effort on development and testing. As long as we're logged on as the same user on all machines containing clients and servers to be tested, DCOM will be able to connect and execute. For production, however, we must plan our security strategy carefully using DCOM's security blanket mechanism. This will be the subject matter of Chapter 9.Interactive User