LDAP und Active Directory

Diese Seite beinhaltet die folgenden Abschnitte:

Aktivierung von LDAP für die Nutzerverwaltung
Voraussetzungen
Verbindungseinstellungen
Sucheinstellungen
Rollenzuweisungen
Gruppenzuweisungen
Attributzuweisungen
Import
Export
Microsoft Active Directory Service (ADS)
- Simple/None Authentication
- Kerberos-Authentifizierung

security.manager erlaubt die Anbindung bestehender LDAP-Verzeichnisse als Quelle von Nutzerinformationen. Das LDAP-Verzeichnis ersetzt in diesem Fall die security.manager Nutzerdatenbank und wird genutzt, um Nutzer zu authentifizieren. Bei der Verwendung des LDAP-Adapters wird die Nutzerverwaltung in den passiven Modus versetzt. Das bedeutet, dass die Nutzerinformationen aus dem LDAP dargestellt werden, sie jedoch nicht verändert werden können. Zur Administration der Nutzer können existierende LDAP-Applikationen verwendet werden.

Aktivierung von LDAP für die Nutzerverwaltung

Führen Sie die folgenden Schritte aus, um LDAP für die Nutzerverwaltung zu aktivieren und mit der Konfiguration zu beginnen:

Setzen Sie die Konfigurations-Eigenschaft usermgr.type entweder auf ldap oder hybrid.
Melden Sie sich als Super-Administrator (smadmin) an und klicken Sie auf Einstellungen → LDAP/ADS Konfiguration.

Voraussetzungen

Damit die LDAP-Anbindung reibungslos funktioniert, muss der technische Nutzer bzw. bei anonymer Verbindung der anonyme Nutzer volle Leserechte auf dem zu durchsuchenden Teilbaum des LDAP besitzen.

Neben der expliziten Zuordnung von Attributen oder Knoten des LDAP auf Gruppennamen, die im security.manager verwendet werden sollen, wird wahlweise eine implizite Zuordnung von Nutzern zu Gruppen unterstützt. Dabei wird die Gruppe eines Nutzers über den Namen des Elternknotens im LDAP abgeleitet. Zur Suche nach impliziten Gruppen werden die operationalen Attribute hasSubordinates und numSubordinates verwendet. Wenn ihr LDAP-System diese Attribute nicht unterstützt, werden die objectClass-Werte der Gruppen auf Basis der Gruppe des ersten Nutzers ermittelt. Die implizite Gruppenzuordnung kann über die Verbindungseinstellungen de.conterra.implicitgroups.enabled und de.conterra.hassubordinates.enabled gesteuert werden.

Verbindungseinstellungen

In dieser Ansicht werden die Konfigurationsparameter für die Verbindung zum LDAP konfiguriert:

Hierbei können Sie folgende Eigenschaften definieren:

java.naming.provider.url (erforderlich)

Der Wert dieser Eigenschaft ist die Verbindungs-URL zum LDAP, z.B. ldaps://myhost.example.com

java.naming.security.principal (optional)

Dies ist der Name des technischen Nutzers, der zum Verbindungsaufbau und zur Suche im LDAP verwendet wird. Dieser Wert ist von der Authentifizierungsmethode abhängig.

java.naming.security.credentials (optional)

Diese Eigenschaft beschreibt das Passwort des technischen Nutzers. Dieser Wert ist optional und von der Authentifizierungsmethode abhängig.

java.naming.security.authentication (optional)

Diese Eigenschaft beschreibt den Typ der Authentifizierung. Der Standardwert ist simple. Die möglichen Werte sind:

none: Der Administrator greift als anonymer Nutzer auf den LDAP zu, d.h. es muss kein technischer Nutzer definiert werden.
simple: Es muss ein technischer Nutzer definiert werden, als der sich der Administrator gegenüber dem LDAP authentifiziert. Dieser technische Nutzer muss in dem LDAP suchen dürfen. Die Authentifizierung erfolgt dabei mit der „simple bind" Methode.
GSSAPI: Verwendung der Kerberos-Authentifizierung. Dies bedeutet, dass ein technischer Nutzer definiert werden muss, als der sich der Administrator gegenüber dem LDAP authentifiziert. Hierbei führt der Administrator zuerst ein Login am Domain Controller durch, um ein Kerberos-Ticket zu erhalten. Mit diesem Ticket authentifiziert sich der Administrator gegenüber dem LDAP. Der technische Nutzer muss in dem LDAP suchen dürfen.

java.naming.factory.initial (optional)

Dies ist eine interne Eigenschaft, die den Wert com.sun.jndi.ldap.LdapCtxFactory besitzen muss.

de.conterra.provider.alternatives (optional)

