Parameters of the LDAP/ADS User Manager Configuration

The LDAP/ADS User Manager connected to the Content Management Server can be configured by means of the following parameters:

By means of these two parameters, the host name (or the IP address) and the port, respectively, on which the LDAP/ADS server is running can be specified. Example:

<host>ldap.server</host>
<port>389</port>

This parameter defines the version of the LDAP server (2 or 3). Example:

<protocolVersion>3</protocolVersion>

The encryption type. One of the following values can be specified:

• none: no encryption
• ssl: SSL encryption
• tls: TLS encryption

Example:

<secureConnection>none</secureConnection>

The credentials (DN and password) the CM uses to identify itself to the LDAP server. Example:

<bindDn>cn=administrator,cn=Users,dc=company,dc=de</bindDn>
<bindPassword>password</bindPassword>

The top-level DN of the subtree in the LDAP directory hierarchy that contains the users. Example:

<userSearchBase>ou=people,dc=company,dc=de</userSearchBase>

Like userSearchBase but referring to groups. Example:

<groupSearchBase>ou=groups,dc=company,dc=de</groupSearchBase>

The name of the LDAP attribute used to associate users with the groups of which they are members. Example:

<groupToUserRelationAttribute>uniqueMember</groupToUserRelationAttribute>

Using this parameter the users returned by the LDAP user manager can be filtered (restricted). Example:

<userFilter>(objectclass=inetOrgPerson)</userFilter>

Analogous to userFilter, this parameter allows to filter the user groups. Example:

<groupFilter>(objectclass=groupOfUniqueNames)</groupFilter>

Allows to specify the method used to generate the LDAP query for determining the user data. Two methods are included in the CMS, simple and lookup.

• simple:

  If this method is used, the following assumptions are made:

  • The DN of all users has the same format throughout the LDAP directory. The DN is composed from the login and the format specified in the dnFormat parameter.
  • All logins in the LDAP directory can be identified uniquely by means of this dnFormat. The LDAP filter specified by means of the userFilter parameter is therefore ignored.
  • All users can be found in the specified LDAP directory entry (scope=base)

  Example:

  <userResolver>
    <name>simple</name>
    <properties>
      <dnFormat>uid=%s,dc=company,dc=de</dnFormat>
    </properties>
  </userResolver>

  In this format string, %s is replaced with the login to yield the DN which is then placed into the LDAP query. Assuming that the login is maria, the result would be:

  uid=maria,dc=company,dc=de (objectclass=*) ... -scope base

• lookup:

  This is the default value of the userResolver. In this mode it is assumed that the location of the DN in the LDAP directory tree may be different from user to user.

  • In addition to the filters specified userFilter another filter is added which reads the login from the attribute specified as idAttribute. Thus, it is required to define the LDAP login attribute by means of idAttribute.
  • The LDAP query will be generated so that all of the LDAP tree is searched (scope=subtree).

  Example:

  <userResolver>
    <name>lookup</name>
    <properties>
      <idAttribute>uid</idAttribute>
    </properties>
  </userResolver>

  With (objectclass=inetOrgPerson) as the userFilter and dc=company,dc=de as the userSearchBase, the following LDAP query is generated for the hermann user login:

  dc=company,dc=de (&(objectclass=inetOrgPerson)(uid=hermann)) ... -scope subtree

This parameter refers to groups and functions analogously to userResolver. Example:

<groupResolver>
  <name>lookup</name>
  <properties>
    <idAttribute>cn</idAttribute>
  </properties>
</groupResolver>

Using this parameter, user fields in the CMS can be mapped to the corresponding LDAP attriibutes. A mapping for login should always exist. Example:

<userAttributeMapping>
  <login>uid</login>
  <realName>description</realName>
</userAttributeMapping>

The groupAttributeMapping parameter refers to groups and works analogously to userAttributeMapping. Example:

<groupAttributeMapping>
  <name>cn</name>
  <realName>description</realName>
</groupAttributeMapping>

This parameter specifies the method with which the global permissions are determined. See Mapping Global Permissions to Groups.

<globalPermissionResolver>
  <name>group</name>
  <properties>
      <groupNameFormat>admins_%s</groupNameFormat>
  </properties>
</globalPermissionResolver>

This parameter serves to specify a list of users permitted to act as superUser in the CMS. Example:

<superUsers type="list">
  <login>root</login>
</superUsers>

This parameter specifies whether users-to-group assignments via the groupToUserRelationAttribute are made by means of the respective user's login or not. The default value is false. Examples:

• member: uid=tester,dc=company,dc=de
memberValueIsLogin: false.
  This has the effect that the value of the member attribute is assumed to contain the DN and not just the login.
• member: tester
memberValueIsLogin: true because the login is be used to determine group membership.

Example:

<memberValueIsLogin>false</memberValueIsLogin>