Troubleshoot portal access

 

+
Search Tips   |   Advanced Search

 

  1. Portal URL does not open
  2. Unable to connect to portal
  3. Login attempt is unsuccessful, but no error message is displayed
  4. Exception javax.servlet unavailable when starting WebSphere Portal
  5. Application Error message displays when accessing the portal
  6. Unable to log in as the portal administrator
  7. Redirected back to login screen
  8. Cannot log in to WebSphere Portal environment with Active Directory as LDAP
  9. Login fails with a user ID that contains special characters
  10. Accessing portlets prior to authentication
  11. Unable to log into the portal immediately after logging out
  12. User is logged out of the portal
  13. Portal does not render, HTML markup is not supported
  14. Browser returns an invalid syntax error
  15. Browser does not finish loading page
  16. Error 503 when accessing the portal on AIX
  17. Exception message displays when attempting to log in to the portal
  18. Portal Log in link is missing
  19. During portal migration, XmlAccess reports an AuthorizationModelException with error code EJPSB0125E
  20. Receive 404 accessing /myportal after enabling Trust Association

 

Portal URL does not open

If you try to open the portal URL, but the browser returns a 404 message (file not found), check the base URI and default home page.

Solution: The portal does not work unless a base URI is configured. The default base URI is /wps. For example, if the default base URI and the default home page were configured for the portal, you would open the URL...

http://hostname.example.com:port/wps/portal

...where hostname is the host.name for the Web server that the portal uses and port is the transport port created by IBM WAS.

 

Unable to connect to portal

IBM WebSphere Portal is an application server that is running on WAS. If you are having trouble launching WebSphere Portal you might want to verify that the application server was successfully installed.

Solution: Verify that the application server is installed by starting the WAS Administrative Console and look for settings that are specific to WebSphere Portal. For example, WebSphere Portal installs the following entries in the left panel of the Administrative Console:

 

Login attempt is unsuccessful, but no error message is displayed

If the login to the portal is unsuccessful, typically, the error is the result of incorrectly entering a valid user ID and password, or, depending on the WebSphere Portal version and Fix Pack level, an error screen requesting that the user explicitly log out of portal at the end of a session.

Solution: In the case where login is not successful but no obvious error message is displayed, there are several possibilities.

If an authentication front end, such as TAM is deployed and a corresponding TAI is configured for WAS, there might be an error in the configuration of the authentication front-end component.

If the authentication proxy and TAI are working correctly, there might be a problem in the JAAS login processing. Activate the PortalCoreTraceLogger to generate trace output.

The PDLoginModule, if present, can be traced by adding debug=true as a parameter to the loginmodule in portallogin.config.

If no authentication proxy or TAI are configured, and the symptom seen is that the user is immediately placed back at the login form after submitting the filled-in login form, a likely cause is that WAS single signon and the associated necessary cookie enablement is not correctly configured.

Verify the Web browser is enabled for cookies. A cookie with a valid LTPA token is needed to access URLs that are secured by WAS.

A good test is to activate cookie prompting in the browser. In Internet Explorer 7...

  1. Start Internet Explorer.
  2. From the toolbar select Tools.
  3. Select Internet Options.
  4. Select the Privacy tab.
  5. Click the Advanced button.
  6. Place a check in the Override Automatic Cookie Handling check box.
  7. Under First Party Cookies, select the Accept option.
  8. Under Third Party Cookies, select the Accept option.
    Note: If you do not wish to automatically accept cookies, select the Prompt option instead. You will then be prompted every time a Web site tries to send you a cookie.
  9. Click OK.
  10. In the Internet Options window, click OK.

An LtpaToken cookie should be seen after the login form is submitted, and the DNS domain associated with that cookie must be correctly set to enable it to be sent back to WebSphere Portal on subsequent requests.

If the DNS domain of the cookie is not correct, go to the WAS Administrative Console Security Center, and on the Authentication Tab, make the necessary corrections.

Note that the single signon cookie domain must consist of at least two names separated by a period. For example, setgetweb.com is acceptable, but setgetweb is not.

 

Exception javax.servlet unavailable when starting WebSphere Portal

If you receive an exception that the javax.servlet is unavailable when starting WebSphere Portal, you might have used the DB2 server name instead of the WebSphere Portal DB2 user ID as the profile owner.

Solution: Verify that the DbUser property points to the correct profile owner's user ID for theWebSphere Portal database to which you are transferring a component. Save the correct value and then re-transfer.

 

Application Error message displays when accessing the portal

Solution: Verify that the WAS is installed correctly.

 

Unable to log in as the portal administrator

If the following message is displayed, the administration portlets could not be deployed during the WebSphere Portal installation: 

 Our portal does not have any pages.

Solution:

If WebSphere Portal is running and the portlets didn't deploy, rerun the action-deploy-portlets configuration task to redeploy.

 

Redirected back to login screen

