Anbindung des IdM (LDAP/AD)

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:

• Authentisierung des Users
• Abruf der Attribute des Users

Diese beiden Schritte werden in der Datei ./conf/ldap.properties unabhängig voneinander konfiguriert.

/opt/shibboleth-idp/conf/ldap.properties

# 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.

/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 https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199505688/LDAPAuthnConfiguration.

/opt/shibboleth-idp/conf/ldap.properties

idp.attribute.resolver.LDAP.searchFilter        = (uid=$resolutionContext.principal)

Triggern Sie das Einlesen der neuen Einstellungen:

root@idp:~# touch /opt/shibboleth-idp/war/idp.war

/opt/shibboleth-idp/conf/ldap.properties

# 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.

/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 https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199505688/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)

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.

• 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.
• Bei der Fehlermeldung 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.
• 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 weitermachen.