Der an den Content Management Server angebundene LDAP/ADS-Benutzer-Manager kann mit den folgenden Parametern konfiguriert werden:
host / portMit diesen beiden Parametern werden der Hostname (oder die IP-Adresse) bzw. der Port angegeben, auf dem der LDAP/ADS Server läuft. Beispiel:
<host>ldap.server</host> <port>389</port>
protocolVersion
Dieser Parameter gibt die Version des LDAP-Servers (2 oder 3) an. Beispiel:
<protocolVersion>3</protocolVersion>
secureConnection
Die Art der Verschlüsselung. Die folgenden Werte sind zulässig:
none
: keine Verschlüsselungssl
: SSL Verschlüsselungtls
: TLS VerschlüsselungBeispiel:
<secureConnection>none</secureConnection>
bindDn / bindPassword
Die Anmeldedaten (DN und Passwort), mit denen sich der CM gegenüber dem LDAP-Server authentifiziert. Beispiel:
<bindDn>cn=administrator,cn=Users,dc=company,dc=de</bindDn> <bindPassword>password</bindPassword>
userSearchBase
Der top-level DN des Teilbaums in der LDAP-Verzeichnishierarchie, in dem die User abgelegt sind. Beispiel:
<userSearchBase>ou=people,dc=company,dc=de</userSearchBase>
groupSearchBase
Wie userSearchBase
, jedoch auf Gruppen bezogen. Beispiel:
<groupSearchBase>ou=groups,dc=company,dc=de</groupSearchBase>
groupToUserRelationAttribute
Der Name des LDAP-Attributs, über das die Benutzer einer Gruppe zugeordnet werden. Beispiel:
<groupToUserRelationAttribute>uniqueMember</groupToUserRelationAttribute>
userFilter
Mit diesem Parameter kann das Ergebnis der vom LDAP zurückgegebenen Benutzer gefiltert (eingeschränkt) werden. Beispiel:
<userFilter>(objectclass=inetOrgPerson)</userFilter>
groupFilter
Ermöglicht es, analog zu userFilter
, die Benutzergruppen einzuschränken. Beispiel:
<groupFilter>(objectclass=groupOfUniqueNames)</groupFilter>
userResolver
Hiermit kann die Methode spezifiziert werden, mit der die LDAP-Anfrage zur
Ermittlung der Benutzerdaten erstellt wird. Es werden zwei Methoden mitgeliefert, simple
und
lookup
.
simple
:
Bei dieser Methode werden die folgenden Annahmen gemacht:
dnFormat
angegebenen Format zusammengesetzt.dnFormat
eindeutig identifiziert werden. Der im Parameter
userFilter
angegebene LDAP-Filter wird daher nicht
angewandt.scope=base
)Beispiel:
<userResolver> <name>simple</name> <properties> <dnFormat>uid=%s,dc=company,dc=de</dnFormat> </properties> </userResolver>
In dem Format-String wird %s
durch das Login ersetzt,
um den DN zu erzeugen, der dann in die LDAP-Anfrage eingesetzt wird.
Unter der Annahme, dass das Login maria
ist, ergibt sich:
uid=maria,dc=company,dc=de (objectclass=*) ... -scope base
lookup
:
Dies ist der voreingestellte Wert des userResolvers, der darauf zugeschnitten ist, dass der Speicherort des DN im LDAP-Verzeichnisbaum von Benutzer zu Benutzer variieren kann.
userFilter
angegebenen Filtern wird
ein weiterer hinzugefügt, der das Login dem in idAttribute
angegebenen Attribut entnimmt. Daher muss als idAttribute
das LDAP-Attribut angegeben werden, in dem das Login gespeichert
ist.scope=subtree
) durchsucht.Beispiel:
<userResolver> <name>lookup</name> <properties> <idAttribute>uid</idAttribute> </properties> </userResolver>
Mit (objectclass=inetOrgPerson)
als
userFilter
und dc=company,dc=de
als
userSearchBase
wird für einen Benutzer mit dem Login
hermann
die folgende LDAP-Anfrage erstellt:
dc=company,dc=de (&(objectclass=inetOrgPerson)(uid=hermann)) ... -scope subtree
groupResolver
Dieser Parameter funktioniert analog zu userResolver
, bezogen auf Gruppen. Beispiel:
<groupResolver> <name>lookup</name> <properties> <idAttribute>cn</idAttribute> </properties> </groupResolver>
userAttributeMapping
Mit diesem Parameter können Benutzerfeldern im CMS die entsprechenden LDAP-Attriibute zugeordnet werden. Es sollte immer eine Zuordnung für login
geben. Beispiel:
<userAttributeMapping> <login>uid</login> <realName>description</realName> </userAttributeMapping>
groupAttributeMapping
Das groupAttributeMapping
funktioniert analog zu
userAttributeMapping
, bezogen auf Gruppen. Beispiel:
<groupAttributeMapping> <name>cn</name> <realName>description</realName> </groupAttributeMapping>
globalPermissionResolver
Dieser Parameter spezifiziert die Methode, mit der die globalen Rechte ermittelt werden. Siehe hierzu Abbildung globaler Rechte über Gruppen.
<globalPermissionResolver> <name>group</name> <properties> <groupNameFormat>admins_%s</groupNameFormat> </properties> </globalPermissionResolver>
superUsers
Mit diesem Parameter kann eine Liste von Logins angegeben werden, die im
CMS als superUser
(Admins) agieren dürfen. Beispiel:
<superUsers type="list"> <login>root</login> </superUsers>
memberValueIsLogin
Dieser Parameter spezifiziert, ob die Benutzer den Gruppen mit Hilfe von
groupToUserRelationAttribute
direkt über Ihr Login zugeordnet
sind oder nicht. Voreinstellung: false
. Beispiele:
member
: uid=tester,dc=company,dc=de
memberValueIsLogin
: false
.member
den DN enthält und nicht nur das Login.member
: tester
memberValueIsLogin
: true
, weil das Login
unmittelbar verwendet werden kann, um die Gruppenzugehörigkeit
festzustellen.Beispiel:
<memberValueIsLogin>false</memberValueIsLogin>