Troubleshoot LDAP and security

 

+
Search Tips   |   Advanced Search

 

Content

  1. Warning when running configuration tasks to enable security
  2. Unable to deploy portlets after configuring LDAP
  3. Create users when specifying a preferred language in Windows Active Directory fails
  4. The "<" and ">" characters display incorrectly
  5. Pipe character used with the Credential Vault
  6. The validate-ldap task fails when configuring Active Directory over SSL
  7. Unable to use some functions using IBM Tivoli Directory Server Web Administration (Solaris only)
  8. Special characters limitation in Member Distinguished Name
  9. Syntax error on Sun ONE LDAP when importing PortalUsers.ldif
  10. Unable to see pages in Pixo browser
  11. Problem: Browser back button can show secured page after logout
  12. Failed Stop Operation
  13. Debugging the Tivoli Access Manager Login Module
  14. Problem with single sign-on
  15. Cannot use the XML configuration interface if it is externalized in security
  16. When using Domino, cannot create users and groups

 

Problem: Warning when running configuration tasks to enable security

You might receive a warning message stating that it is not possible to modify credential-segment resources when running either of the following configuration tasks:

Solution: Ignore the warning message.

This can happen if you perform these steps:

  1. Install WebSphere Portal and WebSphere Application Server.

  2. Enable security, for example, by running the enable-security-wmmur-db configuration task.

  3. Uninstall WebSphere Portal and do not uninstall WebSphere Application Server.

  4. Install WebSphere Portal again.

  5. Enable security again, by running the enable-security-wmmur-db configuration task.

    After running this task you might see a message stating that it is not possible to modify credential-segment resources.

 

Problem: Unable to deploy portlets after configuring LDAP

During the enable-security-ldap configuration task, one of the final actions to be run is action-create-deployment-credentials. if this last action fails, it leaves the portal in a state in which you are able to authenticate successfully against the LDAP that you configured but the administrative user is unable to deploy portlets because the three deployment credential vault slots have not been created.

Cause: The failure of the action-create-deployment-credentials task is usually due to incorrect settings in the wpconfig.properties file, especially in the Advanced LDAP settings.

Solution: There are two ways to resolve this problem.

A. If you are able to recognize the incorrect setting in wpconfig.properties you can make a change to the file and rerun the enable-security-ldap task. If the task completes successfully, you have solved the problem. If it is not successful, go to step B .

B. Create the vault slots manually through the credential vault slot portlet in the portal administrative user interface. Follow these directions:

  1. Log in to WebSphere Portal as the administrative user and navigate to...

    Portal Administration | Access | Credential Vault portlet

  2. Select Add a vault slot.

  3. Edit...

    wp_root/config/work/createDeploymentCredentials.xml

  4. Create a shared vault slot in the Default vault. In the name field refer to the xml file name parameter (i.e. deployment.user). Under Vault resource associated with vault slot: select new: and enter the name there as well.

  5. In the Shared userid: field, enter the value of the external-id parameter in the xml file and in the Shared password: field, enter the password that is set for the password-secret tag in the xml file.

  6. Press the OK button to create the vault slot.

  7. Repeat steps 2 through 6 two more times to create a vault slot for deployment.keystore and deployment.truststore using the same parameters in the xml file for the same fields in the portlet.

 

Problem: Creating users when specifying a preferred language in Windows Active Directory fails

If Windows Active Directory is the LDAP server for your portal and specify a preferred language when you create users, perform the workaround before you create any users. Otherwise, the attempt to create the users will fail and the following message will be displayed: 

Backend storage system failed. Please try again later.

Solution:

  1. Add preferredLanguage to the Windows Active Directory user schema. Refer to the Windows Active Directory documentation for specific instructions.

  2. Add or uncomment the following mapping to the wmmLDAPServerAttributes.xml file on the WebSphere Portal machine: 
    <attributeMap  wmmAttributeName="preferredLanguage"
               pluginAttributeName="preferredLanguage"
               applicableMemberTypes="Person"
               dataType="String"
               valueLength="256"
               multiValued="false"
               readOnly="false"/>

 

Problem: The "<" and ">" characters display incorrectly

In the...

was_root/lib/app/config/services/ConfigService.properties

...file, there is a flag to enable or disable the Cross Site Scripting (CSS) security protection.

