Zugriffsfehler nach Aktivierung der Sicherheitskomponente

Verwenden Sie diese Informationen, wenn nach dem Aktivieren der Sicherheit Zugriffsprobleme 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.

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

[AIX Solaris HP-UX Linux Windows][IBM i]Falls Sie kein Problem finden, das Ihrem Problem gleicht, oder falls Sie das Problem mit bereitgestellten Informationen nicht beheben können, suchen Sie in der Hilfe zur Fehlerbehebung von IBM nach weiteren Informationen.

Nach dem Aktivieren der Sicherheitskomponente ist der partielle bzw. vollständige Zugriff auf die Administrationskonsole oder die Verwendung des Tools wsadmin nicht möglich

  • [AIX Solaris HP-UX Linux Windows][IBM i]Sollten Sie nicht auf die Administrationskonsole zugreifen können oder bestimmte Objekte nicht anzeigen oder aktualisieren können, suchen Sie im Protokoll SystemOut des Anwendungsservers, in dem sich die Seite der Administrationskonsole befindet, nach einer diesbezüglichen Fehlernachricht.
  • [z/OS]Sollten Sie nicht auf die Administrationskonsole zugreifen können oder bestimmte Objekte nicht anzeigen oder aktualisieren können, suchen Sie in den Protokollen des Anwendungsservers, in dem sich die Seite der Administrationskonsole befindet, nach einer diesbezüglichen Fehlernachricht.
    Anmerkung: Sie benötigen für die nächsten beiden Punkte die Administrationskonsole. Sollten Sie Probleme beim Zugriff auf die Administrationskonsole haben, müssen Sie die Sicherheit inaktivieren und die Administrationskonsole erneut starten. Geben Sie zum Inaktivieren der Sicherheit an der Eingabeaufforderung den folgenden Befehl ein:
    wsadmin.sh -conntype NONE
    Geben Sie Folgendes ein, wenn die Eingabeaufforderung wieder angezeigt wird:
    securityoff
    Starten Sie den Deployment Manager erneut, nachdem Sie die Sicherheit inaktiviert haben.
  • Möglicherweise hat Ihre ID keine Berechtigung für Verwaltungstasks. Dieses Problem wird angezeigt durch Fehlermeldungen wie die folgenden:
    • [8/2/02 10:36:49:722 CDT] 4365c0d9 RoleBasedAuth A CWSCJ0305A: Die rollenbasierte Berechtigungsprüfung ist für den Sicherheitsnamen MeinServer/MeineBenutzer-ID mit der Zugriffs-ID MeinServer/S-1-5-21-882015564-4266526380-2569651501-1005 beim Abruf der Methode getProcessTyp für Ressource Server und Modul Server fehlgeschlagen.
    • Ausnahmenachricht: "CWWMN0022E: Der Zugriff auf die Operation getProcessType in der MBean "Server" wurde verweigert."
    • Beim Ausführen des Befehls wird folgende Fehlernachricht angezeigt: wsadmin -username j2ee -password j2ee: CWWAX7246E: Es kann keine Verbindung vom Typ "SOAP" zu Host "BIRKT20" hergestellt werden, weil ein Authentifizierungsfehler aufgetreten ist. Vergewissern Sie sich, dass der Benutzer und das Kennwort in der Befehlszeile bzw. in einer Eigenschaftendatei richtig angegeben wurden.
    Wählen Sie in der Administrationskonsole Systemverwaltung > Konsolbenutzer aus, und überprüfen Sie, ob die ID ein Member ist. Ist dies nicht der Fall, erteilen Sie der ID mindestens die Berechtigung "Überwachung", und fügen Sie sie für den Lesezugriff (Read-Only) hinzu.
  • Vergewissern Sie sich, dass die Funktionalität der gesicherten Anwendung aktiviert ist. Die Funktionalität der gesicherten Anwendung ist aktiviert, wenn WebSphere Application Server SAF-Lesezugriff auf die RACF-Klasse FACILITY und das Profil BBO.TRUSTEDAPPS.<Kurzname_der_Zelle>.<Kurzname_des_Clusters> hat.
