HP OpenView Operations Administrator's Reference - filibeto.org

About Process Security
About OVO Processes
About Process Security
When communication between the management server and the managed
nodes is required, OVO carries out basic authorization checks
independently of DCE. However, DCE enables you to implement a much
more stringent security policy at process levels between, for example, an
RPC client and an RPC server, specifically in the areas of authentication
and data protection.
The level of data protection is chosen by the client, although the server
has the option of deciding whether a chosen level is sufficient. OVO
handles authentication in the context of either the RPC client or the RPC
server. For example, just as a server verifies that an incoming request is
from a genuine OVO client, so an RPC client verifies that the server it is
calling is a real OVO server.
About Process Authentication
During the authentication process, the OVO RPC obtains a login context.
Every secure RPC process has a login context, which it either inherits
from its parent process or establishes itself. The login context requires a
name (or principal) and a password (or key). Since OVO processes
usually run without any user interaction, reliance on an inherited login
context is not sufficiently secure. For this reason, each process creates its
own login context, with a name and password that must be registered at
the DCE security service. However, as in UNIX, multiple OVO processes
may run within the same login context. Management and maintenance
of the login context is carried out internally by the control agent and
control manager.
After the authentication process has completed successfully, a connection
is established, and the RPC request-reply sequence starts.
Authentication can be limited to the connection, the first RPC
client-server call, or all RPCs between the client and server.
Chapter 10 389