Der Wert dieser Eigenschaft ist eine kommaseparierte Liste von alternativen LDAP Verbindungs-URLs, z.B: ldaps://myhost1.example.com,ldaps://myhost2.example.com.

de.conterra.implicitgroups.enabled (optional)

Aktiviert die Suche nach möglichen Elternknoten von Nutzern (Impliziten Gruppen). Standardwert ist true. Erlaubt sind true oder false.

de.conterra.hassubordinates.enabled (optional)

Erlaubt die Nutzung von hasSubOrdinates in LDAP Abfragen. Standardwert ist true. Erlaubt sind true oder false.

Sollte der LDAP ein SSL Zertifikat verwenden, welches nicht von einer offiziellen Zertifizierungsstelle ausgestellt wurde, muss das SSL Zertifikat wie unter Umgang mit SSL Zertifikaten beschrieben importiert werden.

Verwenden Sie Windows als Betriebssystem, können Sie mit der Java-Option -Djavax.net.ssl.trustStoreType=WINDOWS-ROOT die Windows Zertifikatsverwaltung anbinden. Mehr Information erhalten Sie unter Use Windows Truststore.

Sucheinstellungen

Hier werden die Parameter für die Benutzersuche definiert. Aufgrund dieser Parameter werden die DNs der Benutzer aus dem Nutzernamen abgeleitet und eine Suche definiert, welche den Knoten des Nutzers im LDAP ermittelt. Folgende Werte können definiert werden:

Base DN

Definiert den Wurzelknoten der LDAP Suche, ab dem nach Nutzern gesucht wird, z.B. CN=Users,DC=Company,DC=Net.

Filter

Definiert einen allgemeinen Filterausdruck zur Erkennung von Nutzerknoten. Setzen Sie ihn möglichst spezifisch, z.B. (objectClass=user).

Match

Filterausdruck zur Identifizierung des LDAP-Nutzerknotens anhand der von Nutzenden eingegebenen Kennung während des Login.
Geben Sie den Filterausdruck in der Form ldap_attributname={0} an. security.manager vergleicht dann die von Nutzenden eingegebene Kennung, repräsentiert durch {0}, mit dem LDAP-Attribut ldap_attributname, um den zugehörigen LDAP-Nutzerknoten zu identifizieren.

Beispiel: sAMAccountName={0}

Scope

Definiert die Tiefe der Suche im LDAP. Mögliche Werte sind:

base: Nur der mit Base DN identifizierte Knoten wird durchsucht.
onelevel: Die direkten Kindknoten des mit Base DN identifizierten Knotens werden durchsucht.
subtree: Der komplette Teilbaum des mit Base DN identifizierten Knotens wird durchsucht.

Authentication

Definiert die Art der Anmeldung eines einzelnen Nutzers zur Passwortprüfung, mögliche Werte sind:

simple: Die vom Nutzer bereitgestellten Informationen (Nutzername und Passwort) werden über eine „simple-bind" Authentifizierung gegenüber dem LDAP validiert.
GSSAPI: Die vom Nutzer bereitgestellten Informationen (Nutzername und Passwort) werden über eine Kerberos-Authentifizierung am Domain Controller validiert. Ist diese Authentifizierung erfolgreich, werden nur noch die Daten des Nutzers im LDAP/ADS gesucht.

Rollenzuweisungen

Hier wird die Übersetzung von Attributwerten eines Nutzers im LDAP zu einem Rollennamen innerhalb der Anwendung definiert. Die Definition entspricht der Aussage "Wenn das Attribut X vorhanden ist und den Wert Y besitzt, so besitzt der Nutzer die Rolle Z". Beispiele für typische Rollenattribute sind memberOf Attribute eines Nutzers. Für Attributwerte im LDAP ist '*' als Wildcard erlaubt, so dass beispielsweise alle Nutzer einer bestimmten E-Mail-Domäne auf eine bestimmte Rolle abgebildet werden können (z.B. '*.gov.uk' auf die Rolle 'Government').

Gruppenzuweisungen

In diesem Dialog wird konfiguriert, wie ein Attributwert oder der Distinguished-Name (DN) eines Nutzerknotens die Zuordnung zu einer Gruppe ermöglicht.

Es können verschiedene Arten der Gruppenzuweisung verwendet werden. Dabei werden folgende Arten unterschieden:

Zuweisung einer Gruppe durch ein LDAP-Attribut und seinem Wert.

Die Interpretation dieser Zuordnung entspricht der Rollenzuweisung, d.h. wenn das Attribut X vorhanden ist und den Wert Y besitzt, wird der Nutzer der Gruppe Z zugeordnet. Wie bei Rollen ist hier das Attribut memberOf ein häufiger Kandidat für Gruppenzuweisungen.
Zuweisung einer Gruppe durch die Angabe eines Basis-DN.

