Portal Member Manager configuration
Overview
The WebSphere Portal user repository consists of one of three data sources:
- A database alone, which might be accessible only through a Custom Registry (DB only)
- An LDAP alone (LDAP only)
- A database (Lookaside repository) and an LDAP directory server (LDAP and Lookaside)
The data source name is contained in...
<wp_root>/shared/app/wmm/wmm.xmlIf LDAP is used, mapping of profile attributes to LDAP object classes and attributes is defined in...
wp_root/wmm/wmmLDAPAttributes_XXX.xmlFor example...
wp_root/wmm/wmmLDAPAttributes_AD.xmlHere is a template file that can be referenced...
wmmLDAPAttributes_ACTIVE_DIRECTORY.xmlThese files specify the names of the various repositories, their Member Manager adapter implementation classes, and the mapping between attributes in Member Manager and the repositories. By default, the user attributes mapping to the LDAP directory is based on the inetOrgPerson schema that is supported by most LDAP directories.
The following entries exist in the wmm.xml configuration file for Member Manager.
Do not change entries that are not documented in this chart.
Attribute Default Value wmm name member manager description member manager defaultRealmName wmmRealm horizontalPartitioning false lookAside false configurationFile <wp_root>/wmm/wmmAttributes.xml uniqueIdGeneratorClassName com.ibm.ws.wmm.uniqueid.WMMUniqueMemberIdentifierGenerator maximumSearchResults 200 searchTimeOut 12000 maximumSearchResultsForSortingAndPaging 1000 pagingMemberObject true timeToRemovePagedCacheEntry 900 databaseRepositoryName wmmDB UUID DB1 supportTransactions true wmmGenerateExtId true adapterClassName com.ibm.ws.wmm.db.DatabaseRepository supportDynamicAttributes true supportGetPersonByAccountName false profileRepositoryForGroups DB1 dataSourceName jdbc/wmmDS databaseType cloudscape dataAccessManagerClassName com.ibm.ws.wmm.db.dao.cloudscape.WMMCloudscapeDao saltLength 12 ldapRepositoryName wmmLDAP UUID LDAP1 adapterClassName com.ibm.ws.wmm.ldap.ibmdir.IBMDirectoryAdapterImpl supportDynamicAttributes false wmmGenerateExtId true supportGetPersonByAccountName true profileRepositoryForGroups LDAP1;DB1 supportTransactions false adminId an=root profileRepositoryForGroups LDAP1;DB1 adminPassword ****** (Do not use a clear text password here) ldapHost localhost ldapPort 389 ldapTimeOut 6000 ldapAuthentication SIMPLE ldapType 0 memberOfAttributeName memberOf groupCacheRefreshInterval -1 objectClassesNotForUpdate groupOfNames nodeMap node="cn=users,dc=yourco,dc=com" pluginNode cn=users,dc=yourco,dc=com nodeMap node="cn=groups,dc=yourco,dc=com" pluginNode cn=groups,dc=yourco,dc=com searchBases for supportedLdapEntryType name="Person" cn=users,dc=yourco,dc=com searchBases for supportedLdapEntryType name="Group" cn=groups,dc=yourco,dc=com Here are detailed descriptions of the attributes that are new in WebSphere Portal Version 5.0.
memberOfAttributeName
On some LDAP servers all entries have a special attribute that is used to store the groups this entry belongs to. This attribute can be used to improve performance when looking up groups that a member belongs to. This attribute specifies the name of the attribute used as memberOf Attribute. For Active Directory, the value should be set to memberOf. If this attribute is presented in wmm.xml, then Member Manager uses the memberOf attribute to look up group membership. If this attribute is not present, Member Manager uses the member or uniqueMember attribute to look up group membership. This attribute should be set only for Active Directory Server and IBM Directory Server.
groupCacheRefreshInterval
Member Manager caches the names of all groups. This caching improves performance when looking up group members. This attribute is used for specifying how often the group cache should be refreshed (how often all groups from the LDAP server should be read). The unit of this attribute is seconds. It can have the following values:
- 0: Group cache is always refreshed when there is a request for the group cache. This is the default setting if this attribute is not presented. This option has the lowest performance, but can ensure that the data in group cache is always the latest.
- <any negative number>: If the value is a negative number, the group cache will not refresh until the number of groups specified is created, renamed, or removed through Member Manager. This option has the highest performance. If a group is created, renamed, or removed directly from the LDAP server, the changes will not be reflected in the group cache until Member Manager is restarted. If the group is created, renamed, or removed through Member Manager, the group cache is refreshed. This option can be used for improved performance if there is no update on groups from the LDAP server side.
- <any positive number>: If the value is a positive number, the group cache is refreshed if this number of seconds has passed and there is a request for the group cache. The group cache is not refreshed if there is no request for the group cache, even if the time since the last refresh has exceeded the specified seconds. If a group is created, renamed, or removed through Member Manager, the group cache is refreshed. For example, if groupCacheRefreshInterval=600, then when a new group is created from the LDAP server, this new group might not be in the group cache in 10 minutes.
objectClassesNotForUpdate
This attribute specifies object classes that should not be added to existing members unless the members already have such object classes. The object classes that are specified in the objectClassesForRead attribute are used to determine if an LDAP entry belongs to this member type. In the following example, if an LDAP entry object class attribute contains either groupOfNames or groupOfURLs, this entry is considered as a Group member type in Member Manager.<supportedLdapEntryType name="Group" rdnAttrTypes="cn" objectClassesForRead="groupOfNames;groupOfURLs" objectClassesForWrite="groupOfNames;ibm-appUUIDAux"/>If there is no objectClassesNotForUpdate value specified, when you get a member that does not contain all object classes for read, Member Manager attempts to update the object class attribute of this member to include the rest. For example, when you get a group whose object class is groupOfURLs, Member Manager attempts to add groupOfNames to the object class of this group. Sometimes this is not wanted. To prevent the update, add groupOfNames to the objectClassesNotForUpdate attribute as follows: objectClassesNotForUpdate="groupOfNames". This should be set if there are multiple group object classes and you do not want Member Manager to normalize them so that all group objects have the union of all the object classes
searchBases
Specifies the search bases for the appropriate member type. Multiple search bases are separated by a semicolon (;). For example:searchBases="cn=users1,dc=yourco,dc=com;cn=users2,dc=yourco,dc=com"If search bases are specified for a member type, Member Manager searches only under the specified search bases when looking up members of this member type. If search bases are not specified, Member Manager searches under the nodes that are defined in the nodeMaps tag. Specifying search bases can improve performance. For example, if all groups are under cn=groups,dc=yourco,dc=com, you can specify cn=groups,dc=yourco,dc=com as the search base for the Group member type:<supportedLdapEntryType name="Group" rdnAttrTypes="cn" objectClassesForRead="groupOfNames" objectClassesForWrite="groupOfNames " searchBases="cn=groups,dc=yourco,dc=com"/>In this example, Member Manager searches for groups only under cn=groups,dc=yourco,dc=com instead of under dc=yourco,dc=com, which is specified in the nodeMaps tag.
For WebSphere Portal, the searchBases for the Person member type should be the same as the pluginNode in the second nodeMap. The searchBases for the Group member type should be the same as the pluginNode in the third nodeMap.
<nodeMaps> <nodeMap node="dc=yourco,dc=com" pluginNode="dc=yourco,dc=com" /> <nodeMap node="cn=users,dc=yourco,dc=com" pluginNode="cn=users,dc=yourco,dc=com" /> <nodeMap node="cn=groups,dc=yourco,dc=com" pluginNode="cn=groups,dc=yourco,dc=com" /> </nodeMaps> <supportedLdapEntryTypes> <supportedLdapEntryType name="Person" rdnAttrTypes="uid" objectClassesForRead="inetOrgPerson" objectClassesForWrite="inetOrgPerson" searchBases="cn=users,dc=yourco,dc=com"/> <supportedLdapEntryType name="Group" rdnAttrTypes="cn" objectClassesForRead="groupOfNames" objectClassesForWrite="groupOfNames" searchBases="cn=groups,dc=yourco,dc=com"/>
Changing Member Manager password
During installation, WebSphere Portal generates the configuration parameters for Member Manager and stores them in <wp_root>/shared/app/wmm/wmm.xml. You can manually edit this file to modify the initial configuration settings.
If you change the database password after installation, also update the data source configuration using WebSphere administrative console so that it can continue to access the user registry.
If you change the LDAP password after installation, also update the wmm.xml file with the encrypted password. For LDAP password change, generate an encrypted password and replace the encrypted passwords. See Changing Passwords for instructions.
See also
- Member Manager
- User registries
- Mapping LDAP attributes
- Increasing the connection pool size for Member Manager
- Changing passwords