Dies ist eine alte Version des Dokuments!
Anbindung des IdM (LDAP/AD)
Vorbereitungen
Zertifikat am IdM
Hostname = CN?
Der Hostname des IdM muss im Zertifikat enthalten sein, entweder direkt im CN oder im SubjectAlternativeName!Der Pfad zum Root-Zertifikat der verwendeten PKI muss angegeben werden. So können Sie ihn vorab überprüfen:
root@idp:~# openssl s_client -connect ldap.uni-beispiel.de:ldaps -showcerts -CAfile /etc/ssl/certs/Deutsche_Telekom_Root_CA_2.pem
Verbindungsparameter bereithalten
So können Sie die LDAP-/AD-Verbindungsparameter manuell prüfen:
root@idp:~# ldapsearch -x -W -D cn=idp,cn=systemusers,dc=hochschule-XY,dc=de -H ldaps://ldap.hochschule-XY.de -b "ou=people,dc=hochschule-XY=de" '(uid=irgendeinExistierenderUser)'
Konfiguration zweier Abfragen
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 der Datei ./conf/ldap.properties
unabhängig voneinander konfiguriert.
LDAP-Abfrage 1: User-Authentisierung
- /opt/shibboleth-idp/conf/ldap.properties
# Beispielkonfiguration, die für OpenLDAP und AD 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 # DFN-PKI: idp.authn.LDAP.trustCertificates = /etc/ssl/certs/T-TeleSec_GlobalRoot_Class_2.pem # lokales CA-Zertifikat: #idp.authn.LDAP.trustCertificates = /etc/ssl/certs/beispiel-hs_local_ca_cert.pem # Wenn festgestellt werden soll, ob der Account aktiv ist, müssen die entsprechenden Attribute geholt werden idp.authn.LDAP.returnAttributes = passwordExpirationTime,loginGraceRemaining 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 # sofern die User im LDAP in Sub-Bäumen verteilt sind bitte das hier aktivieren: #idp.authn.LDAP.subtreeSearch = true
Passwörter werden ab IdPv4 standardmäßig in der besser geschützen Datei ./credentials/secrets.properties
gespeichert. Hier hinterlegen Sie das Bind-Passwort.
- /opt/shibboleth-idp/credentials/secrets.properties
idp.authn.LDAP.bindDNCredential = geheim007
Laden Sie das Servlet neu:
root@idp:~# touch /opt/shibboleth-idp/war/idp.war
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)
Triggern Sie das Einlesen der neuen Einstellungen:
root@idp:~# touch /opt/shibboleth-idp/war/idp.war
Test der LDAP-Verbindung
Testen!
Testen Sie die LDAP-Verbindung, bevor Sie weitermachen!- Tragen Sie Ihren IdP in der Metadatenverwaltung ein und nehmen Sie ihn in die Test-Föderation auf.
- Warten Sie 90 Minuten, bis die nächste Aktualisierung der Föderationsmetadaten stattgefunden hat.
- Machen Sie mithilfe unseres öffentlichen Test-SPs einen ersten Login-Versuch, siehe unter Funktionstests.
Es werden Ihnen zum jetzigen Zeitpunkt noch keine Attribute angezeigt.
Troubleshooting
- Wenn Sie den Fehler
opensaml::SecurityPolicyException
bekommen, sehen Sie bitte auf der Troubleshooting-Seite nach. - Beim LDAP-Fehler
Invalid Credentials
stellen Sie bitte sicher, dass Sie in./conf/ldap.properties
bzw../credentials/secrets.properties
bei den Zugangsdaten des Bind-Accounts keine Leerzeichen an den Zeilenenden stehen haben. Das Passwort steht nicht in Hochkommata oder Anführungszeichen. - Sollten Sie nicht erfolgreich zum Test-SP zurückgeleitet werden, achten Sie darauf, von welchem System die Fehlermeldung im Browser generiert wird: Entsteht sie am IdP oder an unserem Test-SP? Schauen Sie bitte in der Logdatei
./logs/idp-process.log
oder im Shibboleth-Wiki nach möglichen Ursachen. - 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!