Erreur d'activation et de configuration de la sécurité

Utilisez ces informations pour résoudre des incidents liés à la configuration ou à l'activation de la sécurité.

Remarque : Cette rubrique fait référence à un ou plusieurs des fichiers journaux de serveur d'applications. Il est recommandé de configurer le serveur de telle sorte qu'il utilise l'infrastructure de journalisation et de trace HPEL (High Performance Extensible Logging) à la place des fichiers SystemOut.log, SystemErr.log, trace.log et activity.log sur les systèmes distribués et IBM® i. Vous pouvez également utiliser HPEL conjointement avec vos fonctions de journalisation z/OS natives. Si vous utilisez l'infrastructure HPEL, vous pouvez accéder à toutes les informations de journalisation et de trace en utilisant l'outil de ligne de commande LogViewer à partir de votre répertoire bin de profil de serveur. Pour plus d'informations sur l'utilisation de HPEL, voir les informations sur l'utilisation de HPEL en vue du traitement des incidents liés aux applications.

[AIX Solaris HP-UX Linux Windows][IBM i]Pour des conseils d'ordre général sur le diagnostic et la résolution des incidents liés à la sécurité, voir Résolution des incidents liés au composant de sécurité.

Affichage du message "Mot de passe LTPA non défini. Echec de la validation"

Affichage du message "Mot de passe LTPA non défini. Echec de la validation" dans la console d'administration après sauvegarde des paramètres de la sécurité globale

Cette erreur peut se produire si, lors de la configuration de la sécurité WebSphere Application Server, vous sélectionnez LTPA comme mécanisme d'authentification et que vous ne renseignez pas la zone du mot de passe LTPA. Pour résoudre ce problème :
  • Sélectionnez Sécurité > Sécurité globale > Mécanismes d'authentification et expiration > LTPA.
  • Renseignez les zones du mot de passe et de confirmation du mot de passe.
  • Cliquez sur OK.
  • Essayez à nouveau de définir la sécurité administrative ou d'application.
[AIX Solaris HP-UX Linux Windows][z/OS]

Le fichier setupClient.bat ou setupClient.sh ne s'exécute pas correctement

Le fichier setupClient.bat sur les systèmes d'exploitation Windows et le fichier setupClient.sh sur les plateformes Linux et UNIX indiquent un emplacement incorrect pour le fichier de propriétés de la sécurité SOAP.
[Windows]Dans le fichier setupClient.bat, l'emplacement correct est :
set CLIENTSOAP=-Dcom.ibm.SOAP.ConfigURL=file:%WAS_HOME%/properties/soap.client.props
[AIX][Linux][AIX HP-UX Solaris][z/OS]Dans le fichier setupClient.sh, la variable CLIENTSOAP est :
CLIENTSOAP=-Dcom.ibm.SOAP.ConfigURL=file:$WAS_HOME/properties/soap.client.props
Dans les fichiers setupClient.bat et setupClient.sh, procédez comme suit :
  1. Supprimez la barre oblique ( / ) après le fichier :.
  2. Remplacez sas par soap.
[HP-UX]

Java HotSpot Server VM warning

Une fois que vous avez activé la sécurité sur des plateformes HP-UX 11i, l'erreur suivante du fichier native_stdout.log se produit, le processus core est vidé et WebSphere Application Server ne démarre pas :
Java HotSpot(TM) Server VM warning: 
Unexpected Signal 11 occurred under user-defined signal handler 0x7895710a
Pour corriger cette erreur, appliquez les correctifs recommandés par Hewlett Packard pour Java™ du site de support Hewlett Packard à l'adresse suivante : http://www.hp.com.

WebSphere Application Server Version 6 ne fonctionne pas correctement avec Enterprise Workload Manager (EWLM)

Pour utiliser WebSphere Application Server Version 6 avec EWLM, vous devez manuellement mettre à jour les fichiers server.policy de WebSphere Application Server. Exemple :
grant codeBase "file:/<rép_princ_install_EWLM>/classes/ARM/arm4.jar" {
 permission java.security.AllPermission; 
};
Sinon, une exception de sécurité Java 2 peut survenir pour violation des droits de sécurité Java 2.

