Troubleshooting LDAP and security

 

+
Search Tips   |   Advanced Search

 

This section contains information that can assist you in preventing, identifying, and correcting problems related to WebSphere Portal. For information related to specific components, see the appropriate troubleshooting topic.

See the Security topic in the iSeries Information Center for more information.

 

Unable to deploy portlets after configuring LDAP

Problem: 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. Open the file...

    <wp_root>/config/work/createDeploymentCredentials.xml

    ...for viewing.

  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.

 

Cannot login to configure the database to use a third-party user registry

By default, WebSphere Portal is set up in database-only configuration for user authentication. In other words, the server must be manually set up to authenticate against a third party user registry such as an LDAP server.

Solution: If you experience a login issue, confirm the user entries in the tables listed below. These tables are in the portal database and during the portal server login process, they are used by Member Manager in a database-only configuration:

These tables can be viewed by starting up the Cloudscape client and connecting to the portal database (wps50). The portal server must be stopped in order to connect successfully to the database.

 

In Windows 2000 Active Directory, creating users when specifying a preferred language fails

If Windows 2000 Active Directory is the LDAP server for your portal and you need to 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.

The workaround is:

  1. Add preferredLanguage to the Windows 2000 Active Directory user schema. Refer to the Windows 2000 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"/>

 

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.

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:

The relevant entry in the ConfigService.properties file is: # Flag whether Cross-Site-Scripting security protection is turned on.
#
# Default: true
security.css.protection = true

 

Pipe character used with the Credential Vault

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.

 

Syntax error on Sun ONE LDAP when importing PortalUsers.ldif

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

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

dn: dc=yourco,dc=com
objectclass: domain
objectclass: top
dc: yourco,dc=com <-- should remove this line to avoid syntax error
dc:yourco

 

Unable to see pages in Pixo browser

Problem: 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.

 

Removing WebSphere Portal content publishing groups from the portal before enabling security

Follow these steps to move users and groups from the test server:

Steps 1 and 2 delete the groups from the database and step 3 re-creates the groups in the LDAP environment. You must complete these steps on the test server before you import the configuration to the production server.

  1. Create DeleteGroups.xml using a text editor and save the file. This file should contain the following contents to delete specific groups and users from the database: 
        <?xml version="1.0" encoding="UTF-8"?>
 <request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation=
 "PortalConfig_1.2.xsd" type="update" create-oids="true">

    <portal action="locate">
    <user action="delete" name="WCPAdmin"/>
    <user action="delete" name="<user name>"/>
 <user action="delete" name="<user name>"/>
 <user action="delete" name="<user name>"/>
 <user action="delete" name="<user name>"/>
 <group action="delete" name="<group name>"/>
 <group action="delete" name="<group name>"/>
 <group action="delete" name="<group name>"/>
 <group action="delete" name="<group name>"/>
 <group action="delete" name="<group name>"/>
 <group action="delete" name="<group name>"/>
 <group action="delete" name="<group name>"/>
 <group action="delete" name="<group name>"/>
 <group action="delete" name="<group name>"/>
 <group action="delete" name="<group name>"/>
 </portal>
 </request>

    Where <user name> and <group name> are specific users and groups.

  2. From the administrator machine directory that contains the xmlaccess.bat (or .sh) file, enter the following on the command line for DeleteGroups.xml, substituting the fully qualified file name for the XML file name: 
     Windows: xmlaccess.bat -in "xmlfilename" -user user -pwd password 
 -url http://yourco.prodserver.com:port/wps/config
 UNIX: ./xmlaccess.sh -in xmlfilename -user user -pwd password 
 -url http://yourco.prodserver.com:port/wps/config

    Where user is the portal administrator ID, password is the password for the administrator ID, yourco.prodserver.com:port is the production server URL and port number, and xmlfilename is the fully qualified name of the XML file (use double quotation marks if the path contains spaces).

  3. Enable security through LDAP on the machine.

