HP UX B6941-90001 - Manual (Page 441)

Chapter 10 441
Tuning, Troubleshooting, Security, and Maintenance
ITO Security
Authentication
DCE’s security mechanism allows you to protect the communication
between server and managed node using DCE RPC. An important step in
the authentication procedure that an DCE RPC process goes through
involves the obtaining of a login context. A 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), which are checked by the DCE security server prior
to a connection. Since ITO processes usually run without any user
interaction, reliance on an inherited login context is not suitable.
Consequently, the ITO processes create their own login context with a
name and password that must be registered at the DCE security service.
The RPC clients use the login context to get a server-specific ‘ticket’
which will then be passed with each RPC. The client obtains this ticket
from the DCE security service only if it has already passed the
authentication process. This ticket contains a key which is not visible to
the client application and known only to the security service and the
server. The RPC server verifies the ticket using the server’s password in
the key file and rejects non- matching RPCs, i.e. if a client receives a
successful response from the server, it knows that an authentic server
processed the request. The only information the server has at this point
is whether or not the client is authentic. Subsequently, it extracts from
the RPC handle the following information:
❏ the client’s name
❏ the level of protection the client has chosen
Once the authentication process has completed successfully, a connection
is established, and the RPC call sequence initiates. You can configure
ITO to carry out the authentication check at the RPC connection to a
server, at the beginning of each RPC client-server call, or for each
network packet.
In the context of ITO, Figure 10-1 on page 442 uses the example of
message transmission to illustrate the authentication process the DCE
client and server go through. The numerical call outs in Figure 10-1 on
page 442 point to further information, which is provided in the following
list:
1. The RPC client ( opcmsga ) reads its password from the key file
2. The RPC client logs in, gets a login context, and obtains a
security-server ticket