[z/OS]Hinweis: In einer Umgebung mit WebSphere Application Server Network Deployment können Synchronisationsprobleme auftreten, wenn Sie Ihre Sicherheitseinstellungen speichern und der Node Agent nicht aktiv ist.

Nach dem Aktivieren der Sicherheitskomponente ist der Zugriff auf eine Webseite nicht möglich

Wenn keine geschützten Ressourcen verfügbar sind, sind folgende Ursachen möglich:
  • Authentifizierungsfehler - Die Sicherheit von WebSphere Application Server kann die ID der Person oder des Prozesses nicht identifizieren. Symptome von Authentifizierungsfehlern:
    Auf einem Netscape-Browser:
    • Nach einem Anmeldeversuch wird die Nachricht Berechtigung fehlgeschlagen. Wiederholen? angezeigt.
    • Eine beliebige Anzahl von Anmeldeversuchen wird zugelassen. Wenn die Option "Abbrechen" ausgewählt wird, um die Wiederholung zu stoppen, wird die Nachricht Error 401 angezeigt.
    • Typische Browser-Nachricht: Error 401: Basic realm='Default Realm'.
    Browser Internet Explorer:
    • Nach einem Anmeldeversuch wird der Anmeldedialog erneut angezeigt.
    • Lässt drei Versuche zur Wiederholung der Anmeldung zu.
    • Zeigt nach drei erfolglosen Wiederholungen die Nachricht Error 401 an.
  • Berechtigungsfehler - Die Sicherheitskomponente hat festgestellt, dass die Person bzw. der Prozess, die bzw. der die Anforderung abgesetzt hat, nicht berechtigt ist, auf die geschützte Ressource zuzugreifen. Symptome von Berechtigungsfehlern:
    • Netscape: Nachricht "Error 403: AuthorizationFailed" wird angezeigt.
    • Internet Explorer:
      • Nachricht "You are not authorized to view this page message" wird angezeigt.
      • Fehlernachricht "HTTP 403 Forbidden" wird ebenfalls angezeigt.
  • SSL-Fehler - Die Sicherheit von WebSphere Application Server verwendet intern die SSL-Technologie (Secure Sockets Layer), um Übertragungen zu schützen und zu verschlüsseln. Wenn die internen SSL-Einstellungen nicht ordnungsgemäß konfiguriert sind, kann dies zu Problemen führen. Möglicherweise haben Sie auch die SSL-Verschlüsselung für die Datenübertragungen Ihrer Webanwendung oder Ihres Enterprise-Bean-Clients aktiviert. Falls Sie dabei falsche Konfigurationswerte angegeben haben, kann dies unabhängig davon, ob die Sicherheit von WebSphere Application Server aktiviert ist, zu Problemen führen.
    • SSL-Fehler werden häufig durch Fehlernachrichten angezeigt, die eine Anweisung wie Fehler: Der Ausgangskontext konnte nicht abgerufen werden, oder der Anfangskontext wurde nicht gefunden. Prozess wird beendet. enthalten und denen eine Ausnahme vom Typ javax.net.ssl.SSLHandshakeException folgt.

Nach dem Aktivieren der Sicherheitskomponente kann der Client nicht auf eine Enterprise-Bean zugreifen