Follow these steps to read the groups correctly:

  1. From the administrator machine directory that contains the xmlaccess file, enter the following on the command line for each of the six XML files substituting the fully qualified file name for the XML file name: 
     <wp_root>/wpcp/v5.0.2/author/portlet/wpcpGroups.xml
 <wp_root>/wpcp/v5.0.2/author/portlet/wpcpworkspace.xml
 <wp_root>/wpcp/v5.0.2/author/samples_v5.0.2/db2/sampleUtilities/samplePAC.xml
 <wp_root>/wpcp/v5.0.2/author/samples_v5.0.2/db2/sampleUtilities/sampleUsers.xml
 <wp_root>/config/templates/DocumentManagerGroups.xml
 <wp_root>/config/templates/DocumentManagerPAC.xml
 Windows: xmlaccess.bat -in "xmlfilename" -user user -pwd password 
 -url http://yourco.prodserver.com:port/wps/config
 UNIX: ./xmlaccess.sh -in xmlfilename -user user -pwd password 
 -url http://yourco.prodserver.com:port/wps/config

    Where user is the portal administrator ID, password is the password for the administrator ID, yourco.prodserver.com:port is the production server URL and port number, and xmlfilename is the fully qualified name of the XML file (use double quotation marks if the path contains spaces).

  2. Run the following configuration task from the <wp_root>/wpcp/v5.0.2/config directory: 
    WPCPconfig.bat action-cfg-author-security

 

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, make sure that the XML configuration interface virtual resource is not externalized.

 

Cannot create users and groups when using Domino

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".

 

URL Addressibility in WebSphere Portal 5.0.x

The uri.requestid parameter in the ConfigService.properties file determines whether WebSphere Portal should use a Request ID on URLs. By default, this setting is set to "false". This means that no Request ID is used and that URL Addressability is used.

For example, 

  uri.requestid = false
  http://<wp_hostname>:9081/wps/myportal/!ut/p/.cmd/cs/.ce/7_0_A/.s/7_0_M0

If you change the uri.requestid parameter to true, it should read: 

  uri.requestid = true
  http://<wp_hostname>:9081/wps/myportal/!ut/p/.cmd/cs/.ce/7_0_A/.s/7_0_M0/.r/1

 

Slow login when using Active Directory as LDAP

Problem: Login performance problems when using Active Directory as the LDAP for WebSphere Portal.

