Dies ist eine alte Version des Dokuments!


Anbindung IdM (LDAP/AD)

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:

/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
# ACHTUNG: Hostname des LDAP-Servers muss mit dem CN-Wert (bzw. einem der alternativen
# Hostnamen) im Zertifikat übereinstimmen!
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
#
# 'neue' DFN-PKI-Hierarchie:
idp.authn.LDAP.trustCertificates                = /etc/ssl/certs/T-TeleSec_GlobalRoot_Class_2.pem
# bei Verwendung einer lokalen CA (default bei MS ActiveDirectory) muss das lokale CA-Zertifikat
# referenziert werden:
#idp.authn.LDAP.trustCertificates                = /etc/ssl/certs/beispiel-hs_local_ca_cert.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
# sofern die User im LDAP in Sub-Bäumen verteilt sind bitte das hier aktivieren:
#idp.authn.LDAP.subtreeSearch                    = true

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

root@idp-dev:/opt/shibboleth-idp# systemctl restart tomcat9

Siehe auch im Shibboleth Wiki unter LDAPAuthnConfiguration.

/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-dev:/opt/shibboleth-idp# systemctl restart tomcat9
  • tragen Sie Ihren idP in der Metadatenverwaltung ein
  • warten Sie 90 min, bis der neue Eintrag auf den DFN-Testsystemen angekommen ist
  • machen Sie mithilfe unserer Test-SPs einen ersten Login-Versuch, siehe unter Funktionstests.

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

Beim Fehler opensaml::SecurityPolicyException sehen Sie bitte auf der Troubleshooting-Seite nach.

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 oder generiert unser Test-SP die Fehlermeldung, schauen Sie bitte in idp-process.log nach, was die Ursache ist. Mithilfe dieser Meldungungen 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 5 Jahren