Zeige QuelltextÄltere VersionenLinks hierherNach oben Letzte ÄnderungenPer E-Mail sendenDruckenPermalink × ← Eintrag in Metadatenverwaltung Minimalkonfiguration der Attribute → Anbindung des IdM (LDAP/AD) Inhaltsverzeichnis Vorbereitungen Zertifikat am IdM Verbindungsparameter bereithalten Konfiguration zweier Abfragen LDAP-Abfrage 1: User-Authentisierung LDAP-Abfrage 2: User-Attribute Test der LDAP-Verbindung Troubleshooting 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/T-TeleSec_GlobalRoot_Class_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.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 # 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 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. Attribute werden Ihnen zum jetzigen Zeitpunkt noch nicht angezeigt. 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. 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 weitermachen. idp4, tutorial, ldap, idm, included-in-ansible ← Eintrag in Metadatenverwaltung Überblick: Tutorial zur IdP-Inbetriebnahme Minimalkonfiguration der Attribute → idp4 tutorial ldap idm included-in-ansible Zuletzt geändert: vor 17 Monaten Anmelden