Security problems

This information covers common problems that occur with security in TADDM.

Discover permission granted to user but receives an error when viewing the objects created

Note: This problem does not apply to TADDM 7.3.0.2, and later.

Problem: Users with the Discover permission can create an object, but can receive an error message when viewing the created object.
Solution: Grant Discover permission and at least Read access to DefaultAccessCollection (all objects) to users who are allowed to create objects manually, including collections and access collections. Although users with only the Discover permission can create an object, they can encounter an error message when viewing the created object.

Logins to Data Management Portal take too long to complete

Problem: When memory is low on the TADDM server, and TADDM is configured to use the federated repositories functionality of IBM® WebSphere® Application Server, logging in to the Data Management Portal might take as long as 25 minutes to complete successfully.
Solution: Free system resources on the TADDM server. You might need to restart the computer where the TADDM server is installed.

Password changes not supported for users defined in external user registries

Problem

Either the Lightweight Directory Access Protocol (LDAP) or the WebSphere federated repository is configured as the TADDM user registry. In the Discovery Management Console, if an LDAP user or WebSphere federated repository user tries to change the user password using File > Change Password, the following message is displayed:

Unexpected system error. Contact IBM support.

TADDM does not support password changes for users that are defined in external user registries.

Solution

Use registry-specific tools to change user passwords. For example, LDAP users can change passwords using LDAP tools, and WebSphere federated repository users can change passwords in the WebSphere administrator console.

Users are not displayed in the Data Management Portal UI

Problem

If you have more than 100 users in your LDAP or WebSphere Federated Repositories, all users are not displayed in the Data Management Portal UI. Instead, the Data Management Portal UI either contains no users or missing users.

The default in the collation.properties file for the com.collation.security.auth.searchResultLimit= property has the default value of 100.

For LDAP, the error.log contains the following message:

SecurityManager [RMI TCP Connection(198)-9.42.31.44]  
ERROR service.SecurityManagerServiceImpl - LdapUserRegistry:getUsers() -- 
Search Result Limit Exceeded Exception received from 
	getUserNames(): CTJTS0085E 
The following search result limit is exceeded: 100.

For WebSphere Federated Repositories, the error log contains the following message:

The Data Management Portal only displays 100 users by default.

Solution

Edit the com.collation.security.auth.searchResultLimit=nnn property statement. Increase the value of nnn to accommodate the expected number of users. For example: com.collation.security.auth.searchResultLimit=150

LDAP users cannot be displayed in the Data Management Portal UI

Problem: With LDAP properly configured, the administrator is unable to display users by clicking the Users icon in the Data Management Portal. The browser might become unresponsive, and an InvalidUserException might appear in the logs.
Solution: Make sure that your LDAP user groups contain only valid users. If you delete an LDAP user, you must also manually remove that user from any LDAP user groups of which it is a member. If TADDM encounters an invalid user as a member of a user group, an error occurs, and no users can be displayed.

Errors when trying to log in with an SSL connection

Problem

When you log in to the Discovery Management Console with an SSL connection, you select the Establish a secure (SSL) session check box, but an SSL connection is not completed. An error message is displayed that states that the server is not running.

Solution

Ensure that you have downloaded the truststore and specified the location of the truststore file on the client system. To download the truststore, click Show SSL Options on the TADDM launch page and follow the displayed instructions. To use the truststore correctly, complete the following tasks:

Make sure that the specified directory contains a valid truststore file, and that the truststore file has not been renamed.
When specifying the location of the truststore file, do not include the file name.
Ensure that the name of the directory that contains the truststore file does not have a trailing path separator at the end. For example, if you saved the truststore file as
```
C:\domain_certs\Domain.cert
```
enter the directory for the truststore as
```
C:\domain_certs
```
Ensure that the directory that you specify exists.

If the problem persists, delete the truststore file, and download it again.

For more information, refer to the TADDM Installation Guide.

Secure connection fails when opening the TADDM launch page or Discovery Management Console using Firefox

Problem

When attempting to connect to the TADDM launch page or log in to the Discovery Management Console using Transport Layer Security (TLS) 1.0 and Firefox version 3.0 or later, the following error is displayed:

Secure Connection Failed

	An error occurred during a connection to taddm.mycompany.com:9431.
	Cannot communicate securely with peer: no common encryption algorithm(s).
	(Error code: ssl_error_no_cypher_overlap)

Solution

To allow secure connection to the TADDM UI with Firefox 3 and later, you must ensure that TLS has been enabled. To enable TLS in Firefox 3.6, follow these steps:

In Firefox, click Tools > Options.
In the Options notebook, click the Advanced tab.
Click the Encryption tab.
In the Protocols section, click Use TLS 1.0.
Click OK.
Attempt to open the TADDM launch page. An Untrusted Connection message is displayed.
Click Add Exception. The Add Security Exception window is displayed.
Click Confirm Security Exception. The TADDM launch page is displayed.

Connections to LDAP server are refused

Problem

On Windows operating systems, if clients are attempting many connections to the LDAP server, these connections can be refused. Error messages are logged by the LDAP server. Check in the ibmslapd.log file that an error like the following example is present:

Feb 11 14:36:04 2004 Communications error: 
Exceeding 64 connections/OCH - dropping socket.

Solution

If such an error exits, complete the following steps:

Stop the server.
Save a copy of your ibmslapd.conf file.

Insert the following information in the section that starts with 'dn:

cn=FrontEnd,cn=Configuration': 
ibm-slapdSetenv: SLAPD_OCHANDLERS=5

Restart your server.

If you continue to receive similar error messages, increase the value of the SLAPD_OCHANDLERS environment variable by increments of five until you stop receiving error messages. This workaround can be found in the IBM Tivoli® Directory Server, Problem Determination Guide, Version 6.1 at http://www-01.ibm.com/support/knowledgecenter/SSVJJU_6.3.0/com.ibm.IBMDS.doc/pdguide.htm?cp=SSVJJU_6.3.0%2F0-7 under Known limitations and general troubleshooting, in the section, Platform-specific problems, For Windows 2000, Windows Server 2003 Enterprise, Windows XP, Windows Server 2003 R2 Datacenter Edition, Windows Server 2008, and Windows 7 only, Communications error: Exceeding 64 connections/OCH.

Domain Management Portal login fails when using WebSphere Federated Repositories authentication

Problem

When using WebSphere Federated Repositories for authentication, attempts to log in to the Domain Management Portal fail, although logging in to the Discovery Management Console is successful.

Solution

This problem indicates that the TADDM server was not able to connect to the WebSphere Virtual Member Manager (VMM). To correct the problem:

Make sure the correct WebSphere host is specified in the following configuration files (located in the $COLLATION_HOME/etc directory:
- collation.properties
- ibmessclientauthncfg.properties
- sas.client.props
If the host name is incorrect, the $COLLATION_HOME/log/services/SecurityManager.log log file shows the following error message:
```
Fatal NamingException initializing VMM user management module: A
communication failure occurred while attempting to obtain an initial
context with the provider URL: host
```
Make sure the $COLLATION_HOME/etc/sas.client.props file specifies the correct WebSphere instance bootstrap port number in the following entry:
```
com.ibm.CORBA.securityServerPort=port
```
If you are using the CCMDB or IBM SmartCloud Control Desk WebSphere instance, the default bootstrap port is 9809. Other WebSphere Application Server products use a default bootstrap port of 2809.
If the specified bootstrap port is incorrect, the $COLLATION_HOME/log/services/SecurityManager.log log file shows the following error message if the TADDM log level is set to DEBUG:
```
Fatal NamingException initializing VMM user management module:
  NO_PERMISSION exception caught
```
Make sure the WebSphere Virtual Member Manager EJB interface is correctly installed on the WebSphere Application Server instance that TADDM is configured to use. If the VMM interface is not correctly installed, the $COLLATION_HOME/log/services/SecurityManager.log log file shows the following error message:
```
Fatal NamingException initializing VMM user management module: Context: 
ctgCell01/nodes/ctgNode01/servers/nodeagent, name: 
ejb/com/ibm/websphere/wim/ejb/WIMServiceHome: First component in name 
ejb/com/ibm/websphere/wim/ejb/WIMServiceHome not found.
```
To verify the VMM installation on the WebSphere Application Server system, check the SystemOut.log log file in the /profiles/ctgDmgr01/logs/dmgr/ subdirectory of the WebSphere Application Server directory. This file should include lines similar to the following:
```
[10/18/07 8:28:28:953 CDT] 00000016 EJBContainerI I WSVR0037I:
  Starting EJB jar: wimejb.jar
[10/18/07 8:28:29:296 CDT] 00000016 EJBContainerI I WSVR0057I:
  EJB jar started: wimejb.jar
```
To install the VMM interface on a Tivoli Integrated Portal server, follow these steps:
1. Copy the wim.ear file from a WebSphere Application Server installation to the \IBM\tivoli\tip\installableApps directory on the Tivoli Integrated Portal server.
2. On the Tivoli Integrated Portal server, go to the \IBM\tivoli\tip\profiles\TIPProfile\bin directory and run the following commands:
```
wsadmin.bat 
$AdminApp install "path\wim.ear" {-appname wim -cell TIPCell -server server1} 
$AdminConfig save
```
  where path is the fully qualified path to the installableAppsdirectory where you copied the wim.ear file.
3. Restart the Tivoli Integrated Portal service.

Error when starting the TADDM server

Problem

The ./control status command displays the status of Topology and Proxy service as starting but not started.

Solution

Verify the location of the TADDM encryption key file:

Open the collation.properties file.

Locate the following line in the file:

com.collation.security.key=etc/TADDMSec.properties

Note the location of the TADDMSec.properties file.
Verify that TADDMSec.properties file is in the location as specified in collation.properties file. If not, move the file to the correct location.
Restart your server.

Single sign-on fails after turning on VMM and federated repositories

Problem

When you turn on VMM and federated repositories, single sign-on (SSO) fails, and the server returns error 403.

Solution

Make sure that the All Authenticated parameter of TrustClientRole is set to Yes. To do this, complete the following steps.:
1. Navigate to the following directory:
```
TIP_HOME/profiles/TIPProfile/bin
```
2. Run the following command:
```
wsadmin.sh -username TIP_user -password password 
```
3. At the wsadmin prompt, run the following command:
```
AdminApp view authnsvc_ctges 
```
  In the output, look for Role: TrustClientRole All Authenticated: Yes.
4. If the Role is set to Yes, proceed to the next step. If it is set to No, complete the following steps:
  1. At the wsadmin prompt, run the following commands:
    AdminApp edit authnsvc_ctges {-MapRolesToUsers {{"TrustClientRole" No Yes "" ""}}}
    
    AdminConfig save
    
    AdminApp view authnsvc_ctges
    
    From the output, look for Role: TrustClientRole All Authenticated: Yes.
  2. Restart the Tivoli Integrated Portal server:
```
stopServer.sh server1
```
```
startServer.sh server1
```
Propagate the changes to external Java™ Authorization Contract for Containers (JACC) provider:
1. Log on to the Tivoli Integrated Portal console.
2. Expand Settings > Websphere Administrative Console, and click Launch Websphere administrative console.
3. In WebSphere Application Server, expand Security > Global security, and click the External authorization providers link.
4. Select the Update with application names listed check box.
5. In the text field, type authnsvc_ctges, and click Apply.
6. In the messages area at the top of the page, click Save.
7. Stop and restart the Tivoli Integrated Portal console.

When launching in context to TADDM, single sign-on does not work

Problem

You have configured TADDM to use WebSphere federated repositories, and you can successfully log in to the TADDM Data Management Portal and Discovery Management Console. However, when you launch in context to TADDM, single sign-on (SSO) does not work. To have the launch in context displayed properly, you must log in to TADDM again.

Solution

A WebSphere SSO token is not passed to TADDM. To solve this problem, complete the following steps:

Ensure that the correct WebSphere SSO domain has been configured correctly. See the WebSphere documentation for details.
In the Web address that you use to access the WebSphere installation, use a fully qualified domain name (FQDN) rather than a short host name. For example, use yourmachine.yourcompany.com rather than yourmachine.
WebSphere compares the host name from the Web address to the configured SSO domain to determine whether to forward an SSO token to TADDM. If you do not access WebSphere using an FQDN, no SSO token is passed to TADDM during a launch-in-context operation.

When TADDM data-level security is enabled, an error can occur when deleting a CI

Problem

When TADDM data-level security is enabled and you delete a Configuration Item (CI), if you do not have access to all related Configuration Items, the delete operation fails.

Solution

If a delete fails, in order to remove the CI, the delete operation must be carried out again. This task must be carried out by the TADDM administrator or by a user with equivalent permissions. Administrator has Read, Update, Discover, and Admin permissions.

Read & Update are data permissions applicable to access collections:

DefaultAccessCollection (virtual collection of all objects)
Specific access collections created programmatically or using the UI

In order to delete a particular CI, the user must have Read and Update permissions on access collections containing all CIs related to the CI to be deleted.

Users can perform Delete or Merge options on CIs that are in access collections they have not been granted access to

Problem: From the Discovery Management Console tree, you can right-click any object (CI) that you do not have access for and you are able to use the Delete or Merge function. You can merge all objects (except the durable object) and delete them.
Solution: This condition is a current limitation.