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
Summary of Contents for -UX B6941-90001
Page 6: ...6 ...
Page 8: ...8 ...
Page 27: ...27 1 Prerequisites for Installing ITO Agent Software ...
Page 43: ...43 2 Installing ITO Agents on the Managed Nodes ...
Page 115: ...115 3 File Tree Layouts on the Managed Node Platforms ...
Page 163: ...163 4 Software Maintenance on Managed Nodes ...
Page 183: ...183 5 Configuring ITO ...
Page 298: ...298 Chapter5 Configuring ITO Variables ...
Page 299: ...299 6 Installing Updating the ITO Configuration on the Managed Nodes ...
Page 315: ...315 7 Integrating Applications into ITO ...
Page 333: ...333 8 ITO Language Support ...
Page 352: ...352 Chapter8 ITO Language Support Flexible Management in a Japanese Environment ...
Page 353: ...353 9 An Overview of ITO Processes ...
Page 372: ...372 Chapter9 An Overview of ITO Processes Secure Networking ...
Page 373: ...373 10 Tuning Troubleshooting Security and Maintenance ...
Page 481: ...481 A ITO Managed Node APIs and Libraries ...
Page 499: ...499 B Administration of MC ServiceGuard ...
Page 513: ...513 C ITO Tables and Tablespaces in the Database ...
Page 520: ...520 AppendixC ITO Tables and Tablespaces in the Database ITO Tables and Tablespace ...
Page 521: ...521 D ITO Man Pages Listing ...
