Fehler bei der Konfiguration und Aktivierung der Sicherheit

Verwenden Sie diesen Artikel, um Probleme bei der Konfiguration oder Aktivierung der Sicherheit zu beheben.

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.

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

Fehlernachricht "LTPA-Kennwort nicht gesetzt. Validierung fehlgeschlagen" error message

Die Nachricht "LTPA-Kennwort nicht gesetzt. Validierung fehlgeschlagen" erscheint nach dem Speichern der Verwaltungs- und Anwendungssicherheitseinstellungen als Fehlermeldung in der Administrationskonsole.

Dieser Fehler tritt auf, wenn die Konfiguration der Sicherheitskomponente von WebSphere Application Server, "LTPA", als Authentifizierungsverfahren ausgewählt und das Feld für das LTPA-Kennwort nicht definiert wird. Gehen Sie wie folgt vor, um den Fehler zu beheben:
  • Wählen Sie Sicherheit > Globale Sicherheit > Authentifizierungsverfahren und Verfallszeit > LTPA aus.
  • Füllen Sie die Felder für das Kennwort und die Kennwortbestätigung aus.
  • Klicken Sie auf OK.
  • Versuchen Sie erneut, die Verwaltungs- oder Anwendungssicherheit zu aktivieren.
[AIX Solaris HP-UX Linux Windows][z/OS]

Die Datei "setupClient.bat" bzw. "setupClient.sh" funktioniert nicht ordnungsgemäß

Die Datei setupClient.bat auf Windows-Betriebssystemen bzw. setupClient.sh auf Linux- und UNIX-basierten Plattformen enthält ungültige Angaben für das Verzeichnis der Datei mit den SOAP-Sicherheitseigenschaften.
[Windows]In der Datei setupClient.bat muss das richtige Verzeichnis wie folgt lauten:
set CLIENTSOAP=-Dcom.ibm.SOAP.ConfigURL=file:%WAS_HOME%/properties/soap.client.props
[AIX][Linux][AIX HP-UX Solaris][z/OS]In der Datei setupClient.sh ist die Variable CLIENTSOAP wie folgt gesetzt:
CLIENTSOAP=-Dcom.ibm.SOAP.ConfigURL=file:$WAS_HOME/properties/soap.client.props
Bearbeiten Sie die Dateien setupClient.bat und setupClient.sh wie folgt:
  1. Entfernen Sie den führenden Schrägstrich ( / ) hinter file:.
  2. Ändern Sie sas in soap.
[HP-UX]

Warnung zur Java-HotSpot-Server-VM

Wenn Sie die Sicherheit auf der Plattform HP-UX 11i aktivieren, wird der folgende Fehler in der Datei native_stdout.log aufgezeichnet. Außerdem wird ein Kernspeicherauszug erstellt, und WebSphere Application Server wird nicht gestartet.
Warnung zur Java-HotSpot-Server-VM: Unexpected Signal 11 occurred under user-defined signal handler 0x7895710a
Sie können diesen Fehler vermeiden, indem Sie die von Hewlett Packard für Java™ empfohlenen Fixes, die Sie unter der folgenden URL finden, anwenden: http://www.hp.com.

WebSphere Application Server Version 6 funktioniert mit dem Enterprise Workload Manager (EWLM) nicht

Wenn Sie WebSphere Application Server Version 6 mit EWLM verwenden möchten, müssen Sie die Dateien mit dem Namen "server.policy" von WebSphere Application Server manuell aktualisieren. Beispiel:
grant codeBase "file:/<EWLM-Installationsausgangsverzeichnis>/classes/ARM/arm4.jar" {
 permission java.security.AllPermission;
};
Andernfalls könnten Sie eine Java-2-Sicherheitsausname wegen eines Verstoßes gegen die Java-2-Sicherheitsberechtigung empfangen.

Nähere Informationen zur Konfiguration der Dateien "server.policy" finden Sie im Artikel Berechtigungen der Datei "server.policy".

Aktuelle Informationen des IBM Support zu bekannten Problemen und ihrer Behebung finden Sie auf der Webseite des IBM Support.

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 PMR öffnen, lesen Sie bitte die Informationen auf der Webseite des IBM Support.

NMSV0610I: Von einer javax.naming.Context-Implementierung wurde eine NamingException ausgelöst.

