Document revision date: 15 July 2002 | |
Previous | Contents | Index |
Run DISPCMPNT.EXE on the system you designate as the remote machine (or server system). The remote system can also be a Windows NT system. When you receive the Server: Waiting message from the component, run the client on the system you designate as the local machine (or client system). For example:
To use the COM client, enter the following:
$ client :== $path-nameCLIENT.EXE $ client remote-system-name To which server do you want to connect? 1) In-Process Server 2) Out-of-Process Server : |
Enter
2
to select remote server execution, out-of-process server.
C.2.1.5 Running the Application on OpenVMS as an In-Process Server
To run the sample where the component is an in-process server, run only the client. For example:
$ run dclient |
$ run client |
The client displays the following:
To which server do you want to connect? 1) In-Process Server 2) Out-of-Process Server : |
Enter
1
to select the in-process server.
C.2.2 Windows NT Instructions
The following sections describe how to build the application on a Windows NT system.
In order to build Visual C++ applications from a DOS window, you must first set up a number of environment variables. If you did not select the option to have these variables set up automatically when you installed Visual C++, you will need to set them up each time you create a DOS window. To set up these variables, execute the file
|
Copy the README-DISPATCH-SAMPLE1.TXT file and the following files from the COM examples directory to your Windows NT system:
CLIENT.CXX DCLIENT.CXX DISPCMPNT.CXX DISPCMPNT.DEF DISPCMPNT.IDL MAKE-ONE. MAKEFILE.BAT REGISTRY.CXX REGISTRY.H |
Build the sample using the MAKEFILE.BAT file. For example:
C:> MAKEFILE |
The Makefile builds and registers both the in-process and
out-of-process servers.
C.2.2.2 Registering the Application on Windows NT
The build procedure make-one automatically registers DISPCMPNT.DLL , PROXY.DLL , and DISPCMPNT.EXE as follows:
regsvr32 -s Dispcmpnt.dll Dispcmpnt /RegServer |
To unregister the application, enter the following:
regsvr32 -u Dispcmpnt.dll Dispcmpnt /UnRegServer |
Run DCLIENT or CLIENT . Follow the same procedure as described for OpenVMS for running the application as an in-process server ( Section C.2.1.5) and an out-of-process server ( Section C.2.1.3).
Use the name of a remote machine (UNC or DNS) as an argument to
instantiate the object on the remote machine.
C.3 Cross-Domain Security Example (CLIENTAUTH)
This example shows how you can authenticate a remote client that is not
in the server's domain or in a domain that has a trust with the
server's domain. The client must pass to this application the
credentials (user name, domain and password) of an account on the
server's domain that is allowed access and launch permissions. In fact,
the client need not be in any domain and can be anywhere on the
network. This is demonstrated in Section C.3.1.3.
C.3.1 OpenVMS Instructions
The following sections describe how to build the application on an OpenVMS system.
Not all functionality is present in the underlying Windows NT infrastructure on OpenVMS. Therefore, you cannot run the client on OpenVMS. This example works when you run the client on Windows NT and the server on OpenVMS. |
Copy files from the DCOM examples directory to your local directory:
$ set default mydisk:[mydirectory] $ copy dcom$examples:[clientauth]*.* [] |
To build the application, run the command procedure:
$ @build_clientauth |
The BUILD file builds and registers both the in-process and
out-of-process servers.
C.3.1.1 Registering the Application on OpenVMS
PROXY$SHR.EXE , CLIENTAUTH$SHR.EXE , and CLIENTAUTH.EXE are registered automatically by the build procedure. To register the application manually, use the following procedure:
$ regsvr32 :== $DCOM$REGSVR32.EXE $ regsvr32 <path-name>CLIENTAUTH$SHR.EXE $ regsvr32 <path-name>PROXY$SHR.EXE |
$ regsvr32 /u <path-name>CLIENTAUTH$SHR.EXE $ regsvr32 /u <path-name>PROXY$SHR.EXE |
$ clientauth :== $<path-name>CLIENTAUTH.EXE $ clientauth /regserver |
$ clientauth /unregserver |
To run the example when the component is an out-of-process server, run CLIENTAUTH.EXE . When you receive the server waiting message from the component, run the client (in a separate window or terminal session).
$ run clientauth |
$ client :== $<path-name>CLIENT.EXE For OutProc: $ client 2 $ |
Run CLIENTAUTH.EXE on the system you designate as the remote machine, or server system. The remote system can also be a Windows NT system. When you receive the server waiting message from the component, run the client on the system you designate as the local machine, or client system.
$ client :== $<path-name>CLIENT.EXE $ client <remote-system-name> 2 $ Please enter account to use on remote machine: $ Username: $ Domain: $ Password: |
The client asks whether you want to start an in-process server or an
out-of-process server. For remote server execution, specify
out-of-process server. You then are prompted to enter the user name,
domain, and password of an account on the remote server. Make sure this
account has been granted access and launch permissions to the component
(see Section 6.3.2).
C.3.1.4 Running the Application on OpenVMS as an In-Process Server
To run the sample when the component is an in-process server, run only the client:
For InProc: $ client 1 $ |
The client asks whether you want to start an in-process server or an
out-of-process server. Specify in-process server.
C.3.2 Windows NT Instructions
The following sections describe how to build the application on a Windows NT system.
In order to build Visual C++ applications from a DOS window, you must first set up a number of environment variables. If you did not select the option to have these variables set up automatically when you installed Visual C++, you will need to set them up each time you create a DOS window. To set up these variables, execute the following file:
|
Copy the file README-CLIENTAUTH.TXT and the following files from the DCOM examples directory to your Windows NT system:
CLIENT.CXX CLIENTAUTH.CXX CLIENTAUTH.DEF CLIENTAUTH.IDL GUIDS.CXX MAKE-ONE. MAKEFILE.BAT PROXY.DEF REGISTRY.CXX REGISTRY.H |
Build the sample using the MAKEFILE.BAT file:
> MAKEFILE |
The Makefile builds and registers both the in-process and
out-of-process servers.
C.3.2.2 Registering the Application on Windows NT
CLIENTAUTH.DLL , PROXY.DLL , and CLIENTAUTH.EXE are registered automatically by the build procedure <make-one>:
regsvr32 -s clientauth.dll regsvr32 -s Proxy.dll clientauth /RegServer |
To unregister the application:
regsvr32 -u clientauth.dll regsvr32 -u Proxy.dll clientauth /UnRegServer |
Run CLIENT. Follow the same procedure as described for running the application on an in-process server and out-of-process server (see Section C.3.1.2 and Section C.3.1.4).
Do not use command line arguments to instantiate the object on the current machine. Instead, use the name of a remote machine (UNC or DNS) as an argument to instantiate the object on the remote machine.
(i.e) >Client hostname ! point the client at the remote system 2 ! means outproc invocation > >Username: >Domain: >Password: |
The following sections describe tasks you must complete when upgrading
from a previous version of COM for OpenVMS.
D.1.1 Rebuild Existing COM for OpenVMS Applications
If your COM for OpenVMS applications include references to any of the following APIs, you must recompile the modules that include the references and relink the application:
LoadLibraryA
LoadLibraryW
LoadLibraryExW
LoadLibraryExA
GetModuleFileNameA
GetModuleFileNameW
GetModuleHandleW
GetProcAddress
FreeLibrary
Some sample COM applications that shipped with COM Version 1.0 for
OpenVMS include references to these APIs in the modules REGISTRY and
CMPNT. If you built any samples, or if you built your own COM
applications based on these samples, you should recompile and relink
those applications.
D.1.2 Configuring the Windows NT Systems
For COM Version 1.0 for OpenVMS (unauthenticated COM) the COM for OpenVMS documentation instructed you to change specific values in your Windows NT registry to allow unauthenticated COM for OpenVMS to interoperate with Windows NT. COM Version 1.2 for OpenVMS, COM Version 1.1-B for OpenVMS, and COM Version 1.1-A for OpenVMS support authentication. As a result, you must set or reset the Windows NT Registry values we asked you to change for COM Version 1.0 for OpenVMS back to their default authenticated settings. To set the Windows NT Registry values, use the following procedure:
HKEY_LOCAL_MACHINE\Software\Microsoft\Ole |
Value name | Recommended COM V1.0 setting | Default (Authenticated) Value data (COM V1.2 setting) | Registry type |
---|---|---|---|
ActivationSecurity | N | Remove | REG_SZ |
PersonalClasses | N | Remove | REG_SZ |
You must have Windows NT Administrator privileges to view and update these settings. |
On OpenVMS systems, you must set or reset the specific OpenVMS Registry values. You can use the Windows NT Registry editor to edit the OpenVMS Registry, or you can use the REG$CP utility. To set the OpenVMS Registry values, use the following procedure:
HKEY_LOCAL_MACHINE\Software\Microsoft\Ole |
$ MCR REG$CP REG> LIST VALUE HKEY_LOCAL_MACHINE\Software\Microsoft\Ole REG> DELETE VALUE HKEY_LOCAL_MACHINE\Software\Microsoft\ Ole ActivationSecurity REG> DELETE VALUE HKEY_LOCAL_MACHINE\Software\Microsoft\ Ole PersonalClasses REG> DELETE VALUE HKEY_LOCAL_MACHINE\Software\Microsoft\ Ole LegacyAuthenticationLevel REG> DELETE VALUE HKEY_LOCAL_MACHINE\Software\Microsoft\ Ole LegacyImpersonationLevel REG> LIST VALUE HKEY_LOCAL_MACHINE\Software\Microsoft\Ole REG> EXIT |
If you configured an application to run with COM Version 1.0 for OpenVMS (unauthenticated COM for OpenVMS ) on Windows NT, you might want to reconfigure the Windows NT settings to take advantage of COM Version 1.2 for OpenVMS (authenticated COM for OpenVMS ).
Under COM Version 1.0 for OpenVMS after you registered a component, the COM for OpenVMS documentation instructed you to check the security properties on that component to ensure that an unauthenticated user can activate the image. Use the following procedure:
For COM Version 1.2 for OpenVMS, you must repopulate the OpenVMS Registry
to include security settings. Use the DCOM$SETUP command procedure to
display the OpenVMS COM Tools menu, and choose option 3.
D.2.2 Changing Application Security Settings in the OpenVMS Registry
COM Version 1.0 for OpenVMS, which shipped with OpenVMS 7.2, did not support NTLM security. As a result, the OpenVMS account through which you (or the system) registered the COM Version 1.0 for OpenVMS COM application was the owner for any OpenVMS Registry keys created as part of the application registration. For example, using COM Version 1.0 for OpenVMS, if you logged into the SYSTEM account and registered the SAMPLE1 application, all SAMPLE1's OpenVMS Registry keys are owned by SYSTEM.
COM Version 1.2 for OpenVMS supports NTLM security. The system now uses the network account to control access to the OpenVMS Registry keys. As a result of this change, previous security settings might prevent a nonprivileged user from accessing an application's registry keys. This means that a nonprivileged user working on an existing application might not be able to unregister or reregister an application.
To prevent this registration lockout, you must change the permission of the application. You can change the permission from either the Windows NT system or the OpenVMS system. Use either of the following procedures:
Previous | Next | Contents | Index |
privacy and legal statement | ||
6539PRO_019.HTML |