Gehen Sie wie folgt vor, wenn der Client nach der Aktivierung der Sicherheitskomponente nicht auf eine Enterprise-Bean zugreifen kann:
  • Lesen Sie nach, mit welchen Schritten Sie die Ressourcen schützen und die Zugriffsberechtigung für die Ressourcen erteilen.
  • [AIX Solaris HP-UX Linux Windows][IBM i]Durchsuchen Sie die JVM-Protokolle des Servers nach Fehlern, die sich auf den Enterprise-Bean-Zugriff und -Schutz beziehen. Prüfen Sie alle Fehler in der Nachrichtentabelle.

    [z/OS]Durchsuchen Sie die Serverprotokolle nach Fehlern, die sich auf den Enterprise-Bean-Zugriff und -Schutz beziehen. Prüfen Sie alle Fehler in der Nachrichtentabelle.

    Fehler wie "Authentifizierung für /UNAUTHENTICATED beim Aufrufen von Ressource securityName:/UNAUTHENTICATED fehlgeschlagen; accessId:UNAUTHENTICATED wurden keine der erforderlichen Rollen erteilt." zeigen Folgendes an:
    • Ein ungeschütztes Servlet oder eine JSP hat auf eine geschützte Enterprise-Bean zugegriffen. Wenn auf ein ungeschütztes Servlet zugegriffen wird, wird der Benutzer nicht aufgefordert, sich anzumelden, daher wird das Servlet mit der Benutzer-ID UNAUTHENTICATED ausgeführt. Wenn das Servlet eine geschützte Enterprise-Bean aufruft, schlägt der Aufruf fehl.

      Zur Behebung dieses Fehlers müssen Sie das Servlet, das auf die geschützte Enterprise-Bean zugreift, schützen. Vergewissern Sie sich, dass für die RunAs-Eigenschaft eine ID angegeben ist, die auf die Enterprise-Bean zugreifen kann.

    • Ein nicht authentifiziertes Java-Clientprogramm greift auf eine geschützte Enterprise-Bean-Ressource zu. Das kann der Fall sein, wenn für die von der Eigenschaftendatei sas.client.props gelesene und vom Clientprogramm verwendete Datei das Flag securityEnabled auf true gesetzt wurde.

      Zur Lösung dieses Problems müssen Sie sicherstellen, dass für die Datei sas.client.props auf der Clientseite das Flag securityEnabled auf true gesetzt wurde.

    Fehler wie "Authentifizierung für gültiger_Benutzer beim Aufrufen von Ressource securityName:/username fehlgeschlagen;accessId:xxxxxx wurden keine der erforderlichen Rollen erteilt." zeigen an, dass ein Client versucht hat, auf eine geschützte Enterprise-Bean-Ressource zuzugreifen und der bereitgestellten Benutzer-ID die erforderlichen Rollen für diese Enterprise-Bean nicht zugeordnet wurden.
    • Prüfen Sie, ob der Zugriff auf die erforderlichen Rollen für die Enterprise-Bean-Ressource erfolgt. Zeigen Sie die erforderlichen Rollen für die Enterprise-Bean-Ressource im Implementierungsdeskriptor der Webressource an.
    • Prüfen Sie die Berechtigungstabelle, und vergewissern Sie sich, dass dem Benutzer bzw. der Gruppe, zu der der Benutzer gehört, eine der erforderlichen Rollen zugeordnet wurde. Sie können die Berechtigungstabelle für die Anwendung, die die Enterprise-Bean-Ressource enthält, auch in der Administrationskonsole anzeigen.
  • [z/OS]Wenn Sie LocalOS- und SAF-Berechtigung verwenden, überprüfen Sie die SAF-EJBROLEs-Konfiguration. Stellen Sie Folgendes sicher:
    • Die Klasse EJBROLE wurde aktiviert.
    • Die Rolle wurde in SAF definiert.
    • Die Benutzer-ID wurde für den die Rolle payroll-department berechtigt.
    • Die Klasse wurde nach der Berechtigungserteilung aktualisiert.
