|
COM/DCOM
Troubleshooting a COM/DCOM Connection
The following tips provide assistance for troubleshooting a COM/DCOM connection.
- Make sure you observe COM/DCOM requirements:
- You must use a SAS server to test a DCOM connection. You cannot test a DCOM configuration by trying to connect to a server on the same machine. This type of connection uses COM instead.
- To obtain details about why a DCOM connection attempt failed, check the System Log using the Event Viewer on NT
(Start Programs Administrative Tools Event Viewer). Double
click on an event that has a source of DCOM.
- In order to get two machines working with DCOM across untrusted
domains, the AuthenticationLevel must be set to NONE on both machines.
However, if you do this, the impersonation of the client will fail.
There is also a requirement that the user names and passwords must be
identical in both domains. In this case, Authentication can be enabled.
- To determine if launch permissions or access permissions need to be
fixed, use the control panel to assign a sound to for starting and
ending processes. If you hear the sound, launch permissions are probably
OK, but access permissions need to be adjusted. If you don't hear a
sound, check your launch permissions. This is necessary because the
server process may come and go faster than the NT task manager can
update.
- Make sure the registry settings are correct:
- To reset application-specific dcomcnfg settings, edit the registry
and remove the following keys:
HKEY_CLASSES_ROOT\AppID\SAS.EXE (if it exists)
HKEY_CLASSES_ROOT\AppID\
{440196D4-90F0-11D0-9F41-00A024BB830C}
Run dcomcnfg and view the (empty) access and launch permissions. When
you press OK or Apply, the dcomcnfg utility will put in some values for
access and launch permissions. You can see those values by viewing the
access and launch permissions again through dcomcnfg.
- The Default security registry location is
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole
- DCOM registry settings affect local COM also. DefaultAccessPermissions
(recommend Interactive and System), DefaultLaunchPermissions (recommend
Interactive and System), and Impersonation (recommend IMPERSONATE) are
all important for local COM. If you need to run local COM without
a license, set the authentication level to CONNECT.
- Restart any affected server or client processes.
- Individual registry keys can be secured with regedt32, but not
regedit.
- Make sure the working directory is correct:
- Make sure the permissions are correct:
- The NT Service Control Manager (SCM) runs in rpcss.exe.
The SCM is responsible for launching SAS under both COM and DCOM.
- If you do not have a license for the Integration Technologies
product, the IOM server restricts incoming connections by allowing
connections from the local machine only. As part of this verification, SAS System
Version 8 servers must be able to impersonate the client. Because the SAS Workspace
Manager will adjust the impersonation level settings when making a local
connection to allow this check to work, if you are using Version 8 of the SAS
System, then you should consider using the
SAS Workspace Manager to initiate the client session.
SAS System 9 and later servers can make this determination regardless of whether the client impersonation is enabled.
- The system account must have launch and access permissions (the SCM
runs under the system account).
- A good technique to use to determine what user ID is being used to
read/write files is to enable auditing on the file. To do this, first
use the User Manager Policies Audit...
to enable auditing for File and Object Access.
At this point, nothing will actually be audited
until the specific files that you want audited are enabled for auditing.
Do this from the File Manager. Select Properties Security tab Auditing for each file you want to audit. (If you do this for
a directory, you can specify all files under that directory.)
To view the audited information, use the Event Viewer and select
Log Security.
This will show you what user ID attempted to access the files specified through
the user manager.
- An error message that states "Server execution failed" when trying
to connect to the IOM server can be caused by many things including
trying to connect to an IOM server with an expired license or having an
invalid username/password in the dcomcnfg identity settings.
- Events work by having the IOM server make a call on an interface
that the client provides to SAS. In order for SAS to make a call on that
interface, the client must grant permission to SAS to make the call.
As another alternative, Microsoft has suggested setting the client's authentication level to None.
For a C/C++ application, this can be controlled through CoInitializeSecurity. For a Visual Basic application, set the
default authenticationLevel to None using dcomcnfg on the client side.
Note that this implies that events cannot be encrypted, and that the
only way to encrypt non-event data is through the server-side
authenticationLevel settings in dcomcnfg.
- Make sure the authentication is correct:
- On NT 4, the only authentication provided by default is NTLM, which
uses RC4 for packet encryption (if you turn it on, of course).
|