Member Manager LDAP repository configuration

 

+
Search Tips   |   Advanced Search

 

Following is a sample Member Manager LDAP repository configuration in wmm.xml. 

   
      <repositories>

      <federationRepository           
         name="wmmDBFederation"
         UUID="DB1"
         supportTransactions="true"
         adapterClassName="com.ibm.ws.wmm.db.DataBaseFederationAdapter"
         dataSourceName="jdbc/wpsdbDS"
         databaseType="dbtype"
         dataAccessManagerClassName="com.ibm.ws.wmm.db.dao.dbtype.WMMdbtypeDao"/>

      <ldapRepository 
         name="wmmLDAP"
         UUID="LDAP1"
         adapterClassName="com.ibm.ws.wmm.ldap.activedir.ActiveDirectoryAdapterImpl"
         ldapType="0"
         configurationFile="xml/wmmLDAPAttributes.xml"
         wmmGenerateExtId="false"
         supportDynamicAttributes="false"
         supportGetPersonByAccountName="true"
         supportTransactions="false"
         ldapTimeOut="6000"
         ldapHost="ldapserver.yourco.com"
         adminId="CN=ldapadmin,CN=users,DC=yourco,DC=com"
         adminPassword="XXXXXX"
         ldapPort="636"
         ldapAuthentication="SIMPLE"
         sslEnabled="true"
         sslTrustStore="C:\WebSphere\Appserver\etc\DummyServerTrustFile.jks"
         cacheGroups="false"
         groupsCacheTimeOut (groupCacheRefreshInterval)="600"
         groupsCacheSize="10000"
         cacheAttributes="true"
         attributesCacheSize="2000"
         attributesCacheTimeOut="600"
         attribtueSizeCacheLimit="1000"
         cacheNames="true"
         namesCacheSize="2000"
         namesCacheTimeOut="600"
         searchResultCacheLimit="1000"
         cachesDiskOffLoad="false"
         groupMemberAttributeMap="group:member;groupOfNames:member:groupOfUnqiueNames:uniqueMember"
         groupDynamicMemberAttributeMap="groupOfURLs:memberURL"
         groupMembershipAttributeMap="memberOf"
         profileRepositoryForGroups="LDAP1"
         dirContextsMaxSize="10"
         dirContextsMinSize="5"
         dirContextTimeout="3000"
         dirContextTimeToLive="600"
         translateRDN="false"
         objectClassesNotForUpdate="groupOfNames"
         
         <readMemberType>
            <memberType name="Person" /> 
            <memberType name="Group" /> 
            <memberType name="Organization" />
            <memberType name="OrganizationalUnit" />
         <createMemberType>
            <memberType name="Person" /> 
            <memberType name="Group" /> 
            <memberType name="Organization" />
            <memberType name="OrganizationalUnit" />
         </createMemberType>
         <updateMemberType>
            <memberType name="Person" /> 
            <memberType name="Group" /> 
            <memberType name="Organization" />
            <memberType name="OrganizationalUnit" />
         </updateMemberType>
         <deleteMemberType>
            <memberType name="Person" /> 
            <memberType name="Group" /> 
            <memberType name="Organization" />
            <memberType name="OrganizationalUnit" />
         </deleteMemberType>
         <renameMemberType>
            <memberType name="Person" /> 
            <memberType name="Group" /> 
            <memberType name="Organization" />
            <memberType name="OrganizationalUnit" />
         </renameMemberType>
         <moveMemberType>
            <memberType name="Person" /> 
            <memberType name="Group" /> 
            <memberType name="Organization" />
            <memberType name="OrganizationalUnit" />
         </moveMemberType>
         <nodeMaps>
            <nodeMap node="dc=yourco,dc=com" />
            <nodeMap node="cn=users,dc=yourco,dc=com" />
            <nodeMap node="cn=groups,dc=yourco,dc=com" />
         </nodeMaps>
         <supportedLdapEntryTypes>
            <supportedLdapEntryType name="Person"
               rdnAttrTypes="cn"
               objectClassesForRead="person"
               objectClassesForWrite="person"
               searchBases="cn=users,dc=yourco,dc=com"
               searchFilter="(ObjectCategory=Person)"/>
            <supportedLdapEntryType name="Group"
            rdnAttrTypes="cn"
               objectClassesForRead="group"
               objectClassesForWrite="group"
               searchBases="cn=groups,dc=yourco,dc=com"
               searchFilter="(ObjectCategory=Group)"/>
            <supportedLdapEntryType name="Organization"
            rdnAttrTypes="o"
               objectClassesForRead="organization"
               objectClassesForWrite="organization "/>
            <supportedLdapEntryType name="OrganizationalUnit"
            rdnAttrTypes="ou"
               objectClassesForRead="organizationalUnit"
               objectClassesForWrite="organizationalUnit "/>
            </supportedLdapEntryTypes>
         </ldapRepository>
   </repositories>