Pour obtenir plus d'informations sur la configuration des fichiers server.policy, reportez-vous à la rubrique Droits d'accès au fichier server.policy.

Pour toutes les dernières informations disponibles auprès du support technique IBM sur les incidents recensés et leur résolution, accédez à la page IBM Support.

Le support technique d'IBM possède des documents permettant de gagner du temps lors de la collecte des informations requises pour résoudre ce problème. Avant d'ouvrir un PMR, consultez la page IBM Support du serveur qui héberge la ressource à laquelle vous tentez d'accéder.

NMSV0610I: Une exception NamingException est générée par une implémentation javax.naming.Context

Si vous utilisez une authentification des communications entrantes CSIv2, une authentification de base est requise et les clients Java s'exécutant avec com.ibm.CORBA.validateBasicAuth=true risquent d'échouer avec l'exception suivante :
If you use CSIv2 inbound authentication, basic authentication is required, and Java™ 
clients running with com.ibm.CORBA.validateBasicAuth=true might fail with the 
following exception:

NMSV0610I: A NamingException is being thrown from a javax.naming.Context 
           implémentation. Détails :

Implémentation du contexte : com.ibm.ws.naming.jndicos.CNContextImpl
Méthode du contexte : lookupExt
Nom du contexte : TestaburgerNode01Cell/nodes/TestaburgerNode01/servers/server1
Nom cible : SecurityServer
Autres données : "" ""
Trace de pile d'exceptions : exception javax.naming.NoPermissionException: NO_PERMISSION reçue. L'exception racine est org.omg.CORBA.NO_PERMISSION : vmcid: 0x49421000 code mineur : 92 achevé : Non
...
SECJ0395E: Impossible de localise le serveur de sécurité sur l'hôte/le port : 9.42.72.27/9100 {0} afin de valider l'ID utilisateur et le mot de passe entrés. Il peut être nécessaire de spécifier un hôte ou un port de serveur de sécurité valide dans le fichier
(RACINE_INSTALL_WAS)/properties/sas.client.props.

Pour corriger ce problème, modifiez la propriété com.ibm.CORBA.validateBasicAuth=false dans le fichier sas.clients.props du client, qui se trouve dans WAS_HOME/profiles/<nom_profil>/properties, puis exécutez le client.

Le servlet de performances affiche des erreurs d'autorisation et ne peut pas fournir de statistiques

Dans WebSphere Application Server Version 6.1, lorsque la sécurité administrative est activée, le service d'administration est verrouillé. Cependant, si la sécurité d'application n'est pas activée, aucune question d'authentification ne survient pour les requêtes entrantes et, par conséquent, les droits d'accès permettant au servlet de performances d'accéder au service d'administration n'existent pas.

Si la sécurité administrative est activée, vous devez également activer la sécurité d'application afin que le servlet de performances traite les requêtes entrantes.

Le message "La valeur de nom n'est pas valide" s'affiche lors de la migration des utilisateurs et des groupes une fois que le fournisseur JACC pour Tivoli est configuré

[AIX Solaris HP-UX Linux Windows][IBM i]Lorsque vous utilisez l'utilitaire migrateEAR pour faire migrer les modifications apportées aux utilisateurs et aux groupes de la console une fois que le fournisseur JAAC pour Tivoli est configuré, l'erreur de configuration ci-dessous s'affiche dans le fichier systemOut.log.

[z/OS]Lorsque vous utilisez l'utilitaire migrateEAR pour faire migrer les modifications apportées aux utilisateurs et aux groupes de la console une fois que le fournisseur JAAC pour Tivoli Access Manager est configuré, l'erreur de configuration ci-dessous s'affiche dans la sortie appropriée du fichier journal de travail.

La valeur de nom <specialSubjects> n'est pas valide
[z/OS]Remarque : Le fichier SystemOut n'existe pas sur le système d'exploitation z/OS et c'est la raison pour laquelle vous devez vérifier la sortie du journal de travail concerné sur le système d'exploitation z/OS.