[AIX Solaris HP-UX Linux Windows][IBM i]Wenn Ausnahmen vom Typ org.omg.CORBA.NO_PERMISSION eintreten, wenn Sie sich über das Programm anmelden, um auf eine geschützte Enterprise-Bean zuzugreifen, zeigen an, dass auf dem Server eine Ausnahme für die Authentifizierung aufgetreten ist. Normalerweise wird die CORBA-Ausnahme durch eine zugrunde liegende com.ibm.WebSphereSecurity.AuthenticationFailedException ausgelöst. Möchten Sie die tatsächliche Ursache der Ausnahme, die bei der Authentifizierung aufgetreten ist, ermitteln, müssen Sie den gesamten Trace-Stack überprüfen:
  1. Beginnen Sie damit, dass Sie den Text der Ausnahme hinter WSSecurityContext.acceptSecContext(), reason: anzeigen. Normalerweise wird der Fehler ohne weitere Analyse beschrieben.
  2. Ist diese Beschreibung nicht ausreichend, prüfen Sie die CORBA-Minor-Codes. Diese Codes sind in den Referenzinformationen zur Fehlerbehebung bei den Sicherheitskomponenten in diesem Dokument enthalten.
    In der folgenden Ausnahme ist z. B. der CORBA-Minor-Code 49424300 aufgeführt: Die Fehlerursache gemäß der Tabelle mit dem CORBA-Minor-Code lautet:
    authentication failed error
    Mit anderen Worten, in diesem Fall ist die Benutzer-ID bzw. das Kennwort, die bzw. das vom Clientprogramm bereitgestellt wurde, wahrscheinlich ungültig:
    org.omg.CORBA.NO_PERMISSION: Caught WSSecurityContextException in 
    WSSecurityContext.acceptSecContext(), reason: Major Code[0] Minor Code[0] 
    Message[ Exception caught invoking authenticateBasicAuthData from SecurityServer 
    for user jdoe. Ursache: com.ibm.WebSphereSecurity.AuthenticationFailedException] 
    minor code: 49424300 completed: 
    No at com.ibm.ISecurityLocalObjectBaseL13Impl.PrincipalAuthFailReason.map_auth_fail_to_minor_code 
    (PrincipalAuthFailReason.java:83)

[AIX Solaris HP-UX Linux Windows][IBM i]Das Clientprogramm hat vom Server eine Ausnahme des Typs CORBA INITIALIZE mit dem eingebettetem Fehler CWWSA1477W: Abweichung bei den Sicherheitskonfigurationen von Client und Server empfangen.

[AIX Solaris HP-UX Linux Windows][IBM i]Dieser Fehler zeigt an, dass die Sicherheitskonfiguration des Servers sich von der Sicherheitskonfiguration des Clients grundlegend unterscheidet. In der vollständigen Ausnahmenachricht sind die spezifischen Abweichungen aufgeführt. In der folgenden Ausnahme sind z. B. drei Abweichungen aufgeführt:
Ausnahme empfangen: org.omg.CORBA.INITIALIZE: 
CWWSA1477W: SECURITY CLIENT/SERVER CONFIG MISMATCH: 
Die Sicherheitskonfiguration des Client (sas.client.props oder Einstellungen in der
grafischen Benutzerschnittstelle) bieten keine Unterstützung für die
Sicherheitskonfiguration des Servers. Gründe: 
FEHLER 1: CWWSA0607E: Der Client erfordert SSL-Vertraulichkeit, aber der
Server unterstützt diese Option nicht. 
FEHLER 2: CWWSA0610E: Der Server erfordert SSL-Integrität, aber der Client
unterstützt diese Option nicht. 
FEHLER 3: CWWSA0612E: Der Client erfordert eine Clientauthentifizierung (z. B.
Benutzer-ID/Kennwort oder Token), aber der Server unterstützt diese Option nicht. 
     minor code: 0 
     completed: No at 
com.ibm.ISecurityLocalObjectBaseL13Impl.SecurityConnectionInterceptor.getConnectionKey
(SecurityConnectionInterceptor.java:1770)

[AIX Solaris HP-UX Linux Windows][IBM i]Im Allgemeinen müssen Sie zur Behebung des Fehlers die Sicherheitskonfiguration des Clients oder des Servers ändern. Wenn Sie feststellen möchten, welche Konfigurationseinstellung betroffen ist, lesen Sie den Text, der nach der CWWSA-Fehlernachricht folgt. Ausführliche Erläuterungen und Anweisungen finden Sie in der Nachrichtenreferenz zur Fehlernachricht. Wählen Sie dazu die Ansicht Referenz des Information Centers aus und erweitern Sie in der Navigationsstruktur den Eintrag Nachrichten.