Following are detail description of all attributes in the Member Manager LDAP repository:

 

Member Manager LDAP Repository configuration attributes

 

name

The name of the repository. For Member Manager LDAP repository, the default name is wmmLDAP.

 

UUID

The universal unique identifier of the repository. We can use any name as long as it is different from other repository's UUIDs in wmm.xml.

 

adapterClassName

The implementation class name of the repository adapter.

For Member Manager LDAP repository, the adapter classes for different LDAP server are listed in the following table:

LDAP Server Type Adapter Class
IBM Directory Server com.ibm.ws.wmm.ldap.ibmdir.IBM DirectoryAdapterImpl
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

 

ldapType

Reserved for IBM internal use.

 

configurationFile

The relative or absolute path to the Member Manager LDAP attributes XML file.

Member Manager comes with the following template files for different LDAP servers.

LDAP Server Type Member Manager LDAP attributes XML file name
IBM Directory Server wmmLDAPAttributes_IDS.xml
Active Directory wmmLDAPAttributes_AD.xml
Domino wmmLDAPAttributes_DM.xml
Novell eDirectory wmmLDAPAttributes_NDS.xml
SUN One wmmLDAPAttributes_SO.xml

The default location of these files in under...

portal_server_root\wmm\

The default value for this attribute is wmm/wmmLDAPAttributes_XXX.xml.

If this is a clustered environment, the default location is...

WebSphere\AppServer\profiles\profile\config\wmm\

We can also use an absolute path like...

C:\WebSphere\Portal\wmm\wmmLDAPServerAttributes.xml

 

wmmGenerateExtId

Define whether or not the repository needs Member Manager to generate an external identifier.

If you map extId to... set wmmGenerateExtId to...
Unique id attribute generated by LDAP server false
Unique id attribute ibm-appUUID true
Distinguished Name of the member false

If you map external identifier to a unique attribute which is automatically populated by the LDAP server (first way) or map to DN (third way), we need to set...

wmmGenerateExtId

...to false. If you map external identifier to the attribute...

ibm-appUUID

...and need Member Manager to generate the value for this attribute, we need set...

wmmGenerateExtId

...to true (second way).

 

supportDynamicAttributes

Defines whether or not support dynamic attributes. "true" means the repository allows the caller to dynamically create new attributes through createAttributeDefinition API.

For Member Manager LDAP repository, this parameter should be set to "false" since Member Manager LDAP repository does not support this feature.

 

supportGetPersonByAccountName

Defines whether or not the getPersonByAccountName API is supported for the repository.

Member Manager LDAP repository supports this API. So this value is should be set to "true".

 

supportTransactions

Defines whether or not the repository supports transaction.

For Member Manager LDAP repository, this value should be set to "false" since Member Manager LDAP repository does not support transaction.

 

ldapTimeOut

The time limit for LDAP search in milliseconds. If the value is 0, this means to wait forever.

The parameter is overwritten by the searchTimeOut parameter in search API.

 

ldapHost

The host name or IP address of the LDAP server.

 

adminId

