Registres du système d'exploitation local

Avec l'implémentation du registre pour le système d'exploitation local, le mécanisme d'authentification de WebSphere Application Server peut utiliser la base de données des comptes utilisateur disponible sur le système d'exploitation local.

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.

[IBM i]Si vous voulez utiliser le registre de système d'exploitation local pour représenter les principaux qui accèdent à vos ressources WebSphere Application Server, vous n'avez pas besoin d'effectuer de configuration particulière du registre d'utilisateurs. Ce registre est utilisé pour authentifier et autoriser les utilisateurs qui accèdent aux ressources WebSphere Application Server, mais pas les utilisateurs de WebSphere Application Server qui accèdent aux ressources du système d'exploitation. WebSphere Application Server ne fonctionne pas sous le profil d'utilisateur du système d'exploitation des utilisateurs de WebSphere Application Server. Par contre, WebSphere Application Server fonctionne sous le profil du système d'exploitation configuré par l'administrateur de WebSphere Application Server.

[IBM i]Vous ne pouvez autoriser un utilisateur d'une ressource WebSphere Application Server que s'il existe un profil d'utilisateur pour cet utilisateur dans le système d'exploitation. La commande CRTUSRPRF (Create User Profile) permet de créer des ID utilisateur pouvant être utilisés par WebSphere Application Server

[AIX Solaris HP-UX Linux Windows]Le registre LDAP (Lightweight Directory Access Protocol) est centralisé. Ce n'est pas le cas pour la plupart des registres de système d'exploitation local.

[AIX Solaris HP-UX Linux Windows]WebSphere Application Server fournit des implémentations pour le registre des comptes local et le registre des domaines Windows . Il propose également des implémentations pour le registre des comptes utilisateur Linux, Solaris, et AIX. Windows Active Directory est pris en charge via l'implémentation du registre d'utilisateurs LDAP présenté ultérieurement.

[AIX Solaris HP-UX Linux Windows]
Remarque : Pour Active Directory (contrôleur de domaine), les trois niveaux de groupe sont le groupe local, le groupe global et le groupe universel. Les deux types de groupe sont Sécurité et Distribution.
Lorsqu'un groupe est créé, la valeur par défaut est Global et le type par défaut est Sécurité. Avec le support de registre de domaine Windows NT pour les contrôleurs de domaine Windows 2003, WebSphere Application Server prend en charge uniquement les groupes globaux de type Sécurité. Il est recommandé d'utiliser le support de registre Active Directory au lieu d'un registre de domaineWindows NT si vous utilisez les contrôleurs de domaine Windows 2003 domain, car Active Directory prend en charge tous les portées et types de groupe. Active Directory prend également en charge un groupe imbriqué qui n'est pas pris en charge par le registre de domaine Windows NT. Active Directory est un registre de contrôle centralisé.
Remarque : WebSphere Application Server n'a pas à installer le membre du domaine car il peut être installé sur n'importe quel système et n'importe quelle plateforme. Notez que l'appel natif du domaine Windows NT ne renvoie que le groupe de support, sans erreur.

[AIX Solaris HP-UX Linux Windows][IBM i]N'utilisez pas le registre de système d'exploitation local dans un environnement WebSphereApplication Server où les serveurs d'applications sont répartis sur plusieurs systèmes car chaque système dispose de son propre registre d'utilisateurs.

[AIX Solaris HP-UX Linux Windows]Le registre de domaine Windows et NIS (Network Information Services) sont des exceptions. Le registre de domaine Windows et les services NIS (NIS Network Information Services) sont des registres centralisés. Le registre de domaine Windows est pris en charge par WebSphere Application Server, contrairement à NIS.

[AIX Solaris HP-UX Linux Windows][IBM i]Comme mentionné précédemment, les ID d'accès provenant du registre d'utilisateurs sont utilisés lors des vérifications d'autorisation. Comme il s'agit généralement d'identificateurs uniques, ils varient en fonction des systèmes même si des utilisateurs et des mots de passe identiques sont définis sur chaque système.

