The LDAP/ADS User Manager connected to the Content Management Server can be configured by means of the following parameters:
host / portBy 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>protocolVersion
This parameter defines the version of the LDAP server (2 or 3). Example:
<protocolVersion>3</protocolVersion>secureConnection
The encryption type. One of the following values can be specified:
none
: no encryptionssl
: SSL encryptiontls
: TLS encryptionExample:
<secureConnection>none</secureConnection>bindDn / bindPassword
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>userSearchBase
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>groupSearchBase
Like userSearchBase
but referring to groups. Example:
<groupSearchBase>ou=groups,dc=company,dc=de</groupSearchBase>groupToUserRelationAttribute
The name of the LDAP attribute used to associate users with the groups of which they are members. Example:
<groupToUserRelationAttribute>uniqueMember</groupToUserRelationAttribute>userFilter
Using this parameter the users returned by the LDAP user manager can be filtered (restricted). Example:
<userFilter>(objectclass=inetOrgPerson)</userFilter>groupFilter
Analogous to userFilter
, this parameter allows to filter the user groups. Example:
<groupFilter>(objectclass=groupOfUniqueNames)</groupFilter>userResolver
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:
dnFormat
parameter.dnFormat
. The LDAP filter
specified by means of the userFilter
parameter is
therefore ignored.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.
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
.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>userAttributeMapping
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>groupAttributeMapping
The groupAttributeMapping
parameter refers to groups and
works analogously to userAttributeMapping
. Example:
<groupAttributeMapping> <name>cn</name> <realName>description</realName> </groupAttributeMapping>globalPermissionResolver
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>superUsers
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>memberValueIsLogin
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
.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>