This problem occurs when, after submitting a user name and password in response to the login screen, you are immediately redirected back to the login screen again.

Solution: Usually, this is a result of a configuration problem with the security support of WAS. An easy way to diagnose this problem is to activate cookie prompting. To resolve this problem, perform the following steps:

  1. In Internet Explorer, select...

    Tools | Internet Options | Security tab | Internet zone | Custom Level

  2. Scroll down until you see Cookies.

  3. Select Prompt for both stored and per-session cookies.

  4. Save and exit.

Internet Explorer should then prompt you whenever a server attempts to set a cookie on the browser. The prompt will say Security Alert and will ask if you will allow the Web site to place a cookie on the computer. Select the More Info button on the prompt to display the cookie name and other information.

When you attempt to log in to WebSphere Portal, we should see the following two cookies being set on the browser:

You might also see a third cookie, WasReqURL, if you access /wps/myportal directly and were redirected by WAS to the WebSphere Portal login screen.

If you don't see the LtpaToken cookie, then you will not be able to successfully log in to WAS and WebSphere Portal.

If this is the case, it is possible that the problem is that the domain of the LtpaToken cookie is not configured correctly in WAS. To correct this, perform the following steps:

  1. In the WAS Administrative Console, select...

    Security | Authentication Mechanisms | LTPA

  2. Select Single Signon in Additional Properties.

  3. Verify that Single Signon is enabled by checking the box.

    Note that when using WebSEAL as an authentication proxy, this might not be required.

  4. The Domain must be set such that a cookie marked with that domain will be sent to the browser and then returned on subsequent requests from the browser to WAS.

 

Cannot log in to WebSphere Portal environment with Active Directory as LDAP

When trying to log in to WebSphere Portal environment with Active Directory as LDAP over SSL, you might receive the following error:

The system could not log into the account.
Reason: The system could not retrieve the user account information data store.
Please try again later.

Solution: Cycle WebSphere Portal

 

Login fails with a user ID that contains special characters

Solution: Verify the user ID contains valid characters...

  • a-z
  • AZ
  • period (.)
  • underscore (_)

Diacritics, such as the umlaut, are not allowed.

Users can specify other characters in the First Name and Last Name fields.

If the user IDs of the portal users contain special characters, for example, double-byte characters, verify the property...

com.ibm.CORBA.ORBCharEncoding=UTF8

...has been set on the administrative server and all application servers.

 

Accessing portlets prior to authentication

By default, portlets placed on a page that does not require authentication do not have access to a portlet session (PortletSession object). This can cause problems when the portlet attempts to access the session without first checking to verify the session is available. Or, the portlet might write an error message to the portlet log or the user interface if the session is not available.

Solution:

There are two possible solutions:

 

Unable to log into the portal immediately after logging out

If the Authorization failed error occurs when you try to log in to the portal immediately after logging out, the portal system time is ahead of the client system time.

Solution: Set the correct time on the client system clock.

 

User is logged out of the portal

There are two reasons why a user can be logged out by the portal:

  • The portal browser window is inactive for a time period that exceeds the timeout.
  • The user's LTPA token expires.

The following sections provide solutions for both problems.

Solution: Timeout by inactivity in the portal browser window

If a user opens a portlet in a secondary browser window, interactions with that portlet are not sent to the portal. As a result, users could exhaust their portal session in the secondary window and be logged out of the portal, even if the portal window is still open.

We can configure session management at the Web container level. This includes configuring the duration of portal sessions. When you configure session management at the Web container level, all applications and the respective Web modules in the Web container normally inherit that configuration, setting up a basic default configuration for all applications and Web modules below it.

However, we can set up different configurations individually for specific applications and Web modules that vary from the Web container default. These different configurations override the default for these applications and Web modules only.

When you overwrite the default session management settings on the application level, all the Web modules below that application inherit this new setting unless they too are set to overwrite these settings.

To change the duration of portal sessions by level, perform the following steps:

  1. Open the Administrative Console for WAS.

  2. Select the level that this configuration applies to:

    • For the Web container level:

      Servers | Application Servers | application_server | Web Container

    • For the enterprise application level:

      Applications | Applications | application

    • For the Web module level:

      Applications | Enterprise Applications | application | Related Items | Web Modules | Web_module

  3. Under Additional Properties, click Session Management

  4. Make whatever changes we need to manage sessions

  5. If you are working on the Web module or application level and want these settings to override the inherited Session Management settings, under General Properties, select Overwrite.

  6. Click Apply and Save.

Solution: Expiration of the user's LTPA token

During the portal installation, the LTPA token expiration is set to 120 minutes. Users who are in session with the portal for more than two hours are logged out and will have to re-authenticate to continue using the portal. To change this setting, perform these steps:

  1. Open the Administrative Console for WAS.

  2. On the menu bar, click...

    Security | Global security | Authentication | Authentication mechanisms | LTPA

  3. Modify the timeout value as required.

  4. Click...

    Apply | Save link | Save button

  5. Close the Administrative Console.

  6. Restart the Administrative Server for WAS for the changes to take effect.

 