[AIX Solaris HP-UX Linux Windows][IBM i]L'authentification des certificats client Web n'est pas actuellement prise en charge lors de l'utilisation du registre d'utilisateurs du système d'exploitation local. Toutefois, l'authentification du certificat client Java™ fonctionne avec un registre d'utilisateurs du système d'exploitation local. L'authentification du certificat client Java mappe le premier attribut du nom de domaine du certificat vers l'ID utilisateur du registre d'utilisateurs.

[AIX Solaris HP-UX Linux Windows][IBM i]Même si les certificats client Java fonctionnent correctement, l'erreur suivante s'affiche dans le fichier SystemOut.log :

CWSCJ0337E: La méthode mapCertificate n'est pas prise en charge

L'erreur concerne les certificats client Web. Toutefois, elle s'affiche également pour les certificats client Java. Ignorez cette erreur pour les certificats client Java.

[z/OS]Un registre de système d'exploitation local est centralisé au sein d'un sysplex.

[z/OS]WebSphere Application Server utilise les interfaces SAF (System Authorization Facility). Ces interfaces sont définies par MVS pour autoriser les applications à utiliser les services d'autorisation ou les registres du système dans le but de contrôler l'accès aux ressources, telles que les fichiers et les commandes MVS. Le mécanisme SAF permet de traiter directement les demandes d'autorisation par le biais de la fonction RACF (Resource Access Control Facility) ou d'un fournisseur de sécurité z/OS tiers. Si vous n'avez pas sélectionné le système d'exploitation local comme registre d'utilisateurs, vous devez fournir un mappage entre une identité du registre d'utilisateurs et un ID utilisateur SAF. Pour plus d'informations, voir Modules de mappage SAF (System Authorization Facility) personnalisés.

[z/OS]L'authentification des certificats client Web est prise en charge lors de l'utilisation du registre d'utilisateurs du système d'exploitation local. Des certificats numériques peuvent être mappés vers des identités MVS à la fois par des clients Web et Java lors de la sélection du système d'exploitation local. Un filtre de noms de certificats peut être utilisé pour simplifier le mappage. Si vous utilisez RACF comme serveur de sécurité, la commande RACDCERT MAP crée un profil de ressource qui mappe plusieurs identités d'utilisateur vers un certificat numérique afin de simplifier l'administration des certificats, conserve l'espace de stockage dans la base de données RACF et gère la comptabilité ou la granularité du contrôle des accès.

[AIX Solaris HP-UX Linux Windows]

Droits requis

