Use this information if you are experiencing access problems
after enabling security.
What kind of error are you seeing?
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 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 > Global
security. 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:
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.
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.
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.