Server Reference Guide : Configuring the OpenROAD Server : DCOM Configuration : Global Settings
 
Share this page          
Global Settings
To configure global settings for the local machine, right-click the My Computer node in the Component Services tree view, and select Properties. A dialog with several tab pages, including Default Properties and COM Security, appears.
Default Properties Tab Page
The Default Properties tab page lets you change the default DCOM Authentication Level used by clients on that machine. This default is used by all OpenROAD client applications. Other applications may or may not use this default. (For example, IIS does not.)
If you want your OpenROAD clients on this machine to be able to access servers on other domains without having to explicitly use a Routing string of unauthenticated on the Initiate call, set this to None.
Note:  Using an Authentication Level of None is not recommended. Routing unauthenticated clients through an HTTP gatekeeper is a more secure way to provide unauthenticated access to specific OpenROAD Server applications.
Leave the Default Impersonation Level set at Identify.
COM Security Tab Page
On Windows versions that support only basic DCOM security, this page is titled “Default Security” or “Default COM Security” and it provides buttons that let you edit the default Launch Permissions and default Access Permissions that apply to any DCOM server that is not configured with customized permissions. The OpenROAD DCOM servers (ASO, SPO) are installed with customized permissions, and they do not rely on these defaults.
On Windows versions that support enhanced DCOM security this page is titled “COM Security” and it provides similar buttons (“Edit Default”) that let you edit the default permissions. But it also provides new buttons (“Edit Limits”) to allow you to edit the machine-wide DCOM limits. You will typically need to edit those limits to enable remote clients to access your OpenROAD Server.
The enhanced DCOM security model is configured by two separate ACLs: one for Access Permissions, and one for Launch and Activation Permissions. When you edit the Access Permissions ACL, you will see separate check boxes to grant local and remote access. When you edit the Launch and Activation Permissions ACL, you will see separate check boxes for local launch, remote launch, local activation, and remote activation.
A remote client connecting to a private server (ASO) requires Remote Access, Remote Launch, and Remote Activation permissions. A local client of the ASO requires only the local flavors of those same three permissions.
A remote client connecting to a shared server (SPO) requires just Remote Access and Remote Activation permission. (Since only the orsposvc service is meant to launch the SPO, no other client needs launch permission.) Similarly, local clients require only the local flavors of Access and Activation permission.
Note:  These machine-wide DCOM limits simply define a low-water mark that is applied to all DCOM servers on the machine. Individual servers can, and should, be configured for more specific and more restrictive permissions.