Unauthenticated DCOM Access
Authenticated access requires that both the client and server trust a common security authority to perform the authentication. Typically, that security authority would be a Windows Domain Controller to which the client logs on. Sometimes the local security authority of the server machine can perform the authentication (if the client has a local account on the server machine, and the client is logged on to the client machine using the same user ID and password as that registered on the server machine).
If there is no common domain or other security authority shared between the client and server, then you can choose to allow unauthenticated (anonymous) access, although generally we do not recommended this because it provides no security.
Unauthenticated access requires cooperation by both the client and the server. This fact is often a source of confusion because most users are unaware of their client-side authentication level. For unauthenticated access to succeed, the client and server must both be willing to allow unauthenticated communication. The SPO is installed with an authentication level of Packet Privacy because this provides the most secure default. If you want to allow unauthenticated DCOM access you must change the SPO authentication level to None.
The Remote Server Object (RSO) Initiate method provides a routing parameter that lets you temporarily override the client's default authentication level and make an explicitly unauthenticated connection to a particular server. To request an unauthenticated connection, pass "unauthenticated" as the routing string.
There are several reasons why you might want to use this approach instead of changing the machine-wide DCOM default on your client machine:
• Changing the machine-wide DCOM default authentication level potentially can affect other applications besides OpenROAD, and might not be desirable for all applications.
• The machine-wide DCOM default authentication level is not used by some client processes, such as Microsoft's Internet Information Server (IIS). If your Active Server Page (ASP) script needs to make an unauthenticated connection to an SPO, you can accomplish that connection only with an explicitly unauthenticated Initiate call.
• Performance is usually better. By default, DCOM first attempts to establish an authenticated connection, and only after those attempts fail does it fall back to an unauthenticated connection. Those failed attempts often impose a significant performance penalty. If you know in advance that your server can be reached only through an unauthenticated connection, it can be faster to request the unauthenticated connection explicitly, forcing DCOM to bypass the attempts to establish authenticated connections.
Note: Unauthenticated DCOM provides absolutely no security and is therefore not a recommended configuration. The HTTP transport option provides a more secure way to enable access across disparate platforms, and to allow a controlled degree of unauthenticated access. The HTTP gatekeeper application in your web server can implement application-level authentication using your own mechanisms, and can limit unauthenticated access to specific OpenROAD Server applications and to specific SCP names within those applications. Unauthenticated DCOM permits anyone with network connectivity to the server machine to access any SCP in any OpenROAD Server application. For more information on HTTP transport, see HTTP Routing on page 191.