Fehler nach der Aktivierung der Sicherheit

Verwenden Sie diese Informationen, wenn nach der Aktivierung der Sicherheit Fehler auftreten.

Anmerkung: Dieser Artikel referenziert eine oder mehrere Protokolldateien des Anwendungsservers. Alternativ dazu wird empfohlen, den Server so zu konfigurieren, dass er die HPEL-Protokoll- und -Traceinfrastruktur (High Performance Extensible Logging) verwendet und nicht die Dateien SystemOut.log , SystemErr.log, trace.log und activity.log auf verteilten oder IBM® i-Systemen. Sie können HPEL auch in Verbindung mit Ihren nativen z/OS-Protokolleinrichtungen verwenden. Wenn Sie HPEL verwenden, können Sie mit dem Befehlszeilentool LogViewer im Verzeichnis "bin" des Serverprofils auf alle Ihre Protokoll- und Tracedaten zugreifen. Weitere Informationen zur Verwendung von HPEL finden Sie in der Dokumentation zum Einsatz von HPEL für die Fehlerbehebung in Anwendungen.
Welcher Fehler wird angezeigt?

[AIX Solaris HP-UX Linux Windows][IBM i]Allgemeine Hinweise zur Diagnose und Behebung sicherheitsbezogener Fehler enthält der Artikel Fehlerbehebung bei den Sicherheitskomponenten.

Der IBM Support besitzt Dokumente, mit denen Sie Zeit bei der Erfassung der für die Lösung des Problems erforderlichen Informationen einsparen können. Bevor Sie einen Fehlerbericht öffnen, sollten Sie sich die folgende Seite des IBM Support ansehen:

Authentifizierungsfehler beim Zugriff auf eine Webseite

Mögliche Fehlerursachen sind:
  • Benutzername oder Kennwort falsch. Vergewissern Sie sich, dass der Benutzername und das Kennwort richtig angegeben wurden.
  • Fehler in der Sicherheitskonfiguration: Der Typ der Benutzerregistry wurde nicht richtig definiert. Überprüfen Sie die Eigenschaft "Benutzerregistry" in den Einstellungen für die Verwaltungssicherheit in der Administrationskonsole. Vergewissern Sie sich, dass mit der Eigenschaft die richtige Benutzerregistry angegeben ist.
  • Interner Programmfehler. Wenn die Clientanwendung ein eigenständiges Java-Programm ist, erfasst oder sendet sie die Berechtigungsdaten möglicherweise nicht richtig.

[AIX Solaris HP-UX Linux Windows][IBM i]Wenn die Konfiguration der Benutzerregistry und die Benutzer-ID und das Kennwort richtig zu sein scheinen, aktivieren Sie die Traceerstellung in WebSphere Application Server, um die Fehlerursache zu bestimmen. Verwenden Sie zum Aktivieren des Sicherheitstrace die Tracespezifikation com.ibm.ws.security.*=all=enabled.

Berechtigungsfehler beim Zugriff auf eine Webseite

Wenn ein Benutzer keinen Zugriff auf eine Ressource hat, dies aber vorgesehen ist, liegt das wahrscheinlich an einem fehlenden Konfigurationsschritt. Lesen Sie den Artikel Zugriff auf Verwaltungsrollen berechtigen.

Führen Sie insbesondere folgende Schritte durch:
  • Überprüfen Sie die erforderlichen Rollen für die aufgerufene Webressource.
  • Überprüfen Sie die Berechtigungstabelle, um sicherzustellen, dass der Benutzer oder die Gruppen, zu denen der Benutzer gehört, einer der erforderlichen Rollen zugeteilt sind.
  • Sie können die erforderlichen Rollen für die Webressource im Implementierungsdeskriptor der Webressource anzeigen.
  • Sie können die Berechtigungstabelle für die Anwendung, die die Webressource enthält, auch in der Administrationskonsole anzeigen.
  • Überprüfen Sie mit einem Benutzer, dem die erforderlichen Rollen erteilt wurden, ob dieser Benutzer auf die problematischen Ressourcen zugreifen kann.
  • Wenn dem betroffenen Benutzer ein oder mehrere Rollen zugeteilt werden müssen, ordnen Sie diesen Benutzer über die Administrationskonsole den erforderlichen Rollen zu. Stoppen Sie die Anwendung, und starten Sie sie anschließend erneut.

[AIX Solaris HP-UX Linux Windows][IBM i]Wenn dem Benutzer zwar die erforderlichen Rollen zugewiesen wurden, er aber trotzdem nicht auf die geschützten Ressourcen zugreifen kann, aktivieren Sie den Sicherheitstrace mit com.ibm.ws.security.*=all=enabled als Tracespezifikation. Erfassen Sie die Traceinformationen für die weitere Fehlerbehandlung.

Authentifizierung schlägt fehl, wenn Codepages von Client und Server sich unterscheiden

Wenn ein Client eine Codepage verwendet, die sich von der des Servers unterscheidet, und bei der Basisauthentifizierung für die Benutzer-ID und das Kennwort keine ASCII-Zeichen (US-Englisch) verwendet werden, schlägt die Anmeldung fehl. Der HTTP-Header beinhaltet nicht die Informationen zur Codierungsmethode, die für das Umsetzen der codierten Daten erforderlich sind, der Server weiß also nicht, wie er die Informationen richtig codieren soll.
Verwenden Sie ein Anmeldeformular, das auf POST-Parametern im HTML-Nachrichtentext basiert. Die Verschlüsselung für den Text wird vom Browser gesendet und kann so richtig decodiert werden.
Anmerkung: Web-Service-Kunden können nicht die Formularanmeldung verwenden, um dieses Problem zu lösen. Benutzer müssen sicherstellen, dass die Codepages von Client und Server konsistent sind.

Fehlernachricht: CWSCJ0314E: Die aktuelle Java-2-Sicherheitsrichtlinie hat eine potenzielle Zugriffsschutzverletzung auf dem Server gemeldet.