Hier kann eine Gruppenzuordnung aufgrund eines Elternknotens eines Nutzerknotens erfolgen. Beispiel: Hat ein Nutzerknoten die DN cn=Lex Luthor,ou=Villains,dc=dev,dc=conterra,dc=com so kann eine Gruppenzuordnung aufgrund des direkten Elternknotens ou=Villains,dc=dev,dc=conterra,dc=com oder eines höheren Elternknotens dc=dev,dc=conterra,dc=com erfolgen. Diese Zuordnungen können gemixt werden. Wenn mehrere gültige Zuordnungen für einen Nutzer existieren, wird die spezifischere Zuordnung angewandt.
Implizite Zuweisung durch die Ableitung der Gruppe aus dem direkten Elternknoten des Nutzerknotens.

Bei dieser Art der Zuordnung handelt es sich um eine Zuordnung auf Basis der DN des Nutzers, wobei die Gruppe dann den Namen des direkten Elternknotens des Nutzerknotens erhält. Diese Zuweisung ist intern immer aktiv und wird durch „explizite" Konfiguration der anderen Zuweisungsarten überschrieben.

Diese drei Zuordnungsarten können miteinander gemischt werden, hierbei ist folgende Reihenfolge zu beachten:

Attributbasierte Zuordnungen haben das höchste Gewicht und überschreiben alle anderen Zuordnungen.
Basis-DN basierte Zuordnungen überschreiben nur die implizite Gruppenzuordnung.
Implizite Gruppenzuordnungen haben das schwächste Gewicht und können von allen anderen Arten überschrieben werden.

Attributzuweisungen

Es ist möglich, LDAP-Attributwerte in das vom Authentifizierungsdienst erzeugte SAML-Token zu überführen. Einige Werte werden direkt für die Darstellung innerhalb des Administrators verwendet (wie Vorname oder E-Mail-Adresse). Jeder andere Wert kann durch eine erstellte Attributzuweisung in das SAML-Token übernommen werden, so dass diese den Anwendungen zur Verfügung stehen.

Hierbei wird im Dialog zwischen verpflichtenden und optionalen Attributzuweisungen unterschieden.

Bei den verpflichtenden Attributzuweisungen werden Zuordnungen definiert, die der Administrator zur Anzeige der Nutzerinformationen unter dem Reiter Nutzer benötigt. Diese Werte besitzen schon eine interne SAML Attribut-ID, diese muss hier daher nicht definiert werden. Wird dennoch eine SAML Attribut-ID vergeben, so wird dieses Attribut doppelt im SAML Ticket abgelegt.

Unter den optionalen Attributzuweisungen können weitere Zuordnungen von LDAP-Attributen getätigt werden. Diese Zuordnungen werden jedoch nur in den durch den WAS ausgestellten SAML Tickets sichtbar, können aber nicht in der Nutzerverwaltung des Administrators eingesehen werden. Für die optionalen Attributzuweisungen muss eine SAML Attribut-ID vergeben werden, unter der das Attribut im SAML-Ticket abgelegt wird.

Import

Verwenden Sie den Import-Dialog, um eine zuvor exportierte Datei mit LDAP-Einstellungen zu importieren.

Export

Verwenden Sie den Export-Dialog, um die aktuellen LDAP-Einstellungen in eine XML-Datei zu exportieren.

Microsoft Active Directory Service (ADS)

In diesem Abschnitt werden die nötigen technischen Voraussetzungen für den ADS-Support beschrieben. Allgemein wird ein ADS exakt so wie ein normaler LDAP konfiguriert, nur bei Kerberos-Authentifizierung sind zusätzliche Schritte zu tätigen.

Simple/None Authentication

Bei ADS Anbindung mit simpler oder anonymer Authentifizierung erfolgt diese exakt wie bei anderen LDAP-Systemen.

Wenn man in der Suchkonfiguration als Match sAMAccountName={0} verwendet, kann der Nutzer sich mit seinem Nutzernamen ohne Domainsuffix anmelden, z.B: testuser statt testuser@example.com. Wird userPrincipalName={0} genutzt, ist der exakte Domainname notwendig.

Beispiel für die Sucheinstellungen

base="DC=Test,DC=EXAMPLE,DC=Net"
filter="(objectClass=user)"
match="sAMAccountName={0}"
scope="subtree"
authentication="simple"

Kerberos-Authentifizierung

