Parameter der LDAP/ADS-Benutzermanager-Konfiguration

Der an den Content Management Server angebundene LDAP/ADS-Benutzer-Manager kann mit den folgenden Parametern konfiguriert werden:

host / port

Mit 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üsselung
ssl: SSL Verschlüsselung
tls: TLS Verschlüsselung

Beispiel:

<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:
- Der DN aller Benutzer ist im gleichen Format im LDAP vorhanden. Der DN wird aus dem Login und den im Parameter dnFormat angegebenen Format zusammengesetzt.
- Alle Logins im LDAP können durch die Verwendung dieses dnFormat eindeutig identifiziert werden. Der im Parameter userFilter angegebene LDAP-Filter wird daher nicht angewandt.
- Alle Benutzer sind im angegebenen LDAP-Verzeichniseintrag zu finden (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.
- Zu den im 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.
- Die LDAP-Anfrage wird so erstellt, dass sie den kompletten LDAP-Baum (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.
Dies wird so interpretiert, dass der Wert des Attributs 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>