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é.
- Affichage du message "Mot de passe LTPA non défini. Echec de la validation"
Le fichier setupClient.bat ou setupClient.sh ne s'exécute pas correctement
Java HotSpot Server VM warning
- WebSphere Application Server Version 6 ne fonctionne pas correctement avec Enterprise Workload Manager (EWLM)
- Si vous avez correctement configuré la sécurité, mais que vous êtes confronté à des incidents lors de l'accès à des ressources Web ou à la console d'administration, reportez-vous à Erreurs ou incidents d'accès après l'activation de la sécurité.
- NMSV0610I: Une exception NamingException est générée par une implémentation javax.naming.Context
- Le servlet de performances affiche des erreurs d'autorisation et ne peut pas fournir de statistiques
- 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é
- JDK Supn ne peut pas lire un fichier de clés PKCS12 créé par le serveur d'applications
- L'appel d'une ressource sécurisée à partir d'une ressource non sécurisée n'est pas pris en charge
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
- Sélectionnez .
- 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]](../images/dist.gif)
![[z/OS]](../images/ngzos.gif)
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]](../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
- Supprimez la barre oblique ( / ) après le fichier :.
- Remplacez sas par soap.
![[HP-UX]](../images/hpux.gif)
Java HotSpot Server VM warning
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)
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
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é
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.
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]](../images/ngzos.gif)
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.