Um einen ADS über Kerberos-Authentifizierung anzubinden ist eine erweiterte Konfigurationen der JVM des Tomcat nötig. Erstellen Sie eine krb5.conf-Datei, die die möglichenDomains und Hostnamen der Domain Controller enthält.

Das folgende Beispiel einer krb5.conf Datei zeigt die Konfiguration eines Kerberos-Realms TEST.EXAMPLE.COM.

# For detailed configuration possibilities see:
# http://www.mit.edu/~kerberos/krb5-1.5/krb5-1.5.3/doc/krb5-admin/krb5.conf.html#krb5.conf

[libdefaults]
# defines the default realm, only users of this realm are
# allowed to login without full domain name
default_realm = TEST.EXAMPLE.COM

[domain_realm]
# provides a translation from a domain name or hostname
# to a Kerberos realm name
.test.example.com = TEST.EXAMPLE.COM

[realms]
# defines the possible realms,
# kdc is the hostname of the domain controller used
# for the kerberos authentication
TEST.EXAMPLE.COM = {
kdc = test.example.com
}

Der Pfad zu der krb5.conf Datei muss beim Start der JVM des Tomcat als Parameter mitgegeben werden. Dazu muss folgender Parameter konfiguriert werden:

java.security.krb5.conf=[Pfad zur krb5.conf]

Die Konfiguration dieses Parameters erfolgt analog zu den Proxy-Einstellungen.

Die Kerberos-Konfiguration gilt für den gesamten Tomcat-Prozess und damit für alle darin betriebenen Webanwendungen. Es ist möglich, mehrere Kerberos-Realms in der krb5.conf Datei zu definieren, so dass verschiedene Domain Controller verwendet werden können.

Um die Kerberos-Authentifizierung in der LDAP Konfiguration des Administrators anzuschalten, muss im Folgenden als Authentifizierungsmethode GSSAPI gewählt werden. Verzichten Sie bei der Definition der Verbindungseinstellungen auf die Angabe eines technischen Nutzers (Name/Password), so erfolgt die Verbindung zum ADS mit dem Nutzer unter dem der Tomcat-Prozess gestartet wurde. D.h. dieser Systemnutzer muss entsprechend Suchrechte auf dem ADS besitzen. Um eine erfolgreiche Anmeldung eines Nutzers zu gewährleisten, muss in der Suchkonfiguration die Eigenschaft Match den Wert userPrincipalName={0} und die Eigenschaft Authentication den Wert GSSAPI besitzen.

Authentifizierung auf Basis der Identität des Prozess-Besitzers

Wenn der Prozessbesitzer eine Verbindung via GSSAPI erzeugen soll, muss der Zugriff auf das "Kerberos Ticket Granting Ticket" sichergestellt werden.

Die Anmeldung (Passwortprüfung) eines Nutzers erfolgt immer am Kerberos Domain Controller. Das Resultat einer erfolgreichen Anmeldung ist ein Kerberos-Ticket. Dieses Kerberos-Ticket enthält den vollen Domainnamen des Nutzers. Mit diesem Domainnamen führt der Administrator die Suche nach dem Nutzerknoten im ADS durch. Deshalb muss als Match das Attribut userPrincipalName verwendet werden. Erst wenn der Nutzerknoten im ADS gefunden wurde, ist die Anmeldung erfolgreich.

Beispiel für die Sucheinstellungen

base="DC=Test,DC=CONTERRA,DC=Net"
filter="(objectClass=user)"
match="userPrincipalName={0}"
scope="subtree"
authentication="GSSAPI"

Bekannte Kerberos-Fehlermeldungen

Caused by: KrbException: Server not found in Kerberos database (7)
Hier ist der DNS Lookup nach dem Namen des ADS nicht korrekt. Abhilfe schafft ein Eintrag in der hosts Datei des Systems.

Beispiel:
```
172.22.180.157	your.fullqualified.adshostname
```
Caused by: KrbException: Cannot get kdc for realm <your realm >
Dieser Fehler weißt darauf hin, dass der technische Nutzer mit einem nicht korrekt geschriebenen Realmnamen bzw. Domainnamen konfiguriert worden ist. Der Realmname muss exakt wie in der krb5.conf Datei geschrieben werden.

Beispiel: testuser@TEST.EXAMPLE.COM
Gute Praxis ist, den Realmnamen immer groß oder immer klein zu schreiben.
Caused by: KrbException: Fail to create credential. (63) - No service creds
Diesen Fehler erhält man, wenn das Kerberossystem versucht den LDAP/ADS einem anderen REALM als dem des technischen Nutzers zuzuordnen. Das Problem ist ein fehlender domain_realm Eintrag für die Domain des ADS.

Beispiel: test.example.com = TEST.EXAMPLE.COM