Operating Systems: i5/OS
Personalize the table of contents and search results
Security enablement followed by errors
Use this information if you are experiencing errors after security
is enabled.
What kind of error are you seeing?
For
general tips on diagnosing and resolving security-related problems, see the
topic Troubleshooting
the security component. IBM Support has documents and tools that can save you time
gathering information needed to resolve problems as described in Troubleshooting help from IBM. Before opening a problem report, see the Support
page:
Authentication error accessing a Web page
Possible
causes for authentication errors include:
- Incorrect user name or passwords. Check the user name and password
and make sure that they are correct.
- Security configuration error : User registry type is not set correctly. Check
the user registry property in administrative security settings in the administrative
console. Verify that the user registry property is the intended user registry.
- Internal program error. If the client application is a Java standalone
program, this program might not gather or send credential information correctly.
If
the user registry configuration, user ID, and password appear correct, use
the WebSphere Application Server trace to
determine the cause of the problem. To enable
security trace, use the com.ibm.ws.security.*=all=enabled trace
specification.
Authorization error accessing a Web page
If a user who is supposed to have access to a resource does
not, a configuration step is probably missing. Review Authorizing access to administrative roles.
Specifically:
- Check the required roles for the accessed Web resource.
- Check the authorization table to make sure that the user, or the groups
to which the user belongs, is assigned to one of the required roles.
- View required roles for the Web resource in the deployment descriptor
of the Web resource.
- View the authorization table for the application that contains the Web
resource, using the administrative console.
- Test with a user who is granted the required roles, to see if the user
can access the problem resources.
- If the user is required to have one or more of the required roles, use
the administrative console to assign that user to required roles, stop, and
restart the application.
If
the user is granted required roles, but still fails to access the secured
resources, enable security
trace, using com.ibm.ws.security.*=all=enabled as
the trace specification. Collect trace information for further resolution.
Authentication fails
when code pages differ between the client and the server
When a client
uses a code page that is different from the server, and non-US-ASCII characters
are used for the user ID and password during basic authentication, the login
does not succeed. The HTTP header does not include the encoding method information
that is necessary to translate the encoded data, so the server does not know
how to decode the information correctly. Use a login form that relies
on POST parameters, which are in the HTML body text. The encoding for the
text is sent by the browser and so is capable of being decoded properly.
Note: Web services customers are not able to use form login to resolve this
problem. Users must ensure there is consistency in the code pages between
the client and the server.
Error Message: CWSCJ0314E: Current Java
2 security policy reported a potential violation on server
If
you find errors on your server similar to:
Error Message: CWSCJ0314E: Current Java 2 Security policy reported a potential violation of
Java 2 Security Permission. Please refer to Problem Determination Guide for further information.
{0}Permission/:{1}Code/:{2}{3}Stack Trace/:{4}Code Base Location/:{5}
The Java security manager checkPermission method
has reported a SecurityException exception .
The
reported exception might be critical to the secure system. Turn on security
trace to determine the potential code that might have violated the security
policy. Once the violating code is determined, verify if the attempted operation
is permitted with respect to Java 2 Security, by examining all applicable
Java 2 security policy files and the application code.
A more detailed
report is enabled by either configuring RAS trace into debug mode, or specifying
a Java property.
- Check
the trace enabling section
for instructions on how to configure Reliability Availability Serviceability
(RAS) trace into debug mode, or
- Specify the following property in the Application Servers > server_name >
ProcessDefinition > Java Virtual Machine panel from the administrative
console in the Generic JVM arguments panel:
- Add the java.security.debug run-time flag
- Valid values:
- access
-
Print all debug information including required permission, code, stack,
and code base location.
- stack
-
Print debug information including required permission, code, and stack.
- failure
-
Print debug information including required permission, and code.
For a review of Java security policies, see the Java 2 Security
documentation at http://java.sun.com/j2se/1.3/docs/guide/security/index.html. Tip: If
the application is running with a Java Mail application programming interface
(API), this message might be benign. You can update the installed
Enterprise Application root/META-INF/was.policy file
to grant the following permissions to the application:
- permission java.io.FilePermission "${user.home}${/}.mailcap",
"read";
- permission java.io.FilePermission "${user.home}${/}.mime.types",
"read";
- permission java.io.FilePermission "${java.home}${/}lib${/}mailcap",
"read";
- permission java.io.FilePermission "${java.home}${/}lib${/}mime.types",
"read";
Error message: CWMSG0508E: The JMS Server
security service was unable to authenticate user ID:" error displayed in SystemOut.log
when starting an application server
This error can result
from installing the Java Message Service (JMS) API sample and then enabling
security. You can follow the instructions in the Configure and Run page of
the corresponding JMS sample documentation to configure the sample to work
with WebSphere Application Server security.
You can verify the installation
of the message-driven bean sample by launching the installation program, selecting Custom,
and browsing the components which are already installed in the Select the
features you like to install panel. The JMS sample is shown as Message-Driven
Bean Sample, under Embedded Messaging.
You can also verify this
installation by using the administrative console to open the properties of
the application server that contains the samples. Select MDBSamples and
click uninstall.
Error message: CWSCJ0237E: One or more
vital LTPAServerObject configuration attributes are null or not available after
enabling security and starting the application server
This error
message can result from selecting Lightweight Third Party Authentication (LTPA)
as the authentication mechanism, but not generating the LTPA keys. The LTPA
keys encrypt the LTPA token.
To resolve this problem:
- Click Security > Secure administration, applications and infrastructure>
Authentication > Authentication mechanisms and expiration> LTPA
- Enter a password, which can be anything.
- Enter the same password in Confirm Password.
- Click Apply.
- Click Generate Keys.
- Click Save.
The AccessControlException exception, is reported
in the SystemOut.log
The problem is related to the Java 2 security
feature of WebSphere Application Server, the API-level security framework
that is implemented in WebSphere Application Server. An exception similar
to the following example displays. The error message and number can vary.
CWSRV0020E: [Servlet Error]-[validator]: Failed to load servlet:
java.security.AccessControlException: access denied
(java.io.FilePermission
app_server_root/systemApps/isclite.ear/isclite.war/WEB-INF/validation.xml read)
For an explanation of Java
2 security, how and why to enable or disable it, how it relates to policy
files, and how to edit policy files, see the Java 2 security topic in the information center navigation. The topic explains that Java 2 security is
not only used by this product, but developers can also implement it for their
business applications. Administrators might need to involve developers, if
this exception is created when a client tries to access a resource that is
hosted by WebSphere Application Server.
Possible causes of these errors
include:
- Syntax errors in a policy file.
- Syntax errors in permission specifications in the ra.xml file
that is bundled in a .rar file. This case applies to
resource adapters that support connector access to CICS or other resources.
- An application is missing the specified permission in a policy file, or
in permission specifications in ra.xml file bundled in
a .rar file.
- The class path is not set correctly, preventing the permissions for the resource.xml file
for Service Provider Programming Interface (SPI) from being correctly created.
- A library called by an application, or the application, is missing a doPrivileged
block to support access to a resource.
- Permission is specified in the wrong policy file.
To resolve these problems:
- Check all of the related policy files to verify that the permission shown
in the exception, for example java.io.FilePermission, is specified.
- Look for a related ParserException exception in the SystemOut.log file
which reports the details of the syntax error.
CWSCJ0189E: Caught ParserException while creating template for application policy
profile_root/config/cells/cell_name/nodes/node_name/app.policy
Where:
- cell_name represents the name of your cell.
- profile_name represents the name of your profile.
- node_name represents the name of your node.
The exception is com.ibm.ws.security.util.ParserException: line 18:
expected ';', found 'grant'
- Look for a message similar to: CWSCJ0325W: The permission permission specified
in the policy file is unresolved.
- Check the call stack to determine which method does not have the permission.
Identify the class path of this method. If it is hard to identify the method,
enable the Java2 security Report.
- Configuring
RAS trace by specifying com.ibm.ws.security.core.*=all=enabled,
or specifying a Java property.java.security.debug property.
Valid values for the java.security.debug property are:
- access
-
Print all debug information including: required permission, code, stack,
and code base location.
- stack
-
Print debug information including: required permission, code, and stack.
- failure
-
Print debug information including: required permission and code.
- The report shows:
- Permission
-
The missing permission.
- Code
-
Which method has the problem.
- Stack Trace
-
Where the access violation occurred.
- CodeBaseLocation
-
The detail of each stack frame.
Where:
- app1 represents the name of your application.
- app_server_root represents
the installation root directory for WebSphere Application Server Network Deployment.
- profile_root represents
the location and name of a particular profile in your system.
- profile1 or profile_name represents the name
of your profile.
- server1 or server_namerepresents the name of
your application server.
- If the method is SPI, check the resources.xml file
to ensure that the class path is correct.
- To confirm that all of the policy files are loaded correctly, or what
permission each class path is granted, enable the trace with com.ibm.ws.security.policy.*=all=enabled.
All loaded permissions are listed in the trace.log file.
Search for the app.policy, was.policy and ra.xml files.
To check the permission list for a class path, search for Effective Policy
for classpath.
If there are any syntax errors in the policy file
or the ra.xml file, correct them with the policytool. Avoid editing the policy manually, because
syntax errors can result.
- If a permission is listed as Unresolved, it does not
take effect. Verify that the specified permission name is correct.
- If the class path that is specified in the resource.xml file
is not correct, correct it.
- If a required permission does not exist in either the policy files or
the ra.xml file, examine the application code to see
if you need to add this permission. If so, add it to the proper policy file
or the ra.xml file.
- If the permission is not granted outside of the specific method that is
accessing this resource, modify the code needs to use a doPrivileged block.
- If this permission does exist in a policy file
or a ra.xml file and the permission was loaded correctly,
but the class path still does not have the permission in its list, the location
of the permission might not be correct. Read Java 2 security in the information center navigation carefully to determine
in which policy file or ra.xml file to specify that permission.
Tip: If the application is running with the Java Mail API,
you can update the installed Enterprise Application root/META-INF/was.policy file
to grant the following permissions to the application:
- permission java.io.FilePermission "${user.home}${/}.mailcap",
"read";
- permission java.io.FilePermission "${user.home}${/}.mime.types",
"read";
- permission java.io.FilePermission "${java.home}${/}lib${/}mailcap",
"read";
- permission java.io.FilePermission "${java.home}${/}lib${/}mime.types",
"read";
Error Message: CWSCJ0336E: Authentication
failed for user {0} because of the following exception {1}
This
error message results if the user ID that is indicated is not found in the
Lightweight Directory Access Protocol (LDAP) user registry. To resolve this
problem:
- Verify that your user ID and password are correct.
- Verify that the user ID exists in the registry.
- Verify that the base distinguished name (DN) is correct.
- Verify that the user filter is correct.
- Verify that the bind DN and the password for the bind DN are correct.
If the bind DN and password are not specified, add the missing information
and retry.
- Verify that the host name and LDAP type are correct.
Consult with the administrator of the user registry if the problem persists.
Error Message: SECJ0352E:
Could not get the users matching the pattern {0} because of the following
exception {1}
This authentication failure message displays
when an external user account repository is corrupted or unavailable, and
WebSphere Application Server is unable to authenticate the user name in the
repository. Generally, authentication error messages are followed by additional
information that indicates the nature or root cause of the problem, such as:
Make sure the users matching the pattern exist in the registry. Contact your service representative if the problem persists.
This additional information might not provide a clear user action if the
user account repository is corrupted or the user loses connectivity between
WebSphere Application Server and an external user account repository. The
external user account repository, which is referred to as a repository in
this document, might be a Lightweight Directory Access Protocol (LDAP) product. To
resolve this problem, you might need to re-install the repository and verify
that it installs successfully by testing the connection. CAUTION:Proceed
with the following steps only if you have ensured that all WebSphere Application
Server-related configuration settings are accurate.
Complete the following
steps to resolve the issue:
- Restart both the repository and WebSphere Application Server.
- Test the connection to the repository. If the connection attempt still
fails, it might be necessary to re-install the repository.
- If diagnostics are provided with the repository, run them to avoid having
to re-install the repository. Attention: If the previous steps
do not fix the problem, you might need to re-install the repository. Before
proceeding, generate a complete list of all the configured users and groups;
you will need to re-populate these fields after the re-installation.
- If necessary, re-install the corrupted repository.
- Populate the users and groups from your list into the newly installed
repository.
- Restart both the repository and WebSphere Application server.
- In the administrative console, navigate to Security > Secure administration,
applications, and infrastructure, and select the appropriate user account
repository. For example, select Standalone LDAP registry if you are
using a standalone Lightweight Directory Access Protocol repository.
- Click Test connection to ensure that WebSphere Application Server
can connect to the repository.
Generate keys error when using the Profile
Management tool to create a new profile
When you create a new profile
using either the Profile Management tool or the command-line manageprofiles
utility, an error message displays that indicates either partial success or
failure. The error message, which is located in the install_dir/logs/manageprofiles/profile_name_create.log
file, might point to an error in either the generateKeysforSingleProfile task
or the generateKeysForCellProfile task.
The Profile Creation tool and
the manageprofiles utility invoke several tasks. The generateKeysForSingleProfile
task is invoked when you create a stand-alone application server or a deployment
manager profile. The generateKeysForCellProfile task is invoked when you create
a cell profile. Both of these tasks are the first tasks to invoke the wsadmin
commands. Although the log indicates an error in one of these tasks, the error
might actually result from a wsadmin command failure and not an error in the
security tasks.
To determine the actual cause of the problem, review
the information that is provided in the following log files:
- install_dir/logs/manageprofiles/profile_name_create.log
file indicates the error code of the failure
- install_dir/logs/manageprofiles/profile_name/keyGeneration.log
file
- install_dir/logs/manageprofiles/profile_name/wsadminListener.log
file
Related concepts
Troubleshooting
and support
Related tasks
Troubleshooting security configurations
Related Reference
Access problems after enabling security
Reference topic