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/T-TeleSec_GlobalRoot_Class_2.pem
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)'
Bei einem Login-Vorgang des Users am IdP macht der IdP im Hintergrund zwei LDAP-Abfragen:
Diese beiden Schritte werden in der Datei ./conf/ldap.properties unabhängig voneinander konfiguriert.
# Beispielkonfiguration, die für OpenLDAP funktionieren kann: idp.authn.LDAP.authenticator = bindSearchAuthenticator idp.authn.LDAP.ldapURL = ldaps://ldap.hochschule-XY:636 idp.authn.LDAP.useStartTLS = false idp.authn.LDAP.sslConfig = certificateTrust # Wenn Ihr IdM den Aufbau eines LDAP-Connection-Pools nicht unterstützt, können Sie den Pool global abschalten, # in dem Sie diese Zeile einfügen und das Kommentarzeichen entfernen: # idp.authn.LDAP.disablePooling = true # DFN-PKI: #idp.authn.LDAP.trustCertificates = /etc/ssl/certs/T-TeleSec_GlobalRoot_Class_2.pem # Sectigo-Zertifikat: idp.authn.LDAP.trustCertificates = /etc/ssl/certs/USERTrust_RSA_Certification_Authority.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 idp.authn.LDAP.userFilter = (uid={user}) idp.authn.LDAP.bindDN = cn=idp,cn=systemusers,dc=hochschule-XY,dc=de # Sofern die Useraccounts im LDAP in Sub-Bäumen verteilt sind, aktivieren Sie bitte dies: #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.
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 https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199505688/LDAPAuthnConfiguration.
idp.attribute.resolver.LDAP.searchFilter = (uid=$resolutionContext.principal)
Triggern Sie das Einlesen der neuen Einstellungen:
root@idp:~# touch /opt/shibboleth-idp/war/idp.war
# Beispielkonfiguration, die für AD funktionieren kann: idp.authn.LDAP.authenticator = adAuthenticator idp.authn.LDAP.ldapURL = ldaps://ldap.hochschule-XY:636 idp.authn.LDAP.useStartTLS = false idp.authn.LDAP.sslConfig = certificateTrust # Wenn Ihr IdM den Aufbau eines LDAP-Connection-Pools nicht unterstützt, können Sie den Pool global abschalten, # in dem Sie diese Zeile einfügen und das Kommentarzeichen entfernen: # idp.authn.LDAP.disablePooling = true # DFN-PKI: #idp.authn.LDAP.trustCertificates = /etc/ssl/certs/T-TeleSec_GlobalRoot_Class_2.pem # Sectigo-Zertifikat: idp.authn.LDAP.trustCertificates = /etc/ssl/certs/USERTrust_RSA_Certification_Authority.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 # Format DN resolution, used by directAuthenticator, adAuthenticator idp.authn.LDAP.dnFormat. = %s@domain.com # Sofern die Useraccounts im LDAP in Sub-Bäumen verteilt sind, aktivieren Sie bitte dies: #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.
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 https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199505688/LDAPAuthnConfiguration.
# 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
Sie haben im letzten Schritt Ihren IdP in die Test-Föderation aufgenommen. Wenn seitdem mindestens 90 Minuten vergangen sind, können Sie jetzt einen ersten Login-Versuch mithilfe unseres öffentlichen Test-SP3 machen.
Weitere Informationen zu den Test-SPs finden Sie unter Funktionstest IdP.
opensaml::SecurityPolicyException bekommen, sehen Sie bitte auf der Troubleshooting-Seite nach.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.Login Failure: javax.net.ssl.SSLException: Could not initialize SSL context stellen Sie bitte sicher, dass in ./conf/ldap.properties beim Pfad zum Zertifikat kein Leerzeichen am Zeilenende steht. ./logs/idp-process.log oder im Shibboleth-Wiki nach möglichen Ursachen.Erst wenn der Login funktioniert, sollten Sie weitermachen.