Incidents d'accès après l'activation de la sécurité
Utilisez ces informations si vous rencontrez des problèmes d'accès après avoir activé la sécurité.
- Impossible d'accéder à tout ou partie de la console d'administration ou d'utiliser l'outil wsadmin une fois la sécurité activée
- Impossible d'accéder à une page Web une fois la sécurité activée
- Erreur d'authentification lors de l'accès à une page Web
- Erreur d'autorisation lors de l'accès à une page Web
- Le client ne peut pas accéder à un bean enterprise une fois la sécurité activée
- Le programme client n'obtient jamais d'invite lors de l'accès à un bean enterprise sécurisé
- Impossible d'arrêter un serveur d'applications, un gestionnaire de noeud ou un noeud une fois la sécurité activée
L'exception AccessControlException est signalée dans le fichier SystemOut.log
- Impossible de se connecter à la console d'administration une fois la connexion unique activée
- SECJ0306E : Aucun justificatif d'appel ou reçu n'existe dans l'unité d'exécution.
- Une erreur Name NotFoundException s'est produite lors de la connexion initiale aux référentiels fédérés.
Pour des conseils d'ordre général sur le diagnostic et la résolution
des incidents liés à la sécurité, reportez-vous à la rubrique Conseils pour l'identification et la résolution des problèmes liés aux composants de sécurité.
Si vous ne trouvez pas d'incident similaire au vôtre, ou si les informations fournies ne permettent pas de résoudre votre problème,
reportez-vous à la rubrique Support IBM pour la résolution des incidents.
Impossible d'accéder à tout ou partie de la console d'administration ou d'utiliser l'outil wsadmin une fois la sécurité activée
Si vous ne pouvez pas accéder à la console d'administration, ou visualiser et mettre à jour certains objets, recherchez un message d'erreur relatif à cet incident dans le journal SystemOut du serveur d'applications qui héberge la page de la console d'administration.
Si vous ne pouvez pas accéder à la console d'administration, ou visualiser et mettre à jour certains objets, recherchez un message d'erreur relatif à cet incident dans les journaux du serveur d'applications qui héberge la page de la console d'administration.
Remarque : Vous devez utiliser la console d'administration pour les deux prochaines étapes. Si un problème survient lors de l'accès à la console d'administration, vous devez désactiver la sécurité et redémarrer la console d'administration. Pour désactiver la sécurité, entrez la commande suivante au niveau de l'invité de commande système :
Lorsque l'invite de commande système s'affiche à nouveau, entrez :wsadmin.sh -conntype NONE
Redémarrez le gestionnaire de déploiement après la désactivation de la sécurité.securityoff
- Il est possible que votre ID utilisateur ne soit pas autorisé à effectuer des tâches
d'administration.
Cet incident est signalé par des erreurs du type :
- [8/2/02 10:36:49 :722 CDT] 4365c0d9 RoleBasedAuth A CWSCJ0305A : Echec du contrôle d'autorisation à base de rôle pour le nom de sécurité MonServeur/monIdUtilisateur, idAccès MonServeur/S-1-5-21-882015564-4266526380-2569651501-1005 lors de l'appel de la méthode getProcessType sur le serveur de ressources et le serveur de modules.
- Message de l'exception : "CWWMN0022E : Accès refusé pour l'opération getProcessType sur le MBean serveur"
- Lors de l'exécution de la commande : wsadmin -nomutilisateur j2ee -motdepasse j2ee : CWWAX7246E : Impossible d'établir une connexion "SOAP" à l'hôte "BIRKT20" en raison d'un échec d'authentification. Assurez-vous que l'ID utilisateur et le mot de passe sont corrects sur la ligne de commande ou dans un fichier de propriétés.
- Vérifiez que la fonctionnalité d'application certifiée est activée. La fonctionnalité d'application certifiée est activée si WebSphere Application Server a un accès en lecture SAF à la classe RACF nommée FACILITY et utilise le profil nommé BBO.TRUSTEDAPPS.<nom abrégé_cellule>.<nom abrégé_cluster>.
![[z/OS]](../images/ngzos.gif)
Impossible d'accéder à une page Web une fois la sécurité activée
- Erreurs d'authentification - La sécurité WebSphere
Application Server ne parvient pas à identifier l'ID de la personne ou du processus. Les signes d'erreurs d'authentification sont les
suivants :Sur un navigateur Netscape :
- L'autorisation a échoué. Le message Réessayer ? s'affiche après une tentative de connexion.
- Autorise un nombre illimité de nouvelles tentatives de connexions et affiche le message Erreur 401 à l'activation de Cancel pour arrêter la nouvelle tentative.
- Message type du navigateur : Erreur 401 : Domaine de base='Domaine par défaut'.
Sur un navigateur Internet Explorer :- L'invite de connexion s'affiche de nouveau après une tentative de connexion.
- Autorise trois nouvelles tentatives de connexion.
- Affiche le message Erreur 401 après trois tentatives infructueuses.
- Erreurs d'autorisation - La fonction de sécurité a détecté que la personne ou le processus demandeur n'est pas
autorisé à accéder à la ressource sécurisée. Les signes d'erreurs d'autorisation
sont les suivants :
- Navigateur Netscape : Affichage du message "Erreur 403 : Echec d'autorisation".
- Internet Explorer :
- Affichage du message "Vous n'êtes pas autorisé à visualiser cette page".
- L'erreur "Interdiction HTTP 403" s'affiche également.
- Erreurs SSL - La sécurité WebSphere
Application Server utilise la technologie SSL (Secure Sockets Layer) en interne pour
sécuriser et chiffrer ses propres communications, et une configuration incorrecte des
paramètres internes SSL peut provoquer des incidents. Vous pouvez également avoir activé le chiffrement SSL pour votre
propre trafic client d'application Web ou de bean enterprise, lequel, s'il n'est pas configuré correctement, peut
provoquer des incidents, que la sécurité
WebSphere
Application Server soit
activée ou non.
- Les incidents liés à SSL sont souvent indiqués par des messages d'erreur contenant une déclaration similaire à celle de l'exemple suivant : ERREUR : Impossible d'obtenir le contexte initial ou de localiser le contexte de départ. Sortie du programme et suivie de javax.net.ssl.SSLHandshakeException
Le client ne peut pas accéder à un bean enterprise une fois la sécurité activée
- Revoyez les procédures de sécurisation et d'accord d'accès aux ressources.
Parcourez les journaux JVM du serveur à la recherche d'erreurs liées à l'accès et à la sécurité des beans enterprise. Comparez les messages d'erreur trouvés à ceux répertoriés dans la table de référence des messages.
Parcourez les journaux JVM du serveur à la recherche d'erreurs liées à l'accès et à la sécurité des beans enterprise. Comparez les messages d'erreur trouvés à ceux répertoriés dans la table de référence des messages.
Les messages d'erreur du type Echec d'autorisation pour /UNAUTHENTICATED lors de l'appel de ressource nomSécurité:/UNAUTHENTICATED;idAccès:UNAUTHENTICATED ne détient aucun des rôles requis rôles indiquent les informations suivantes :- Un servlet ou un fichier JSP (JavaServer Pages) non protégé a accédé à un bean enterprise protégé. Lors de l'accès
à un servlet non protégé, l'utilisateur n'est pas invité à se connecter et le servlet
s'exécute donc sans authentification.
En conséquence, tout appel à un bean enterprise protégé
échoue.
Pour résoudre ce problème, sécurisez le servlet accédant au bean enterprise protégé. Assurez-vous que la propriété runAs du servlet est définie à un ID autorisé à accéder au bean enterprise.
- Un programme client Java non authentifié accède à une
ressource de bean enterprise protégée.
Cet
incident se produit lorsque le fichier lu par le fichier des propriétés sas.client.props qu'utilise le programme client n'a pas l'indicateur securityEnabled défini à true.
Pour résoudre cet incident, assurez-vous que l'indicateur securityEnabled du fichier sas.client.props côté client est bien défini à true.
Les messages d'erreur du type Echec d'autorisation pour utilisateur_valide lors de l'appel de ressource nomSécurité:/nomutilisateur;idAccès:xxxxxx ne détient aucun des rôles requis indique qu'un client a tenté d'accéder à une ressource de bean enterprise sécurisée mais que l'ID utilisateur fourni ne détient pas les rôles requis pour ce bean enterprise.- Vérifiez les rôles requis par la ressource de bean enterprise accédée. Visualisez les rôles requis pour la ressource enterprise dans le descripteur de déploiement de la ressource Web.
- Contrôlez la table d'autorisation et assurez-vous que l'utilisateur ou le groupe auquel appartient l'utilisateur détient l'un des rôles requis. Vous pouvez consulter la table d'autorisation de l'application contenant la ressource de bean enterprise à l'aide de la console d'administration.
- Un servlet ou un fichier JSP (JavaServer Pages) non protégé a accédé à un bean enterprise protégé. Lors de l'accès
à un servlet non protégé, l'utilisateur n'est pas invité à se connecter et le servlet
s'exécute donc sans authentification.
En conséquence, tout appel à un bean enterprise protégé
échoue.
Si vous utilisez le système d'exploitation local et l'autorisation SAF, vérifiez la configuration des classes EJBROLE SAF. Plus spécifiquement, vérifiez les points suivants :
- La classe EJBROLE est activée.
- Le rôle est défini dans SAF.
- Le rôle est attribué à l'ID utilisateur.
- La classe est régénérée après l'opération d'autorisation.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
- Commencez par afficher le texte qui suit Motif de WSSecurityContext.acceptSecContext() dans l'exception. Il décrit généralement l'incident, sans analyse plus approfondie.
- Si l'incident n'est pas détaillé, reportez-vous aux codes mineurs CORBA (Common Object Request Broker Architecture). Ces codes sont répertoriés dans la rubrique résolution des incidents des composants de sécurité.Par exemple, l'exception suivante indique un code mineur CORBA 49424300. L'explication de cette erreur, indiquée dans la table des codes mineurs CORBA, est la suivante :
Dans ce cas, l'ID utilisateur ou le mot de passe fourni ici par le programme client est probablement incorrect :Erreur - Echec de l'authentification
org.omg.CORBA.NO_PERMISSION : Exception WSSecurityContextException interceptée dans WSSecurityContext.acceptSecContext(), motif : Code majeur[0] Code mineur[0] Message[ Exception caught invoking authenticateBasicAuthData from SecurityServer pour l'utilisateur jdoe. Raison : com.ibm.WebSphereSecurity.AuthenticationFailedException] code mineur : 49424300 terminé : Non sur com.ibm.ISecurityLocalObjectBaseL13Impl.PrincipalAuthFailReason.map_auth_fail_to_minor_code (PrincipalAuthFailReason.java:83)
Le programme client reçoit du serveur
l'exception CORBA INITIALIZE avec une erreur CWWSA1477W : SECURITY CLIENT/SERVER CONFIGURATION MISMATCH imbriquée.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
Exception reçue : org.omg.CORBA.INITIALIZE:
CWWSA1477W: SECURITY CLIENT/SERVER CONFIG MISMATCH:
La configuration de la sécurité du client (sas.client.props ou paramètres de sortie de la
console d'administration) ne prend pas en charge la configuration de sécurité du serveur
pour les raisons suivantes :
ERREUR 1 : CWWSA0607E : Le client requiert la confidentialité SSL mais le serveur ne la prend pas en charge.
ERREUR 2 : CWWSA0610E : Le client requiert l'intégrité SSL mais le serveur ne la prend pas en charge.
ERREUR 3: CWWSA0612E: Le client requiert l'intégrité SSL mais
le serveur ne la prend pas en charge.
code mineur : 0
terminé : Non sur
com.ibm.ISecurityLocalObjectBaseL13Impl.SecurityConnectionInterceptor.getConnectionKey
(SecurityConnectionInterceptor.java:1770)
En général, la résolution du problème exige de modifier
la configuration de la sécurité du client ou du serveur. Pour déterminer
laquelle des deux configurations est en cause, examinez le texte qui suit
le message d'erreur CWWSA. Pour des instructions et des explications plus
détaillées, examinez la table de référence, en sélectionnant la
vue Référence de l'InfoCenter et en développant Messages
dans l'arborescence de navigation.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
- Dans l'erreur 1, le client nécessite la confidentialité SSL alors que le serveur ne la prend pas en charge. Ce problème peut être résolu de deux manières. Mettez à jour le serveur pour qu'il prenne en charge la confidentialité SSL ou mettez à jour le client pour qu'il n'en ait plus besoin.
- Dans l'erreur 2, le client requiert l'intégrité SSL alors que le serveur ne la prend pas en charge. Ce problème peut être résolu de deux manières. Mettez à jour le serveur pour prendre en charge l'intégrité SSL ou mettez à jour le client pour qu'il n'en ait plus besoin.
- Dans l'erreur 3, le client requiert l'authentification via un ID utilisateur et un mot de passe alors que le serveur ne prend pas en charge ce type d'authentification du client. Modifiez la configuration du client ou du serveur. Pour modifier la configuration du client, modifiez le fichier SAS.CLIENT.PROPS s'il s'agit d'un client Java pur ou modifiez la configuration des communications sortantes du serveur dans la console d'administration de sécurité. Pour modifier la configuration du serveur cible, modifiez la configuration des communications entrantes dans la console d'administration de sécurité.
De même, une exception telle que org.omg.CORBA.INITIALIZE : JSAS0477W :
SECURITY CLIENT/SERVER CONFIG MISMATCH: s'affichant sur le serveur qui tente de
servir une demande client indique une disparité de configuration de la sécurité entre
le client et serveur. La procédure permettant de résoudre cet incident est identique
à celle préconisée pour les exceptions JSAS1477W décrites ci-dessus.
Le programme client n'obtient jamais d'invite lors de l'accès à un bean enterprise sécurisé
Même lorsque la sécurité semble activée et qu'un bean enterprise est sécurisé, il arrive que le client exécute la méthode distante sans y être invité. Si la méthode distante est protégée, vous obtenez un incident d'autorisation. Sinon, exécutez la méthode en tant qu'utilisateur non authentifié.
- La sécurité du serveur avec lequel vous dialoguez n'est peut-être pas activée. Vérifiez auprès de l'administrateur WebSphere Application Server si la sécurité est activée sur ce serveur. Accédez aux paramètres de sécurité dans la section Sécurité de la console d'administration.
- La sécurité n'est pas activée pour le client dans le fichier sas.client.props. Ouvrez le fichier sas.client.props afin de vérifier que la propriété com.ibm.CORBA.securityEnabled a la valeur true.
- Aucune propriété ConfigURL n'est spécifiée pour le client. Vérifiez que la propriété com.ibm.CORBA.ConfigURL est indiquée sur la ligne de commande du client Java, à l'aide du paramètre -D.
- La syntaxe URL de la propriété ConfigURL indiquée est incorrecte ou le fichier
sas.client.props qui la désigne est introuvable. Vérifiez que la propriété com.ibm.CORBA.ConfigURL est valide. Recherchez dans la
documentation Java une description des règles de formatage
des adresses URL. Assurez-vous
également que le fichier existe dans le chemin spécifié.
Exemple de propriété valide : C:/WebSphere/AppServer/properties/sas.client.props.
La configuration client ne prend pas en charge l'authentification du client de la couche messages (ID utilisateur et mot de passe). Vérifiez que le fichier sas.client.props contient l'une des propriétés suivantes définie à true :
- com.ibm.CSI.performClientAuthenticationSupported=true
- com.ibm.CSI.performClientAuthenticationRequired=true
La configuration serveur ne prend pas en charge l'authentification du client de la couche messages, qui se compose d'un ID utilisateur et d'un mot de passe. Vérifiez auprès de l'administrateur WebSphere Application Server si l'authentification par ID utilisateur et mot de passe est spécifiée pour la configuration des communications entrantes du serveur dans la section Administration du système de l'outil d'administration de la console d'administration.
Impossible d'arrêter un serveur d'applications, un gestionnaire de noeud ou un noeud une fois la sécurité activée
Si vous faites appel à des utilitaires de ligne de commande pour arrêter des processus WebSphere Application Server, définissez des paramètres supplémentaires après avoir activé la sécurité afin de fournir des informations d'authentification et d'autorisation.
Utilisez la commande ./stopServer
-help pour afficher les paramètres à utiliser.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
- ./stopServer nomServeur -username nom -password motdepasse
- ./stopNode -username nom -password motdepasse
- ./stopManager -username nom -password motdepasse
Si vous utilisez la fenêtre des
services Windows ou la
commande net stop pour arrêter les processus
WebSphere
Application Server et que
le service n'a pas pu être arrêté, mettez à jour le service Application Server existant à l'aide d'arguments stop
supplémentaires. Vous devrez probablement arrêter le processus serveur à partir du gestionnaire de tâches avant de mettre à jour le service. Utilisez les paramètres -stopArgs et -encodeParams
pour mettre le service à jour comme décrit dans l'exemple "Mise à jour d'un service Application
Server existant" de l'article Commande
WASService.
Impossible de se connecter à la console d'administration une fois la connexion unique activée
Cet incident se produit lorsque la connexion unique (SSO) est activée et que vous tentez d'accéder à la console d'administration à l'aide du nom abrégé du serveur, par exemple http://monserveur:numéro_port/ibm/console. Le serveur accepte vos ID utilisateur et mot de passe mais vous renvoie à la page de connexion au lieu de la console d'administration.
Pour résoudre cet incident, utilisez le nom d'hôte complet du serveur, par exemple http://monserveur.monréseau.masociété.com:9060/ibm/console.
SECJ0306E : Aucun justificatif d'appel ou reçu n'existe dans l'unité d'exécution.
Le message suivant s'affiche quand un ou plusieurs noeuds de la cellule n'ont pas été synchronisés lors de la configuration :SECJ0306E: Aucun justificatif d'appel ou reçu n'existe dans l'unité d'exécution. La vérification d'autorisation basée sur des rôles n'aura aucun ID d'accès de l'appelant à vérifier . Les paramètres sont : accéder à la méthode d'appel getServerConfig sur la ressource FileTransferServer et le module FileTransferServer. La trace de pile est l'exception java.lang.Exception : les justificatifs reçus et d'appel ont la valeur null.
Assurez-vous que tous les noeuds sont synchronisés, puis redémarrez le gestionnaire de déploiement.
Une erreur Name NotFoundException s'est produite lors de la connexion initiale aux référentiels fédérés.
Lorsque le serveur tente une recherche indirecte sur le nom java:comp/env/ds/wimDS et effectue sa connexion EJB initiale aux référentiels fédérés, le message d'erreur suivant apparaît dans le fichier SystemOut.log :
Lorsque le serveur tente une recherche indirecte sur le nom java:comp/env/ds/wimDS et effectue sa connexion EJB initiale aux référentiels fédérés, le message d'erreur suivant apparaît dans la sortie du journal de travail concerné :
NMSV0612W: A NameNotFound Exception
![[z/OS]](../images/ngzos.gif)
L'erreur NameNotFoundException est causée par la définition de liaison de référence du nom JNDI (Java Naming and Directory Interface) jdbc/wimDS Java dans le fichier ibm-ejb-jar-bnd.xmi. Vous pouvez ignorer ce message d'avertissement. Ce message ne s'affiche pas lors de la configuration du référentiel de base de données wimDS.

Toutefois, un module Java EE 5 ou version ultérieure peut exister dans une application qui inclut des fichiers antérieurs à Java EE 5 et utilise l'extension de nom de fichier .xmi.
Les fichiers ibm-webservices-ext.xmi, ibm-webservices-bnd.xmi, ibm-webservicesclient-bnd.xmi, ibm-webservicesclient-ext.xmi et ibm-portlet-ext.xmi continuent d'utiliser les extensions de fichier .xmi.
sptcfg