Use this information if you are experiencing access problems
after enabling security.
Note: This topic references one or more of the application
server log files. As a recommended alternative, you can configure
the server to use the High Performance Extensible Logging (HPEL) log
and trace infrastructure instead of using SystemOut.log , SystemErr.log, trace.log, and activity.log files on distributed and IBM® i systems. You can also use
HPEL in conjunction with your native z/OS® logging facilities. If you are using HPEL, you can access
all of your log and trace information using the LogViewer command-line
tool from your server profile bin directory. See the information
about using HPEL to troubleshoot applications for more information
on using HPEL.
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.
- 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 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 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
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:
![[IBM i]](../images/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.
![[IBM i]](../images/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.
![[IBM i]](../images/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:
- 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.
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.
![[IBM i]](../images/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
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.
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:
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.
Supported configurations: 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:
- For an application or module that uses a Java EE version prior to version 5, the file
extension must be .xmi.
- For an application or module that uses Java EE 5 or later, the file extension must
be .xml. If .xmi files are included with the application or module,
the product ignores the .xmi files.
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