Cause:

  1. The parameter objectClassis not indexed. Using an indexed parameter such as objectCategory will improve performance.

  2. In Active Directory, the "computer" object class extends from the "user" object class. Using the default filter such as (&(cn=*)(objectClass=user)) will return all users and computers. To only return users, define a userFitler such as (&(cn=*)(objectCategory=Person).

Solution:

  1. To improve Active Directory performance, use the ObjectCategory parameter instead of objectclass, perform the following steps:

    1. Open the LDAP Advanced Properties screen.

    2. In the User Filter field, replace objectclass=user with objectCategory=user.

    3. In the Group Filter field, replace objectclass=group with objectCategory=group.
      Note:       In the Group Member Id Map field, add ;objectCategory:group" to the end of the field.

    4. Change the wmm.xml file by applying the following Member Manager fix and prerequisites:

      1. Fix: PQ84174

      2. Prerequisites:

        • PQ83389

        • Member Manager 5.0.2 GM Driver

  2. After the fix has been applied, make the following change to add ObjectCategory to the search filter Member Manager formulate.

    1. In a text editor, open the wmm.xml file.

    2. Find the following stanza: 
          <supportedLdapEntryType name="Person"
                            rdnAttrTypes="uid" 
                            objectClassesForRead="user"
                            objectClassesForWrite="user"
                            searchBases="cn=groups,dc=yourco,dc=com"/>

      In this stanza, objectClassesForRead for "Person" is defined as "user" When searching for all users, Member Manager will formulate the filter as (&(cn=*)(objectClass=user)).

    3. At the end of this stanza, add a new parameter called searchFilter, as shown in bold below: 
       <supportedLdapEntryType name="Person"
                            rdnAttrTypes="uid" 
                            objectClassesForRead="user"
                            objectClassesForWrite="user"
                            searchBases="cn=users,dc=yourco,dc=com"
                            searchFilter="(ObjectCategory=Person)"/>

      Defining the searchFilter parameter will allow you to define the filter on which to search. In the example above, when searching for all users, the search filter will become (&(cn=*)(objectCategory=Person).

 

Can the LDAP suffixes be modified on WebSphere Portal?

Note: Reconfiguring WebSphere Portal to use a different LDAPUserSuffix and LDAPGroupSuffix is not recommended.

If, for example, you have changed your LDAP schema, the reconfiguration is possible. Even in this situation, reconfiguring is not recommend unless your portal server is fairly new and has not had much activity. Any resources created by current portal users will be inaccessible after this reconfiguration because the Portal Access Control (PAC) will not be aware of the changes. The general procedure for the suffix change is as follows:

  1. Open the file wpconfig.properties in a text editor.

  2. Modify the Portal Admin User and Portal Admin Group information to reflect default settings (as discussed in Disabling WebSphere Application Server Global Security).

  3. Run the configuration task: WPSconfig disable-security.

  4. Modify the necessary entries in the wpconfig.properties to reflect your new suffix information (including portal admin user and group information).

  5. Run the configuration task: WPSconfig enable-security-ldap.

  6. Restart server1 and WebSphere_Portal application servers.

 

Can Lotus Collaborative Environments share an LDAP server?

Senario: You have the environments below set up, and you are trying to confirm whether Single Signon (SSO) will work between WebSphere Portal in a test environment and your collaborative components (Domino, Sametime, Quickplace) in a development environment. You do not have collaborative components set up in the test environment.

Development Environment: Test Environment:

  • WebSphere Portal 5.02 running on WebSphere Application Server 5.02

  • LDAP Server

  • Web Server

  • Domino Server

  • Sametime Server

  • Quickplace Server

Single Signon works successfully between the portal server and the collaborative components in this environment.

  • WebSphere Portal 5.02 running on WebSphere Application Server 5.02

  • LDAP Server

  • Web Server

 

Additional Details: The LDAP server in the Development Environment is not the same LDAP server as in the Test Environment (In other words, they have different hostnames and are not part of any LDAP cluster).

Solution: You do not have a need to have Single Signon capability between each of the WebSphere Portal and WebSphere Application Server servers. As long as the collaborative components share the LTPA Token with WebSphere Portal and WebSphere Application Server, Single Signon should work.

However, the limiting factor in this environment is the WebSphere Application Servers that are set up for Single Signon require the participating WebSphere Application Servers to use the same LDAP server. Therefore, in this current setup, Single Signon would not work between WebSphere Portal in the Test Environment and the collaborative components in the Development Environment because WebSphere Portal in the Test Environment authenticates to a different LDAP server than the one set up in the LDAP realm of the LTPA Token for the collaborative components in the Development Environment.

In this scenario, either have the same LDAP server for each environment, or install the collaborative components into the Test Environment and use a separate LTPA Token for each environment.

 

Implementing multiple object classes in WebSphere Portal

To configure WebSphere Portal to support multiple object classes for functions such as user and group searches, perform the following steps.

  1. In a text editor, open the .xml file containing the properties that reference the object classes. For example, the <wp_home>/shared/app/wmm/wmm.xml.

  2. Find the objectClass attribute to be edited and type all object classes to be included for the properties. Separate each object class by a semicolon ";".

    For example, the objectClassesForRead attribute (in the supportedLdapEntryType stanza) determines if a LDAP entry belongs to the specified member type. In the following example, any LDAP entries will be considered a "Person" in Member Manager if it contains either "inetOrgPerson" or "ePerson" in its object class attribute. 
    <supportedLdapEntryType name="Person" 
                        rdnAttrTypes="uid" 
                        objectClassesForRead="inetOrgPerson;ePerson" 
                        objectClassesForWrite="inetOrgPerson;ePerson"/>

    Likewise, in the following example, any LDAP entries will be considered a "Group" in Member Manager if it contains either "groupOfNames" or "ibm-appUUIDAux" in its object class attribute. 

    <supportedLdapEntryType name="Group" 
                        rdnAttrTypes="cn" 
                        objectClassesForRead="groupOfNames;ibm-appUUIDAux" 
                        objectClassesForWrite="groupOfNames;ibm-appUUIDAux"/>

    In these examples, the objectClassesForWrite attribute is the value of the object class attribute when creating a new member on the LDAP server using WebSphere Portal. As set above, when a "Person" is created, the object class of the LDAP entry created will contain both "inetOrgPerson" and "ePerson"; and when a "Group" is created, the object class of the LDAP entry created will contain both "groupOfNames" and "ibm-appUUIDAux".

 

Cannot access WebSphere Portal after changing a user's DN wtih the Domino administrator

Problem: When using Domino as the LDAP server for WebSphere Portal, a user's Distinguished Name (DN) was modified using the Domino Administrator instead of using the WebSphere Portal interface. The user can no longer access all areas of WebSphere Portal.

Cause: WebSphere Portal stores the DN of a user in its database for various purposes. Changing the DN of a user in Domino does not change the DN of that user in all areas and WebSphere Portal cannot re-associate the DN in its database with the user's new DN. Therefore, information that was once stored with the DN of a particular user will be lost.

Solution: The DN can be manually recreated for access control as well as the credential vault, although this is not recommended. DN cannot be recreated for ownership of private pages. For a WebSphere Portal system that has just been installed and configured with LDAP, manually recreate the DN. Some information loss should be expected. However, for a system that has been in use for a while, manually recreating the DN would result in extensive information loss. Additionally, extensive manual changes would be needed to prevent other items from being lost.

 

Some users and groups not being returned from back-end LDAP server

Problem: WebSphere Portal uses JNDI to retrieve users and groups from a back-end LDAP server. Except for some standard attributes, JNDI returns all attributes as string. Therefore, non-standard attributes must be registered to the JNDI API.

Cause: By default, JNDI returns all attributes as string, except for a standard list of attributes. To enable non-string attributes to be returned as binary attributes by JNDI, you need to register those attributes to the JVM.

Solution: Configure WebSphere Portal for non-standard binary LDAP attributes by adding the following line to the wmm.xml file: 

<ldapRepository name="wmmLDAP"
                UUID="LDAP1"
...
java.naming.ldap.attributes.binary="<yourattributenames>" >

Replace <yourattributenames> with the names of the attributes that should be returned as binary data. Enter the attribute names as a list separated by spaces, for example: 

java.naming.ldap.attributes.binary="attributename1 attributename2"

 

Upgrade the Domain Controller to Microsoft Windows 2003 failing

Problem: The initial step for a Domain Controller's upgrade from Microsoft Windows 2000 Server to 2003 is to run the adprep.exe utility from the \i386 directory of the Windows 2003 installation media, which properly prepares the Active Directory for the upgrade. The adprep /forestprep command fails with errors similar to: 

Add error on line 333: Unwilling to Perform
The server side error is "Schema update failed" attribute in may-contain does not exist."
An error has occurred in the program...and the upgrade to Windows Server 2003 is blocked

(Details on this are available from Microsoft's Knowledge Base, and from the Windows Server 2003 Deployment Kit.)

Cause: Wrong OID value documented for preferredLanguage attribute in Information Center for Active Directory configuration. If you added the Object ID (OID) documented in the WebSphere Portal Information Center for configuring the product with Active Directory to the schema prior to the documentation correction (approximately August 2004), the OID is incorrect.

If the system remains on this level of the operating system there are no discernible issues known. However, the attempt to upgrade the Domain Controller to Microsoft Windows 2003 will fail because of this invalid OID. Previously, before correcting the documentation defect from APAR PQ92194, the Information Center had the wrong Unique X500 Object ID (OID) listed (it was written as "2.16.840.1.113730.1.39" when in fact it should have been "2.16.840.1.113730.3.1.39"). If you had gone through the configuration following those instructions, you might have entered the wrong OID. Here is the link to the article (corrected) on the web: http://publib.boulder.ibm.com/pvc/wp/502/smb/en/InfoCenter/wpf/cfg_msadwp.html#change_schema

Solution:

WARNING: This is a potentially destructive operation. Be sure that the syntax of all modifications is correct, otherwise, you can permanently destroy the Active Directory schema. Try this operation in a test environment first.

  1. Modify the following registry value on the schema master: 
    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
   Value Name: Schema Update Allowed
   Value Type: REG_DWORD
   Value Data: 1
    (This can also be accomplished in the support tools, under Active Directory Schema > Operations Master, and the checkbox would need to be checked to allow "The Schema may be modified on this Domain Controller".)

  2. Open LDP.exe on the schema master (Start > Run > ldp). LDP.exe is a utility available from Microsoft in the Server Resource Kit or in the Support Tools package.

  3. Click the Connection menu, select Bind (no need to specify credentials if you are already logged in as the administrator).

  4. Click the View menu, select Tree.

  5. Type the following in the BaseDN field: 
    cn=schema,cn=configuration,dc=,dc=com
    example: 
    cn=schema,cn=configuration,dc=mydomainname,dc=com

  6. In the left pane, right-click on the object CN=preferredLanguage and select Modify

  7. In the Modify dialog box, add the following: 
    Attribute: adminDisplayName
   Values: brokenpreferredLanguage
Operation: Replace

  8. Click Enter, then Run, then Close.

  9. Modify the LDAPDisplayName (or "LDAP-Display-Name") attribute in the same way, changing preferredLanguage to brokenpreferredLanguage.

  10. Next select the Browse menu, click ModifyRdn, and make the following change: Old Dn: 
    CN=preferredLanguage,CN=Schema,CN=Configuration,DC=<forest root domain>,DC=com
    New Dn: 
    CN=brokenpreferredLanguage,CN=Schema,CN=Configuration,DC=<forest root domain>,DC=com

  11. Rerun adprep /forestprep.

  12. Remember to change back the Schema Update Allowed registry value when finished, or uncheck the checkbox from Step 1.

See also