What kind of error are you seeing?
For general tips
on diagnosing and resolving security-related problems, see the topic Troubleshooting the security
component.
If you do not
see a problem that resembles yours, or if the information provided does not
solve your problem, see Obtaining help from IBM.
I cannot access all or part of the administrative
console or use the wsadmin tool after enabling security
- If you cannot
access the administrative console, or view and update certain objects, look
in the SystemOut log of
the application server which hosts the administrative console page for a related
error message.
- You might not have authorized your ID for administrative tasks. This
problem is indicated by errors such as:
- [8/2/02 10:36:49:722 CDT] 4365c0d9 RoleBasedAuth A CWSCJ0305A:
Role based authorization check failed for security name MyServer/myUserId,
accessId MyServer/S-1-5-21-882015564-4266526380-2569651501-1005 while invoking
method getProcessType on resource Server and module Server.
- Exception message: "CWWMN0022E: Access denied for the getProcessType
operation on Server MBean"
- When running the command: wsadmin -username j2ee -password j2ee:
CWWAX7246E: Cannot establish "SOAP" connection to host "BIRKT20" because
of an authentication failure. Please ensure that user and password are correct
on the command line or in a properties file.
To grant an ID administrative authority, from the administrative console,
click System Administration > Console Users and validate that the ID
is a member. If it is not, add the ID with at least monitor access privileges,
for read-only access.
- Verify that the enable_trusted_application flag is
set to true. To check the enable_trusted_application flag
value using the administrative console, click Security > Global Security.
Under Additional properties, click Custom properties > EnableTrustedApplications.
I cannot access a Web page after enabling security
When
secured resources are not accessible, probable causes include:
- Authentication errors - WebSphere Application Server security cannot identify
the ID of the person or process. Symptoms of authentication errors include:
On
a Netscape browser:
- Authorization failed. Retry? message displays after an
attempt to log in.
- Accepts any number of attempts to retry login and displays Error
401 message when Cancel is clicked to stop retry.
- A typical browser message displays: Error 401: Basic realm='Default
Realm'.
On an Internet Explorer browser:
- Login prompt displays again after an attempt to log in.
- Allows three attempts to retry login.
- Displays Error 401 message after three unsuccessful retries.
- Authorization errors - The security function has identified the requesting
person or process as not authorized to access the secured resource. Symptoms
of authorization errors include:
- Netscape browser: "Error 403: AuthorizationFailed" message is displayed.
- Internet Explorer:
- "You are not authorized to view this page" message is displayed.
- "HTTP 403 Forbidden" error is also displayed.
- SSL errors - WebSphere Application Server security uses Secure Socket
Layer (SSL) technology internally to secure and encrypt its own communication,
and incorrect configuration of the internal SSL settings can cause problems.
Also you might have enabled SSL encryption for your own Web application or
enterprise bean client traffic which, if configured incorrectly, can cause
problems regardless of whether WebSphere Application Server security is enabled.
- SSL related problems are often indicated by error messages which contain
a statement such as: ERROR: Could not get the initial context or unable
to look up the starting context.Exiting. followed by javax.net.ssl.SSLHandshakeException
The client cannot access an enterprise bean
after enabling security
If client access to an enterprise bean fails
after security is enabled:
If
org.omg.CORBA.NO_PERMISSION exceptions
occur when programmatically logging on to access a secured enterprise bean,
an authentication exception has occurred on the server. Typically the CORBA
exception is triggered by an underlying
com.ibm.WebSphereSecurity.AuthenticationFailedException.
To determine the actual cause of the authentication exception, examine the
full trace stack:
- Begin by viewing the text following WSSecurityContext.acceptSecContext(),
reason: in the exception. Typically, this text describes the failure
without further analysis.
- If this action
does not describe the problem, look up the CORBA minor code. The codes are
listed in the article titled Troubleshooting
the security components reference.
For example, the following exception
indicates a CORBA minor code of 49424300. The explanation of this error in
the CORBA minor code table reads:
authentication failed error.
In this case the user ID or password supplied by the client program
is probably invalid:
org.omg.CORBA.NO_PERMISSION: Caught WSSecurityContextException in WSSecurityContext.acceptSecContext(), reason: Major Code[0] Minor Code[0] Message[ Exception caught invoking authenticateBasicAuthData from SecurityServer for user jdoe. Reason: com.ibm.WebSphereSecurity.AuthenticationFailedException] minor code: 49424300 completed: No at com.ibm.ISecurityLocalObjectBaseL13Impl. PrincipalAuthFailReason.map_auth_fail_to_minor_code (PrincipalAuthFailReason.java:83)
A CORBA
INITIALIZE exception with CWWSA1477W: SECURITY CLIENT/SERVER
CONFIGURATION MISMATCH error embedded, is received by client program
from the server.
This
error indicates that the security configuration for the server differs from
the client in some fundamental way. The full exception message lists the
specific mismatches. For example, the following exception lists three errors:
Exception received: org.omg.CORBA.INITIALIZE:
CWWSA1477W: SECURITY CLIENT/SERVER CONFIG MISMATCH:
The client security configuration (sas.client.props or outbound settings in administrative
console) does not support the server security configuration for the following reasons:
ERROR 1: CWWSA0607E: The client requires SSL Confidentiality but the server does not support it.
ERROR 2: CWWSA0610E: The server requires SSL Integrity but the client does not support it.
ERROR 3: CWWSA0612E: The client requires client (e.g., userid/password or token), but the server does
not support it.
minor code: 0
completed: No
at com.ibm.ISecurityLocalObjectBaseL13Impl.SecurityConnectionInterceptor.getConnectionKey(SecurityConnectionInterceptor.java:1770)
In
general, resolving the problem requires a change to the security configuration
of either the client or the server. To determine which configuration setting
is involved, look at the text following the CWWSA error message.
For more detailed explanations and instructions, look in the message reference,
by selecting the Reference view of the information center navigation
and expanding Messages in the navigation tree.
In these particular cases:
- In ERROR 1, the client is requiring SSL confidentiality but the server
does not support SSL confidentiality. Resolve this mismatch in one of two
ways. Either update the server to support SSL confidentiality or update the
client so that it no longer requires it.
- In ERROR 2, the server requires SSL integrity but the client does not
support SSL integrity. Resolve this mismatch in one of two ways. Either update
the server to support SSL integrity or update the client so that it no longer
requires it.
- In ERROR 3, the client requires client authentication through a user id
and password, but the server does not support this type of client authentication.
Either the client or the server needs to change the configuration. To change
the client configuration, modify the SAS.CLIENT.PROPS file for a
pure client or change the outbound configuration for the server in the Security
GUI. To change the configuration for the target server, modify the inbound
configuration in the Security GUI.
Similarly,
an exception like org.omg.CORBA.INITIALIZE: JSAS0477W: SECURITY CLIENT/SERVER
CONFIG MISMATCH: appearing on the server trying to service a client request
indicates a security configuration mismatch between client and server. The
steps for resolving the problem are the same as for the JSAS1477W exceptions
previously described.
Client program never gets prompted when accessing
secured enterprise bean
Even though it appears security is enabled
and an enterprise bean is secured, it can happen that the client executes
the remote method without prompting. If the remote method is protected, an
authorization failure results. Otherwise, execute the method as an unauthenticated
user.
Possible reasons for this problem include:
- The server with which you are communicating might not have security enabled.
Check with the WebSphere Application Server administrator to ensure that the
server security is enabled. Access the global security settings from within
the Security section of the administrative console.
- The client does not have security enabled in the sas.client.props file.
Edit the sas.client.props file to ensure the property com.ibm.CORBA.securityEnabled is
set to true.
- The client does not have a ConfigURL specified. Verify that the property com.ibm.CORBA.ConfigURL is
specified on the command line of the Java client, using the -D parameter.
- The specified ConfigURL has an invalid URL syntax, or the sas.client.props that
is pointed to cannot be found. Verify that the com.ibm.CORBA.ConfigURL property
is valid, for example, similar to the C:/WebSphere/AppServer/properties/sas.client.props file
on Windows systems. Check the Java documentation for a description of URL
formatting rules. Also, validate that the file exists at the specified path.
- The client configuration
does not support message layer client authentication (user ID and password).
Verify that the sas.client.props file has one
of the following properties set to true:
- com.ibm.CSI.performClientAuthenticationSupported=true
- com.ibm.CSI.performClientAuthenticationRequired=true
- The server configuration
does not support message layer client authentication (user ID and password).
Check with the WebSphere Application Server administrator to verify that user
ID and password authentication is specified for the inbound configuration
of the server within the System Administration section of the administrative
console administration tool.
Cannot stop an application server, node manager,
or node after enabling security
If you use command line utilities
to stop WebSphere Application Server processes, apply additional parameters
after enabling security to provide authentication and authorization information.
Use the ./stopServer.sh
-help command to display the parameters to use.
Use the following command options after enabling
security:
- ./stopServer.sh hostname -username name -password password
- ./stopNode.sh -username name -password password
- ./stopManager.sh -username name -password password
If you use the
Windows service panel or the net stop command to stop the WebSphere Application
Server processes, update the existing Application Server service using an
additional stop argument. Use the -stopArgs and the-encodeParams parameters
to update the service as described in the "Updating an existing Application
Server service" example in the WASService
command article.
After enabling single signon, I cannot log on
to the administrative console
This problem occurs when single signon
(SSO) is enabled, and you attempt to access the administrative console using
the short name of the server, for example http://myserver:9060/ibm/console.
The server accepts your user ID and password, but returns you to the log on
page instead of the administrative console.
To correct this problem,
use the fully qualified host name of the server, for example http://myserver.mynetwork.mycompany.com:9060/ibm/console.