Portal does not render, HTML markup is not supported

The Supported Markups portlet in Administration is used to add, remove, and edit markup languages supported by the portal. It is possible that an administrator could remove or change HTML as a supported markup. If this happens, the portal user interface will no longer render in any of the supported Web browsers.

Solution:

Follow these steps to recover from this error.

  1. Make sure the portal is started.

  2. Create an XML file in the portal server config directory. For example, create recoverHTML.xml in the following WebSphere Portal installation directory:

  3. Insert the following XML markup for the file content and save the file. 

     
<request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:noNamespaceSchemaLocation="PortalConfig_1.2.xsd"
         type="update" 
         create-oids="true">

    <portal action="locate">

        <markup action="update" 
                active="true" 
                default-charset="UTF-8" 
                objectid="html"
                mimetype="text.html" name="html">

        <localedata charset="UTF-8" 
                    locale="en" 
                    prefix="markup.html">

        <url>file:///$server_root$/config/work/SetupPortal_en.properties</url>

        </localedata>

        </markup>
    </portal>

    <status element="all" result="ok"/>

 </request>

  4. From a command prompt, change to the WebSphere Portal installation directory:

  5. Run the XMLAccess command against the XML file that you created. On a Windows system, for example: 

     xmlaccess -in C:\WebSphere\PortalServer\config\work\recoverHTML.xml 
 -user adminID -pwd adminPassword

  6. HTML is supported by the portal once the command has completed successfully. Log back into the portal and reopen the Supported Markups portlet to view the changes.

 

Browser returns an invalid syntax error

Some browsers might return a page not found - invalid syntax error when attempting to access WebSphere Portal.

Solution: Certain browsers require that you include the URL type, such as http://, before entering URLs with non-standard ports. Always include the URL type when entering the portal URL to prevent this error.

 

Browser does not finish loading page

When using Internet Explorer to access WebSphere Portal, the browser appears to finish loading the page (the icon stops spinning.) before the page actually is finished.

Solution: This is a known issue with the Internet Explorer browser. For details see http://support.microsoft.com/kb/183110.

 

Error 503 when accessing the portal on AIX

On AIX, accessing the portal might return a 503 error.

Solution: To prevent this, be sure that the root user has db2profile in the.profile file using the following steps:

  1. In our.bashrc,.dshrc, or.profile file, add if [ -f /home/db2inst1/sqllib/db2profile ]; then. /home/db2inst1/sqllib/db2profile; fi

    ...where db2inst1 represents our database installation.

  2. Reopen all the shells.

  3. Validate that the environment has set the DB2 profile environment variables, such as DB2INSTANCE=db2inst1 where db2inst1 represents our database installation by running the env command.

  4. Execute the.profile to verify root can connect to DB2.

  5. Restart the server1 and WebSphere_Portal application servers.

 

Exception message displays when attempting to log in to the portal

The following exception occurs when a user attempts to log in to the portal: 

 2005.01.28 06:30:14.984 E com.ibm.wps.datastore.impl.DataStoreContext handleException 
 EJPDB0031E: Object was not found in database

Solution: This exception occurs when a user is simultaneously logged into the portal multiple times. The user must be properly logged out before the login attempt will be successful.

 

Portal Log in link is missing

The Log in link could be missing because the page that contains the Login portlet is inactive. Pages are made inactive whenever they are being edited in Edit Layout.

Solution: Click Done in Edit Layout.

If we cannot complete the Edit Layout process for some reason, such as a session timeout, we can reactivate the login page using xmlaccess. The following example would be appropriate for a default Portal installation: 

 <content-node action="update" active="true" uniquename="wps.Login" />

 

During portal migration, XmlAccess reports an AuthorizationModelException with error code EJPSB0125E

This exception indicates that the previous version contains invalid role assignments that cannot be created within the current version. The following role assignments for the Anonymous Portal User are considered invalid in the current version:

  • Privilieged User@somepage

  • Editor@somepage

  • Manager@somepage

  • Administrator@somepage

All those role assignments would allow the anonymous user to modify existing portal content which is not supported by the portal runtime.

Solution: In the previous version, change all of the above role assignments into User roles; see Roles for information.

 

Receive 404 accessing /myportal after enabling Trust Association

After enabling Trust Association in WebSphere Application Server manually or by using a WebSphere Portal configuration task, you receive a 404 error when attempting to access a protected portal resource under the URI /myportal. You expect to see the login page. The 404 error is displayed if you trace the HTTP headers and/or use Mozilla Firefox®. If using Microsoft® Internet Explorer®, you may see the message "Page cannot be displayed".

Solution: Install APAR PK34390