Wenn Sie mit eingehender Authentifizierung gemäß CSIv2 arbeiten, ist eine Basisauthentifizierung erforderlich, und Java-Clients, die mit com.ibm.CORBA.validateBasicAuth=true ausgeführt werden, können mit der folgenden Ausnahme fehlschlagen:
Wenn Sie mit eingehender Authentifizierung gemäß CSIv2 arbeiten, ist eine
Basisauthentifizierung erforderlich, und Java-Clients, die mit com.ibm.CORBA.validateBasicAuth=true
ausgeführt werden, können mit der folgenden Ausnahme fehlschlagen:

NMSV0610I: Von einer javax.naming.Context-Implementierung wurde eine NamingException ausgelöst.
Einzelheiten folgen:

Kontextimplementierung: com.ibm.ws.naming.jndicos.CNContextImpl
Kontextmethode: lookupExt
Kontextname: TestaburgerNode01Cell/nodes/TestaburgerNode01/servers/server1
Zielname: SecurityServer
Weitere Daten: "" ""
Stack-Trace zur Ausnahme: javax.naming.NoPermissionException: NO_PERMISSION exception caught. Eigentliche Ausnahme: org.omg.CORBA.NO_PERMISSION: vmcid: 0x49421000 minor code: 92 completed: No
...
SECJ0395E: Der SecurityServer an Host/Port:9.42.72.27/9100 für die Validierung der eingegebenen Benutzer-ID/Kennwort-Kombination wurde nicht gefunden. Möglicherweise ist in der Datei
"(WAS_INSTALL_ROOT)/properties/sas.client.props" kein gültiger Host/Portwert für den SecurityServer angegeben.

Zur Behebung dieses Problems ändern Sie die Eigenschaft com.ibm.CORBA.validateBasicAuth=false in der Clientdatei sas.clients.props im Verzeichnis WAS_HOME/profiles/<Profilname>/properties und führen anschließend den Client aus.

Leistungsservlet zeigt Berechtigungsfehler an und kann keine Statistikdaten bereitstellen

In WebSphere Application Server Version 6.1 wird der Verwaltungsservice bei Aktivierung der Verwaltungssicherheit gesperrt. Ist die Anwendungssicherheit jedoch nicht aktiviert, wird für eingehende Anforderungen keine Authentifizierungsanforderung abgesetzt, und das Leistungsservlet hat keine Berechtigungsnachweise für den Zugriff auf den Verwaltungsservice.

Wenn die Verwaltungssicherheit aktiviert ist, müssen Sie auch die Anwendungssicherheit aktivieren, damit das Leistungsservlet eingehende Anforderungen verarbeiten kann.

Bei der Migration von Benutzern und Gruppen wird nach der Konfiguration des JACC-Providers für Tivoli eine Fehlernachricht wie "Namenswert ist ungültig" angezeigt

[AIX Solaris HP-UX Linux Windows][IBM i]Wenn Sie das Dienstprogramm "migrateEAR" verwenden, um die Änderungen, die nach der Konfiguration des JACC-Providers für Tivoli Access Manager an Konsolbenutzern und -gruppen vorgenommen wurden, zu migrieren, wird der folgende Konfigurationsfehler in der Datei "systemOut.log" angezeigt.

[z/OS]Wenn Sie das Dienstprogramm "migrateEAR" verwenden, um die Änderungen, die nach der Konfiguration des JACC-Providers für Tivoli Access Manager an Konsolbenutzern und -gruppen vorgenommen wurden, zu migrieren, wird der folgende Konfigurationsfehler in der entsprechenden Ausgabe der Jobprotokolldatei angezeigt.

<specialSubjects> Namenswert ist ungültig
[z/OS]Anmerkung: Da die Datei "SystemOut.log" im Betriebssystem z/OS nicht existiert, müssen Sie die Ausgabe des entsprechenden Jobprotokolls im Betriebssystem z/OS überprüfen.

Das Dienstprogramm "migrateEAR" migriert die in der Datei "admin-authz.xml" enthaltenen Benutzer- und Gruppendaten. Es konvertiert jedoch nicht die in der Datei "admin-authz.xml" aufgelisteten XML-Tags, wenn die Gruppe pdwas-admin vor der Migration zur Zugriffssteuerungsliste (ACL) des Administrators in Tivoli Access Manager hinzugefügt wird.

