Monitoring, Version 6.2
Access to the Tivoli Enterprise Portal is controlled by user accounts defined to the portal server. In addition to defining the user IDs that are authorized to log on to the Tivoli Enterprise Portal, these accounts define the permissions that determine which Tivoli Enterprise Portal features a user is authorized to see and use, a list of monitored applications the user is authorized to see, and a list of Navigator views (and the highest level within a view) the user can access. An initial sysadmin user ID with full administrator authority is provided so you can log in to the Tivoli Enterprise Portal and add more user accounts. For information on creating user accounts setting user permissions, see IBM Tivoli Monitoring: Administrator's Guide.
If user security is enabled on the hub Tivoli Enterprise Monitoring Server (Security: Validate User), a password as well as a user ID is required to log in to the Tivoli Enterprise Portal. Password authentication is controlled by the host of the hub monitoring server. If the hub is configured to authenticate users, when a user logs in to the Tivoli Enterprise Portal, the portal server asks the hub monitoring server to validate the account and sends the encrypted user ID and password. The hub monitoring server validates the account by sending a request to the operating system. For authentication to be performed at the hub, then, Tivoli Enterprise Portal user IDs and associated passwords must be defined on the hub computer. How you configure password authentication depends upon the operating system where the hub monitoring server is installed (see Table 13).
| Operating system of the hub monitoring server | Method of Tivoli Enterprise Portal password authentication |
|---|---|
| Windows | User accounts |
| Linux and UNIX | Password files |
| z/OS | RACF, CA-ACF2, CA-TOP SECRET, or Network Access Method |
Wait to enable user authentication at the hub monitoring server until you have completed and tested at least a basic installation of Tivoli Management Services components and IBM Tivoli Monitoring base agents. Before you enable user authentication on the hub, at a minimum, add the sysadmin user ID to the network domain user accounts or to the operating system on the host where the hub monitoring server is installed. On Windows, the installation program creates a sysadmin user account and asks you to specify a password for that ID. On other systems, an administrator must create the user account, if it does not already exist.
When you enable security on the hub monitoring server, you have the option of enabling validation using LDAP instead of the local registry for user authentication.
Before you configure LDAP authentication, the LDAP administrator must create a filter mapping Tivoli Enterprise Portal user IDs to LDAP names. If you intend to use SSL for communications with the LDAP server, a CMS key store and key store stash must be created, using GSKit, and public key certificates imported into either the CMS key store, the LDAP keystore, or both.
A public key certificate is a digital document that associates a user ID with a public key. Digital certificates establish, or certify, the identity of a public key holder. They are issued by a trusted third party, or certificate authority (CA). They contain the key holder's name, a serial number, a copy of the certificate holder's public key, and other information such as expiration date of the certificate, and are signed by the CA that issued the certificate.
LDAP user authentication works with the following types of certificates:
If the LDAP at your site requires certificates from a CA, one or both of the following two certificates must be imported into the CMS key store:
The LDAP administrator can tell you which certificates are required.
Some sites also require that monitoring server certificates be used by the LDAP server. The LDAP administrator can tell you if a monitoring server certificate is necessary. If so, one or both of the following two certificates must be imported into the LDAP server and CMS key stores:
See Creating a new key database, Creating a new public-private key pair and certificate request and Receiving the CA-signed certificate for more information.
[ Top of Page | Previous Page | Next Page | Contents | Index ]