Understanding the WebSphere Portal 6.1 Security Configuration -- Stand-alone LDAP using Domino 8.0.1

Goals of this document:

-Enable stand-alone LDAP security for a stand-alone WebSphere Portal environment with Lotus Domino as the LDAP server
-Understand how to populate values in the wkplc.properties file based on information from the LDAP server
-Understand where certain values are written to in order to troubleshoot possible errors or unexpected results during server startup, login, or when managing users/groups via the administration portlets.

Environment:

-stand-alone WebSphere Portal 6.1 (Content Server installation) on Microsoft Windows 2003
-WebSphere Application Server 6.1.0.15
-LDAP: Lotus Domino 8.0.1
-Database: Derby 10.1.3.2

Assumptions and hints on Domino setup:

a) The Domino LDAP server has been set up with the proper access control and person/group entries per the Preparing a Domino Directory Server page in the WebSphere Portal 6.1 Information Center.

NOTE: -Even though "Author" or above access is given to the wpsadmins group, confirm that one of the attributes included in the Domino ACL for names.nsf is "Create documents". Also, confirm that a configuration document exists in the names.nsf under Configuration->Servers->Configurations and the option "Allow LDAP users write access" is set to "Yes". Otherwise, you won't be able to create users/groups via the administration portlets in WebSphere Portal. Finally, if you are using multiple address books via directory assistance in Domino, you'll need to set up the access control on each address book to avoid the situation mentioned in technote 1318176.

b) You have received the relevant information for the LDAP server including the appropriate object classes and attributes for the users. If you need to collect this information yourself, you can use the ldapsearch tool found in the c:/notes directory of Lotus Notes 8 or download the ldapsearch tool from the WebSphere Application Server Support site.

Example command from my environment:

ldapsearch -h -D "cn=wpsbind,o=ibm" -w "(cn=wps*)" > myLdapObjects.txt

The above command gave me the object classes and attributes for the wpsadmin and wpsbind users, as well as the wpsadmins group:

CN=wpsadmin,O=ibm
cn=wpsadmin
mail=wpsadmin/ibm@raleigh.ibm.com
displayname=wpsadmin/ibm
objectclass=dominoPerson
objectclass=inetOrgPerson
objectclass=organizationalPerson
objectclass=person
objectclass=top
sn=wpsadmin
uid=wpsadmin

CN=wpsadmins
cn=wpsadmins
mail=wpsadmins@raleigh.ibm.com
displayname=wpsadmins
objectclass=dominoGroup
objectclass=groupOfNames
objectclass=top
member=CN=wpsadmin,O=ibm
member=CN=wpsbind,O=ibm

c) Key hints on the Domino person and group setup:

-When creating the users in Domino, confirm that you have populated the User Name value with two values in the User Name field with this format (and order):

wpsadmin/Domain
wpsadmin

-When populating the members of the wpsadmins group, confirm that the members display with their Domino domain in the Members field and not just the shortname value. Ex: wpsadmin/ Domain

Steps to enable stand-alone LDAP security:

The following steps depend heavily on the WebSphere Portal 6.1 Information Center procedure.
However, additional comments are offered to aid in setting up the user registry configuration.

1) Start server1 and WebSphere_Portal if they are not already started.

2) Open the file /ConfigEngine/config/helpers/wp_security_domino.properties with a text editor. We will modify the values directly here instead of wkplc.properties since this file provides some default values that are appropriate for Domino. The wp_security_domino.properties also excludes many of the values in wkplc.properties in order to avoid distraction for this specific task.

3) The wp_security_domino.properties does give brief descriptions of each property in the file. However, the following attached table attempts to give further understanding of where and/or how the values will be used during runtime in case you wish to make any changes to the runtime files after running the configuration task. Use the LDAP information you have received from your LDAP administrator along with the table to fill in the appropriate values in wp_security_domino.properties and save and close the file.

Table of Properties for WP61-Domino setup-standalone.ods

Notes on the attached table
-The two primary runtime files to be referenced are:

/config/cellsecurity.xml
/config/cellswim/config/wimconfig.xml

These files will be written to by the configuration task, but the the updated values will not take effect until the server is restarted.

-In the security.xml, you will see activeUserRegistry="LDAPUserRegistry_1" after running the security configuration task in step 6. Thus, any reference in the table to

-You cannot use multiple values for the object class entity types when configuring security in WebSphere Portal 6.0, but you can add the additional object classes afterwards. See technote 1318615 for further details. This will be corrected in 6.1.0.1.

-Take care to use the proper syntax when typing the standalone.ldap.userFilter and standalone.ldap.groupFilter values. Otherwise, the startup or login for both WebSphere Portal and server can fail as noted in technote 1316901.

-The standalone.ldap.et.user.searchFilter and standalone.ldap.et.group.searchFilter can be left blank, as a search filter using the relevant object class and attribute will be contstructed automatically during runtime.


4) Run the following task to copy the values from wp_security_domino.properties to wkplc.properties:

ConfigEngine -DparentProperties=./config/helpers/wp_security_domino.properties -DSaveParentProperties=true

See the WebSphere Po rtal 6.1 Information Center for further information on this task.

NOTE: Even though the task succeeds, you may receive an ADMN0022E message, which can be ignored. If you wish to avoid this message, you can add the -DWasPassword= parameter to your command line.

5) Run the LDAP validation task: ConfigEngine validate-standalone-ldap -DWasPassword=

NOTE: -DWasPassword refers to the password for your WebSphere Application Server security userID that exists in the out of the box file registry. This is the user you chose when installing WebSphere Portal, so in my case, its the password for my user "uid=wasadmin,o=defaultWIMFileBasedRealm", which still resides in fileRegistry.xml under /config/cells/.

6) Run the LDAP modify task: ConfigEngine wp-modify-ldap-security -DWasPassword=

NOTE: -DWasPassword refers to the same password value you used in the previous step.

7) Stop the application servers (still using the -DWasPassword value from previous steps):

stopServer server1 -username wasadmin -password
stopServer WebSphere_Portal -username wasadmin -password

8) Start the application servers from /bin:

startServer server1
startServer WebSphere_Portal

9) Run the attribute validation task: ConfigEngine wp-validate-standalone-ldap-attribute-config -DWasPassword=

NOTE 1: Now that you have restarted the servers, the -DWasPassword will be the password for your WebSphere Application Server security userID that exists in the LDAP.

NOTE 2: Even though the result of this task may be BUILD SUCCESSFUL, you will want to review the results of this task in the ConfigTrace.log because it provide additional information that may require you to take action. For example, you need to map your email address attribute so that you can create users with email addresses via the WebSphere Portal interface. See technote 1318616 for details.

Checkpoints:

-No security-related errors should exist on startup of WebSphere Portal and server1.
-LDAP users including the WebSphere Portal administrative user should be able to log into WebSphere Portal via the login portlet.
-The WebSphere Portal administrativeuser should see the Administration link when logging into WebSphere Portal.
-Login for the Integrated Solutions Console and the stopServer/serverStatus commands should succeed using the WebSphere Application Server userID's (in LDAP) credentials.
-Creation of users should succeed using the Sign Up feature (see NOTE 2 above).
-Creation/searching of users/groups should succeed via the Manage Users and Groups portlet in WebSphere Portal.

If any of the checkpoints fail, then post your issue to the WebSphere Portal forum or create a PMR with WebSphere Portal Support and supply the relevant MustGather information.

If you have ideas/suggestions on enhancing this article, please post your comments. For example, we will soon post a similar article on setting up the federated repository with Active Directory.

Attachments: