Tipps zur Fehlerbehebung bei SSO-Konfigurationen für die Sicherheit

Es können verschiedene allgemeine Probleme auftreten, wenn Sie Single Sign-on (SSO) zwischen einem WebSphere Application Server und einem Domino-Server. Zu diesen Problemen gehören: Fehler beim Speichern der SSO-Konfiguration von Domino Web, Authentifizierungsfehler beim Zugriff auf eine geschützte Ressource und SSO-Fehler beim Zugriff auf eine geschützte Ressource. Sie können diverse Aktionen ausführen, um diese Fehlersituationen zu beheben und die SSO-Konfiguration wiederherzustellen.

  • Fehler beim Sichern des Domino-Dokuments für die SSO-Webkonfiguration

    Der Client muss in der Lage sein, Domino-Server-Dokumente für die an SSO teilnehmenden Domino-Server zu finden. Das Konfigurationsdokument für Web-SSO wird für die angegebenen Server verschlüsselt. Der im Verzeichniseintrag festgelegte Home-Server muss auf einen Server in der Domino-Domäne zeigen, in der sich die teilnehmenden Server befinden. Dieser Zeiger stellt sicher, dass Suchoperationen die öffentlichen Schlüssel der Server finden können.

    Wenn Sie die Nachricht empfangen, dass einer oder mehrere der teilnehmenden Domino-Server nicht gefunden werden können, dann sind diese Server nicht in der Lage, das Dokument für die SSO-Webkonfiguration zu entschlüsseln oder SSO auszuführen.

    Wird das Dokument für die SSO-Webkonfiguration gesichert, wird in der Statusleiste angezeigt, wie viele öffentliche Schlüssel verwendet wurden, um das Dokument zu verschlüsseln, indem die aufgelisteten Server, Verfasser und Administratoren des Dokumentes gesucht werden.

  • Die Domino-Serverkonsole kann das Dokument für die SSO-Webkonfiguration beim Systemstart des Domino-HTTP-Servers nicht laden

    Bei der Konfiguration von SSO wird das Serverdokument im Feld Sitzungsauthentifizierung für den Mehrserverbetrieb konfiguriert. Der Domino-HTTP-Server versucht beim Systemstart, ein Dokument für die SSO-Webkonfiguration zu finden und zu laden. Die Domino-Serverkonsole meldet Folgendes, wenn ein gültiges Dokument gefunden und entschlüsselt wurde: HTTP: Web-SSO-Konfiguration erfolgreich geladen.

    Falls ein Server das Dokument für die SSO-Webkonfiguration nicht laden kann, kann SSO nicht arbeiten. In einem solchen Fall gibt der Server die folgende Nachricht aus: HTTP: Fehler beim Laden der SSO-Webkonfiguration. Rückkehr zur Authentifizierung für Single-Server-Sitzungen.

    Stellen Sie sicher, dass es in der Ansicht "Webkonfigurationen" des Domino-Verzeichnisses und in der verdeckten Ansicht "$WebSSOConfigs" nur ein Konfigurationsdokument für Web-SSO gibt. Mehr als ein Dokument kann nicht erstellt werden; jedoch können während der Replikation weitere Dokumente hinzugefügt werden.

    Falls Sie nur ein Web-SSO-Konfigurationsdokument prüfen können, müssen Sie eine weitere Bedingung beachten. Wenn der öffentliche Schlüssel des Serverdokuments nicht mit dem öffentlichen Schlüssel in der ID-Datei übereinstimmt, kann dieselbe Fehlernachricht angezeigt werden. In diesem Fall scheitern alle Versuche, das Dokument für die SSO-Webkonfiguration zu entschlüsseln, und es wird diese Fehlernachricht generiert.

    Diese Situation kann auftreten, wenn die ID-Datei mehrmals erstellt wurde, das Serverdokument aber nicht korrekt aktualisiert wurde. Normalerweise wird in der Domino-Serverkonsole die Fehlernachricht angezeigt, dass der öffentliche Schlüssel nicht mit der Server-ID übereinstimmt. In diesem Fall kann SSO nicht arbeiten, da das Dokument mit einem öffentlichen Schlüssel verschlüsselt wird, für den der Server den zugehörigen privaten Schlüssel nicht besitzt.

    Gehen Sie wie folgt vor, um das Problem mit den nicht übereinstimmenden Schlüsseln zu lösen:
    1. Kopieren Sie den öffentlichen Schlüssel von der ID-Datei des Servers, und fügen Sie ihn in das Serverdokument ein.
    2. Erstellen Sie das Dokument für die SSO-Webkonfiguration erneut.
  • Authentifizierung scheitert beim Zugriff auf eine geschützte Ressource

    Wird ein Webbenutzer wiederholt zur Eingabe von Benutzer-ID und Kennwort aufgefordert, funktioniert SSO nicht, da entweder der Domino- oder der WebSphere Application Server-Sicherheitsserver nicht in der Lage ist, den Benutzer beim LDAP-Server zu authentifizieren. Überprüfen Sie die folgenden Möglichkeiten:

    • Überprüfen Sie, ob von der Domino-Servermaschine aus auf den LDAP-Server zugegriffen werden kann. Verwenden Sie das TCP/IP-Dienstprogramm ping, um die TCP/IP-Konnektivität zu überprüfen, und um zu überprüfen, ob die Hostmaschine aktiv ist.
    • Überprüfen Sie, ob der LDAP-Benutzer im LDAP-Verzeichnis definiert ist. Verwenden Sie das Dienstprogramm idsldapsearch, um zu bestätigen, dass die Benutzer-ID existiert und das Kennwort korrekt ist. Geben Sie beispielsweise den folgenden Befehl in einer Zeile ein:

      [AIX Solaris HP-UX Linux Windows][IBM i]Sie können die OS/400-Qshell, eine UNIX-Shell oder unter Windows eine DOS-Eingabeaufforderung verwenden.

      % ldapsearch -D "cn=John Doe, ou=Rochester, o=IBM, c=US" -w mypassword
      -h myhost.mycompany.com -p 389 -b "ou=Rochester, o=IBM, c=US" (objectclass=*)
      Das Prozentzeichen (%) symbolisiert die Eingabeaufforderung, und ist nicht Teil des Befehls. Daraufhin wird eine Liste der Verzeichniseinträge erwartet. Mögliche Fehlerbedingungen und -ursachen sind in der folgenden Liste aufgeführt:
      • Kein solches Objekt: Dieser Fehler zeigt an, dass der Verzeichniseintrag, auf den sich entweder der nach der Option -D angegebene DN des Benutzers oder der nach der Option -b angegebene Basis-DN bezieht, nicht existiert.
      • Ungültige Berechtigungsnachweise: Dieser Fehler zeigt an, dass das Kennwort ungültig ist.
      • Kein Kontakt zum LDAP-Server: Dieser Fehler zeigt an, dass der für den Server angegebene Hostname oder Port ungültig oder der LDAP-Server nicht aktiv ist.
      • Eine leere Liste bedeutet, dass das durch die Option -b bezeichnete Basisverzeichnis keinen Verzeichniseintrag enthält.
    • Stellen Sie bei der Verwendung des Kurznamens oder der Benutzer-ID anstelle des registrierten Namens sicher, dass der Verzeichniseintrag mit dem Kurznamen konfiguriert ist. Im Domino-Verzeichnis ist dies das Feld "Kurzname/Benutzer-ID" des Dokuments "Person". Bei anderen LDAP-Verzeichnissen ist dies die Eigenschaft "Benutzer-ID" des Verzeichniseintrags.
    • Falls die Authentifizierung in Domino scheitert, wenn ein anderes LDAP-Verzeichnis als Domino verwendet wird, überprüfen Sie die Konfigurationseinstellungen des LDAP-Servers im Directory-Unterstützungsdokument in der Directory-Unterstützungsdatenbank. Überprüfen Sie ebenfalls, ob das Serverdokument auf das richtige Directory-Unterstützungsdokument verweist. Die folgenden im Directory-Unterstützungsdokument angegebenen LDAP-Werte müssen mit den Werten übereinstimmen, die für die Benutzerregistrierungsdatenbank in der Administrationsdomäne von WebSphere Application Server angegeben wurden:
      • Domänenname
      • Name des LDAP-Host
      • LDAP-Port
      • Basis-DN
      Außerdem müssen sich die im Directory-Unterstützungsdokument definierten Regeln auf den Basis-DN des Verzeichnisses beziehen, das die Verzeichniseinträge des Benutzers enthält.

      Für die Anforderungen des Domino-Servers an den LDAP-Server kann ein Trace durchgeführt werden, indem der Datei notes.ini des Servers die folgende Zeile hinzugefügt wird:

      webauth_verbose_trace=1
      Nach dem Neustart des Domino-Servers werden die Tracenachrichten in der Konsole des Domino-Servers angezeigt, sobald Webbenutzer versuchen, sich beim Domino-Server zu authentifizieren.

  • Berechtigung scheitert beim Zugriff auf eine geschützte Ressource

    Wenn nach erfolgreicher Authentifizierung eine Nachricht zu einem Berechtigungsfehler angezeigt wird, ist die Sicherheit nicht ordnungsgemäß konfiguriert. Überprüfen Sie die folgenden Möglichkeiten:

    • Überprüfen Sie für Domino-Datenbanken, ob der Benutzer in den Einstellungen für die Zugriffssteuerung für die Datenbank definiert ist. In der Dokumentation zur Verwaltung von Domino finden Sie die korrekte Methode zur Angabe des DN des Benutzers. Zum Beispiel muss für den DN cn=John Doe, ou=Rochester, o=IBM, c=US der Wert in der Zugriffssteuerungsliste in der Form "John Doe/Rochester/IBM/US" eingestellt werden.
    • Überprüfen Sie für durch WebSphere Application Server geschützte Ressourcen, ob die Sicherheitsberechtigungen richtig definiert sind.
      • Falls ausgewählten Gruppen Berechtigungen gewährt werden, müssen Sie sicherstellen, dass der Benutzer, der auf die Ressource zugreift, der Gruppe angehört. Zum Beispiel können Sie die Member der Gruppen überprüfen, indem Sie zur Anzeige von Verzeichnisinhalten die folgende Webadresse eingeben: Ldap://meinHost.meineFirma.com:389/ou=Rochester, o=IBM, c=US??sub
      • Wenn Sie nach dem Festlegen der Berechtigungen die LDAP-Konfigurationsdaten (Host, Port und Basis-DN) in einer WebSphere Application Server-Administrationsdomäne geändert haben, sind die vorhandenen Berechtigungen wahrscheinlich ungültig und müssen neu definiert werden.

  • SSO-Fehler beim Zugriff auf geschützte Ressourcen

    Wenn ein Webbenutzer aufgefordert wird, sich bei jedem Zugriff auf eine Ressource zu authentifizieren, ist SSO nicht richtig konfiguriert. Überprüfen Sie die folgenden Möglichkeiten:

    1. Konfigurieren Sie WebSphere Application Server und Domino Server so, dass sie dasselbe LDAP-Verzeichnis verwenden. Durch das für SSO verwendete HTTP-Cookie werden der vollständige registrierte Name (Distinguished Name, DN) des Benutzers, zum Beispiel cn=John Doe, ou=Rochester, o=IBM, c=US, und die DNS-Domäne gespeichert.
    2. Definieren Sie Webbenutzer mit hierarchischen Namen, wenn das Domino-Verzeichnis verwendet wird. Aktualisieren Sie zum Beispiel das Feld Benutzername im Dokument Person so, dass Namen mit dem folgenden Format als erstem Wert enthalten sind: John Doe/Rochester/IBM/US.
    3. Geben Sie in Webadressen, die an Domino-Server und WebSphere Application Server, die für SSO konfiguriert sind, übergeben werden den vollständigen Namen des DNS-Servers und nicht nur den Hostnamen oder die TCP/IP-Adresse an. Damit Browser Cookies an eine Gruppe von Servern senden können, muss die DNS-Domäne im Cookie enthalten sein und mit der Webadresse übereinstimmen. Aus diesem Grund können Cookies nicht für mehrere TCP/IP-Domänen verwendet werden.
    4. Konfigurieren Sie Domino und WebSphere Application Server so, dass sie dieselbe DNS-Domäne verwenden. Überprüfen Sie, ob die angegebene DNS-Domäne exakt dieselbe ist, einschließlich der Großschreibung. Sie benötigen den Namen der DNS-Domäne, in der WebSphere Application Server konfiguriert ist. Weitere Informationen finden Sie im Artikel Single Sign-on für die Authentifizierung mit LTPA-Cookies.
    5. Stellen Sie sicher, dass für die Domino-Server im Cluster der vollständige Name des DNS-Servers im Serverdokument angegeben ist. Wenn der vollständige Name des DNS-Servers verwendet wird, kann Domino Internet Cluster Manager (ICM) Anforderungen an Cluster-Member weiterleiten, die mit SSO arbeiten. Falls dieses Feld nicht ausgefüllt wird, leitet ICM Webadressen standardmäßig nur mit dem Hostnamen des Servers an die Web-Server im Cluster weiter. ICM kann das SSO-Cookie nicht senden, da die DNS-Domäne nicht in der Webadresse enthalten ist. Gehen Sie wie folgt vor, um den Fehler zu beheben:
      1. Bearbeiten Sie das Serverdokument.
      2. Klicken Sie aufInternet-Protokolle > HTTP.
      3. Geben Sie den vollständigen DNS-Namen des Servers im Feld Hostnamen ein.
    6. Wenn für eine Administrationsdomäne von WebSphere Application Server ein Port für einen LDAP-Server angegeben wurde, muss das SSO-Konfigurationsdokument des Domino-Web-Servers editiert und vor dem Doppelpunkt (:) ein Backslash (\) in den eingegebenen Wert des Felds "LDAP-Bereich" eingefügt werden. Ersetzen Sie also zum Beispiel meinhost.meinefirma.com:389 durch meinhost.meinefirma.com\:389.

  • Benutzer werden nach Ablauf des Zeitgebers für HTTP-Sitzungen nicht abgemeldet

    Wenn Benutzer von WebSphere Application Server sich bei einer Anwendung anmelden und einen längeren Zeitraum inaktiv sind als durch das Zeitlimit für HTTP-Sitzungen angegeben, werden die Benutzerdaten nicht invalidiert, und die Benutzerberechtigung bleibt aktiv, bis das Zeitlimit für LTPA-Token überschritten wird.

    Führen Sie nach der Anwendung von PK25740 die folgenden Schritte aus, um Benutzer von der Anwendung abzumelden, wenn die HTTP-Sitzung abgelaufen ist.
    Achtung: Die Eigenschaft com.ibm.ws.security.web.logoutOnHTTPSessionExpire gilt nur für Anwendungen, die die formularbasierte Anmeldung verwenden.
    1. Klicken Sie in der Administrationskonsole auf Sicherheit > Globale Sicherheit.
    2. Klicken Sie auf der Seite "Angepasste Eigenschaften" auf Neu.
    3. Geben Sie im Feld "Name" die Eigenschaft "com.ibm.ws.security.web.logoutOnHTTPSessionExpire" ein.
    4. Im Feld "Wert" geben Sie "true" ein.
    5. Klicken Sie auf "Anwenden", und speichern Sie die Änderungen dann in Ihrer Masterkonfiguration.
    6. Resynchronisieren Sie den Server, und starten Sie ihn erneut.
    Unerwartete Neuauthentifizierungen: Wenn Sie die angepasste Eigenschaft "com.ibm.ws.security.web.logoutOnHTTPSessionExpire" auf "true" setze, können unerwartete Neuauthentifizierungen stattfinden, wenn Sie mit mehreren Webanwendungen arbeiten. Standardmäßig hat jede Webanwendung eine eigene HTTP-Sitzung, aber der Web-Browser hat ein einziges Sitzungscookie. Zur Behebung dieses Problems können Sie die HTTP-Sitzungskonfiguration ändern, indem Sie jeder Anwendung einen eindeutigen Sitzungscookienamen oder eine eindeutige Pfadeinstellung zuweisen. Auf diese Weise erhält jede Anwendung ein eigenes Sitzungscookie. Alternativ können Sie mehrere Webanwendungen mit derselben Unternehmensanwendung konfigurieren, damit die HTTP-Sitzung gemeinsam genutzt wird. Weitere Informationen finden Sie im Artikel "Assemblierung für eine gemeinsame Nutzung der Sitzungsdaten".
  • Potenzielle Probleme, wenn SSO aktiviert und Firefox v3.6.11 für die Annahme von Cookies anderer Anbieter konfiguriert ist.
    Wenn Sie SSO aktiviert haben und Firefox v3.6.11 verwenden, trifft einer der folgenden Fälle zu:
    • Firefox ist für die Annahme von Cookies anderer Anbieter konfiguriert, die so lange gültig bleiben, bis sie ablaufen oder bis Firefox geschlossen wird.
    • Sie haben eine Sitzung geöffnet, wechseln aber in andere Anwendungen.
    • Es sind mehrere Sitzungen für unterschiedliche Anwendungen geöffent, die unterschiedliche Benutzer für die Berechtigung erfordern.

    Möglicherweise wird die folgende Fehlernachricht angezeigt: Error 403: AuthorizationFailed.

    Zur Behebung des Problems löschen Sie die Cookies anderer Anbieter wie folgt, bevor Sie eine neue Anwendung starten:
    1. Wählen Sie Firefox-Tools > Einstellungen > Datenschutz aus.
    2. Stellen Sie sicher, dass unter "Firefox wird eine Chronik" der Wert anlegen ausgewählt ist.
    3. Klicken Sie auf Einzelne Cookies löschen, um die Cookies zu löschen.

    Sie können auch die anderen Sitzungen schließen, wenn Firefox für die Annahme von Cookies anderer Anbieter konfiguriert ist, die gültig bleiben, bis Firefox geschlossen wird.


Symbol, das den Typ des Artikels anzeigt. Referenzartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rsec_troublesso
Dateiname:rsec_troublesso.html