Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
de:shibidp3config-idm [2017/03/24 11:41] Raoul Gunnar Boreniusde:shibidp3config-idm [2021/05/03 13:16] (aktuell) – gelöscht Silke Meyer
Zeile 1: Zeile 1:
-======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: 
- 
-=== LDAP-Abfrage 1: User-Authentisierung === 
- 
-<file properties /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 
-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 
-# 
-# 'alte' DFN-PKI-Hierarchie: 
-idp.authn.LDAP.trustCertificates                = /etc/ssl/certs/Deutsche_Telekom_Root_CA_2.pem 
-# 'neue' DFN-PKI-Hierarchie: 
-#idp.authn.LDAP.trustCertificates                = /etc/ssl/certs/T-TeleSec_GlobalRoot_Class_2.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 
- 
-</file> 
- 
-Starten Sie Tomcat neu um die neuen Einstellungen zu aktivieren (dabei Logdateien mitverfolgen!): 
-<code bash> 
-root@idp-dev:/opt/shibboleth-idp# systemctl restart tomcat8 
-</code> 
- 
-Siehe auch im Shibboleth Wiki unter [[https://wiki.shibboleth.net/confluence/display/IDP30/LDAPAuthnConfiguration|LDAPAuthnConfiguration]]. 
- 
-=== LDAP-Abfrage 2: User-Attribute === 
- 
-<file properties /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) 
-</file> 
- 
-Starten Sie Tomcat neu um die neuen Einstellungen zu aktivieren (dabei Logdateien mitverfolgen!): 
-<code bash> 
-root@idp-dev:/opt/shibboleth-idp# systemctl restart tomcat8 
-</code> 
- 
-=== Bevor Sie weiter machen müssen Sie unbedingt die LDAP-Verbindung testen! === 
- 
-  * tragen Sie Ihren idP in der [[https://www.aai.dfn.de/verwaltung/|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 https://www.aai.dfn.de/teilnahme/funktionstest/. 
- 
-Es werden Ihnen jetzt noch keine Attribute angezeigt, was aber nicht weiter tragisch ist. 
- 
-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, 
-schauen Sie bitte in idp-process.log nach, was die Ursache ist. Generiert unser Test-SP 
-die Fehlermeldung, schauen Sie bitte im Online-Log https://testsp2.aai.dfn.de/ShibLogViewer2/SPLogViewer.html des SP. Mithilfe dieser Meldung 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 [[de:shibidp3config-attribute|Attribute]]-Konfiguration angehen! 
- 
  
  • Zuletzt geändert: vor 7 Jahren