Contained Within
Find More Documentation
Featured Support Resources
| Descargar este libro en PDF (833 KB)
Appendix C Troubleshooting
a J2EE Agent Deployment in Policy Agent 2.2
This appendix explains how you can resolve problems that you might encounter
while deploying or using J2EE agents.
Be sure to also check the Sun Java System Access Manager Policy Agent 2.2 Release Notes,
to see if the problem that you encounter is a known limitation of the agent.
If workarounds are available for such problems, they are provided in the release
notes.
J2EE Agent Troubleshooting Instructions
This section includes various symptoms. Each symptom is accompanied
by one or more possible causes. Each possible cause is accompanied by a troubleshooting
solution.
|
1. Symptom: The agent does not require users to login before access
is granted to the application.
|
|
Possible Cause
|
Troubleshooting Solution
|
|
1–1) The application has not been configured to use the agent.
|
1–1) For information about deploying the agent application, see Chapter 4, Post-Installation Tasks of Policy Agent 2.2 for IBM WebSphere Portal Server 5.1.0.2.
|
|
1–2) The application fails to create an SSO token because a valid
agent profile does not exist. J2EE agents authenticate with Access Manager using
an agent profile, which is created in Access Manager Console.
|
1–2) Using Access Manager Console, ensure that a valid agent profile
exists. Using the command line, encrypt the agent profile password with the agentadmin --encrypt command. In the J2EE AMAgent.properties configuration file, ensure that the following properties have
the updated agent profile name and password:
com.sun.identity.agents.app.username =
com.iplanet.am.service.secret=
|
|
1–3) The resources match entries in the not-enforced list.
|
1–3) Make sure that the resources being accessed do not match
the entries in the not-enforced list, and ensure that the list is not empty
or inverted.
|
|
2. Symptom: The agent denies access to all requests.
|
|
Possible Cause
|
Troubleshooting Solution
|
|
2–1) The agent and Access Manager have been installed on the same
machine and the browser might not be setting the HOST header correctly when
redirected from Access Manager to the agent.
|
2–1) Enable port check functionality. For information about enabling
port check functionality, see Enabling Port Check Functionality in J2EE Agents.
|
|
2–2) The deployment container is running as a user who does not
have write privileges to the audit log directory of the agent.
|
2–2) Refer to the path specified in the J2EE agent AMAgent.properties configuration file for the agent’s local audit file and grant
the necessary write permissions for the user of the deployment container process.
|
|
2–3) The agent is unable to validate user’s session token
issued by Access Manager.
|
2–3) Ensure that the agent is installed on the same domain that
is specified as the cookie domain in Access Manager. If not, enable CDSSO functionality.
If that is not the case, try changing the value of the following property: com.sun.identity.agents.config.sso.decode
|
|
2–4) The agent is configured for CDSSO and the validity time of
the authorization response is smaller than the processing time required by
the agent.
|
2–4) Set an appropriate value for the following property: com.sun.identity.agents.config.cdsso.clock.skew
|
|
2–5) The Login URL specified in the J2EE agent AMAgent.properties configuration file is not reachable by the agent.
|
2–5) Ensure that the Access Manager Login URL is reachable from
the machine where the agent is installed.
|
|
2–6) The Access Manager is installed with SSL and the agent cannot
communicate with it correctly.
|
2–6) Install the appropriate root CA certificate in the keystore
used by the deployment container on which the agent is installed.
|
|
3) Symptom: Accessing a protected resource results in an HTTP 404 not
found error.
|
|
Possible Cause
|
Troubleshooting Solution
|
|
3–1) The agent and Access Manager have been installed on the same
machine and the browser being used might not be setting the HOST header correctly
when redirected from Access Manager to the agent.
|
3–1) Enable Port Check Functionality. For more information about
performing this task, see Enabling Port Check Functionality in J2EE Agents.
|
|
3–2) The resource is protected by a J2EE declarative security
constraint which is not being evaluated correctly and the server is trying
to display form-error-page, which does not exist within
the application.
|
3–2) Make sure that the resource specified by form-error-page in the web application’s web.xml deployment
descriptor actually exists within the application.
|
|
3–3) The resource is being accessed by a legacy browser such as
Netscape 4.x and during the installation of the agent no valid value was entered
for agent application URI field.
|
3–3) Reinstall the agent and specify a valid agent application
URI value.
|
|
3–4) The agent is operating in the CDSSO mode and no valid value
was entered for the primary application context path field during agent installation.
|
3–4) Reinstall the agent and specify a valid primary application
context path.
|
|
4) Symptom: When Access Manager is SSL Enabled, the agent denies access
to all resources.
|
|
Possible Cause
|
Troubleshooting Solution
|
|
4–1) The agent does not have the root CA certificate of the signer
of the certificate used by Access Manager.
|
4–1) Install the appropriate root CA certificate in the keystore
used by the deployment container on which the agent is installed.
|
|
5) Symptom: The Access Manager logs indicate that Access Manager is unable
to send notifications to the deployment container protected by the agent.
|
|
Possible Cause
|
Troubleshooting Solution
|
|
5–1) The agent is installed on a server with the preferred listening
protocol set to HTTPS and the root CA certificate for the signer of the agent’s
server certificate is not available in the keystore used by Access Manager.
|
5–1) Add the root CA certificate for the signer of agent’s
server certificate to the keystore used by Access Manager.
|
|
5–2) No valid value was entered for agent application URI during
agent installation.
|
5–2) Reinstall the agent and specify a valid agent application
URI. For example, /agentapp. The same URI should be used
as a context root for deploying the agent application through the administration
console of the container.
|
|
6) Symptom: The following warning messages appear on the console window
from which the deployment container is started or in the deployment container
logs:
Bad level value for property: com.iplanet.services.debug.level
Bad level value for property: com.sun.identity.agents.logging.level
|
|
Possible Cause
|
Troubleshooting Solution
|
|
6–1) These messages are logged by the JDK 1.4 logging framework
in use, which treats the J2EE agent AMAgent.properties configuration
file as the logging configuration file.
|
6–1) These messages are harmless and can be safely
ignored.
|
|