Collecting Data: Tivoli Access Manager Integration for WebSphere Portal
Collecting troubleshooting data for Tivoli Access Manager integration issues with IBM® WebSphere® Portal expedites time to resolution by enabling IBM Support to provide informed problem analysis.
If you have already contacted IBM Support and must collect data to determine the nature of a problem in WebSphere Portal, review the information below for the available methods of data collection. Otherwise, review Collecting Data: Read first for WebSphere Portal.
Tivoli Access Manager integration information
Tivoli Access Manager is an external security manager that can be leveraged to provide the following services for WebSphere Portal:
-WebSEAL Single Sign-on (SSO) for authentication
-Protected Object Space and Access Control List Management for authorization
-Global Sign-on (GSO) lockbox credential vault integration
-Automatic user provisioning from WebSphere Portal self-registration to Tivoli Access Manager
Use the following instructions for collecting the necessary troubleshooting data.
Note: In addition to the Portal tracing described below, it is advisable to gather the following data in parallel in order to obtain an end-to-end view of the request(s) involved in the problem scenario:
- HTTP header logging during reproduction of the issue using a tool such as Fiddler (ensure you are decrypting HTTPS traffic if your testcase is via https://). Support can then correlate the client requests with the server tracing to ensure proper focus.
- both pdweb.snoop and pdweb.debug tracing from the WebSEAL instance for authentication or rendering issues See Collecting Data: ITAM WebSEAL for instructions on setting such tracing in WebSEAL.
I. Enabling trace logging
Enable tracing during problem recreation in order to investigate the specific behavior of the component(s). Choose to enable either static or dynamic tracing and proceed with the steps accordingly. For further information regarding logging and tracing in the portal, refer to the System event logging topic in the WebSphere Portal 7.0 Information Center.
Option A: Enabling static (extended) tracing
Static tracing is the recommended method of capturing data, as it collects data from server startup until problem recreation.
1. Log into the Integrated Solutions Console as the WebSphere Application Server administrator.
2. Click Troubleshooting->Logs and Trace->WebSphere_Portal->Diagnostic Trace.
3. On the Configuration tab, ensure Enable Log is selected. On this same tab, ensure you increase the Maximum File Size and and Maximum Number of Historical Files as needed to ensure that the tracing of the problem recreation is not overwritten due to the amount of traffic on the system and output of the tracing itself.
4. Click Change Log Level Details and enter the following trace string:
If experiencing an authentication issue, use the following trace string. For example, you would set this tracing if you log into TAM WebSEAL and rather than being redirected to the authenticated portal page, you receive the portal login page.
Note: If using the Enhanced Trust Association Interceptor (ETAI), append the following to the above tracestring: :com.ibm.sec.authn.tai.*=all
If experiencing an authorization issue when Tivoli Access Manager is set up to handle authorization for WebSphere Portal, use the following trace string:
If experiencing a Single Sign-On issue with a back-end application using the Credential Vault, use the following trace string:
5. Click OK and save the changes. If clustered, sync the nodes.
6. Restart the WebSphere_Portal application server.
Option B: Enabling dynamic tracing
Dynamic tracing can be used for situations that do not permit a server restart.
1. Log in as the Portal administrator.
2. Click Administration->Portal Analysis->Enable Tracing. The Enable Tracing portlet appears.
3. Type the required trace string into the field Append these trace settings:
[see step 4 under Option A for applicable trace string]
4. Click the Add icon. Enable Tracing updates the field Current trace settings.
Note: Restarting WebSphere Portal will remove traces that were set by using the Enable Tracing Administration portlet.
II. Collecting and submitting logs and configuration data
1. Reproduce the problem. Collect screenshots, userId, and timestamp information as appropriate.
2. Run the following script from <wp_profile>/PortalServer/bin to collect the data:
- Windows: wpcollector.bat
- Linux/Unix/i: wpcollector.sh
Note: If you wish to use wpcollector to FTP the files to IBM Support, include the -Dpmr=<pmr_number> parameter to indicate the relevant PMR #. For example: wpcollector.bat -Dpmr=11111,222,333 If you do not FTP your files via wpcollector, you'll find the "wp.mustgather.zip" file or the "<pmr #>-wp.mustgather-timestamp.zip" file in <wp_profile_root> /filesForAutoPD/.
3. Manually collect the following files from the WebSEAL system:
- WebSEAL junction XML files (include only those used to access Portal) from the junction database directory as defined in the [junction] stanza of webseald-<webseal_instance_name>.conf
4. Send the files to IBM Support by using the instructions outlined in Exchanging information with IBM Technical Support for problem determination.
Note: When sending in logs for review, include any relevant screenshots, timestamps, userIds, etc. in order to expedite analysis of the issue.
More support for:
Software version: 7.0, 8.0, 8.5, 9.0
Operating system(s): AIX, IBM i, Linux, Solaris, Windows
Software edition: Enable, Express, Extend, Hypervisor Edition, Server
Reference #: 1579530
Modified date: 24 January 2017
Translate this page: