WAS v8.5 > Reference > Troubleshooting tips

Access problems after enabling security

Use this information if you are experiencing access problems after enabling security.

IBM recommends using the HPEL log and trace infrastructure. With HPEL, one views logs using the LogViewer command-line tool in PROFILE/bin.

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 we 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 dmgr console or use wsadmin after enabling security


Cannot access a web page after enabling security

When secured resources are not accessible, probable causes include:


The client cannot access an enterprise bean after enabling security

If the 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:

  1. Begin by viewing the text following WSSecurityContext.acceptSecContext(), reason: in the exception.

    Typically, this text describes the failure without further analysis.

  2. 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 articletitled 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.

This error indicates 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 
dmgr 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:

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 we use command-line utilities to stop WAS processes, apply additional parameters after enabling security to provide authentication and authorization information.

Use the ./stopServer -help command to display the parameters to use.

Use the following command options after enabling security:

If we use the Windows service panel or the net stop command to stop the WAS 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, cannot logon to the dmgr console

This problem occurs when SSO is enabled, and you attempt to access the dmgr console using the short name of the server, for example http://myserver:port_number/ibm/console. The server accepts the user ID and password, but returns you to the logon page instead of the dmgr console.

To correct this problem, use the fully qualified host name of the server, for example http://myserver.mynetwork.mycompany.com:9060/ibm/console.


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:

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. We can ignore this warning message. The message does not display when the wimDS database repository is configured.

For IBM extension and binding files, the .xmi or .xml file name extension is different depending on whether you are using a pre-Java EE 5 application or module or a Java EE 5 or later application or module. An IBM extension or binding file is named ibm-*-ext.xmi or ibm-*-bnd.xmi where * is the type of extension or binding file such as app, application, ejb-jar, or web. The following conditions apply:

However, a Java EE 5 or later module can exist within an application that includes pre-Java EE 5 files and uses the .xmi file name extension.

The ibm-webservices-ext.xmi, ibm-webservices-bnd.xmi, ibm-webservicesclient-bnd.xmi, ibm-webservicesclient-ext.xmi, and ibm-portlet-ext.xmi files continue to use the .xmi file extensions. sptcfg


Related concepts:

Troubleshoot
Troubleshooting help from IBM


Reference:

Security enablement followed by errors
WASService command


+

Search Tips   |   Advanced Search