Fehler bei der Konfiguration und Aktivierung der Sicherheit
Verwenden Sie diesen Artikel, um Probleme bei der Konfiguration oder Aktivierung der Sicherheit zu beheben.
- Fehlernachricht "LTPA-Kennwort nicht gesetzt. Validierung fehlgeschlagen" error message
Die Datei "setupClient.bat" bzw. "setupClient.sh" funktioniert nicht ordnungsgemäß
Warnung zur Java-HotSpot-Server-VM
- WebSphere Application Server Version 6 funktioniert mit dem Enterprise Workload Manager (EWLM) nicht
- Wenn Sie die Sicherheitskomponente konfiguriert haben, jetzt jedoch Schwierigkeiten haben, auf Webressourcen oder die Administrationskonsole zuzugreifen, lesen Sie den Artikel Fehler bzw. Zugriffsfehler nach Aktivieren der Sicherheitskomponente.
- NMSV0610I: Von einer javax.naming.Context-Implementierung wurde eine NamingException ausgelöst.
- Leistungsservlet zeigt Berechtigungsfehler an und kann keine Statistikdaten bereitstellen
- 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
- Sun-JDK kann einen PKCS12-Keystore, der von Application Server erstellt wurde, nicht lesen
- Aufruf einer sicheren Ressource aus einer nicht sicheren Ressource wird nicht unterstützt
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.
- Wählen Sie 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]](../images/dist.gif)
![[z/OS]](../images/ngzos.gif)
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]](../images/windows.gif)
set CLIENTSOAP=-Dcom.ibm.SOAP.ConfigURL=file:%WAS_HOME%/properties/soap.client.props
![[AIX]](../images/aixlogo.gif)
![[Linux]](../images/linux.gif)
![[AIX HP-UX Solaris]](../images/unix.gif)
![[z/OS]](../images/ngzos.gif)
CLIENTSOAP=-Dcom.ibm.SOAP.ConfigURL=file:$WAS_HOME/properties/soap.client.props
- Entfernen Sie den führenden Schrägstrich ( / ) hinter file:.
- Ändern Sie sas in soap.
![[HP-UX]](../images/hpux.gif)
Warnung zur Java-HotSpot-Server-VM
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
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:
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
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.
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]](../images/ngzos.gif)
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.