Solution: It might be desirable to disable CSS if you use form input fields containing "less than" and "greater than" signs. During the POST of a form containing such characters to a portlet, the output of the "<" will be seen as "&lt;" and ">" as "&gt;." Other non-alphabetical characters like "&", single quotes, and double quotes appear as intended. Disabling CSS allows the "<" and ">" characters to appear as intended. Characters such as "<" and ">" will be encoded to minimize the security risk of typing markup in a field that could disrupt portal content.

Disabling CSS is done at the portal level and not just the portlet level. While it might be convenient to disable the CSS protection in some circumstances, it exposes a potential vulnerability when passing form input into a Web application. Some secure programs could unwittingly accept data from an untrusted user (the attacker) and pass that data on to a different user's application (the victim). If the secure program does not protect the victim, the victim's application (in this case, his or her Web browser) can then process that data in a way harmful to the victim.

This is a particularly common problem for web applications using HTML or XML, where the problem is known by several names including "cross-site scripting," "malicious HTML tags," or "malicious content," and can happen on SSL and non-SSL connections. Without CSS security protection, the hacker could gain complete access to some pages. Here are some of the problems associated with not implementing this security feature:

  • SSL-encrypted connections might be exposed
  • Attacks might be persistent through poisoned cookies
  • Attacker might access restricted web sites from the client
  • Domain-based security policies might be violated
  • Use of less-common character sets might present additional risk
  • Attacker might alter the behavior of forms

The relevant entry in the ConfigService.properties file is:

# Flag whether Cross-Site-Scripting security protection is turned on.
security.css.protection = true

 

Problem: Pipe character used with the Credential Vault

Solution: Only the names of vault segments, vault slots, and resources cannot use the pipe character. The vertical or | character can be used in the description.

 

Problem: The validate-ldap task fails when configuring Active Directory over SSL

If configuring Active Directory over SSL, the validate-ldap task might fail with the following message:

javax.naming.CommunicationException: Request: lcancelled

Solution: Apply Windows 2000 Service Pack 4 to Active Directory to correct this issue. Details can be found in Microsoft Knowledge Base Article - Access Active Directory with LDAP by Using Sun JNDI Calls May Not Work

 

Problem: Unable to use some functions using IBM Tivoli Directory Server Web Administration (Solaris only)

Solution: To be able to use more functions of IBM Tivoli Directory Server Web Administration, use IBM Tivoli Directory Server in English mode by completing the following steps:

  1. Edit the file <ihs_root>/conf/httpd.conf

    Change the following line : 

    * Old   : SetEnv LANG  ja_JP.PCK
* New   : SetEnv LANG  C

  2. Restart httpd deamon.

 

Problem: Special characters limitation in Member Distinguished Name

