Back
LDAP
WebSphere Portal V6 Enterprise Scale Deployment
- Advantages of Multiple LDAP Directory Support
- Virtual portals and realms
- LDAP browser tools
- ldapsearch.exe
- Multiple LDAP directory scenarios
- Plan for Multiple LDAP directories
- Scenario 1, Default realm with multiple LDAP directories (one to many)
- Scenario 2, One realm per LDAP directory (one to one)
- Scenario 3, Multiple realms & multiple LDAP directories (many to many)
- Configure multiple LDAP directories
- Domino LDAP & groups
- Enable multiple LDAP directories in a cluster
Advantages of Multiple LDAP Directory Support
Advantages of multiple LDAP directories include...
- Ability to service external portal clients with one LDAP directory, such as Tivoli Directory Server, while servicing internal employees with a different LDAP directory, such as Active Directory.
- You no longer have to consolidate user accounts into one LDAP directory to accomodate portal.
This is particularly useful in cases where two or organizations merge or when one organization acquires another and each has different application or corporate LDAP directories containing their users and groups.
- Minimizes the LDAP directory being a single point of failure.
Virtual portals and realms
Virtual portals are logical portals that share the same hardware and software installation yet have the ability to serve up different content to different users.
For example, a single portal installation could contain three separate virtual portals...
- employees
- customers
- suppliers
In Portal v5.1 one of the limitations was all virtual portals had to exist in the same LDAP directory. Each virtual portal was associated with a realm. Despite only having a single LDAP directory, we can have three distinct groupings or "realms" of users.
WebSphere Portal Server v6 extends the concept of realms by adding support for multiple LDAP directories.
Before you begin configuring multiple LDAP directories
- Make sure the LDAP directory is currently supported for use with WebSphere Portal
- Obtain a user name and password in the LDAP directory that WebSphere Portal Server can use to connect (or "bind") to the LDAP directory.
- Ensure that this username has the appropriate access rights to search the LDAP directory for users and groups and has read/write access to the directory
- Write access to the LDAP directory is only required if you are going to allow Portal users to "Sign Up" and create their own login account from Portal or if you have deployed portlets which for some reason need to create or update entries in the LDAP directory. If you are not using these features, then read access to the LDAP directory should be sufficient.
- Verify the servers on which you will be installing WebSphere Portal Server can connect to and query the LDAP directory server. This is particularly important if firewalls are involved.
- Ensure that you have network connectivity on the correct ports. By default, the LDAP protocol uses TCP/IP port 389 (port 636 if using SSL), so it is important to ensure that network connectivity on these ports is in place prior to installing or configuring WebSphere Portal Server.
LDAP browser tools
We can download a free LDAP Browser/Editor from...
www.iit.edu/~gawojar/ldap/One of the pre-requisites for this LDAP Browser/Editor is that Java must be installed on the machine. If you are using a Windows system, once Java is installed, set the JAVA_HOME system variable system variable.
My Computer (right-click) | Environment Variables sectionOn the Path statement add the value...
C:\Program Files\Java\jre1.5.0_06Do not put quotes around the path, even though it contains a space. This produces a Java error because the LDAP browser program misinterprets the JAVA_HOME variable if it is enclosed in quotes.
Edit lbe.bat and specify the JAVA_HOME variable with the same path specified in the Windows environment variables.
:setjavahome set JAVA_HOME=C:\Program Files\Java\jre1.5.0_06After launching the LDAP Browser/Editor, create a profile for the LDAP directory.
Another popular LDAP Browser tool is available from Softerra and can be downloaded from
http://www.softerra.comThis particular tool is Windows based and does not require Java, however it is only a browser not an editor and therefore does not allow you to directly edit LDAP entries.
ldapsearch.exe
ldapsearch.exe can be used to verify...
- connectivity
- authentication
- search
ldapsearch.exe is bundled with with...
- Lotus Domino Server
- Lotus Notes
- IBM Tivoli Directory Server
If you have the Lotus Notes client installed, it can be found in...
C:\Program Files\Lotus\NotesThe following syntax will confirm network connectivity, binding, and searching...
ldapsearch.exe -h hostname -D "FullyDistinguishedBindUserName" -w bind_password -b "search_base" "username"For example...
ldapsearch.exe -h dbids.cam.itso.ibm.com -D "uid=wpsadmin,CN=Users,OU=Cambridge,DC=ibm,DC=com" -w password -b "DC=ibm,DC=com" "(cn=wps admin)"...where...
-h LDAP server’s host name. -D Fully distinguished user name to connect (or bind) to the LDAP directory with. Where uid is the unique identifier of the user, in the case wpsadmin
CN=
OU=
DC=Various containers that combine to make up the user’s fully distinguished name. -w Password assigned to the user. In this case, the password was password. -b Search base or location in the directory to search for user’s names and groups. Results from a typical ldapsearch query
uid=tmclure,cn=users,ou=cambridge,dc=IBM,dc=com
objectclass=organizationalPerson
objectclass=person
objectclass=top
objectclass=inetOrgPerson
uid=tmclure
sn=mclure
givenName=troy cn=troy mclure
Multiple LDAP directory scenarios
Scenario 1, Default realm with multiple LDAP directories (one to many)
In this scenario you have a single realm defined in WebSphere Portal Server. This is the default realm of "portal" that is automatically created when you enable WebSphere Portal Server security with realms.
This is the simplest scenario in terms of deployment and configuration for multiple LDAP directories and is suitable when you do not wish to logically group users in any particular way. This scenario simply requires enabling WebSphere Portal Server with realm support and using the default realm of "portal" that is automatically created.
The default realm is associated with two different LDAP directories i.e you have a "one to many" relationship between the realm and the LDAP directories.
Scenario 2, One realm per LDAP directory (one to one)
In this scenario, WebSphere Portal Server is configured with two realms and two LDAP directories so you have a "one to one" relationship between realms and LDAP directories.
In this scenario, as you already have all the customers in their own LDAP directory, and employees are in a separate one it makes logical sense to associate each directory with its own realm.
This scenario is extensible should you wish to add an additional third or fourth LDAP directory and is representative of a typical real world scenario.
Scenario 3, Multiple realms & multiple LDAP directories (many to many)
This scenario is an extension of scenario two, however instead of an equal number of realms and LDAP directories, here you have a "many to many" relationship.
For example , the realm "customer" is made up of three separate LDAP directories whilst the default realm of "portal" and the "supplier" realm are mapped to their own individual LDAP directories.
This scenario reflects many typical environments where customer data may well be held in different systems each with their own LDAP directory.
Configure multiple LDAP directories
Supported LDAP directories include...
- Domino 6.5.4, 6.5.5 &7.x
- IBM Tivoli Directory Server 5.2 & 6.0
- Novell eDirectory 8.7.3
- Active Directory 2000 & 2003
- Active Directory 2003 with Active Directory Application Mode
- Sun One Directory Server 5.2
Check the WebSphere Portal Server v6 Infocenter for the latest list.
Pre-requisites
- Security in WebSphere Portal Server must be enabled with realm support. If you currently have security enabled without realm support, then disable and re-enable it.
When in non-security mode, using enable-security-ldap, or registering a custom user registry as the WAS Authentication mechanism means that realms cannot be enabled.
- A realm must be mapped to a Virtual Portal.
We can simply use the default realm of "portal".
- In order to be able to log in to a particular virtual portal, a user must be a member of the realm that is associated with that virtual portal
- Decide which directory will act as the primary LDAP directory and enable security to it first before configuring any additional LDAP directories.
- When using multiple LDAP directories, ensure that the distinguished names and the logon attributes (e.g. uid) are unique over all LDAP directories.
Which ever attribute or attributes you have defined to allow users to login to portal, such as...
- uid
- email address
- common name
- etc...
...must be unique across all LDAP directories.
Enable realm support
By default, when you install a WebSphere Portal Server, security is already enabled. However it is not enabled with realm support so it needs to be disabled and then re-enabled with realm support if you are to use multiple LDAP directories.
If you have an existing WebSphere Portal server environment already up and running with security already enabled with realm support then there is no need to disable security
Follow these steps to disable security on the portal server if you do not already have security with realm support enabled.
- Make a copy of...
WP_ROOT/config/helpers/security_disable.properties/security_disable.properties- Edit security_disable.properties and modify the following properties...
wmm.DbPassword
WasPasswordAlso, change the following properties in the security_disable.properties helper file to what you desire the portal administrator user name and password to be after security is disabled.
- Run the config wizard to disable security. Invoke the config wizard by running the following script
WP_ROOT/config/wizard/configwizard.bat- Click next on the Welcome Page screen
- Select "Disable security" and click next
- Enter the WAS Administrator user name and password and then click next
- Select the location of the security_disable.properties helper file you previously edited, and click next.
- Enter the WMM database user name and password and then click next
- Review the summary panel and click next to start begin the process of disabling security.
- After the wizard successfully completes, ensure that the portal server is stopped.
In a clustered environment, make sure you disable security on the primary node.
In a clustered environment, ensure that all portal servers are stopped but that all nodeagents and the Deployment Manager are running before re-enabling security with realms.
Enable security with realm support
Enabling security with realm support cannot be carried out via the Config Wizard. It has to be configured manually.
- Make copies of...
WP_ROOT/config/wpconfig.properties
WP_ROOT/config/wpconfig_dbdomain.properties- Edit wpconfig.properties and set appropriate values.
Here is an example wpconfig.properties file configured for Active Directory:
wpconfig.properties.ADEnter all LDAP related values and DNs in lower case. This is especially important for Domino LDAP as although Domino LDAP returns the DN capitalized...
CN=wpsadmin,OU=Cambridge,O=ibm...specifying CN= or OU= in upper case, rather than as cn= or ou= in lower case, can cause the enable security with realms task to fail.
WAS properties
Property Value WasUserid User ID for WAS security authentication. The fully qualified DN of a current administrative user for the WAS. This value should not contain spaces.
WasPassword Password for WAS security authentication. If a value is specified for WasPassword, a value must also be specified for WasUserid. If WasPassword is left blank, WasUserid must also be left blank.
Portal configuration properties
Property Value PortalAdminId User ID for the WebSphere Portal administrator, which should be the fully qualified DN. For LDAP configuration this value should not contain spaces. - Type the value in lower case, regardless of the case used in the DN.
PortalAdminPwd Password for the WebSphere Portal administrator, as defined in the PortalAdminId property. PortalAdminGroupId Group ID for the group to which the WebSphere Portal administrator belongs. Type the value in lower case, regardless of the case used in the DN.
WpsContentAdministrators Group ID for the WebSphere Content Administrator group. WpsContentAdministratorsShort WebSphere Content Administrators group ID.
WebSphere Portal Security LTPA and SSO configuration
Property Value WpsDocReviewer Group ID for the WebSphere Document Reviewer group WpsDocReviewerShort WebSphere Document Reviewer group ID. LTPAPassword Password for the LTPA token LTPATimeout Specifies the number of minutes after which an LTPA token will expire. SSODomainName Specifies the domain name for all allowable single signon host domains. - Enter the part of the domain that is common to all servers that participate in single signon. Enter the part of the domain that is common to all servers that participate in single signon. For example, if WebSphere Portal has the domain...
portal.us.ibm.com...and another server has the domain...
another_server.ibm.com...enter...
ibm.comTo specify multiple domains, use a semicolon ; to separate each domain name. For example,...
your_co.com;ibm.com
LDAP Properties Configuration
Property Value LookAside Install with LDAP only or with LDAP using a Lookaside database to store attributes which cannot be stored in the LDAP server. Set Lookaside to true if you are using any of the following...
- IWWCM
- Common Mail portlet
- Common Calendar portlet
WmmDefaultRealm Default realm of the user registry (UR) configuration. Set this property before enabling security with enable-security-wmmur-ldap LDAPHostName Host information for the LDAP server that WebSphere Portal will use. LDAPPort Server port of the LDAP directory. LDAPAdminUId User ID for the administrator of the LDAP directory. Member Manager uses this ID to bind to the LDAP to retrieve users attributes, create new users and groups in the LDAP and update user attributes. This ID is not required to be the LDAP admin DN, but rather an ID with sufficient authority for the use cases just cited. If this property is omitted, the LDAP is accessed anonymously and read-only. Type the value in lower case, regardless of the case used in the DN.
LDAPAdminPwd Password for the LDAP directory administrator, as defined in the LDAPAdminUId property. If the LDAPAdminUId is blank, this property must be blank as well. LDAPServerType Type of LDAP Server to be used. Value type:
Tivoli Directory Server IBM_DIRECTORY_SERVER Lotus Domino DOMINO502 Active Directory ACTIVE_DIRECTORY Sun Java System Directory Server IPLANET Novell eDirectory NDS LDAPSuffix This is the DN of the node in the LDAP containing all user and group information for the Portal being configured. LdapUserPrefix RDN prefix attribute name for user entries. LDAPUserSuffix DN suffix attribute name for user entries. Type the value in lower case, regardless of the case used in the DN.
LdapGroupPrefix DN suffix attribute name for group entries. Type the value in lower case, regardless of the case used in the DN.
Advanced LDAP Configuration
Property Value LDAPGroupSuffix DN suffix attribute name for group entries. Value type:
Tivoli Directory Server cn=groups Lotus Domino this value is null Active Directory cn=groups Sun Java System Directory Server ou=groups Novell eDirectory ou=groups LDAPUserObjectClass LDAP object class of the Portal users in the LDAP directory that will log into the Portal being configured. Value type:
Tivoli Directory Server inetOrgPerson Lotus Domino dominoPerson Active Directory user Sun Java System Directory Server inetOrgPerson Novell eDirectory inetOrgPerson LDAPGroupObjectClass LDAP object class of all the groups in the LDAP directory that the Portal will access. LDAPGroupMember Attribute name in the LDAP group object of the membership attribute. LDAPUserFilter Filter used by WAS for finding users in the LDAP.
Value type:
Tivoli Directory Server (&(uid=%v)(objectclass=inetOrgPerson)) Lotus Domino (&(|(cn=%v)(uid=%v))(|(objectclass=dominoPers on)(objectclass=inetOrgPerson))) Active Directory (&(|(cn=%v)(samAccountName=%v))(objectclas s=user)) Sun Java System Directory Server (&(uid=%v)(objectclass=inetOrgPerson)) Novell eDirectory (&(uid=%v)(objectclass=inetOrgPerson)) LDAPGroupFilter Filter used by WAS for finding groups in the LDAP. Value type:
Tivoli Directory Server (&(cn=%v)(objectclass=groupOfUniqueNames)) Lotus Domino (&(cn=%v)(|(objectclass=dominoGroup)(objectcl ass=groupOfNames)(objectclass=groupOfUniqueNames))) Active Directory (&(cn=%v)(objectclass=group)) Sun Java System Directory Server (&(cn=%v)(objectclass=groupOfUniqueNames)) Novell eDirectory (&(cn=%v)(objectclass=groupOfUniqueNames))
IWWCM Properties
Property Value WcmAdminGroupId Group ID for the WCM administrators group. The fully qualified DN of a current administrative user for the WAS. For LDAP configuration this value should not contain spaces.
WcmAdminGroupIdShort WCM administrators group ID. SSORequiresSSL Specify that Single Sign-On is enabled only when requests are over HTTPS connections. - Edit wpconfig_dbdomain.properties and set...
Property Value wmm.DbUser User ID for the database administrator. wmm.DbUser Password for the database administrator. A value must be set for this property; it cannot be empty.
- Stop the portal server
- Validate the values entered in the config files...
- Enable security with realms...
WPSconfig.bat enable-security-wmmur-ldap > enable.log
In a clustered environment, run enable-security-wmmur-ldap on the primary node only.
This will configure LDAP security on the Deployment Manager and subsequently all other portal nodes in the cluster.
- In a clustered environment, if you have enabled security with realms, on the Deployment Manager, edit...
<dmgr_profile_root>/config/wmm/wmmWASAdmin.xml- Add another line between the <wmmWASAdmins> tags that includes the short name for the WAS Administrator user name.
Since the fully distinguished name and short name have the same password we can simply copy and paste the current <admin logonId> tag entry and modify it.
<?xml version=1.0 encoding=UTF-8?> <wmmWASAdmins> <admin logonId=uid=wpsadmin,cn=users,ou=firebrigade,dc=IBM,dc=com logonPassword=anvu7zPZ7jbrZLa4h89Tfg== uniqueUserId= uid=wpsadmin,cn=users,dc=IBM,dc=com/> <admin logonId=wpsadmin logonPassword=anvu7zPZ7jbrZLa4h89Tfg== uniqueUserId= uid=wpsadmin,cn=users,dc=IBM,dc=com/> </wmmWASAdmins>If you do not edit this file, running stopServer.bat and serverStatus.bat will require a fully distinguished user name.
If you do not wish to edit the wmmWASAdmin.xml file on the Deployment Manager, another option is to enable the Deployment Manager for Localmode.
Configure an additional LDAP directory and enable realms
This example requires...
- A non-clustered, non-managed WebSphere Portal Server node with security enabled to IBM Tivoli Directory Server acting as the primary LDAP server containing all employees.
- A Domino 7.0.2 LDAP server as a secondary LDAP server containing all customers.
- Three realms...
portal Maps to the IBM Tivoli Directory Server. Default. Automatically created when security was enabled with realm support.
IBM Tivoli Directory Server belongs to both the "portal" realm as well as "employees" realm. Realms can overlap. The primary LDAP directory is always automatically associated with the default realm.
employees Maps to the IBM Tivoli Directory Server customers Maps to the Domino 7.0.2 LDAP server The following instructions are for a non-clustered environment.
Configuring additional realms fundamentally means configuring wmm.xml. There are different wmm.xml sample files for the various combinations of LDAP directories supported by WebSphere Portal. For IBM Tivoli Directory Server and Domino LDAP we can use the wmm_LDAP_LA_DM.xml sample file.
- Stop the WebSphere Portal Server.
- Make a backup copy of...
portal_server_root/wmm/wmm.xmlThe Member Manager configuration files within a clustered environment are moved from...
portal_server_root/wmm/..to...
was_profile_root/config/wmm directory...via a configuration task that uploads and replicates them to all the cluster nodes.
- Edit wmm.xml and set...
horizontalPartitioning=true...to enable the multiple realms feature...
<wmm name=member manager description=member manager defaultRealmName=portal horizontalPartitioning=true- Edit wmm.xml and add the stanza below...
Set values for...
- databaseType
- dataSourceName
- dataAccessManagerClassName
...appropriate for the database you are using for WMM.
name Name of the repository. Default name is wmmDBFederation. UUID Universal unique identifier of the repository. Must be unique in wmm.xml. supportTransactions Whether or not the repository supports transactions. Should be set to true for Federation Repository. adapterClassName Implementation class name of the repository adapter. Use... com.ibm.ws.wmm.db.DataBaseFederationAdapterdataSourceName JNDI name of the data source which points to the Member Manager database. The default is... jdbc/wmmDSIf you are using a different name, then update this attribute.
We can confirm the datasource name for WMM by looking at the JDBC providers section in the WAS Administration console.
databaseType Database type of the Member Manager database. Here is an Federation Repository configuration for Oracle example.
<federationRepository name=wmmDBFederation UUID=DB1 supportTransactions=true adapterClassName=com.ibm.ws.wmm.db.DataBaseFederationAdapter dataSourceName=wpdbDS_wmm databaseType=oracle dataAccessManagerClassName=com.ibm.ws.wmm.db.dao.oracle.WMMOracleDao/>Database types for the Member Manager database include...
Database databaseType dataAccessManagerClassName DB2 db2 com.ibm.ws.wmm.db.dao.db2.WMMDB2Dao Cloudscape cloudscape com.ibm.ws.wmm.db.dao.cloudscape.WMMClou dscapeDao Oracle oracle com.ibm.ws.wmm.db.dao.oracle.WMMOracleDao Microsoft SQL Server 2000 sqlserver com.ibm.ws.wmm.db.dao.sqlserver.WMMSQLSe rverDao DB2 on ZOS db2_zos com.ibm.ws.wmm.db.dao.db2zos.WMMDB2ZOS Dao DB2 on iSeries db2_iseries com.ibm.ws.wmm.db.dao.db2iseries.WMMDB2iS eriesDao - Add an additional <ldapRepository> section to wmm.xml.
- Select the existing section that starts with <ldapRepository> and ends with </ldapRepository> and choose...
File | CopyPlace the cursor in a new line just below the end of the existing </ldapRepository> entry and choose...
File | Paste- Edit the section you just pasted with values for the additional LDAP directory. Here are example settings for the second, Domino LDAP directory...
<ldapRepository name=wmmLDAP UUID=LDAP2 adapterClassName=com.ibm.ws.wmm.ldap.domino.Domino6LdapAdapterImpl supportDynamicAttributes=false configurationFile=wmmLDAPAttributes_DM.xml wmmGenerateExtId=false supportGetPersonByAccountName=true profileRepositoryForGroups=LDAP2 supportTransactions=false adminId=cn=LDAP Admin,o=ibm adminPassword=password ldapHost=dbdom7.cam.itso.ibm.comldapPort=389 ldapTimeOut=6000 ldapAuthentication=SIMPLE ldapType=0 sslEnabled=false sslTrustStore=C:\IBM\AppServer\etc\DummyServerTrustFile.jks dirContextsMaxSize=20 dirContextsMinSize=5 dirContextTimeToLive=-1 cacheGroups=false groupsCacheTimeOut=600 cacheAttributes=true attributesCacheSize=2000 attributesCacheTimeOut=600 cacheNames=true namesCacheSize=2000 namesCacheTimeOut=600>
- Add an additional <ldapRepository> section for each additional LDAP directory you wish to user with WebSphere Portal Server.
The configurationFile property specifies the config file that defines the attribute names and object classes for the additional LDAP repository we are adding. In our example, it is set to...
wmmLDAPAttributes_DM.xml....and can be found in...
portal_server_root/wmm/Values to update in wmm.xml for an additional LDAP directory
Attribute Value UUID Universal unique identifier of the repository. We can use any name as long as it is different from other repository's UUIDs. In the case as the primary LDAP directory was "LDAP1" you added the additional LDAP directory as "LDAP2"
adapterClassName Implementation class name of the repository adapter configurationFile Relative or absolute path to the Member Manager LDAP attributes XML file. Member Manager comes with the template files for different LDAP directory servers profileRepositoryForGroups UUIDs of the repositories which can contain members in this repository. Usually, this attribute includes the UUID of this repository itself. Multiple UUIDs should be separated by semi colon ;. adminID DN of the LDAP administrator which will be used to create the LDAP connection. This LDAP administrator should have enough access rights to perform defined operations. XML attribute name Value adminPassword Password of the LDAP administrator. Although clear text password is accepted, it is highly recommended that the password should be encrypted for security reason. From a command prompt, run the following task: WPSconfig.{sh|bat} wmm-encrypt -DPassword=passwordUpon completion, examine the task output. Success is indicated with BUILD SUCCESSFUL and the encrypted password.
ldaphost Host name or IP address of the LDAP server. Values for the adapterclassname...
LDAP Server Type adapterClassName IBM Directory Server com.ibm.ws.wmm.ldap.ibmdir.IBMDirectoryAdapterImpl Active Directory Server 2000 com.ibm.ws.wmm.ldap.activedir.ActiveDirectoryAdapterImpl Active Directory Server 2003 com.ibm.ws.wmm.ldap.activedir.ActiveDirectory2003AdapterImpl Domino Directory Server com.ibm.ws.wmm.ldap.domino.Domino6LdapAdapterImpl Novell eDirectory Server com.ibm.ws.wmm.ldap.novell.NovelleDirectoryAdapterImpl SUN One Directory Server com.ibm.ws.wmm.ldap.sunone.SunOneDirectoryAdapterImpl Sample wmm.xml files for different LDAP directory combinations...
Sample wmm file Description wmm_LDAP_IDS_AD IBM Tivoli Directory Server and Active Directory wmm_LDAP_LA_AD Active Directory with Lookaside wmm_LDAP_LA_DM Lotus Domino with Lookaside wmm_LDAP_LA_IDS IBM Tivoli Directory Server with Lookaside wmm_LDAP_LA_IDS_DM IBM Tivoli Directory Server and Lotus Domino with Lookaside wmm_LDAP_LA_NDS Novell NDS with Lookaside wmm_LDAP_LA_SO Sun One Directory Server with Lookaside - Edit the node maps configuration in wmm.xml.
For Member Manager database repository, the member node and repository node are always the same. There is a default node map which maps Member Manager node...
o=Default Organization...to Member Manager Database repository node...
o=DefaultFor the additional LDAP directories, specify that all users and groups exist under...
o=ibmExample node maps configuration for Domino LDAP...
<nodeMaps> <nodeMap node=o=ibm pluginNode=o=ibm/> </nodeMaps>- Configure LDAP supported entry types for the additional LDAP directory.
Locate the <supportedLdapEntryTypes> tag within the <ldapRepository> section for the additional LDAP directory in the section you previously copy and pasted and edit the XML attributes with the correct values for the specific LDAP directory.
This example configures supported entry types for an additional Domino LDAP directory...
<supportedLdapEntryTypes> <supportedLdapEntryType name=Person rdnAttrTypes=cn objectClassesForRead=inetOrgPerson objectClassesForWrite=inetOrgPerson searchBases=o=ibm/> <supportedLdapEntryType name=Group rdnAttrTypes=cn objectClassesForRead=groupOfNames;dominoGroup objectClassesForWrite=groupOfNames;dominoGroup searchBases=o=ibm/> <supportedLdapEntryType name=Organization rdnAttrTypes=o objectClassesForRead=organization objectClassesForWrite=organization/> <supportedLdapEntryType name=OrganizationalUnit rdnAttrTypes=ou objectClassesForRead=organizationalUnit objectClassesForWrite=organizationalUnit/> </supportedLdapEntryTypes>Use an LDAP browser type of tool to help you find the correct attribute and object class names for the particular LDAP directory. Alternatively we can look at the sample file...
wmmLDAPAttributes_XXX.xml...that corresponds to the particular LDAP directory.
- Save wmm.xml.
Open wmm.xml with a browser to see if you have made any typing or formatting errors. If there are no problems you should see the contents of the file. If you have made a typing or formatting error (e.g. missed a bracket) then you should see an error in the browser.
- Backup then check the appropriate wmmLDAPAttributes_XXX.xml and edit it if necessary.
For every supported LDAP Directory type there is a corresponding wwmLDAPAttributes template file that may need to be edited. These template files are located in...
WP_HOME/wmmAs the second LDAP server was a Domino LDAP directory, you used wmmLDAPAttributes_DM.xml, however all the information regarding Domino LDAP attributes in the file was correct for Domino and so no changes were required.
This is not the case for all LDAP directories. For example, in earlier testing with IBM Tivoli Directory Server as an additional LDAP directory, we found that you had to edit the corresponding wmmLDAPAttributes_IDS.xml file because some of the attribute names contained in it were incorrect.
Specifically, for the wmmAttributeName="groupMember" stanza, under the pluginAttributeName entry, you had to change the value from "member" to"uniqueMember"
If you end up having to edit the file that corresponds to the LDAP directory, ensure that you edit the correct one, however prior to editing the attributes file, make sure you create a backup copy of it.
Member Manager LDAP attribute files
LDAP Directory Server Template file IBM Tivoli Directory Server wmmLDAPAttributes_IDS.xml Active Directory wmmLDAPAttributes_AD.xml Domino wmmLDAPAttributes_DM.xml Novell eDirectory wmmLDAPAttributes_NDS.xml SUN One wmmLDAPAttributes_SO.xml - Save the wmmLDAPAttributes_XXX.xml file if you made any changes.
- Make a backup copy of...
WP_HOME/wmm/wmmur.xmlThis file contains the suffixes for users and groups and the realm mappings to the different LDAP directories that you previously defined in wmm.xml.
- Edit wmmur.xml and define which nodes will map to which realms.
In this scenario we have three realms...
portal Maps to the IBM Tivoli Directory Server. employees Maps to the IBM Tivoli Directory Server customers Maps to the Domino 7.0.2 LDAP server Add a second <node> definition tag to wmmur.xml for the Base DN of the additional LDAP directory to the default "portal" realm.
- Add any additional realms in wmmur.xml. Example 4-13 shows the two additional realms you added to wmmur.xml.
– The realm "customer" maps to the Domino LDAP directory and you mapped the node mapped to the suffix of the Domino LDAP directory (O=ibm).
Notice that you did not specify a suffix for where the Domino groups are located. This is because Domino LDAP does not have a group suffix &groups"
–The realm "employees" maps to the IBM Tivoli Directory Server and you chose to map the node to the suffix where the employee users and groups are located.
<realm id=portal delimiter=@ default=true> <node wmmnode=dc=ibm,dc=com/> <node wmmnode=o=ibm/> </realm> <realm id=customers delimiter=@ default=false> <node wmmnode=o=ibm/> </realm> <realm id=employees delimiter=@ default=false> <node wmmnode=cn=employees,dc=users,dc=ibm,dc=com/> </realm>- Save wmmur.xml
- Open wmmur.xml with a browser to see if you have made any typing or formatting errors.
If there are no problems you should see the contents of the file. If you have made a formatting error (e.g. missed a bracket) then you should see an error in the browser.
- Restart the WebSphere Portal Server.
You should now be able to log in with users from both the primary and secondary LDAP servers.
If you plan on creating users and groups via Portal, add defaultParent entries to wmmur.xml. This will allow WMM to know what suffixes to use when creating user and group objects in the LDAP directory.
Create two virtual portals to test multiple LDAP directories
As an additional test for the Multiple LDAP configuration, create two virtual portals...
- employees
- customers
Assign a group from the IBM Tivoli Directory Server to manage the employee virtual portal and a group from the Lotus Domino LDAP Directory to manage the customer virtual portal.
Create some content and customizations in each portal both as an employee and as a customer.
Ensure that when customers (Domino LDAP Directory) log in to the customer virtual portal they can only see the customer content and customizations and also when an employee logs in (IBM Tivoli Directory Server), that they can only see the employee content and customizations.
When you create realms and associate them with virtual portals, the administrator of the default Virtual Portal ("portal") can not log in to the other virtual portals.
We can get around this by adding a "super admin" to the other realms you specified previously in wmmur.xml.
Add the DN of the "super admin" ID to the realms that you want the "super admin" to be able to log in to (where the super admin is not already part of another wmmNode).
<realm id=employees delimiter=@ default=false> <node wmmnode=cn=employees,dc=users,dc=ibm,dc=com/> <node wmmnode=uid=wpsadmin,cn=users,cn=cambridge,dc=ibm,dc=com/> </realm>
Domino LDAP & groups
At present, Domino LDAP has a limitation when used in a multiple LDAP directory environment with WebSphere Portal Server.
Specifically, when Domino LDAP is an additional LDAP directory you will not be able to search for (or use) groups that are stored in the Domino Directory unless you specify a group suffix entry.
This is because groups in Domino LDAP exist under the Root DSE of the directory and are not part of the directory hierarchy (this is often referred to as "flat groups" or a "flat group directory naming structure").
If you specify a group suffix of some kind (as you did in Section 4.3.6, "Steps for adding an additional LDAP directory"), you will however not be able to search for (or use) any Domino groups within portal, because none exist in the directory hierarchy.
In the figure below we can see the Domino LDAP group "cn=wpsadmins" is located under the Root DSE rather than under the "o=ibm" organization suffix where all are user entries are located.
In the figure below we can see that under the Organizational Unit (o=ibm) there is no group container or groups.
This limitation (i.e. no group suffix in Domino LDAP), has been raised with Lotus Development and should hopefully be addressed in a future release of Domino.
The problem therefore arises because when specifying Domino LDAP in a multiple LDAP environment in wmm.xml you would have to specify a "null" value for the Domino group suffix.
In the example below we can see that when you configured Domino LDAP in a multiple LDAP directory environment, you specified a group suffix and search base for groups of "o=ibm", however as previously shown there is no group container or groups under "o=ibm".
<supportedLdapEntryTypes> <supportedLdapEntryType name=Person rdnAttrTypes=cn objectClassesForRead=inetOrgPerson objectClassesForWrite=inetOrgPerson searchBases=o=ibm/> <supportedLdapEntryType name=Group rdnAttrTypes=cn objectClassesForRead=groupOfNames objectClassesForWrite=groupOfNames searchBases=o=ibm/> <supportedLdapEntryType name=Organization rdnAttrTypes=o objectClassesForRead=organization objectClassesForWrite=organization/> <supportedLdapEntryType name=OrganizationalUnit rdnAttrTypes=ou objectClassesForRead=organizationalUnit objectClassesForWrite=organizationalUnit/> </supportedLdapEntryTypes>
Possible workarounds
To overcome the current limitation of not having a container for groups in the Domino LDAP directory, there are a number of possible workarounds:
- Edit the Domino groups to make them hierarchal (i.e. change them so that they now reside in the directory hierarchy).
This is what you did in the lab testing. Created a group in the Domino LDAP directory called "DominoPortalUsers" and edited its name to include a "/ibm"
This resulted in the group having a DN of "cn=DominoPortalUsers, o=ibm" and therefore being part of the directory hierarchy and thus accessible to WebSphere Portal Server.
Although editing the Domino group in this way was fine in a lab environment, you will probably find it is not a practical alternative in any reasonably sized production Domino environment.
This is because groups in Domino are used for mail addressing, access control, security and in agents and Lotusscript code, and modifying them in this way (even via an automated process) may result in unforeseen problems with Domino security, mail and applications.
Editing groups in this way is also not supported so therefore this workaround is not recommended for a production environment.
- Create a secondary Domino Directory containing modified groups and make it accessible to portal via Domino’s Directory Assistance feature.
Domino has the capability to use multiple Domino and LDAP directories through a feature known as "Directory Assistance".
It should therefore be possible to create a new additional Domino Directory and populate it with the Domino groups and then modify the groups to make them hierarchical
The modification of these groups and any subsequent update, additions and deletions could also be automated via a LotusScript agent), or these groups could simply be dedicated to portal and managed independently of the primary Domino Directory.
While there is some administrative overhead with this workaround it does ensure that the Domino environment is not impacted in anyway.
It should be technically possible to modify the Domino LDAP schema to include a new "group hierarchical name" attribute in the group object class. This is not a trivial task and should not be undertaken lightly. Also, as with option 1. it is not supported so any such modification would be at your own risk and may result in unforeseen problems.
Use a product such as IBM Tivoli Directory Integrator to consolidate the Domino groups in a virtual directory accessible to portal.
Enable multiple LDAP directories in a cluster
The steps for configuring multiple LDAP directories in a clustered environment are essentially the same as those above, however there is one key difference that needs to be taken in to consideration.
In a clustered environment, Member Manager files are not located in...
portal_server_root/wmmThey are actually moved to...
<was_profile_root>/config/wmm...when the security configuration task runs, and are then subsequently uploaded to the Deployment Manager which in turn replicates them to all other cluster nodes.
To manually edit the Member Manager files to configure multiple LDAP directories...
- Shut down the Deployment Manager
- Edit the relevant wmm files located in
<was_profile_root>/config/wmm...on the Deployment Manager
- Restart the Deployment Manager and carry out a full re-synchronization with all the cluster nodes.
If wmm.xml references any files that are not in the following list, ensure that you copy the referenced files manually to the Deployment Manager and to each node in the cluster.
For example, if you copied the wmmLDAPAttributes_DM.xml to the Deployment Manager and cluster nodes.
- wmm.xml
- wmmAttributes.dtd
- wmmAttributes.xml
- wmmAttributesDescription.xml
- wmmAttributesMap.dtd
- wmmDBAttributes.xml
- wmmDBAttributesDescription.xml
- wmmLAAttributes.xml
- wmmLDAPAttributes.xml
- wmmLDAPServerAttributes.xml
- wmmur.xml
- wmmWASAdmin.xml
In this section we edited the WMM files. Note that IBM recommends that you do not edit these files directly, but rather leave the Deployment Manager running and "check out" the wmm files from the Deployment Manager configuration repository before you make any changes to them.
We can do this by running the following...
cd portal_server_root/config
./WPSconfig.sh check-out-wmm-cfg-files-from-dmgrOnce checked out, we can then edit the files
The files can then be "checked in" to the Deployment Manager configuration repository by running the following command from...
cd portal_server_root/config
./WPSconfig.sh check-in-wmm-cfg-files-to-dmgrRemember to also carry out a full re-synchronization with all the cluster nodes after you have made the necessary changes.