Möglicherweise werden Fehler wie die folgenden angezeigt:
Fehlernachricht: CWSCJ0314E: Die aktuelle Java 2-Sicherheitsrichtlinie hat eine potenzielle Zugriffsschutzverletzung in Bezug auf die Java 2-Sicherheitsberechtigungen gemeldet.
Weitere Informationen
können Sie der Veröffentlichung "Problem Determination Guide" entnehmen.
{0}Permission/:{1}Code/:{2}{3}Stack Trace/:{4}Code Base Location/:{5}
Die Methode checkPermission des Java-Sicherheitsmanagers hat eine Ausnahme des Typs SecurityException gemeldet.

Die aufgezeichnete Ausnahme kann für das geschützte System kritisch sein. Aktivieren Sie den Sicherheitstrace, um den Code zu ermitteln, der möglicherweise die Sicherheitsrichtlinie verletzt hat. Wenn der Code, der die Verletzung ausgelöst hat, ermittelt wurde, müssen Sie überprüfen, ob die beabsichtigte Operation hinsichtlich der Java 2-Sicherheit zulässig ist. Dazu müssen Sie alle verfügbaren Richtliniendateien der Java 2-Sicherheit und den Anwendungscode selbst untersuchen.

Ausführlichere Informationen erhalten Sie, wenn Sie den RAS-Trace im Debug-Modus konfigurieren oder eine Java-Eigenschaft angeben.
  • [AIX Solaris HP-UX Linux Windows][IBM i]Lesen Sie den Artikel "Konfiguration von Tracing und Protokollierung", der Anweisungen zur Konfiguration des RAS-Trace im Debug-Modus enthält.
  • Geben Sie im Teilfenster "Generische JVM-Argumente" in der Administrationskonsole die folgende Eigenschaft im Teilfenster Server > Servertypen > WebSphere-Anwendungsserver > Servername > Java- und Prozessverwaltung > Prozessdefinition > Java Virtual Machine an:
    • Fügen Sie das Laufzeit-Flag java.security.debug hinzu.
    • Gültige Werte:
      access
      Gibt alle Debug-Informationen aus: erforderliche Berechtigung, Code, Stack und Position der Codebasis.
      stack
      Gibt Debug-Informationen aus: erforderliche Berechtigung, Code und Stack.
      failure
      Gibt folgende Debug-Informationen aus: erforderliche Berechtigung und Code.

Informationen zu den Java™-Sicherheitsrichtlinien finden Sie in der Dokumentation zur Java-2-Sicherheit unter http://www.ibm.com/developerworks/java/jdk/security/.

Tipp: Wird die Anwendung mit einer Java-Mail-API ausgeführt, zeigt diese Nachricht möglicherweise keinen Fehler an. Sie können die Datei Root der installierten Unternehmensanwendung/META-INF/was.policy so aktualisieren, dass die folgenden Berechtigungen der Anwendung erteilt werden:
  • permission java.io.FilePermission "${user.home}${/}.mailcap", "read";
  • permission java.io.FilePermission "${user.home}${/}.mime.types", "read";
  • permission java.io.FilePermission "${java.home}${/}lib${/}mailcap", "read";
  • permission java.io.FilePermission "${java.home}${/}lib${/}mime.types", "read";

Beim Starten eines Anwendungsservers wurde die Fehlernachricht CWMSG0508E: Der Sicherheitsservice des JMS-Servers konnte die Benutzer-ID nicht authentifizieren: in der Datei SystemOut.log angezeigt.

Dieser Fehler kann durch die Installation des Beispiels für die JMS-API und der anschließenden Aktivierung der Sicherheitskomponente ausgelöst werden. Folgen Sie zum Konfigurieren des Beispiels für die Sicherheit von WebSphere Application Server den Anweisungen auf der Seite "Konfiguration und Ausführung" in der Dokumentation des JMS-Beispiels.

Sie können die Installation des MDB-Beispiels prüfen, indem Sie das Installationsprogramm starten. Wählen Sie dann Angepasst aus und zeigen Sie die bereits installierten Komponenten im Teilfenster zur Auswahl der zu installierenden Komponenten an. Das JMS-Beispiel wird als "MDB-Beispiel" unter "Embedded Messaging" angezeigt.

Sie können dies auch überprüfen, indem Sie die Eigenschaften des Anwendungsservers, der die Beispiele enthält, in der Administrationskonsole öffnen. Dazu müssen Sie MDBSamples auswählen und dann auf "Deinstallieren" klicken.

Nach dem Aktivieren der Sicherheitskomponente und dem Starten des Anwendungsservers wurde die Fehlernachricht CWSCJ0237E: Mindestens eines der elementaren LTPAServerObject-Konfigurationsattribute ist leer oder nicht verfügbar angezeigt.

Diese Fehlernachricht kann angezeigt werden, wenn LTPA (Lightweight Third Party Authentication) als Authentifizierungsverfahren ausgewählt wurde, jedoch keine LTPA-Schlüssel generiert wurden. Die LTPA-Schlüssel werden verwendet, um das LTPA-Token zu verschlüsseln.

Gehen Sie wie folgt vor, um den Fehler zu beheben:
  1. Klicken Sie auf Sicherheit > Globale Sicherheit > Authentifizierung > Authentifizierungsverfahren und Verfallszeit > LTPA.
  2. Geben Sie ein beliebiges Kennwort ein.
  3. Geben Sie dasselbe Kennwort unter "Kennwort bestätigen" ein.
  4. Klicken Sie auf "Anwenden".
  5. Klicken Sie auf "Schlüssel generieren".
  6. Klicken Sie auf "Speichern".

Ausnahme des Typs AccessControlException in SystemOut.log

Der Fehler bezieht sich auf das Feature Java 2-Sicherheit von WebSphere Application Server, das Sicherheitsframework auf API-Ebene, das in WebSphere Application Server implementiert wurde. Es wird eine Ausnahme wie die folgende angezeigt. Fehlernachricht und Fehlernummer können variieren.
[AIX Solaris HP-UX Linux Windows]
CWSRV0020E: [Servletfehler]-[validator]: Fehler beim Laden des Servlet:
java.security.AccessControlException: access denied 
(java.io.FilePermission 
Stammverzeichnis_des_Anwendungsservers/systemApps/isclite.ear/isclite.war/WEB-INF/validation.xml read) 
[z/OS]
CWSRV0020E: [Servletfehler]-[Validator]: Fehler beim Laden des Servlet:
java.security.AccessControlException: access denied  
(java.io.FilePermission 
/WebSphere/V6R1M0/AppServer/systemApps/isclite.ear/isclite.war/WEB-INF/validation.xml read)
[IBM i]
CWSRV0020E: [Servletfehler-[validator]: Fehler beim Laden des Servlet:
java.security.AccessControlException: access denied  
(java.io.FilePermission 
Stammverzeichnis_des_Anwendungsservers/systemApps/isclite.ear/isclite.war/WEB-INF/validation.xml read)

[AIX Solaris HP-UX Linux Windows][IBM i]Im Artikel Java-2-Sicherheit des Information Centers wird erläutert, wie und aus welchem Grund die Java-2-Sicherheitskomponente aktiviert bzw. inaktiviert wird und in welcher Beziehung sie zu Richtliniendateien steht. Außerdem wird erläutert, wie Richtliniendateien bearbeitet werden. Dieser Artikel beschreibt, dass die Java 2-Sicherheit nicht nur von diesem Produkt verwendet wird, sondern auch von Entwicklern für Geschäftsanwendungen implementiert werden kann. Wenn ein Client versucht, auf eine Ressource von WebSphere Application Server zuzugreifen und diese Ausnahme ausgelöst wird, müssen Administratoren sich möglicherweise an Entwickler wenden, um das Problem zu lösen.

Mögliche Fehlerursachen:
  • Syntaxfehler in einer Richtliniendatei
  • Syntaxfehler in Berechtigungsspezifikationen, die sich in der Datei ra.xml (gepackt in einer Datei mit der Erweiterung .rar) befinden. Dieser Fall gilt für Ressourcenadapter, die den Connector-Zugriff auf CICS bzw. andere Ressourcen unterstützen.
  • Eine Anwendung verfügt nicht über die angegebene Berechtigung, die sich in einer Richtliniendatei oder in einer Datei ra.xml (gepackt in einer Datei mit der Erweiterung .rar) befindet.
  • Der Klassenpfad ist nicht richtig definiert, wodurch verhindert wird, dass die Berechtigungen für die Datei resource.xml für die SPI (Service Provider Programming Interface) richtig erstellt werden.
  • Eine von einer Anwendung aufgerufene Bibliothek oder die Anwendung selbst verfügt nicht über den doPrivileged-Block, der für den Zugriff auf eine Ressource zulässig ist.
  • Die Berechtigung ist in der falschen Richtliniendatei angegeben.
Gehen Sie wie folgt vor, um diese Fehler zu beheben:
  • Prüfen Sie alle zugehörigen Richtliniendateien, um zu gewährleisten, dass die in der Ausnahme angegebene Berechtigung, z. B. java.io.FilePermission, angegeben ist.
  • Prüfen Sie, ob die Datei SystemOut.log eine zugehörige Ausnahme des Typs ParserException enthält, die die Einzeldaten des Syntaxfehlers angibt.
    [AIX Solaris HP-UX Linux Windows]Beispiele:
    CWSCJ0189E: Beim Erstellen der Schablone für die Anwendungsrichtlinie wurde eine Ausnahme des Typs ParserException abgefangen
    
    Profilstammverzeichnis/config/cells/Zellenname/nodes/Knotenname/app.policy
    [z/OS]
    CWSCJ0189E: Beim Erstellen der Schablone für die Anwendungsrichtlinie wurde eine Ausnahme des Typs ParserException abgefangen
    
    /WebSphere/V6R1M0/AppServer1/profiles/Profilname/config/cells/Zellenname/nodes/Knotenname/app.policy.
    [IBM i]
    CWSCJ0189E: Beim Erstellen der Schablone für die Anwendungsrichtlinie wurde eine Ausnahme des Typs ParserException abgefangen
    
    Profilstammverzeichnis/config/cells/Zellenname/nodes/Knotenname/app.policy
    Für diese Angaben gilt Folgendes:
    • [z/OS]V6R1M0 steht für die Version von WebSphere Application Server, die Sie verwenden.
    • Zellenname steht für den Namen Ihrer Zelle.
    • Profilname steht für den Namen Ihres Profils.
    • Knotenname steht für den Namen Ihres Knotens.
    Die Ausnahme ist com.ibm.ws.security.util.ParserException: Zeile 18: Erwartet wurde ';', Gefunden wurde 'grant'
  • Suchen Sie nach einer Nachricht wie CWSCJ0325W: Die in der Richtliniendatei definierte Berechtigung Berechtigung, konnte nicht aufgelöst werden.
  • Prüfen Sie den Aufruf-Stack, um festzustellen, welche Methode die Berechtigung nicht besitzt. Lokalisieren Sie den Klassenpfad dieser Methode. Wenn es schwierig ist, die die Methode zu lokalisieren, aktivieren Sie den Java-2-Sicherheitsbericht.
    • [AIX Solaris HP-UX Linux Windows][IBM i]RAS-Trace durch Angabe von com.ibm.ws.security.core.*=all=enabled bzw. einer Java-Eigenschaft des Typs property.java.security.debug konfigurieren. Gültige Werte für die Eigenschaft java.security.debug sind:
      access
      Gibt alle Debug-Informationen aus: erforderliche Berechtigung, Code, Stack und Position der Codebasis.
      stack
      Gibt folgende Debug-Informationen aus: erforderliche Berechtigung, Code und Stack.
      failure
      Gibt folgende Debug-Informationen aus: erforderliche Berechtigung und Code.
    • Der Bericht zeigt folgende Informationen an:
      Permission
      Gibt die fehlende Berechtigung an.
      Code
      Gibt an, in welcher Methode ein Problem auftritt.
      Stack Trace
      Gibt an, wo die Zugriffsverletzung aufgetreten ist.
      Code Base Location
      Gibt die Einzeldaten der einzelnen Stack-Rahmen an.
      [AIX Solaris HP-UX Linux Windows]Normalerweise reichen die Informationen zu "permission" und "code" aus, um das Problem zu lokalisieren. Das folgende Beispiel veranschaulicht einen Bericht:
      Permission: 
      Stammverzeichnis_des_Anwendungsservers/logs/server1/SystemOut_02.08.20_11.19.53.log :
      access denied (java.io.FilePermission 
      Stammverzeichnis_des_Anwendungsservers/logs/server1/SystemOut_02.08.20_11.19.53.log delete) 
      
      Code: 
       com.ibm.ejs.ras.RasTestHelper$7  in  
      {file:Stammverzeichnis_des_Anwendungsservers/installedApps/app1/JrasFVTApp.ear/RasLib.jar
      } 
      
      Stack Trace: 
      
      java.security.AccessControlException: access denied (java.io.FilePermission 
      Stammverzeichnis_des_Anwendungsservers/logs/server1/SystemOut_02.08.20_11.19.53.log delete
      ) 
              at java.security.AccessControlContext.checkPermission
                                    (AccessControlContext.java(Compiled Code)) 
              at java.security.AccessController.checkPermission
                                    (AccessController.java(Compiled Code))
              at java.lang.SecurityManager.checkPermission
                                    (SecurityManager.java(Compiled Code)) 
                                     . 
      Code Base Location: 
      
      com.ibm.ws.security.core.SecurityManager : 
      file:/Stammverzeichnis_des_Anwendungsservers/plugins/com.ibm.ws.runtime_6.1.0.jar
      
        ClassLoader: com.ibm.ws.bootstrap.ExtClassLoader 
        Permissions granted to CodeSource 
      (file:/Stammverzeichnis_des_Anwendungsservers/plugins/com.ibm.ws.runtime_6.1.0.jar <no certificates>
      
        { 
          (java.util.PropertyPermission java.vendor read); 
          (java.util.PropertyPermission java.specification.version read); 
          (java.util.PropertyPermission line.separator read); 
          (java.util.PropertyPermission java.class.version read); 
          (java.util.PropertyPermission java.specification.name read); 
          (java.util.PropertyPermission java.vendor.url read); 
          (java.util.PropertyPermission java.vm.version read); 
          (java.util.PropertyPermission os.name read); 
          (java.util.PropertyPermission os.arch read); 
         } 
         ( Diese Liste wird fortgesetzt.)
      [z/OS]
      Permission: 
      /WebSphere/AppServer/logs/server1/SystemOut_02.08.20_11.19.53.log : 
      access denied (java.io.FilePermission 
      WebSphere/AppServer/logs/server1/SystemOut_02.08.20_11.19.53.log delete) 
      
      Code: 
       com.ibm.ejs.ras.RasTestHelper$7  in  
      {file:/WebSphere/AppServer/installedApps/app1/JrasFVTApp.ear/RasLib.jar} 
      
      Stack Trace: 
      
      java.security.AccessControlException: access denied (java.io.FilePermission 
      
      /WebSphere/AppServer/logs/server1/SystemOut_02.08.20_11.19.53.log delete) 
              at java.security.AccessControlContext.checkPermission
                                    (AccessControlContext.java(Compiled Code)) 
              at java.security.AccessController.checkPermission
                                    (AccessController.java(Compiled Code))
              at java.lang.SecurityManager.checkPermission
                                    (SecurityManager.java(Compiled Code)) 
                                     . 
      Code Base Location: 
      
      com.ibm.ws.security.core.SecurityManager : 
      
      file:/WebSphere/AppServer/lib/securityimpl.jar
        ClassLoader: com.ibm.ws.bootstrap.ExtClassLoader 
        Permissions granted to CodeSource 
      (file:/WebSphere/AppServer/lib/securityimpl.jar <no certificates>
        { 
          (java.util.PropertyPermission java.vendor read); 
          (java.util.PropertyPermission java.specification.version read); 
          (java.util.PropertyPermission line.separator read); 
          (java.util.PropertyPermission java.class.version read); 
          (java.util.PropertyPermission java.specification.name read); 
          (java.util.PropertyPermission java.vendor.url read); 
          (java.util.PropertyPermission java.vm.version read); 
          (java.util.PropertyPermission os.name read); 
          (java.util.PropertyPermission os.arch read); 
         } 
         ( Diese Liste wird fortgesetzt.)
      [IBM i]
      Permission: 
      Profilstammverzeichnis/logs/server1/SystemOut_02.08.20_11.19.53.log : 
      access denied (java.io.FilePermission 
      Profilstammverzeichnis/logs/server1/SystemOut_02.08.20_11.19.53.log delete) 
      
      Code: 
       com.ibm.ejs.ras.RasTestHelper$7  in  
      {file:Profilstammverzeichnis/installedApps/app1/JrasFVTApp.ear/RasLib.jar
      } 
      
      Stack Trace: 
      
      java.security.AccessControlException: access denied (java.io.FilePermission 
      Profilstammverzeichnis/logs/server1/SystemOut_02.08.20_11.19.53.log delete
      ) 
              at java.security.AccessControlContext.checkPermission
                                    (AccessControlContext.java(Compiled Code)) 
              at java.security.AccessController.checkPermission
                                    (AccessController.java(Compiled Code))
              at java.lang.SecurityManager.checkPermission
                                    (SecurityManager.java(Compiled Code)) 
                                     . 
      Code Base Location: 
      
      com.ibm.ws.security.core.SecurityManager : 
      file:Stammverzeichnis_des_Anwendungsservers/plugins/com.ibm.ws.runtime_6.1.0.jar
      
        ClassLoader: com.ibm.ws.bootstrap.ExtClassLoader 
        Permissions granted to CodeSource 
      (file:Stammverzeichnis_des_Anwendungsservers/plugins/com.ibm.ws.runtime_6.1.0.jar <no certificates>
        { 
          (java.util.PropertyPermission java.vendor read); 
          (java.util.PropertyPermission java.specification.version read); 
          (java.util.PropertyPermission line.separator read); 
          (java.util.PropertyPermission java.class.version read); 
          (java.util.PropertyPermission java.specification.name read); 
          (java.util.PropertyPermission java.vendor.url read); 
          (java.util.PropertyPermission java.vm.version read); 
          (java.util.PropertyPermission os.name read); 
          (java.util.PropertyPermission os.arch read); 
         } 
         ( Diese Liste wird fortgesetzt.)
      Permission: 
      Profilstammverzeichnis/logs/server1/SystemOut_02.08.20_11.19.53.log : 
      access denied (java.io.FilePermission 
      Profilstammverzeichnis/logs/server1/SystemOut_02.08.20_11.19.53.log delete) 
      
      Code: 
       com.ibm.ejs.ras.RasTestHelper$7  in  
      {file:Profilstammverzeichnis/installedApps/app1/JrasFVTApp.ear/RasLib.jar} 
      
      Stack Trace: 
      
      java.security.AccessControlException: access denied (java.io.FilePermission 
      
      Profilstammverzeichnis/logs/server1/SystemOut_02.08.20_11.19.53.log delete) 
              at java.security.AccessControlContext.checkPermission
                                    (AccessControlContext.java(Compiled Code)) 
              at java.security.AccessController.checkPermission
                                    (AccessController.java(Compiled Code))
              at java.lang.SecurityManager.checkPermission
                                    (SecurityManager.java(Compiled Code)) 
                                     . 
      Code Base Location: 
      
      com.ibm.ws.security.core.SecurityManager : 
      
      file:Stammverzeichnis_des_Anwendungsservers/plugins/com.ibm.ws.runtime_6.1.0.jar
        ClassLoader: com.ibm.ws.bootstrap.ExtClassLoader 
        Permissions granted to CodeSource 
      (file:Stammverzeichnis_des_Anwendungsservers/plugins/com.ibm.ws.runtime_6.1.0.jar <no certificates>
        { 
          (java.util.PropertyPermission java.vendor read); 
          (java.util.PropertyPermission java.specification.version read); 
          (java.util.PropertyPermission line.separator read); 
          (java.util.PropertyPermission java.class.version read); 
          (java.util.PropertyPermission java.specification.name read); 
          (java.util.PropertyPermission java.vendor.url read); 
          (java.util.PropertyPermission java.vm.version read); 
          (java.util.PropertyPermission os.name read); 
          (java.util.PropertyPermission os.arch read); 
         } 
         ( Diese Liste wird fortgesetzt.)
      Permission: 
      Profilstammverzeichnis
      /logs/server1/SystemOut_02.08.20_11.19.53.log : 
      access denied (java.io.FilePermission 
      Profilstammverzeichnis
      /logs/server1/SystemOut_02.08.20_11.19.53.log delete) 
      
      Code: 
       com.ibm.ejs.ras.RasTestHelper$7  in  
      {file:Profilstammverzeichnis
      /installedApps/app1/JrasFVTApp.ear/RasLib.jar} 
      
      Stack Trace: 
      
      java.security.AccessControlException: access denied (java.io.FilePermission 
      
      Profilstammverzeichnis
      /logs/server1/SystemOut_02.08.20_11.19.53.log delete) 
              at java.security.AccessControlContext.checkPermission
                                    (AccessControlContext.java(Compiled Code)) 
              at java.security.AccessController.checkPermission
                                    (AccessController.java(Compiled Code))
              at java.lang.SecurityManager.checkPermission
                                    (SecurityManager.java(Compiled Code)) 
                                     . 
      Code Base Location: 
      
      com.ibm.ws.security.core.SecurityManager : 
      
      file:Stammverzeichnis_des_Anwendungsservers/plugins/com.ibm.ws.runtime_6.1.0.jar
        ClassLoader: com.ibm.ws.bootstrap.ExtClassLoader 
        Permissions granted to CodeSource 
      (file:Stammverzeichnis_des_Anwendungsservers/plugins/com.ibm.ws.runtime_6.1.0.jar <no certificates>
        { 
          (java.util.PropertyPermission java.vendor read); 
          (java.util.PropertyPermission java.specification.version read); 
          (java.util.PropertyPermission line.separator read); 
          (java.util.PropertyPermission java.class.version read); 
          (java.util.PropertyPermission java.specification.name read); 
          (java.util.PropertyPermission java.vendor.url read); 
          (java.util.PropertyPermission java.vm.version read); 
          (java.util.PropertyPermission os.name read); 
          (java.util.PropertyPermission os.arch read); 
         } 
         ( Diese Liste wird fortgesetzt.)
      Für diese Angaben gilt Folgendes:
      • app1 steht für den Namen Ihrer Anwendung.
      • Stammverzeichnis_des_Anwendungsservers steht für das Installationsstammverzeichnis von WebSphere Application ServerWebSphere Application Server Network Deployment.
      • Profilstammverzeichnis steht für Pfad und Namen eines bestimmten Profils in Ihrem System.
      • profile1 bzw. Profilname steht für den Namen Ihres Profils.
      • server1 bzw. Servername steht für den Namen Ihres Anwendungsservers.
  • Wenn SPI als Methode verwendet wird, prüfen Sie die Datei resources.xml, um sicherzustellen, dass der Klassenpfad richtig angegeben ist.
  • Wenn Sie bestätigen möchten, dass alle Richtliniendateien richtig geladen wurden bzw. welche Berechtigung den einzelnen Klassenpfaden erteilt wurde, müssen Sie den Trace mit der Eigenschaft com.ibm.ws.security.policy.*=all=enabled aktivieren. Alle geladenen Berechtigungen sind in der Datei trace.log aufgelistet. Suchen Sie nach app.policy, was.policy und ra.xml. Wenn Sie die Berechtigungsliste für einen Klassenpfad prüfen möchten, suchen Sie nach "Effective Policy for classpath".
  • Wenn die Richtliniendatei oder die Datei ra.xml Syntaxfehler enthält, korrigieren Sie sie mit dem policytool. Vermeiden Sie es, die Richtlinie manuell bearbeiten, da Sie auf diese Weise Syntaxfehler auslösen können.

  • Wenn eine Berechtigung als Nicht aufgelöst aufgeführt ist, ist sie nicht wirksam. Vergewissern Sie sich, dass der angegebene Berechtigungsname richtig ist.
  • Wenn der in der Datei resource.xml angegebene Klassenpfad nicht richtig ist, korrigieren Sie ihn.
  • Ist eine erforderliche Berechtigung in der Richtliniendatei bzw. in der Datei ra.xml nicht vorhanden, untersuchen Sie den Anwendungscode, um festzustellen, ob diese Berechtigung hinzugefügt werden muss. Ist das der Fall, fügen Sie die Berechtigung der Datei ra.xml hinzu.
  • Wenn die Berechtigung nicht außerhalb der spezifischen Methode, die auf diese Ressource zugreift, erteilt werden darf, muss der Code so geändert werden, dass er einen doPrivileged-Block verwendet.
  • [AIX Solaris HP-UX Linux Windows][IBM i]Wenn diese Berechtigung in einer Richtliniendatei oder einer ra.xml-Datei vorhanden ist und die Dateien ordnungsgemäß geladen wurden, für den Klassenpfad jedoch keine Berechtigung in der Liste angegeben ist, ist die Position der Berechtigung möglicherweise ungültig. Lesen Sie den Artikel Java-2-Sicherheit im Navigationsbereich des Information Center sorgfältig, um festzustellen, in welcher Richtliniendatei oder Datei ra.xml diese Berechtigung angegeben werden muss.
Tipp: Wenn die Anwendung mit der Java-Mail-API ausgeführt wird, können Sie die Datei Stammverzeichnis_der_installierten_Unternehmensanwendung/META-INF/was.policy so aktualisieren, dass der Anwendung die folgenden Berechtigungen erteilt werden:
  • permission java.io.FilePermission "${user.home}${/}.mailcap", "read";
  • permission java.io.FilePermission "${user.home}${/}.mime.types", "read";
  • permission java.io.FilePermission "${java.home}${/}lib${/}mailcap", "read";
  • permission java.io.FilePermission "${java.home}${/}lib${/}mime.types", "read";

Fehlernachricht: CWSCJ0336E: Die Authentifizierung von Benutzer {0} ist fehlgeschlagen, weil die Ausnahme {1} eingetreten ist.

Diese Fehlernachricht erscheint, wenn die angegebene Benutzer-ID nicht in der LDAP-Benutzerregistry gefunden wird. Gehen Sie wie folgt vor, um den Fehler zu beheben:
  1. Überprüfen Sie, ob Benutzer-ID und Kennwort richtig eingegeben wurden.
  2. Vergewissern Sie sich, dass der Benutzer in der Registry vorhanden ist.
  3. Überprüfen Sie, ob der definierte Basisname (DN) richtig eingegeben wurde.
  4. Vergewissern Sie sich, dass der Benutzerfilter richtig angegeben wurde.
  5. Überprüfen Sie, ob der Bind-DN und das Kennwort für den Bind-DN richtig angegeben wurden. Wenn der Bind-DN und das Kennwort nicht angegeben wurden, machen Sie die Angaben, und wiederholen Sie anschließend den Vorgang.
  6. Überprüfen Sie, ob der Hostname und der LDAP-Typ richtig angegeben wurden.
Sollte der Fehler weiterhin auftreten, wenden Sie sich an den Administrator der Benutzerregistry.

Fehlernachricht: Bei der Initialisierung des Sicherheits-Collaborators ist eine unerwartete Ausnahme eingetreten. java.lang.SecurityException: AuthConfigFactory error: java.lang.ClassNotFoundException: org.apache.geronimo.components.jaspi.AuthConfigFactoryImpl

Diese Fehlernachricht tritt ein, wenn der Datei "java.security" ein Eintrag für den JASPI-Provider fehlt. Die Standardposition für die Datei "java.security" ist Installationsverzeichnis/properties. Bearbeiten Sie die Datei "java.security", und fügen Sie der Datei die folgenden Zeilen hinzu:
#
# Der vollständig qualifizierte Klassenname der JASPI-Factory-Standardimplementierungsklasse.
#
authconfigprovider.factory=com.ibm.ws.security.jaspi.ProviderRegistry
Anmerkung: Dieser wird nur angezeigt, wenn Sie Ihre Konfiguration so definiert haben, dass diese Klasse verwendet wird. Andernfalls sehen Sie die folgende Fehlernachricht SECJ8032W.

Fehlernachricht: SECJ8032W: AuthConfigFactory is undefined, using the default JASPI factory implementation class

Diese Fehlernachricht wird angezeigt, wenn die JASPI-Factory-Implementierung nicht definiert ist. Die JASPI-Standardfactoryimplementierung wurde in der Serverlaufzeit definiert. JASPI funktioniert jedoch möglicherweise nicht für einen Client.

Geben Sie zur Behebung des Problems den vollständig qualifizierten Klassennamen der JASPI-Factory-Standardimplementierungsklasse als Wert für die Eigenschaft "authconfigprovider.factory" in der Datei "java.security" wie im folgenden Beispiel an:
#
# Der vollständig qualifizierte Klassenname der JASPI-Factory-Standardimplementierungsklasse.
#
authconfigprovider.factory=com.ibm.ws.security.jaspi.ProviderRegistry

Fehlernachricht: SECJ0352E: Die Benutzer, die dem Muster {0} entsprechen, konnten nicht abgerufen werden, weil die Ausnahme {1} eingetreten ist

Diese Nachricht zum Authentifizierungsfehler wird angezeigt, wenn ein externes Repository für Benutzeraccounts beschädigt oder nicht verfügbar ist und WebSphere Application Server den Benutzernamen im Repository nicht authentifizieren kann. Im Allgemeinen beinhalten Nachrichten zu Authentifizierungsfehlern zusätzliche Informationen, die die Spezifik oder eigentliche Fehlerursache anzeigen, wie z. B.:

Stellen Sie sicher, dass die Benutzer, die diesem Muster entsprechen, in der Registry enthalten sind. Wenden Sie sich an den Kundendienst, wenn das Problem weiterhin auftritt.

Diese zusätzlichen Informationen legen möglicherweise keine klare Benutzeraktion fest, wenn das Repository für Benutzeraccounts fehlerhaft ist oder der Benutzer die Verbindung zwischen WebSphere Application Server und einem externen Repository für Benutzeraccounts verliert. Das externe Repository für Benutzeraccounts, das in diesem Dokument einfach als Repository bezeichnet wird, muss ein LDAP-Produkt (Lightweight Directory Access Protocol) sein.
Um dieses Problem zu lösen, müssen Sie das Repository möglicherweise neu installieren und den Installationserfolg durch einen Verbindungstest sicherstellen.
Vorsicht:
Fahren Sie mit den folgenden Schritten nur fort, wenn Sie sichergestellt haben, dass alle Konfigurationseinstellungen, die sich auf WebSphere Application Server beziehen, richtig sind.
Führen Sie die folgenden Schritte aus, um das Problem zu lösen:
  1. Führen Sie für das Repository und WebSphere Application Server einen Neustart durch.
  2. Testen Sie die Verbindung zum Repository. Wenn der Verbindungsversuch wieder fehlschlägt, müssen Sie das Repository möglicherweise noch einmal installieren.
  3. Verfügt das Repository über ein eigenes Diagnoseprogramm, sollten Sie es ausführen, um eine Neuinstallation eventuell vermeiden zu können.
    Achtung: Konnte das Problem mit den vorherigen Schritten nicht gelöst werden, müssen Sie das Repository möglicherweise neu installieren. Generieren Sie eine vollständige Liste aller konfigurierten Benutzer und Gruppen, bevor Sie fortfahren. Sie müssen diese Felder nach der Neuinstallation erneut ausfüllen.
  4. Installieren Sie das beschädigte Repository erneut, falls nötig.
  5. Geben Sie die Benutzer und Gruppen aus Ihrer Liste im neu installierten Repository an.
  6. Führen Sie für das Repository und WebSphere Application Server einen Neustart durch.
  7. Klicken Sie in der Administrationskonsole auf Sicherheit > Globale Sicherheit, und wählen Sie das entsprechende Repository für Benutzeraccounts aus. Wählen Sie beispielsweise die Option Eigenständige LDAP-Registry aus, wenn Sie ein LDAP-Repository verwenden.
  8. Klicken Sie auf Verbindung testen, um sicherzustellen, dass WebSphere Application Server eine Verbindung zum Repository herstellen kann.

Die Validierung des LTPA-Token ist fehlgeschlagen aufgrund ungültiger Schlüssel oder ungültigem Tokentyp.

Wenn die Entserialisierung des Sicherheitskontexts eines LTPA-Tokens mit einer Ausnahme des Typs "WSSecurityException" fehlschlägt, die die folgende Nachricht enthält: Validation of LTPA token failed due to invalid keys or token type, setzen Sie die Eigenschaft "com.ibm.websphere.security.recoverContextWithNewKeys" auf true.

Fehler bei Schlüsselgenerierung, wenn Profile Management Tool verwendet wird

Wenn Sie ein neues Profil mit Profile Management Tool oder mit dem Befehlszeilendienstprogramm "manageprofiles" erstellen, erscheint eine Fehlernachricht, die darüber informiert, dass die Erstellung teilweise erfolgreich war oder fehlgeschlagen ist. Die Fehlernachricht, die sich in der Datei Installationsverzeichnis/logs/manageprofiles/Profilname_create.log befindet, verweist möglicherweise auf einen Fehler in der Task "generateKeysforSingleProfile" oder "generateKeysForCellProfile".

Der Assistent für Profilerstellung und das Dienstprogramm manageprofiles rufen verschiedene Tasks auf. Die Task generateKeysForSingleProfile wird aufgerufen, wenn Sie einen eigenständigen Anwendungsserver oder ein Deployment-Manager-Profil erstellen. Die Task generateKeysForCellProfile wird aufgerufen, wenn Sie ein Zellenprofil erstellen. Beide Tasks rufen die wsadmin-Befehle zuerst auf. Obwohl das Protokoll einen Fehler in einer dieser Tasks anzeigt, ist der Fehler möglicherweise auf einen wsadmin-Befehl und nicht auf die Sicherheitstasks zurückzuführen.

Möchten Sie die tatsächliche Ursache des Problems ermitteln, überprüfen Sie die Informationen in den folgenden Protokolldateien:

  • Die Datei Installationsverzeichnis/logs/manageprofiles/Profilename_create.log zeigt den Fehlercode des Fehlers an
  • Datei Installationsverzeichnis/logs/manageprofiles/Profilname/keyGeneration.log
  • Datei Installationsverzeichnis/logs/manageprofiles/Profilname/wsadminListener.log

Einige Sicherheitsrollen sind für eine gesicherte Anwendung nicht sofort verfügbar, wenn Tivoli Access Manager in LDAP aktiviert ist.

In einigen Fällen sind einige Sicherheitsrollen unter Umständen nicht direkt verfügbar, wenn Sie eine gesicherte Anwendung implementieren und Tivoli Access Manager in LDAP aktiviert ist.

Es kann ein Fehler wie der folgende angezeigt werden:
"Exception: java.lang.OutOfMemoryError"
Möglicherweise können Sie dieses Problem wie folgt beheben:
  1. Ordnen Sie Hauptspeicher für die minimale und maximale Heap-Speichergröße zu.
    1. Klicken Sie in der Administrationskonsole auf Server > Servertypen > WebSphere-Anwendungsserver > server1.
    2. Wählen Sie Serverinfrastruktur > Java- und Prozessverwaltung > Prozessdefinition aus.
    3. Wählen Sie "Java Virtual Machine" aus.
    4. Setzen Sie die Anfangsgröße des Heap-Speichers auf 512 MB und die maximale Größe des Heap-Speichers auf 1024 MB.
    5. Wählen Sie OK und anschließend Speichern aus.
    6. Starten Sie WebSphere Application Server erneut.
  2. Fügen Sie einige Optimierungseigenschaften für das integrierte Produkt Tivoli Access Manager hinzu, während WebSphere Application Server gestoppt ist.
    1. Bearbeiten Sie die Datei amwas.amjacc.template.properties im Verzeichnis config/cells/ZELLENNAME, in dem Sie der Datei die folgenden Eigenschaften hinzufügen:
      com.tivoli.pd.as.jacc.DBRefresh=0
      com.tivoli.pd.as.jacc.AuthTableRemoteMode=yes
      com.tivoli.pd.as.rbpf.NoUncheckedRoles=true

      Dies hilft Ihnen bei der Rekonfiguration des integrierten Produkts Tivoli Access Manager.

    2. Da das integrierte Produkt Tivoli Access Manager bereits konfiguriert ist, können Sie die generierten Konfigurationsdateien mit den zuvor genannten Eigenschaften aktualisieren. Wechseln Sie für jede Instanz von WebSphere Application Server in Network Deployment (dmgr, NAs und Server) in das Verzeichnis profiles/NAME/etc/tam, und führen Sie die folgenden Aktionen aus.
      Fügen Sie für jede Datei, die mit "amjacc.properties" endet, die genannten drei Eigenschaften hinzu:
      com.tivoli.pd.as.jacc.DBRefresh=0
      com.tivoli.pd.as.jacc.AuthTableRemoteMode=yes
      com.tivoli.pd.as.rbpf.NoUncheckedRoles=true

      Aktualisieren Sie für jede Datei, die mit "pdperm.properties" endet, die Eigenschaft "appsvr-dbrefresh" wie folgt: appsvr-dbrefresh=0

      Aktualisieren Sie für jede Datei, die mit "authztable.pdperm.properties" endet, die Eigenschaft "appsvr-mode" wie folgt: appsvr-mode=remote

  3. Starten Sie die Zelle erneut.

Nachdem der Domänenrealm auf nicht vertrauenswürdig gesetzt wurde, können die globalen Sicherheitseinstellungen nicht mehr verwendet werden

Wenn Sie einen vertrauenswürdigen Domänenrealm hinzufügen und zu einem späteren Zeitpunkt entscheiden, diesen Realm in der Administrationskonsole auf "Nicht vertrauenswürdig" zu setzen, wird möglicherweise ein leerer inboundTrustedAuthenticationRealm-Eintrag in der Datei domain-security.xml generiert. Diese leere Definition für eingehende oder abgehende vertrauenswürdige Realms in der Datei domain-security.xml verhindert, dass diese Domäne globale Sicherheitseinstellungen verwenden kann.

Gehen Sie wie folgt vor, um dieses Problem zu beheben:
  1. Entfernen Sie die aktuelle Domäne.
  2. Erstellen Sie eine neue Domäne.
  3. Fügen Sie den falschen Realm nicht als "Vertrauenswürdig" hinzu.

Aktualisierte Namen des globalen Sicherheitsrealms werden dupliziert

Wenn die Namen der globalen Sicherheitsrealms aktualisiert werden, werden auch die Realmnamen der Anwendungssicherheitsdomäne mit denselben Realmnamen aktualisiert.

In WebSphere Application Server Version 8.0 können Sie eine eindeutige Instanz eines eingebundenen Repositorys auf Domänenebene in einer Umgbung mit mehreren Sicherheitsdomänen zusätzlich zu einer vorhandenen Instanz auf globaler Ebene konfigurieren. Wenn jedoch die Benutzerregistry der eingebundenen Repositorys auf globaler Ebene konfiguriert werden oder wenn die Realmnamen auf globaler Ebene nach der Konfiguration der Sicherheitsdomänen konfiguriert werden, werden die Realmnamen für alle Sicherheitsdomänen, die eingebundene Repositorys verwenden, ebenfalls aktualisiert. Dies führt dazu, dass alle Domänen, die eingebundene Repositorys verwenden, das eingebundene Repository verwenden, das auf globaler Ebene definiert ist.

Um dieses Problem zu beheben, aktualisieren Sie Sicherheitsdomänen, die eingebundene Repositorys verwenden, mit dem ursprünglichen Realmnamen, nachdem Sie die eingebundenen Repositorys erstellt haben oder ändern Sie die Realmnamen auf globaler Ebene. Sie können das Problem umgehen, wenn ein eingebundenes Repository auf globaler Ebene konfiguriert wird, bevor Sie ein eingebundenes Repository in einer Sicherheitsdomäne konfigurieren.

Anmerkung: Wenn die Namen der globalen Sicherheitsrealms aktualisiert werden, werden die Realmnamen der Anwendungssicherheitsdomäne in Fixpack 2 nicht mit denselben Realmnamen aktualisiert.

Wenn das Sitzungssicherheitsfeature aktiviert wird, kann ein Fehler auftreten

Wenn das Sitzungssicherheitsfeature aktiviert ist (dies ist der Standardwert in WebSphere Application Server Version 8.0) und mehrere Sitzungen verwenden dieselbe Benutzer-ID, kann Folgendes eintreten: Wenn sich ein Benutzer aus einer Sitzung abmeldet, wird möglicherweise in einer anderen Sitzung der folgende Fehler angezeigt, wenn sich ein anderer Benutzer abmeldet, der mit derselben Benutzer-ID angemeldet ist:
SESN0008E:
Ein als "anonymous" authentifizierter Benutzer hat versucht, auf eine Sitzung zuzugreifen, deren Eigner {<Benutzer>} ist.

Um dieses Problem zu beheben, sollten Sie sicherstellen, dass der vorherige Benutzer abgemeldet ist, bevor sich ein anderer Benutzer mit derselben Benutzer-ID anmeldet.

Fehler vermeiden Fehler vermeiden: Dieses Problem kann möglicherweise auch in einigen Instanzen auftreten, wenn das Sitzungssicherheitsfeature nicht aktiviert ist. In diesem Fall ist die Lösung des Problems dieselbe: Stellen Sie sicher, dass der vorherige Benutzer abgemeldet ist, bevor sich ein anderer Benutzer mit derselben Benutzer-ID anmeldet. gotcha
[z/OS]

ABEND WITH ABEND EC3 REASON=020F2001

Wird die Sicherheit nicht unmittelbar bei Installation von WebSphere Application Server for z/OS, über zPMT-Dialoge oder ISPF-Anpassungsdialoge aktiviert, werden die RACF-Definitionen nicht vollständig generiert. Wenn die Sicherheit später über die Administrationskonsole aktiviert wird, verhindert eine fehlende RACF-Anweisung, dass die Steuerregion von WebSphere Application Server gestartet wird. Weitere Informationen zur Behebung dieses Problems finden Sie im APAR PK36598.


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=rtrb_secprobs2
Dateiname:rtrb_secprobs2.html