Geben Sie zur Behebung dieses Fehlers den folgenden Befehl in padadmin ein, um vor der Migration zu prüfen, ob die Gruppe pdwas-admin sich in der ACL des Administrators befindet:

acl show
_WebAppServer_deployedResources_Roles_administrator_admin-authz_ACL

Das folgende Ergebnis sollte angezeigt werden:

ACL Name:
_WebAppServer_deployedResources_Roles_administrator_admin-authz_ACL
Description: Created by the Tivoli Access Manager
for Websphere Application Server Migration Tool.
Entries:
User sec_master TcmdbsvaBR1
Group pdwas-admin T[WebAppServer]i

Wenn die Gruppe pdwas-admin nicht aufgelistet ist, geben Sie den folgenden Befehl in pdadmin ein, um die ACL der Gruppe pdwas-admin hinzuzufügen:

acl modify 
_WebAppServer_deployedResources_Roles_administrator_admin
-authz_ACL set gruop pdwas-admin T [WebAppServer]i

Sun-JDK kann einen PKCS12-Keystore, der von Application Server erstellt wurde, nicht lesen

Ein Sun-JDK kann keine PKCS12-Keystores lesen, die von Application Server erstellt wurden. Das Sun-JDK kann den Keystore nicht lesen, weil die PKCS12-Implementierung, die von IBM SDK und Application Server verwendet wird, von der im Sun-JDK verwendeten Implementierung abweicht. Diese Abweichung verursacht Probleme, wenn ein Sun-JDK verwendet wird, um den Standard-Trustore "trust.p12" oder den Keystore "key.P12" zu lesen, der von Application Server erstellt wird.

Da der Truststore vom Sun-JDK nicht gelesen werden kann, müssen Sie die Zertifikate zuerst mit einem IBM SDK aus dem Trustore extrahieren. Anschließend können Sie diese Zertifikate in einen Keystore importieren, den das Sun-JDK erkennt, z. B. in einen JKS-Keystore.

Aufruf einer sicheren Ressource aus einer nicht sicheren Ressource wird nicht unterstützt

Wenn Sie eine nicht sichere Ressource verwenden (z. B. JSP oder ein Servlet), die eine sichere Ressource aufruft, kann die Anwendung fehlschlagen, wenn die nicht sichere Ressource Daten von Benutzern erfasst und diese Daten zur Verarbeitung an sichere JSP- oder Servletdateien übergibt.

Zum Vermeiden einer solchen Situation sollten Sie Ihre Webanwendung so strukturieren, dass sich die Benutzer anmelden müssen, bevor die Anwendung HTTP-Post-Aktionen für sichere JSP- oder Servletdateien ausführt. Dazu müssen sie die erste Ressource mit Ihrem gewünschten Sicherheitsmechanismus schützen (z. B. Basisauthentifizierung, formularbasierte Anmeldung oder Zertifizierung).

Diese Einschränkung gilt aus dem Grund, weil die Basisauthentifizierung und die formularbasierte Anmeldung die Servletmethode "sendRedirect" verwenden, die mehrere Auswirkungen für den Benutzer hat. Die Methode "sendRedirect" wird während der Basisauthentifizierung und der formularbasierte Anmeldung zweimal verwendet.

Die Methode "sendRedirect" zeigt anfangs die Seite für Basisauthentifizierung oder für formularbasierte Anmeldung im Web-Browser an. Später führt sie den Web-Browser dann zur ursprünglich angeforderten geschützten Seite zurück. Die Methode sendRedirect(String URL) weist den Web-Browser an, die im URL angegebene Seite mit der Anforderung HTTP GET aufzurufen. Wenn HTTP POST die erste Anforderung an ein geschütztes Servlet oder eine geschützte JSP-Datei ist und keine frühere Authentifizierung oder Anmeldung durchgeführt wurde, wird die Anforderung HTTP POST nicht an die angeforderte Seite übermittelt. HTTP GET wird jedoch übergeben, weil die Basisauthentifizierung und die formularbasierte Anmeldung die Methode "sendRedirect" verwenden, die sich wie eine Anforderung HTTP GET verhält und versucht, nach einer Anmeldung die angeforderte Seite anzuzeigen.


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_secconfigprobs
Dateiname:rtrb_secconfigprobs.html