L'utilisateur qui exécute le processus WebSphere Application Server doit disposer de suffisamment de droits de système d'exploitation afin d'appeler l'API système Windows pour l'authentification et l'obtention d'informations sur les utilisateurs et les groupes à partir du système d'exploitation Windows. Cet utilisateur se connecte à la machine ou en cas d'exécution en tant que service, est l'utilisateur qui a ouvert une session en tant que service. En fonction de la machine (qu'il s'agisse d'une machine autonome ou d'une machine faisant partie d'un domaine ou si cette machine est le contrôleur de domaine), les droits d'accès varient.

  • Pour une machine autonome, l'utilisateur :
    • doit être membre du groupe d'administration,
    • doit disposer du droit Agir en tant que partie du système d'exploitation,
    • doit disposer du droit Ouvrir une session en tant que service, si le serveur est exécuté en tant que service.
  • Pour une machine qui est membre d'un domaine, seul un utilisateur de domaine peut démarrer le processus serveur et :
    • dispose du droit Agir en tant que partie du système d'exploitation dans la règle de sécurité du domaine du contrôleur de domaine,
    • dispose du droit Agir en tant que partie du système d'exploitation dans la règle de sécurité locale sur la machine locale,
    • dispose du droit Ouvrir une session en tant que service sur la machine locale si le serveur est exécuté en tant que service.

      L'utilisateur est un utilisateur de domaine et non un utilisateur local, ce qui implique que lorsqu'une machine fait partie d'un domaine, seul un utilisateur de domaine peut démarrer le serveur.

  • Pour une machine Contrôleur de domaine, l'utilisateur :
    • est membre des groupes d'administration de domaine dans le contrôleur de domaines,
    • dispose du droit Agir en tant que partie du système d'exploitation dans la règle de sécurité du domaine du contrôleur de domaine,
    • dispose du droit Ouvrir une session en tant que service sur le contrôleur de domaine, si le serveur est exécuté en tant que service.
Si l'utilisateur exécutant le serveur ne dispose pas des droits requis, vous pouvez obtenir un message dans les fichiers journaux indiquant :
  • que le client ne dispose pas d'un des droits requis.
  • que l'accès est refusé.
Eviter les incidents Eviter les incidents: Le serveur d'applications doit être démarré avec les privilèges Administrateur si vous utilisez une invite de commande. Démarrez le serveur d'applications depuis une fenêtre d'invite de commande lancée en procédant comme suit :
  • Cliquez avec le bouton droit de la souris sur un raccourci d'invite de commande.
  • Cliquez sur Exécuter en tant qu'administrateur.

    Lorsque vous ouvrez la fenêtre d'invite de commande en tant qu'administrateur une boîte de dialogue du système d'exploitation demande si vous voulez poursuivre. Cliquez sur Continuer.

gotcha
[AIX Solaris HP-UX Linux Windows]

Registres d'utilisateurs local et du domaine

Lors du démarrage de WebSphere Application Server, le processus d'initialisation du module d'exécution de la sécurité tente de déterminer de manière dynamique si la machine locale fait partie d'un domaine Windows. Si la machine fait partie d'un domaine, alors par défaut les groupes et les utilisateurs du registre local ainsi que les groupes et les utilisateurs du registre de domaine peuvent être utilisés à des buts d'authentification et d'autorisation, le registre de domaine étant prioritaire. La liste des utilisateurs et des groupes présentés lors du mappage de rôle de sécurité inclut alors les utilisateurs et les groupes du registre d'utilisateur local et du registre d'utilisateurs du domaine. Les utilisateurs et les groupes peuvent être distingués à l'aide des noms d'hôte associés.

WebSphere Application Server ne prend pas en charge les domaines sécurisés.

Si la machine n'appartient à aucun domaine système Windows, le registre utilisateur local à cette machine est utilisé.

[AIX Solaris HP-UX Linux Windows]

Utilisation du registre d'utilisateurs du domaine et du registre du système d'exploitation local

Lorsque la machine qui héberge le processus WebSphereApplication Server fait partie d'un domaine, le registre d'utilisateurs de domaine et le registre d'utilisateurs local sont utilisés par défaut. La section suivante comporte des informations détaillées et vous recommande les meilleures pratiques afin d'éviter des résultats indésirables.
Remarque : Bien que cette section ne concerne pas directement z/OS, vous devez savoir que la manière dont vous configurez ces registres a une incidence sur les opérations de sécurité générales.
  • Meilleures pratiques
    • Généralement, si le registre local et le registre de domaine ne contiennent pas d'utilisateurs ou de groupes communs, l'administration est plus simple et les effets secondaires indésirables sont supprimés. Dans la mesure du possible, accordez aux utilisateurs et aux groupes un accès à des rôles de sécurité uniques, comprenant l'ID serveur et les rôles d'administration. Dans ce cas, sélectionnez les utilisateurs et les groupes à partir du registre d'utilisateurs local ou du registre d'utilisateurs de domaine pour effectuer le mappage vers les rôles.
    • Lorsque les mêmes utilisateurs ou les mêmes groupes existent à la fois dans le registre d'utilisateurs local et dans le registre d'utilisateurs de domaine, il est recommandé qu'au moins l'ID serveur et les utilisateurs et les groupes mappés vers les rôles d'administration soient uniques dans les registres et existent uniquement dans le domaine.
    • S'il existe un ensemble commun d'utilisateurs, définissez un mot de passe différent afin de vous assurer que l'utilisateur approprié est authentifié.
  • Mode de fonctionnement
    • Lorsqu'une machine fait partie d'un domaine, le registre d'utilisateurs du domaine est prioritaire sur le registre d'utilisateurs local. Par exemple, lorsqu'un utilisateur se connecte au système, le registre d'utilisateurs du domaine tente tout d'abord d'authentifier l'utilisateur. Si l'authentification échoue, le registre d'utilisateurs local est utilisé. Lorsqu'un utilisateur ou un groupe est mappé vers un rôle, les informations d'utilisateur et de groupe sont d'abord obtenues à partir du registre d'utilisateurs du domaine. En cas d'échec, le système tente d'utiliser le registre d'utilisateurs local.
    • Toutefois, lorsqu'un nom de groupe ou d'utilisateur complet, comportant un nom d'hôte ou de domaine, est mappé vers un rôle, alors seul ce registre d'utilisateurs est utilisé pour obtenir les informations. Utilisez la console d'administration ou les scripts pour obtenir les noms de groupe et d'utilisateur complets. Il s'agit de la meilleure méthode pour mapper les utilisateurs et les groupes vers des rôles.
      Conseil : Un utilisateur, Paul, sur une machine du registre d'utilisateurs du système d'exploitation local, par exemple, n'est pas le même que l'utilisateur Paul d'une autre machine du registre d'utilisateurs du domaine, par exemple, car l'ID unique de Paul, l'identificateur de sécurité [SID], dans ce cas, est différent dans les différents registres d'utilisateurs.
  • Exemples
    La machine MaMachine fait partie du domaine MonDomaine. La machine MaMachine contient les utilisateurs et les groupes suivants :
    • MaMachine\utilisateur2
    • MaMachine\utilisateur3
    • MaMachine\groupe2
    Le domaine MonDomaine contient les utilisateurs et les groupes suivants :
    • MonDomaine\utilisateur1
    • MonDomaine\utilisateur2
    • MonDomaine\groupe1
    • MonDomaine\groupe2
    Voici des scénarios utilisant l'ensemble d'utilisateurs et de groupes précédent :
    1. Lorsque l'utilisateur utilisateur2 se connecte au système, le registre d'utilisateurs du domaine est utilisé pour l'authentification. Si l'authentification échoue car le mot de passe est différent, par exemple, le registre d'utilisateurs local est utilisé.
    2. Si l'utilisateur MaMachine\utilisateur2 est mappé vers un rôle, seul l'utilisateur utilisateur2 de la machine MaMachine peut accéder à ce rôle. Ainsi, si le mot de passe d'utilisateur2 est identique sur les registres d'utilisateurs de domaine et local, l'utilisateur utilisateur2 ne peut pas accéder à la ressource, car l'utilisateur utilisateur2 est toujours authentifié à l'aide du registre d'utilisateurs de domaine. Si des registres d'utilisateurs comportent des utilisateurs communs, il est recommandé d'utiliser des mots de passe différents.
    3. Si le groupe groupe2 est mappé vers un rôle, seuls les utilisateurs faisant partie du groupe MonDomaine\groupe2 peuvent accéder à la ressource étant donné que les informations de groupe2 sont d'abord obtenues à partir du registre d'utilisateurs du domaine.
    4. Si le groupe MaMachine\groupe2 est mappé vers un rôle, seuls les utilisateurs faisant partie du groupe MaMachine\groupe2 peuvent accéder à la ressource. Un groupe spécifique est mappé vers le rôle (MaMachine\groupe2 au lieu de groupe2).
    5. Utilisez l'utilisateur utilisateur3 ou MaMachine\utilisateur3 pour mapper un rôle car l'utilisateur utilisateur3 est unique puisqu'il n'existe que dans un registre d'utilisateurs.

    L'autorisation avec le registre d'utilisateurs du domaine peut provoquer des erreurs si un utilisateur ayant le même mot de passe existe à la fois dans le registre d'utilisateurs local et dans le registre d'utilisateurs du domaine. L'autorisation fondée sur les rôles peut alors échouer car l'utilisateur est tout d'abord authentifié dans le registre d'utilisateurs du domaine. Cette authentification génère un ID de sécurité du domaine unique utilisé dans WebSphere Application Server lors de la vérification de l'autorisation. Toutefois, le registre d'utilisateurs local permet d'attribuer des rôles. L'ID de sécurité du domaine ne correspond pas à l'ID de sécurité unique associé au rôle. Pour éviter ce problème, mappez les rôles de sécurité vers les utilisateurs de domaine à la place des utilisateurs locaux.

    Si plusieurs noeuds sont mis en oeuvre, seul un référentiel centralisé peut être utilisé. Cela implique que seul le registre d'utilisateurs du domaine peut être utilisé car les ID uniques de groupe et d'utilisateur varient sur les différents noeuds, comme mentionné précédemment.

Eviter les incidents Eviter les incidents: Avant ce groupe de correctifs, le registre d'utilisateurs du système d'exploitation local sur les systèmes UNIX pouvait ne pas trouver les noms de groupe si le registre contenait un grand nombre de groupes. Ce problème découle d'une limitation de mémoire et se produit généralement lorsque le registre contient plusieurs centaines de groupes. A partir de ce groupe de correctifs, la taille de mémoire tampon peut recevoir un grand nombre de groupes.gotcha
[AIX Solaris HP-UX Linux Windows][IBM i]

Utilisation du registre d'utilisateurs local ou de domaine

Si vous accédez aux utilisateurs et aux groupes à partir du registre d'utilisateurs local ou du registre d'utilisateurs de domaine, et non à partir des deux, définissez la propriété com.ibm.websphere.registry.UseRegistry. Vous pouvez attribuer la valeur local ou domain à cette propriété. Lorsque la valeur local (aucune distinction entre les minuscules et les majuscules) est attribuée à cette propriété, seul le registre d'utilisateurs local est utilisé. Lorsque la valeur correspond à domain (aucune distinction entre les minuscules et les majuscules), seul le registre d'utilisateurs de domaine est utilisé.

Définissez cette propriété en exécutant les étapes ci-dessous qui permettent d'accéder au panneau Propriétés personnalisées de la console d'administration :
  1. Cliquez sur Sécurité > Sécurité globale
  2. Sous Référentiel du compte d'utilisateur, cliquez sur la liste déroulante Définitions des domaines disponibles, sélectionnez Système d'exploitation local, puis cliquez sur Configurer.
  3. Dans le menu Propriétés supplémentaires, sélectionnez Propriétés personnalisées.
Vous pouvez également utiliser l'outil wsadmin pour configurer cette propriété. Lorsque cette propriété est définie, les droits requis pour l'utilisateur qui exécute le processus du produit sont identiques. Par exemple, si la valeur local est attribuée à cette propriété, l'utilisateur exécutant le processus doit disposer des mêmes droits que si la propriété n'était pas définie.
[AIX Solaris HP-UX Linux Windows]

Utilisation des registres d'utilisateurs du système

Les remarques suivantes sont à prendre en compte si vous utilisez les registres d'utilisateurs système :
  • [AIX][HP-UX][Linux][Solaris]Si vous utilisez les registres d'utilisateurs du système, l'ID sous lequel le processus WebSphere Application Server est exécuté doit posséder les droits root afin d'appeler les API du système d'exploitation local pour l'authentification et extraire des informations sur les utilisateurs et les groupes.
  • [AIX][HP-UX][Linux][Solaris]Seul le registre d'utilisateurs de la machine locale est utilisé. NIS (Yellow Pages) n'est pas pris en charge.
  • [HP-UX]Si vous utilisez le registre d'utilisateurs du système d'exploitation local, HP-UX doit être configuré en mode non sécurisé. Le mode sécurisé n'est pas pris en charge lors de l'utilisation du registre d'utilisateurs du système d'exploitation local.
  • [Linux][Solaris]

    Pour que le registre de système d'exploitation local de WebSphere Application Server fonctionne sur les plateformes Linux et Solaris, un fichier de de mots de passe dupliqués doit exister. Le fichier de dissimulation de mots de passe se nomme shadow et se trouve dans le répertoire /etc. Si ce fichier n'existe pas, une erreur se produit après l'activation de la sécurité administrative et la configuration du registre en tant que registre de système d'exploitation local.

    Pour créer le fichier de dissimulation, exécutez la commande pwconv (sans paramètres). Cette commande crée un fichier /etc/shadow à partir du fichier /etc/passwd. Une fois le fichier de dissimulation créé, vous pouvez activer la sécurité du système d'exploitation local.


Icône indiquant le type de rubrique Rubrique de concept



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=csec_localos
Nom du fichier : csec_localos.html