Dies ist eine alte Version des Dokuments!


Anbindung IdM (LDAP/AD)

Die IdM-Anbindung ist erfahrungsgemäss der kniffligste Teil der IdP-Konfiguration. Es empfiehlt sich daher den Default-Loglevel der LDAP-Kategorie zu erhöhen:

/opt/shibboleth-idp/conf/logback.xml
    ...
    <!-- aus Datenschutzgründen nur 14 Tage aufbewahren -->
    <variable name="idp.loghistory" value="14" />
 
    <!-- Much higher performance if you operate on DEBUG. -->
    <!-- <variable name="idp.process.appender" value="ASYNC_PROCESS" /> -->
 
    <!-- Logging level shortcuts. -->
    <variable name="idp.loglevel.idp" value="INFO" />
    <!-- Loglevel von "WARN" auf "INFO" ändern -->
    <variable name="idp.loglevel.ldap" value="INFO" />
    ...

Starten Sie Tomcat neu um die neuen Einstellungen zu aktivieren (dabei Logdateien mitverfolgen!):

root@idp:/opt/shibboleth-idp# systemctl restart tomcat8

Bei einem Login-Vorgang des Users am IdP macht der IdP im Hintergrund zwei LDAP-Abfragen:

  • Authentisierung des Users
  • Abruf der Attribute des Users

Diese beiden Schritte werden in ldap.properties unabhängig voneinander konfiguriert:

LDAP-Abfrage 1: User-Authentisierung

/opt/shibboleth-idp/conf/ldap.properties
# bitte entsprechend den Möglichkeiten Ihres IdM-Systems anpassen, im Beispiel
# eine Konfiguration wie Sie für OpenLDAP und auch Active Directory funktionieren kann:
idp.authn.LDAP.authenticator                    = bindSearchAuthenticator
idp.authn.LDAP.ldapURL                          = ldaps://ldap.hochschule-XY:636
idp.authn.LDAP.useStartTLS                      = false
idp.authn.LDAP.useSSL                           = true
idp.authn.LDAP.sslConfig                        = certificateTrust
#
# Pfad zum Root-Zertifikat der verwendeten PKI, dieser sollte folgendermassen überprüft werden
# bevor er im IdP konfiguriert wird (Beispiel für DFN-PKI):
#
#  openssl s_client -connect ldap.uni-beispiel.de:ldaps -showcerts \
#              -CAfile /etc/ssl/certs/Deutsche_Telekom_Root_CA_2.pem
#
# Wichtig ist dass der Hostnamen des LDAP/AD-Servers im Zertifikat eingetragen ist, oder anders herum,
# dass der LDAP/AD-Server unter dem Zertifikatsnamen erreichbar ist. Sollte dies aus irgend welchen
# Gründen nicht der Fall sein, kann die Zertifikatsüberprüfung mit folgender Konfiguration doch noch
# erfolgreich gemacht werden:
#
# * zu den JAVA-Start-Optionen von Tomcat hinzufügen: "-Djdk.tls.trustNameService=true"
# * in /etc/hosts den Zertifikatsnamen mit der IP des LDAP/AD-Server verknüpfen:
#
#     192.168.0.13 ldap1.hochschule-XY.intra
#
# 'alte' DFN-PKI-Hierarchie:
idp.authn.LDAP.trustCertificates                = /etc/ssl/certs/Deutsche_Telekom_Root_CA_2.pem
# 'neue' DFN-PKI-Hierarchie:
#idp.authn.LDAP.trustCertificates                = /etc/ssl/certs/T-TeleSec_GlobalRoot_Class_2.pem
#
# sofern während der Auth-Phase festgestellt werden  soll, ob der Account aktiv ist, müssen
# hier die entsprechenden Attribute angegeben werden
# (FIXME: konkretes Beispiel für OpenLDAP und AD heraussuchen)
idp.authn.LDAP.returnAttributes                 = passwordExpirationTime,loginGraceRemaining
#
# LDAP-Verbindungsparameter, diese sollten folgendermassen überprüft werden bevor Sie im IdP
# konfiguriert werden:
#
#  ldapsearch -H ldaps://ldap.hochschule-XY.de \
#             -b "ou=people,dc=hochschule-XY=de" \
#             -D cn=idp,cn=systemusers,dc=hochschule-XY,dc=de \
#             -x -w 'geheim007' \
#             uid=irgendeinExistierenderUser
#
idp.authn.LDAP.baseDN                           = ou=people,dc=hochschule-XY,dc=de
# statt "(uid={user})" nehmen Sie bei AD üblicherweise "(cn={user})" oder "(sAMAccountName={user})"
idp.authn.LDAP.userFilter                       = (uid={user})
idp.authn.LDAP.bindDN                           = cn=idp,cn=systemusers,dc=hochschule-XY,dc=de
idp.authn.LDAP.bindDNCredential                 = geheim007

Starten Sie Tomcat neu um die neuen Einstellungen zu aktivieren (dabei Logdateien mitverfolgen!):

root@idp:/opt/shibboleth-idp# systemctl restart tomcat8

Siehe auch im Shibboleth Wiki unter LDAPAuthnConfiguration.

LDAP-Abfrage 2: User-Attribute

/opt/shibboleth-idp/conf/ldap.properties
# wie bei Abfrage 1 muss hier das relevante User-Attribut angegeben werden, für
# MS-AD ist das üblicherweise "(cn=$resolutionContext.principal)" oder "(sAMAccountName=$resolutionContext.principal)"
idp.attribute.resolver.LDAP.searchFilter        = (uid=$resolutionContext.principal)

Starten Sie Tomcat neu um die neuen Einstellungen zu aktivieren (dabei Logdateien mitverfolgen!):

root@idp:/opt/shibboleth-idp# systemctl restart tomcat8

Bevor Sie weiter machen müssen Sie unbedingt die LDAP-Verbindung testen!

Es werden Ihnen jetzt noch keine Attribute angezeigt, was aber nicht weiter tragisch ist.

Sollten Sie nicht erfolgreich zum SP zurückgeleitet werden, achten Sie darauf, von welchem System die Fehlermeldung im Browser generiert wird. Entsteht die Fehlermeldung am IdP, schauen Sie bitte in idp-process.log nach, was die Ursache ist. Generiert unser Test-SP die Fehlermeldung, schauen Sie bitte im Online-Log https://testsp2.aai.dfn.de/ShibLogViewer2/SPLogViewer.html des SP. Mithilfe dieser Meldung und des Shib-Wiki unter https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPTroubleshootingCommonErrors sollten Sie in den meisten Fällen die Ursache bestimmen können. Sollten Sie damit nicht weiterkommen, senden Sie uns bitte einen Screenshot der Fehlermeldung und den genauen Zeitpunkt, zu dem der Fehler aufgetreten ist, damit wir mithilfe unseres SP-Logs die Ursache bestimmen können.

Erst wenn der Login funktioniert sollten Sie die Attribute-Konfiguration angehen!

  • Zuletzt geändert: vor 7 Jahren