Member Manager cannot be used to create a member entry in a repository if the entry has RDN attributes with values which contain the following special characters: "#", ",", "+", """, "\", "<", ">", or ";".

Solution: If you wish to allow the creation of special characters in member entries, create the entry directly into the repository not using Member Manager although Member Manager can be used to read, update, remove, and search the entry. For example, for an LDAP server, use an LDAP server tool or another LDAP application instead of Member Manager to create the entry into the LDAP server.

 

Problem: Syntax error on Sun ONE LDAP when importing PortalUsers.ldif

You might get a syntax error when importing the shipped sample PortalUsers.ldif into Sun One.

Solution: Comment out dc=setgetweb,dc=com to avoid a syntax error.

dn: dc=setgetweb,dc=com

objectclass: domain

objectclass: top

dc: setgetweb,dc=com <-- should remove this line to avoid syntax error

dc:setgetweb

 

Problem: Unable to see pages in Pixo browser

When using the Pixo Internet Microbrowser 2.1 device emulator on a PC, you will not be able to see any pages on your secure portal. This problem is caused by a defect in the Pixo simulator that affects supported cookies. WebSphere Portal with WebSphere Application Server global security enabled requires two cookies, JSESSIONID and LtpaToken. The JSESSIONID cookie is used to identify the WebSphere Portal session in the browser; LtpaToken is used to identify the user for WebSphere Application Server global security. Although two valid cookies are set for this domain, the Pixo browser only sends the most recently set cookie, which causes LtpaToken to replace JSESSIONID. Although LtpaToken allows the user to access WebSphere Portal, the browser is unidentified; therefore, the user will not be able to see any pages.

Solution: Use a real device, or use a different device emulator for cHTML testing.

 

Problem: Browser back button can show secured page after logout

With some browsers you might be able to view the information from a previous portal session by using the back button after logout. When you log out and click the back button, you can see the page that was last viewed.

Example scenario: You view an e-mail and click Log out. The portal returns to the Login panel. If you then click the back button, you might be able to view the e-mail again, depending on your browser.

The problem concerns only the display and view of data. The portal or the displayed data cannot be modified as clicking the back button does not undo the logout.

Cause: When you click the back button, the browser returns to the data cached by the browser.

Solution: Users can prevent the display of secured pages by either closing the browser after logout or clearing the browser cache.

 

Problem: Failed Stop Operation

If you receive the following stopServer.log file: 

A ADMU0111E: Program exiting with error:
javax.management.JMRuntimeException:
ADMN0022E: Access denied for the stop operation on Server 
MBean due to insufficient or empty credentials.

Solution: Choose one of the following options:

  • Modify the SOAP Client Security Enablement section of the was_root/properties/soap.client.props file:

    • Enter the authorized userid after com.ibm.SOAP.loginUserid=.

    • Enter the authorized password after com.ibm.SOAP.loginPassword=.

      This option may require a stop and restart of the appserver.

  • Stop the appserver on the command line and specify a valid userid and password. For example, 
    <WAS_root>/bin/stopServer WebSphere_Portal <userid> <password>

 

Problem: Debugging the Tivoli Access Manager Login Module

Solution: To debug the Tivoli Access Manager supplied PDLoginModule added to WebSphere Portal portallogin.config, add debug=true to the end of the specification of the login module. 

com.ibm.websphere.security.auth.module.proxy.WSLoginModuleProxy
    required delegate=com.tivoli.mts.PDLoginModule debug=true;

The output is written to standard out for the Portal Server Application Server.

 

Problem with single sign-on

Under certain circumstances, there is a problem with single sign-on between WebSphere Portal and other applications on the same WebSphere Application Server installation. When this problem occurs, you are unable to log into an application on an appserver; for example, the WebSphere Application Server Admin console and then logging into a portal running on the same appserver without renewed authentication (single sign-on fails). The portal displays a misleading error message saying that the user's portal session has timed out. The portal then prompts the user to log in again.

Cause:

The session cookie of the other application is not properly specified (the cookie path is too general) and is therefore also sent to the portal. In most cases, the cookie is specified as a simple slash (/). The portal application mistakes this as an old, invalid portal session cookie.

Solution:

Follow these steps to ensure that the application's session cookie is scoped to that application only:

  1. Log in to the WebSphere Application Server Admin console.

  2. Navigate to Applications>Enterprise Applications>respective application>Session Management, where respective application is the application with which single sign-on does not work.

  3. Click the Enable Cookies link (not the checkbox).

  4. Set the cookie path value to the complete application base path. For example, the Admin console of the appserver would be /admin.

  5. Click Apply to save the changes and then restart the application.

 

Problem: Cannot use the XML configuration interface if it is externalized in security

If the virtual resource XML_ACCESS that represents access to the XML configuration interface is put under protection of an external security manager, you can no longer use the XML configuration interface.

Solution: If the access rights of WebSphere Portal are externalized to an external security manager, such as Tivoli Access Manager, verify the XML configuration interface virtual resource is not externalized.

 

Problem: When using Domino, cannot create users and groups

If you are using IBM Lotus Domino Enterprise Server and edit the access control list of names.nsf so that "Maximum Internet name and password" is set to "Reader", you may notice that you are no longer able to create users and groups in WebSphere Portal.

Solution: The recommended setting for "Maximum Internet name and password" is "Author" or higher. By setting this field to "Reader", you would be overriding the regular settings in the access control list and thereby limiting the Author/Editor access that is necessary for WebSphere Portal to function successfully with Domino as the LDAP server.

To access the "Maximum Internet name and password" setting, open names.nsf with a Lotus Notes client (File > Database > Open) and go to File > Database > Access Control > Advanced. Options for this setting range from "No Access" to "Manager".

 

See also

 

WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.

 

IBM is a trademark of the IBM Corporation in the United States, other countries, or both.

 

Tivoli is a trademark of the IBM Corporation in the United States, other countries, or both.