L'utilitaire migrateEAR migre les données d'utilisateurs et de groupes contenues dans le fichier admin-authz.xml. Cependant, l'utilitaire migrateEAR ne convertit pas les balises XML du fichier admin-authz.xml si le groupe pdwas-admin est ajouté à la liste de contrôle d'accès (ACL) de l'administrateur dans Tivoli Access Manager avant la migration.

Pour résoudre cette erreur, entrez la commande suivante dans padadmin pour vérifier si le groupe pdwas-admin est dans la liste de contrôle d'accès de l'administrateur avant d'effectuer la migration :

acl show
_WebAppServer_deployedResources_Roles_administrator_admin-authz_ACL

Le résultat suivant doit s'afficher :

Nom de liste de contrôle d'accès :
_WebAppServer_deployedResources_Roles_administrator_admin-authz_ACL
Description : créé par Tivoli Access Manager
pour WebSphere Application Server Migration Tool.
Entrées :
Utilisateur sec_master TcmdbsvaBR1
Groupe pdwas-admin T[WebAppServer]i

Si le groupe pdwas-admin n'est pas listé, entrez la commande suivante dans pdadmin afin de modifier la liste de contrôle d'accès et ajouter le groupe pdwas-admin :

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

JDK Supn ne peut pas lire un fichier de clés PKCS12 créé par le serveur d'applications

Un JDK Sun ne peut pas lire un fichier de clés PKCS12 créé par le serveur d'applications. En effet, l'implémentation PKCS12 utilisée par le SDK IBM et le serveur d'applications est différente de celle utilisée par le JDK Sun. Cette différence entraîne des incidents lorsqu'un JDK Sun est utilisé pour lire le fichier de clés certifiées par défaut, trust.p12, ou le fichier de clés par défaut, key.P12, créé par le serveur d'applications.

Le fichier de clés certifiées ne pouvant pas être lu par le JDK Sun, vous devez d'abord en extraire les certificats à l'aide d'un SDK IBM. Vous pouvez ensuite importer ces certificats dans un fichier de clés que le JDK Sun peut identifier correctement, comme un fichier de clés JKS.

L'appel d'une ressource sécurisée à partir d'une ressource non sécurisée n'est pas pris en charge

Si vous disposez d'une ressource non sécurisée (comme une page JSP ou un servlet) qui appelle une ressource sécurisée, l'application risque d'échouer si la ressource non sécurisée collecte les données des utilisateurs, puis les poste sur des fichiers JSP ou de servlet sécurisés en vue de leur traitement.

Pour éviter cette situation, structurez votre application Web de sorte que les utilisateurs soient obligés d'ouvrir une session avant que l'application n'effectue des actions HTTP POST sur des fichiers JSP ou de servlet sécurisés. Pour ce faire, sécurisez la première ressource à l'aide du mécanisme de sécurité de votre choix (par exemple, authentification de base, connexion par formulaire ou certificat).

Cette restriction est due au fait que l'authentification de base et la connexion par formulaire utilisent la méthode de servlet sendRedirect, qui comporte plusieurs implications pour l'utilisateur. La méthode sendRedirect est utilisée deux fois au cours de l'authentification de base et de la connexion par formulaire :

La méthode sendRedirect affiche d'abord la page d'authentification de base ou de connexion par formulaire dans le navigateur Web. Elle redirige ensuite ce dernier dans la page protégée sollicitée à l'origine. La méthode sendRedirect(String URL) ordonne au navigateur Web d'utiliser la requête HTTP GET pour accéder à la page spécifiée dans l'adresse Web. Si HTTP POST est la première demande envoyée à un fichier JSP ou de servlet protégé et qu'aucune authentification ou connexion précédente n'a eu lieu, HTTP POST n'est pas acheminé vers la page demandée. En revanche, HTTP GET est acheminé, car l'authentification de base et la connexion par formulaire emploient la méthode sendRedirect, qui se comporte comme une demande HTTP GET qui tente d'afficher la page demandée après l'établissement d'une connexion.


Icône indiquant le type de rubrique Rubrique de référence



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rtrb_secconfigprobs
Nom du fichier : rtrb_secconfigprobs.html