[AIX Solaris HP-UX Linux Windows][IBM i]In diesem Fall bedeuten die genannten Fehler Folgendes:
  • Im Fall von Fehler 1 erfordert der Client SSL-Vertraulichkeit, der Server unterstützt die SSL-Vertraulichkeit jedoch nicht. Es gibt zwei Möglichkeiten, dieses Problem zu beheben. Ändern Sie die Einstellungen des Servers so, dass er die SSL-Vertraulichkeit unterstützt, oder ändern Sie die Einstellungen des Clients so, dass er die SSL-Vertraulichkeit nicht mehr erfordert.
  • Im Fall von Fehler 2 erfordert der Server die SSL-Integrität, aber der Client unterstützt die SSL-Integrität nicht. Es gibt zwei Möglichkeiten, dieses Problem zu beheben. Ändern Sie die Einstellungen des Servers so, dass er die SSL-Vertraulichkeit unterstützt, oder ändern Sie die Einstellungen des Clients so, dass er die SSL-Vertraulichkeit nicht mehr erfordert.
  • Im Fall von Fehler 3 schließlich erfordert der Client die Clientauthentifizierung über Benutzer-ID/Kennwort, aber der Server unterstützt diesen Typ der Clientauthentifizierung nicht. Auch in diesem Fall muss entweder die Clientkonfiguration oder die Serverkonfiguration geändert werden. Zum Ändern der Clientkonfiguration müssen Sie die Datei SAS.CLIENT.PROPS so konfigurieren, dass Sie einen reinen Client erhalten, oder die Ausgangskonfiguration des Servers in der Administrationskonsole für die Sicherheit ändern. Um die Konfiguration des Zielservers zu ändern, müssen Sie die Eingangskonfiguration in der Administrationskonsole für die Sicherheit ändern.

[AIX Solaris HP-UX Linux Windows][IBM i]Wenn der Server beim Versuch, eine Clientanforderung zu bearbeiten, eine Fehlerbedingung wie org.omg.CORBA.INITIALIZE: JSAS0477W: Abweichung bei den Sicherheitskonfigurationen von Client und Server: empfängt, bedeutet das, dass die Sicherheitskonfigurationen zwischen dem Client und dem Server nicht übereinstimmen. Die Schritte, die zur Auflösung des Fehlers erforderlich sind, stimmen mit den oben beschriebenen Schritten für die Ausnahmen vom Typ JSAS1477W überein.

Der Client wird nicht zur Eingabe von Daten aufgefordert, wenn er auf eine gesicherte Enterprise-Bean zugreift

Auch wenn die Sicherheitskomponente scheinbar aktiviert und eine bestimmte Enterprise-Bean geschützt ist, kann der Fall eintreten, dass der Client die ferne Methode ohne Systemanfragen ausführt. Wenn die ferne Methode geschützt wird, erhalten Sie einen Berechtigungsfehler. Ist dies nicht der Fall, führen Sie die Methode als nicht authentifizierter Benutzer aus.