The Distinguished Name (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.

 

adminPassword

The 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=password

Upon completion, examine the task output. Success is indicated with "BUILD SUCCESSFUL" and the encrypted password.

 

ldapPort

The LDAP port of the LDAP server.

For non-SSL connection, the default port is 389; For SSL connection, the default port is 636.

 

ldapAuthentication

A string specifying the type of authentication to use; either none, simple, strong, or a provider-specific string. This attribute is used by Member Manager to set the value of JNDI environment...

java.naming.security.authentication

 

sslEnabled

Set to true to enable SSL. If this parameter is set to false or not presented, SSL is not enabled.

If this parameter is true, a JNDI environment property...

java.naming.security.protocol=ssl

...is added to the environment properties which Member Manager uses for creating LDAP connection.

java.naming.security.protocol="ssl"

...continues to work.

 

sslTrustStore

Absolute path to the truststore used for storing the LDAP server certificate.

Member Manager will set a system property...

javax.net.ssl.trustStore

...to the value of this parameter.

If this parameter is not defined, the default truststore...

<java-home>/lib/security/cacerts

...will be used.

 

cacheGroups

This parameter is mandatory to enable Groups Cache. "true" means the Groups Cache is enabled. "false" or not present means Groups Cache is disabled.

Since Groups Cache needs to cache all groups in Member Manager scope, it may cause memory problem if there are large amount of groups. If there are more than 5000 groups in Member Manager scope, IBM recommends that Groups Cache should be disabled.

 

groupsCacheTimeOut (groupCacheRefreshInterval)

Specifies how frequently the Groups Cache should be refreshed. Unit is second. This parameter is formerly called groupCacheRefreshInterval.

This parameter is optional. If this parameter is not specified, the default value is 600 seconds.

"-1" means Group Caches will not refreshed until there are changes made to groups through Member Manager.

 

groupsCacheSize

Defines the maximum size for the Groups Cache. This parameter is optional. If this parameter is not present, default value is 10000.

Usually the customer does not need to add this parameter because the default value should satisfy the needs of most customers. Only when there are more than 10000 groups under the Member Manager scope on LDAP server, we need to set the groupsCacheSize to a value larger than the total number of groups on LDAP server.

 

cacheAttributes

This parameter is mandatory to enable Attributes Cache. "true" or not present means the Attributes Cache is enabled. "false" means Attributes Cache is disabled.

 

attributesCacheSize

attributesCacheSize is mandatory to enable Attributes Cache.

Used for specifying the maximum size of Attributes Cache (the number of cached entries can be put into Attributes Cache).

 

attributesCacheTimeOut

attributesCacheTimeOut specifies how long the cached entries can stay in the Attributes Cache before being invalidated. Unit is Second.

This parameter is optional. If this parameter is not present, default value is 600.

 

attribtueSizeCacheLimit

Specifies the maximum size of an attribute which can be cached in the Attributes Cache. If not present, default value is 1000.

Some attributes like "member" usually contain large amount of values. Used for preventing Member Manager to cache such large attribute.

0 means no attributes will be cached.

-1 means all attributes will be cached.

 

cacheNames

This parameter is mandatory to enable Names Cache. "true" or not present means the Names Cache is enabled. "false" means Names Cache is disabled.

 

namesCacheSize

namesCacheSize is mandatory to enable Names Cache.

Used for specifying the maximum size of Names Cache (the number of cached entries can be put into Names Cache).

 

namesCacheTimeOut

namesCacheTimeOut specifies how long the cached entries can stay in the Names Cache before being invalidated. Unit is Second.

This parameter is optional. If this parameter is not present, default value is 600.

 

searchResultCacheLimit

searchResultCacheLimit defines the maximum size of a search result which can be cached in Names Cache. If number of entries contained in a search result is larger than this limit, this search result will not be cached in order to reduce the usage of memory.

Default value is 1000.

0 means no search result will be cached.

-1 means all search results will be cached.

 

cachesDiskOffLoad

Whether or not enable off-loading the caches into hard disk. This parameter affects both Groups Cache, Attributes Cache and Names Cache.

By default, when the number of cache entries reaches the maximum size of the cache, eviction of cache entries occurs, allowing new entries to enter the caches. If cachesDiskOffLoad is enabled, the evicted cache entries will be copied to disk for potential future access.

 

groupMemberAttributeMap

Different types of LDAP groups can be supported at the same time. In order to do that, we need to add a new attribute called groupMemberAttributeMap to ldapRepository tag in wmm.xml.

The format of this attribute is...

groupMemberAttributeMap=<object class1>:<member attribute>:<scope>;<object class2>:<member attribute>:<scope>...

 

groupDynamicMemberAttributeMap

Member Manager also supports different types of dynamic groups at the same time. To do this, we need to add the groupDynamicMemberAttributeMap attribute.

The format of this attribute is: groupDynamicMemberAttributeMap=<dynamic group object class 1>:<dynamic member attribute1>;<dynamic group object class 2>:<dynamic member attribute 2>

 

groupMembershipAttributeMap

Many LDAP servers support MemberOf attribute (also called group membership attribute). For every entry on LDAP server, there is an operational attribute which stores the groups this entry belongs to.

For Active Directory, the attribute is called memberOf.

the groupMembershipAttributeMap parameter, we cannot only specify the name of the membership attribute, but also the scope of the membership attribute.

The format of this attribute is...

groupMembershipAttributeMap=<group membership attribute name>:<scope>

 

profileRepositoryForGroups

Defines the 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 ";".

For Member Manager LDAP repository, if the configuration is LDAP only or LDAP + LookAside (LA), this attribute should be only set to the UUID of itself (Member Manager LDAP repository).

If the configuration is DB+LDAP or DB+LDAP+LA, then this attribute can be set to the UUID of Member Manager LDAP repository and Member Manager DB repository. For example, "LDAP1; DB1". This setting means the member on Member Manager LDAP repository can be assigned to groups on both Member Manager LDAP repository and Member Manager database repository.

 

dirContextsMaxSize

Defines the maximum number of live connections. The parameter is mandatory for enabling the pool. If this parameter is not specified or specified a value less or equal to 0, the pool is disabled. In these cases, Member Manager will work like before (only reuse one connection).

When there is no available connection in the pool when request is submitted, the request will wait the number of milliseconds specified in dirContextTimeout. After this time has passed, if there is still no connection available and the current number of live connections is less than the dirContextsMaxSize, a new connection will be created. If the total number of live connections is equal to or larger than dirContextsMaxSize, an exception will be thrown.

 

dirContextsMinSize

Minimum number of live connections. When pool is initialized, this number of connections will be created. The number of live connections will change between the dirContextsMinSize and dirContextsMaxSize depending on the number of concurrent requests.

Must be larger than 0. Default value is 1. In most cases should not be larger than 10.

 

dirContextTimeout

The number of milliseconds a request has to wait before throwing an exception if there are no available connection in the pool and the number of current connections reaches the dirContextTimeout.

0 means the waiting time is forever. Default value is 3000.

 

dirContextTimeToLive

The number of seconds a connection in the connection pool can live. When request a connection from the pool, if this connection already exists in the pool for more than the time defined by dirContextTimeToLive, this connection will be closed no matter this connection is stale or active. A new connection will be created and put back to the pool after it has been used.

Value 0 means a new connection will be created for each request. No connection will be put into the pool and reused.

Value -1 or any negative number means the connection will be reused forever, until the connection is stale.

If dirContextTimeToLive is not present, the default value is -1.

 

translateRDN

Defines whether or not translate the RDN between Member Manager RDN and LDAP RDN when they are different. "true" means Member Manager will translate the RDN when Member Manager RDN is different from LDAP RDN; "false" means Member Manager will not translate.

For example, if Member Manager RDN is defined as uid for member type Person, but the LDAP RDN is defined as cn. To translate the RDN, we need to set this to "true". However there is some performance impact.

IBM recommends that to keep the Member Manager RDN and LDAP RDN same so that this parameter can be set to false.

 

objectClassesNotForUpdate

This attribute specifies object classes you don't want to add to the existing members if they do not have such object classes.

The object classes specified in objectClassesForRead attribute are used to determine if a LDAP entry belongs to this member type. In the following example, if a LDAP entry's object class attribute contains either groupOfNames or groupOfURLs, this entry is considered as a Group member type in Member Manager. 

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

If there is no objectClassesNotForUpdate is specified, when you get a member which does not contain all object classes for read, Member Manager will update the object class attribute of this member to include the rest. For example, when you get a group which object class is groupOfURLs, Member Manager will add groupOfNames to the object class of this group. Sometimes this is not wanted. To prevent the updating from happening, we can add the groupOfNames to the objectClassesNotForUpdate attribute: objectClassesNotForUpdate="groupOfNames".

 

Additional JNDI Environment Properties

We can put additional JNDI environment Properties for the LDAP connection. These properties have higher priority than the fixed attributes. For example, we can add java.naming.security.authentication JNDI environment property to overwrite the ldapAuthentication attribute.

Following is a example on how to add additional JNDI environment property java.naming.provider.protocal.url to enable support LDAP failover: 

<ldapRepository name="wmmLDAP"
      UUID="LDAP1"
      adapterClassName="com.ibm.ws.wmm.ldap.novell.NovelleDirectoryAdapterImpl"
      supportDynamicAttributes="false"
      configurationFile="wmm/xml/wmmLDAPAttributes_NDS.xml"
      wmmGenerateExtId="true"
      supportGetPersonByAccountName="true"
      profileRepositoryForGroups="LDAP1;DB1"
      supportTransactions="false"
      adminId="cn=Admin,dc=com"
      adminPassword="EaDbPFdK9VAf0="
      ldapHost="ldapserver"
      ldapPort="636"
      ldapTimeOut="6000"
      ldapAuthentication="SIMPLE"
      ldapType="0"
      sslEnabled="true"
      java.naming.provider.url="ldap://ldapserver.youroc.com:636
ldap://backupserver.youroc.com:636"

 

readMemberType

Defines the member types supported in the read operation for the repository. Default, all four build-in member types are supported for Member Manager database repository. If you try to get a member whose member type is not supported, an exception will be thrown.

 

createMemberType

Defines the member types supported in the create operation for the repository. Default, all four build-in member types are supported for Member Manager database repository. If you try to create a member whose member type is not supported, an exception will be thrown.

 

updateMemberType

Defines the member types supported in the update operation for the repository. Default, all four build-in member types are supported for Member Manager database repository. If you try to update a member whose member type is not supported, an exception will be thrown.

 

deleteMemberType

Defines the member types supported in the delete operation for the repository. Default, all four build-in member types are supported for Member Manager database repository. If you try to delete a member whose member type is not supported, an exception will be thrown.

 

renameMemberType

Defines the member types supported in the rename operation for the repository. Default, all four build-in member types are supported for Member Manager database repository. If you try to rename a member whose member type is not supported, an exception will be thrown.

 

moveMemberType

Defines the member types supported in the move operation for the repository. Default, all four build-in member types are supported for Member Manager database repository. If you try to move a member whose member type is not supported, an exception will be thrown.

 

nodeMaps

Defines the maps between member nodes and repository nodes.

 

nodeMap

Defines a map between a member node and repository node. For Member Manager LDAP repository, the member node and repository node can be either the same or different.

For example, we can map "cn=user,dc=yourco,dc=com" to "cn=user,dc=yourco,dc=com".

<nodeMap node="cn=users,dc=yourco,dc=com" pluginNode="cn=users,dc=yourco,dc=com" />

We can also map "cn=user,dc=yourco,dc=com" to "ou=users,o=ibm,c=us". In this case, when you try to get a user with member DN "uid=andy,cn=users,dc=yourco,dc=com", Member Manager will convert the member DN to LDAP DN "uid=andy,out=users,ob=ibm,c=us".

<nodeMap node="cn=users,dc=yourco,dc=com" pluginNode="ou=users,o=ibm,c=us" />

When Member Manager performs search, Member Manager will search the plug-in nodes (LDAP nodes) one by one. To improve performance we can specify a "super" node, which contains other nodes. In this way, Member Manager will only search the "super" node instead of search it's children nodes one by one. For example, the following configuration defines a super node "dc=yourco,dc=com" with two children nodes "cn=users,dc=yourco,dc=com" and "cn=groups,dc=yourco,dc=com". Member Manager will only perform one LDAP search under "dc=yourco,dc=com" instead of performing two searches under "cn=users,dc=yourco,dc=com" and "cn=groups,dc=yourco,dc=com". 

<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

Defines LDAP related configuration for all supported member types.

 

supportedLdapEntryType

Defines LDAP related configuration for one member type.

 

name

The name of member type. Member Manager comes with four build-in member types: Person, Group, Organization, and OrganizationalUnit.

 

rdnAttrTypes

The name of the LDAP attribute which will be used as Relative Distinguished Name (RDN). For example, if you define uid as the rdnAttrTypes for Person, when you create a user with attribute...

uid=andy

...and parent as...

cn=users,dc=yourco,dc=com

...the uid attribute will be used to formulate the DN of the user:...

uid=andy,cn=users,dc=yourco,dc=com

In the same case, if you define cn as the rdnAttrTypes, the formulated DN will be like...

cn=Andy Zhuang,cn=users,dc=yourco,dc=com

Multiple attributes can be specified as rdnAttrTypes. They are separated using semicolon ";".

The following example show two attributes uid and email are used as rdnAttrTypes for Person member type. The formulated DN should be like...

uid=andy+email=andy@mail.com,cn=users,dc=yourco,dc=com 

<supportedLdapEntryType name="Person"
      rdnAttrTypes="uid;email"
      objectClassesForRead="inetOrgPerson"
      objectClassesForWrite="inetOrgPerson;ibm-appUUIDAux"/>

 

objectClassesForRead

The object classes specified in objectClassesForRead attribute are used to determine if a LDAP entry belongs to this member type. These object classes are separated by semicolon ";".

For example, in the following configuration, any LDAP entries will be thought as a Person in Member Manager as long as it contains either "inetOrgPerson" or "ePerson" in object class attribute. 

<supportedLdapEntryType name="Person"
rdnAttrTypes="uid"
objectClassesForRead="inetOrgPerson;ePerson"
objectClassesForWrite="groupOfNames;ibm-appUUIDAux"/>

 

objectClassesForWrite

The object classes specified in objectClassesForWrite attribute are used as the value of object class attribute when creating a new member on LDAP server.

In the following example, when you create a group, the object class of the LDAP entry created will contain both groupOfNames and ibm-appUUIDAux. 

<supportedLdapEntryType name="Person"
      rdnAttrTypes="uid"
      objectClassesForRead="inetOrgPerson"
      objectClassesForWrite="groupOfNames;ibm-appUUIDAux"/>

 

searchBases

Specify the search bases for this member type. Multiple search bases are separated by 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 will only search under the specified search bases when looking up for the members of this member type. If search bases are not specified, then Member Manager will search under the nodes defined in nodeMaps tag.

If this is a multiple virtual portal environment, the realm definition of the virtual portal overwrites the searchBase for the objectType. To keep virtual portals that do not have a realm assigned to them functional, keep the searchBase in sync with the nodes where you want the search to start.

Specifying search bases can improve performance. For example, if you are sure that all groups are under "cn=groups,dc=yourco,dc=com". We can specify "cn=groups,dc=yourco,dc=com" as the search base for Group member type: 

<supportedLdapEntryType name="Group"
      rdnAttrTypes="cn"
      objectClassesForRead="groupOfNames"
      objectClassesForWrite="groupOfNames"
      searchBases="cn=groups,dc=yourco,dc=com"/>

In this way, when Member Manager looks up for groups, it only search under "cn=groups,dc=yourco,dc=com" instead of "dc=yourco,dc=com".

 

searchFilter

By default, Member Manager will use the object class to formulate the search filter when doing search. For example, the following wmm.xml defines objectClassesForRead for 'Person' as 'user'. When search for all users, Member Manager will formulate the filter as...

(&(cn=*)(objectClass=user)) 

<supportedLdapEntryType name="Person"
      rdnAttrTypes="uid"
      objectClassesForRead="user"
      objectClassesForWrite="user"
      searchBases="cn=groups,dc=yourco,dc=com"/>

After adding a new parameter called searchFilter, customers can define any filter they want to do the search. In the following example, when search for all users, the search filter will become (&(cn=*)(objectCategory=Person).

 

Related information

 

Parent Topic

Using multiple realms and user registries