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.
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.
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
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.
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]](../images/dist.gif)
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.
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.
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.
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]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
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.Un registre de système d'exploitation local est centralisé au sein d'un sysplex.
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.
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]](../images/dist.gif)
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.
- que le client ne dispose pas d'un des droits requis.
- que l'accès est refusé.

![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
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]](../images/dist.gif)
Utilisation du registre d'utilisateurs du domaine et du registre du système d'exploitation local
- 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.
- ExemplesLa machine MaMachine fait partie du domaine MonDomaine. La machine MaMachine contient les utilisateurs et les groupes suivants :
- MaMachine\utilisateur2
- MaMachine\utilisateur3
- MaMachine\groupe2
- MonDomaine\utilisateur1
- MonDomaine\utilisateur2
- MonDomaine\groupe1
- MonDomaine\groupe2
Voici des scénarios utilisant l'ensemble d'utilisateurs et de groupes précédent :- 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é.
- 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.
- 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.
- 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).
- 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.

![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
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é.
- Cliquez sur
- 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.
- Dans le menu Propriétés supplémentaires, sélectionnez Propriétés personnalisées.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
Utilisation des registres d'utilisateurs du système
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.
Seul le registre d'utilisateurs de la machine locale est utilisé. NIS (Yellow Pages) n'est pas pris en charge.
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.
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.