Mögliche Fehlerursachen sind:
  • Für den Server, mit dem Sie kommunizieren, wurde die Sicherheitskomponente nicht aktiviert. Vergewissern Sie sich beim Administrator von WebSphere Application Server, dass die Sicherheitskomponente des Servers aktiviert ist. Der Zugriff auf die Sicherheitseinstellungen erfolgt über den Abschnitt Sicherheit der Administrationskonsole.
  • Für den Client wurde die Sicherheitskomponente in der Datei sas.client.props nicht aktiviert. Editieren Sie die Datei sas.client.props, um sicherzustellen, dass die Eigenschaft "com.ibm.CORBA.securityEnabled" auf true gesetzt ist.
  • Für den Client wurde kein ConfigURL angegeben. Vergewissern Sie sich, dass die Eigenschaft "com.ibm.CORBA.ConfigURL" angegeben ist, indem Sie in der Befehlszeile des Java-Clients den Parameter "-D" verwenden.
  • Der angegebene ConfigURL hat eine ungültige URL-Syntax oder die Datei sas.client.props, auf die er verweist, kann nicht ermittelt werden. Vergewissern Sie sich, dass die Eigenschaft "com.ibm.CORBA.ConfigURL" gültig ist. Prüfen Sie, ob die Java-Dokumentation eine Beschreibung der Formatierungsregeln für URLs enthält. Prüfen Sie auch, ob die Datei unter dem angegebenen Pfad angegeben ist.

    [AIX Solaris HP-UX Linux Windows][Windows]Ein Beispiel für eine gültige Eigenschaft ist C:/WebSphere/AppServer/properties/sas.client.props.

  • [AIX Solaris HP-UX Linux Windows][IBM i]Die Clientkonfiguration unterstützt die Clientauthentifizierung über die Nachrichtenschicht (Benutzer-ID/Kennwort) nicht. Vergewissern Sie sich, dass in der Datei sas.client.props eines der folgenden Eigenschaften auf true gesetzt ist:
    • com.ibm.CSI.performClientAuthenticationSupported=true
    • com.ibm.CSI.performClientAuthenticationRequired=true
  • [AIX Solaris HP-UX Linux Windows][IBM i]Die Serverkonfiguration unterstützt keine Clientauthentifizierung auf Nachrichtenebene, die sich aus einer Benutzer-ID und einem Kennwort zusammensetzt. Vergewissern Sie sich beim Administrator von WebSphere Application Server, dass die Authentifizierung über Benutzer-ID und Kennwort für die Eingangskonfiguration des Servers im Sicherheitscenter des Verwaltungstools der Administrationskonsole angegeben ist.

Nach dem Aktivieren der Sicherheitskomponente kann ein Anwendungsserver, Knotenmanager oder Knoten nicht gestoppt werden

Wenn Sie zum Stoppen der Prozesse von WebSphere Application Server Befehlszeilenprogramme verwenden, müssen Sie nach dem Aktivieren der Sicherheit zusätzliche Parameter anwenden, um die Authentifizierungs- und Berechtigungsdaten bereitzustellen.

[AIX Solaris HP-UX Linux Windows][IBM i]Zeigen Sie mit dem Befehl ./stopServer -help die zu verwendenden Parameter an.

[AIX Solaris HP-UX Linux Windows][IBM i]Verwenden Sie nach dem Aktivieren der Sicherheitskomponente die folgenden Befehlsoptionen:
  • ./stopServer serverName -username Name -password Kennwort
  • ./stopNode -username Name -password Kennwort
  • ./stopManager -username Name -password Kennwort

[AIX Solaris HP-UX Linux Windows]Wenn Sie die Windows-Anzeige "Dienste" oder den Befehl "net stop" zum Stoppen von WebSphere Application Server-Prozessen verwenden und der Service nicht gestoppt werden kann, müssen Sie den vorhandenen Application Server-Dienst mit zusätzlichen Stoppargumenten aktualisieren. Möglicherweise müssen Sie den Serverprozess über den Task-Manager beenden, bevor Sie den Service aktualisieren. Verwenden Sie die Parameter -stopArgs und -encodeParams, um den Dienst gemäß der Beschreibung im Beispiel "Vorhandenen Application-Server-Dienst aktualisieren" im Artikel Befehl WASService zu aktualisieren. .

Nach dem Aktivieren von SSO (Single Sign-On) kann die Anmeldung an der Administrationskonsole nicht mehr durchgeführt werden

Dieser Fehler tritt auf, wenn SSO (Single Sign-on) aktiviert ist und Sie versuchen, mit dem Kurznamen des Servers auf die Administrationskonsole zuzugreifen, z. B. http://myserver:Portnummer/ibm/console. Der Server akzeptiert Ihre Benutzer-ID und Ihr Kennwort, gibt jedoch die Anmeldeseite und nicht die Administrationskonsole zurück.

Möchten Sie diesen Fehler beheben, verwenden Sie den vollständig qualifizierten Hostnamen des Servers, z. B. http://meinserver.meinnetzwerk.meinefirma.com:9060/ibm/console.

