Use this information if you are experiencing access problems after
enabling security.
What kind of error are you seeing?
For
general tips on diagnosing and resolving security-related problems, see the
topic Security components troubleshooting tips.
If
you do not see a problem that resembles yours, or if the information provided
does not solve your problem, see Troubleshooting 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.
If you cannot
access the administrative console, or view and update certain objects, look
in the logs of the application server which hosts the administrative console
page for a related error message. Note: You will need to use the administrative
console to complete the next two items. If you are having a problem accessing
the administrative console, you will have to turn off security and restart
the administrative console. To turn off security, enter the following command
at the system command prompt:
wsadmin.sh -conntype NONE
When the system command prompt displays again, enter:
securityoff
Restart
the deployment manager after you turn off security.
- 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. 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 the ID is not a member, 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 > Secure administration, applications
and infrastructure. Under Additional properties, click Custom properties
> EnableTrustedApplications.
Remember: You
could encounter synchronization problems if you are in a Network Deployment
environment and save your security settings and the node agent was down.
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 is displayed 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 Sockets
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 that 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 the client access to an enterprise bean
fails after security is enabled:
- Review the steps for securing and granting access to resources.
Browse
the server JVM logs for
errors relating to enterprise bean access and security. Look up any errors
in the message table.
Browse
the server logs for errors that relate to enterprise bean access and security.
Look up any errors in the message table.
Errors similar to
Authorization
failed for /UNAUTHENTICATED while invoking resource securityName:/UNAUTHENTICATED;accessId:UNAUTHENTICATED
not granted any of the required roles roles indicate
that:
- An unprotected servlet or JavaServer Pages (JSP) file accessed a protected
enterprise bean. When an unprotected servlet is accessed, the user is not
prompted to log in and the servlet runs as UNAUTHENTICATED. When the servlet
makes a call to an enterprise bean that is protected, the servlet fails.
To
resolve this problem, secure the servlet that is accessing the protected enterprise
bean. Make sure that the runAs property for the servlet is set to an ID that
can access the enterprise bean.
- An unauthenticated Java client program is accessing an enterprise bean
resource that is protected. This situation can happen if the file that is
read by the sas.client.props properties file that is used by the
client program does not have the securityEnabled flag set to true.
To
resolve this problem, make sure that the sas.client.props file on
the client side has its securityEnabled flag set to true.
Errors similar to Authorization failed for
valid_user while
invoking resource securityName:/username;accessId:xxxxxx not granted
any of the required roles roles indicate that a client attempted
to access a secured enterprise bean resource, and the supplied user ID is
not assigned the required roles for that enterprise bean.
- Check that the required roles for the enterprise bean resource are accessed.
View the required roles for the enterprise bean resource in the deployment
descriptor of the Web resource.
- Check the authorization table and make sure that the user or the group
that the user belongs to is assigned one of the required roles. You can view
the authorization table for the application that contains the enterprise bean
resource using the administrative console.
If you are using
Local OS and System Authorization Facility (SAF) Authorization, check the
SAF EJBROLEs setup. Specifically, verify that
- the EJBROLE class is activated.
- The role is defined to SAF.
- The userid is permitted to the role.
- The class is refreshed after the permit operation.
![[i5/OS]](../../iseries.gif)
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 Common Object Request Broker Architecture
(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
not valid:
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.
![[i5/OS]](../../iseries.gif)
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.
![[i5/OS]](../../iseries.gif)
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
administrative console. To change the configuration for the target server,
modify the inbound configuration in the Security administrative console.
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 seems that security is enabled
and an enterprise bean is secured, occasions can occur when the client runs
the remote method without prompting. If the remote method is protected, an
authorization failure results. Otherwise, run the method as an unauthenticated
user.
Possible reasons for this problem include:
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 -help command to display the parameters to use.
![[i5/OS]](../../iseries.gif)
Use
the following command options after enabling security:
- ./stopServer serverName -username name -password password
- ./stopNode -username name -password password
- ./stopManager -username name -password password
If
you use the Windows service panel or the net stop command to stop the WebSphere
Application Server processes and the service could not be stopped, update
the existing Application Server service using additional stop arguments. You
might need to end the server process from the Task Manager before updating
the service. 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 sign-on, I cannot logon
to the administrative console
This problem occurs when single sign-on
(SSO) is enabled, and you attempt to access the administrative console using
the short name of the server, for example http://myserver:port_number/ibm/console.
The server accepts your user ID and password, but returns you to the logon
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.
The
following exception displays in the SystemOut.log file after I start the server
and enable security: "SECJ0306E: No received or invocation credential exists
on the thread."
The following message displays when one or more nodes
within the cell was not synchronized during configuration:
SECJ0306E: No received or invocation credential exists on the thread. The Role based
authorization check will not have an accessId of the caller to check. The parameters
are: access check method getServerConfig on resource FileTransferServer and module
FileTransferServer. The stack trace is java.lang.Exception: Invocation and received
credentials are both null.
Make
sure that each of the nodes are synchronized and then restart the deployment
manager.
A Name
NotFoundException error occurs when initially connecting to the federated
repositories.
When the server attempts an
indirect lookup on the java:comp/env/ds/wimDS name and makes its initial EJB
connection to the federated repositories, the following error message displays
in the SystemOut.log file:
When the server attempts an
indirect lookup on the java:comp/env/ds/wimDS name and makes its initial EJB
connection to the federated repositories, the following error message displays
in the output of the appropriate job log:
NMSV0612W: A NameNotFound Exception
Note: Because the SystemOut.log file does not exist on the z/OS operating
system, check the output of the appropriate job log on the z/OS operating
system.
The NameNotFoundException error is caused by the reference
binding definition for the jdbc/wimDS Java Naming and Directory interface
(JNDI) name in the ibm-ejb-jar-bnd.xmi file. You can ignore this warning message.
The message does not display when the wimDS database repository is configured.