Chapter 2. Components and architecture 39
The server certificates are installed when you install the Web application on the
WebSphere Application Server. The server key store file contains the public and
private keys for the server. The server trust store file contains the self-signed
certificates for the monitors and NetView Integrated TCP/IP Services
The client certificates are installed when you install the monitor component. The
client key store file contains the public and private key of the client. The client
trust store file contains the monitor’s and server’s self-signed certificates.
The secure ports used by the Web application and the monitor are described in
2.4.2, “Communication port usage” on page 35.
To secure the transport between WebSphere Application Server and the
monitors, you must specify values for the trustStoreName and keyStoreName
parameters in the itmnp.properties file for each monitor.
To secure the transport between the NetView Integrated TCP/IP Services
Component and WebSphere Application Server, you must copy the client
certificates from the IBM Tivoli Monitoring for Network Performance CD-ROM
and store them on the server where the NetView Integrated TCP/IP Services
Component is running. You must then specify values for the trustStoreName and
keyStoreName statements in the nvexportd.properties file. If you choose to
secure the transport, all of the monitors and systems where the NetView
Integrated TCP/IP Services Component is running must be configured to secure
2.4.4 Transport between DB2 and monitor
The DB2 product uses one port to listen for communication from the monitors.
The port number is specified using the DBPort parameter in the monitor
itmnp.properties file. The default value for this port is 50000 for AIX.
itmnpItscTrustStore.jks itmnpServerCert.arm itmnpItscKeyStore.jks
Repositories TrustStore Trusted Certificate KeyStore
Note: The discussion in this section applies to a Web application running on
40 IBM Tivoli Monitoring for Network Performance V2.1: The Mainframe Network Management Solution
By default, IBM Tivoli Monitoring for Network Performance uses
password-protected security when it transmits data to and from the DB2
database. A user ID and password are verified at the DB2 server, and the
password is transmitted using CLEAR_TEXT_PASSWORD_SECURITY.
Security may be increased by configuring for encrypted passwords. Security may
be reduced by configuring for CLIENT verification.
Communication between the monitors and the DB2 database can be secured
using security mechanisms provided by the DB2 server. One of these
mechanisms should be used to protect against unauthorized access to your
The DB2 product supports five security mechanisms, including two that require
Kerberos. However, the IBM Tivoli Monitoring for Network Performance does not
support Kerberos as an option. As a result, only three of the mechanisms are
supported in this environment.
The following DB2 security mechanisms are supported by IBM Tivoli Monitoring
for Network Performance. The security parameter db2Security in
itmnp.properties determines how and where authentication of a user takes place.
The supported types are:
CLIENT: Authentication takes place at the client. As a result, authentication is
not performed at the server. This is the IBM-supplied default value for IBM
Tivoli Monitoring for Network Performance.
SERVER: User ID and password are sent from the client to the server so that
authentication can take place on the server
SERVER_ENCRYPT: User ID and password are sent from the client to the
server so that authentication can take place on the server. This is the same
as SERVER, except that any passwords sent over the network are encrypted.
The IBM Tivoli Monitoring for Network Performance monitor component includes
a DB2 universal driver that allows the monitors to communicate with the DB2
server from a remote system. The DB2 universal driver configuration options
reside in the itmnp.properties file, known as DBDriverType. The names of these
security mechanisms do not exactly match the names of the security
mechanisms on the DB2 server. However, they are related. Table 2-3 on page 41
contains the supported DB2 server mechanisms and the universal driver security
mechanisms that are compatible with each one.