SECJ0306E: Es wurde kein empfangener oder Aufrufberechtigungsnachweis im Thread gefunden.

Die folgende Nachricht wird angezeigt, wenn einer oder mehrere Knoten in der Zelle während der Konfiguration nicht synchronisiert wurden:
SECJ0306E: Es wurde kein empfangener oder Aufrufberechtigungsnachweis im Thread gefunden. Die
rollebasierte Berechtigungsprüfung hat demzufolge nicht die Zugriffs-ID des zu prüfenden aufrufenden Programms. Die Parameter sind Zugriffsprüfmethode getServerConfig für Ressource FileTransferServer und Modul FileTransferServer. Der Stack-Trace ist: java.lang.Exception: Aufruf und empfangene Berechtigungsnachweise sind beide null. 

Stellen Sie sicher, dass alle Knoten synchronisiert sind, und starten Sie anschließend den Deployment Manager erneut.

Ein NameNotFoundException-Fehler tritt auf, wenn zum ersten Mal eine Verbindung zu den eingebundenen Repositorys hergestellt wird

[AIX Solaris HP-UX Linux Windows][IBM i]Wenn der Server versucht, eine indirekte Lookup-Operation für den Namen java:comp/env/ds/wimDS auszuführen und zum ersten Mal eine EJB-Verbindung zu den eingebundenen Repositorys herstellt, wird die folgende Fehlernachricht in der Datei SystemOut.log angezeigt:

[z/OS]Wenn der Server versucht, eine indirekte Lookup-Operation für den Namen java:comp/env/ds/wimDS auszuführen und zum ersten Mal eine EJB-Verbindung zu den eingebundenen Repositorys herstellt, wird die folgende Fehlernachricht in der Ausgabe des entsprechenden Jobprotokolls angezeigt:

NMSV0612W:
Ausnahme vom Typ NameNotFoundException
[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.

Der NameNotFoundException-Fehler wird von der Referenzbindungsdefinition für den JNDI-Namen (Java Naming and Directory Interface) jdbc/wimDS in der Datei ibm-ejb-jar-bnd.xmi ausgelöst. Sie können diese Warnung ignorieren. Bei der Konfiguration des wimDS-Datenbankrepository wird diese Nachricht nicht mehr angezeigt.

Unterstützte Konfigurationen Unterstützte Konfigurationen: Bei IBM Erweiterungs- und Bindungsdateien weicht der Name der XMI- oder XML-Datei ab, je nachdem, ob Sie eine Java EE-Anwendung bzw. ein Java EE-Modul vor oder nach Version 5 verwenden. Eine IBM Erweiterungs- bzw. Bindungsdatei heißt "ibm-*-ext.xmi" bzw. "ibm-*-bnd.xmi". Das Platzhalterzeichen "*" steht für den Typ der Erweiterungs- oder Bindungsdatei, z. B. "app", "application", "ejb-jar" oder "web". Es gelten die folgenden Bedingungen:
  • Für eine Anwendung oder ein Modul, die bzw. das Java EE vor Version 5 verwendet, muss die Dateierweiterung ".xmi" sein.
  • Für eine Anwendung oder ein Modul, die bzw. das Java EE ab Version 5 verwendet, muss die Dateierweiterung ".xml" sein. Wenn Dateien mit der Erweiterung ".xmi" in der Anwendung oder im Modul enthalten sind, werden diese vom Produkt ignoriert.

Ein Modul von Java EE Version 5 oder einer höheren Version kann jedoch in einer Anwendung, die Dateien einer älteren Java EE-Version als Version 5 enthält, koexistieren.

Die Dateien ibm-webservices-ext.xmi, ibm-webservices-bnd.xmi, ibm-webservicesclient-bnd.xmi, ibm-webservicesclient-ext.xmi und ibm-portlet-ext.xmi können die Dateierweiterung ".xmi" weiterhin verwenden.

sptcfg

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_secprobs
Dateiname:rtrb_secprobs.html