The following known problems exist that can affect the following agents: Agent for IBM WebSphere Application Server 5.1.1, Agent for IBM WebSphere Application Server 6.0, Agent for IBM WebSphere Application Server 6.1.
This issue applies to both Agent for IBM WebSphere Application Server 5.1.1 and Agent for IBM WebSphere Application Server 6.0.
The --install option of the agentadmin command can fail because of an issue with the IBM Java Development Kit (JDK). The IBM JDK comes with IBM WebSphere Application Server.
To run the --install option, the agentadmin script searches for a JDK with a Sun Microsystems JCE provider. However, the IBM JDK does not come with this JCE provider.
Therefore, to allow the agent installer to work with the IBM JDK, implement the steps described in the following workaround.
Workaround: The following task involving the editing of the agentadmin file makes available a JCE implementation that allows the agent installer to function properly.
Change to the directory containing the agentadmin file:
PolicyAgent-base/bin
Create a backup copy of agentadmin file.
This file is either the agentadmin script or, for Windows systems, the agentadmin.bat file.
Edit the agentadmin file accordingly.
Locate the last line of the agentadmin script.
This line starts with the following string: $JAVA_VM -classpath ...
Add the following two properties between the string $JAVA_VM and the string -classpath:
-DamCryptoDescriptor.provider=IBMJCE -DamKeyGenDescriptor.provider=IBMJCE
For example, after editing the final line of the script, it appears as follows:
$JAVA_VM -DamCryptoDescriptor.provider=IBMJCE -DamKeyGenDescriptor.provider=IBMJCE -classpath $AGENT_CLASSPATH com.sun.identity.agents.tools.launch.AgentAdminLauncher $*
This issue applies to both Agent for IBM WebSphere Application Server 5.1.1 and Agent for IBM WebSphere Application Server 6.0.
An exception message appears in the debug logs for the message mode. The exception message states that the DirectoryManager class cannot be found. The message is issued by the software development kit (SDK) as it searches for an indication of the mode in which it is running: remote or server.
Workaround: You can safely ignore this message.
The problem occurs when spaces are used in the common name (cn) in specific scenarios. The following conditions can cause the problem:
When either of the following agents are used:
Agent for IBM WebSphere Application Server 5.1.1
Agent for IBM WebSphere Application Server 6.0
When either of the following agentadmin options are used:
agentadmin --setGroup
agentadmin --removeGroup
When Access Manager 6.3 is used, since the problem occurs when the group name includes cn, which is specific to Access Manager 6.3.
The following agentadmin command illustrates the problem. Notice that the cn contains spaces: was admin role. The spaces before and after the string admin are not allowed:
/agentadmin --setGroup administrator "cn=was admin role,dc=example,dc=com" /opt/WebSphere/AppServer/config/cells/
Workaround: Use a text editor of your choice to directly map the groups in the admin-authz.xml file.
This issue applies to both Agent for IBM WebSphere Application Server 5.1.1 and Agent for IBM WebSphere Application Server 6.0.
The sample application issues a message that erroneously states that you must be logged in with the role “employee” in order to be granted access.
The following specific conditions apply:
Install and configure Agent for IBM WebSphere Application Server
Deploy the sample application.
Invoke the declarative J2EE security test sample.
At this point, a message appears saying that access to this servlet requires you to belong to the “employee” role.
Log in with the role “employee.”
Access is denied.
Log in with the role “manager.”
Access is allowed.
Workaround: None. However, be aware of the situation and be sure to log in as a user who belongs to the “manager” role.
This issue applies to both Agent for IBM WebSphere Application Server 5.1.1 and Agent for IBM WebSphere Application Server 6.0.
If two instances of Agent for IBM WebSphere Application Server are required on the same host, you cannot use the same agent bits to install each instance.
Workaround: Download a second set of bits to install the second instance of Agent for IBM WebSphere Application Server.
This issue applies to both Agent for IBM WebSphere Application Server 5.1.1 and Agent for IBM WebSphere Application Server 6.0.
Be aware that this issue only occurs on Windows systems. During the installation of the agent, you are prompted for the encryption key, as such:
Enter a valid Encryption Key. [ ? : Help, < : Back, ! : Exit ] Enter the Encryption Key []:
Usually, a default encryption key is provided in the prompt. However, depending upon the configuration of the IBM WebSphere Application Server instance, the IBM Java Virtual Machine (JVM) might return an empty encryption key. In such a case, the agent installer presents the prompt without a default encryption key included, as illustrated by the preceding example prompt.
Workaround: Manually enter a random value in response to this prompt.
This behavior has been observed with Agent for IBM WebSphere Application Server 6.0. Though rare, CLASPATH variable settings can be cleared after the agentadmin command is executed.
Workaround: Manually add the following entries to the CLASPATH variable of the IBM WebSphere Application Server 6.0 instance (where agent_001 is an example of the agent instance. It might be another instance, such as a agent_002or agent_003):
PolicyAgent-base/agent_00x/config
PolicyAgent-base/locale