Access problems after enabling security
Use this information if you are experiencing access problems after enabling security.
- I cannot access all or part of the administrative console or use the wsadmin tool after enabling security
- Cannot access a web page after enabling security
- Authentication error accessing a Web page
- Authorization error accessing a Web page
- The client cannot access an enterprise bean after enabling security
- Client program never gets prompted when accessing secured enterprise bean
- Cannot stop an application server, node manager, or node after enabling security
- The AccessControlException exception, is reported in the SystemOut.log
- After enabling single sign-on, cannot logon to the administrative console
- SECJ0306E: No received or invocation credential exists on the thread.
- Name NotFoundException error occurs when initially connecting to the federated repositories
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:
When the system command prompt displays again, enter:wsadmin.sh -conntype NONE
Restart the deployment manager after you turn off security.securityoff
- 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.
- Verify that the trusted application functionality is enabled. The trusted application functionality is enabled if WebSphere Application Server has SAF access of READ to the RACF class of FACILITY, and profile of BBO.TRUSTEDAPPS.<cell short name>.<cluster short name>.
Cannot access a web page after enabling security
- Authentication errors - WebSphere Application Server security cannot
identify the ID of the person or process. Symptoms of authentication errors include:
- 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'.
- Login prompt displays again after an attempt to log in.
- 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:
Error 403: AuthorizationFailed
message is displayed.You are not authorized to view this page message
is displayed.HTTP 403 Forbidden
error is 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
- 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 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.
- 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.
- 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.
- 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:
In this case the user ID or password supplied by the client program is probably not valid:authentication failed error
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.
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 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.
- 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 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 does not have a valid URL syntax, or the sas.client.props that
is pointed to cannot be found. Verify that the com.ibm.CORBA.ConfigURL
property is valid. Check the Java documentation
for a description of URL formatting rules. Also, validate that the
file exists at the specified path.
An example of a valid property is C:/WebSphere/AppServer/properties/sas.client.props.
- 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, which consists of a 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 -help command to display the parameters to use.
- ./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, 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.
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.
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
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.
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.