Administration des utilisateurs AIX : mkuser/chuser/lsuser, /etc/security/user et changement de mot de passe forcé

Ce que c'est

AIX répartit les données des comptes utilisateurs sur davantage de fichiers que ne le suppose un modèle mental Linux limité à /etc/passwd. mkuser, chuser et lsuser sont les commandes prises en charge pour créer, modifier et lister les comptes ; elles écrivent dans /etc/passwd et dans la base de données de sécurité, principalement /etc/security/user (attributs de politique par utilisateur, comme les restrictions d'horaires de connexion) et /etc/security/passwd (empreinte du mot de passe et indicateurs) ; l'historique des mots de passe est conservé à part dans /etc/security/pwdhist. mkuser ne définit volontairement aucun mot de passe : la page de manuel indique qu'il ne crée pas d'informations de mot de passe pour l'utilisateur. Un compte tout juste créé a donc un astérisque dans son champ de mot de passe et ne peut pas se connecter par mot de passe tant qu'un administrateur n'en a pas défini un, généralement avec passwd ou pwdadm.

pwdadm gère les indicateurs liés au mot de passe séparément de sa valeur : pwdadm -f ADMCHG <user> impose un changement à la prochaine connexion, indépendamment de la définition d'un mot de passe précis (un mot de passe défini par un administrateur porte normalement déjà cet indicateur), et pwdadm -q <user> affiche les indicateurs actuels. /etc/security/user contient aussi des restrictions de connexion telles que logintimes, qui limite les plages horaires pendant lesquelles un compte peut se connecter. Comme cet attribut se trouve en dehors de /etc/passwd, un échec de connexion sans cause apparente dans /etc/passwd s'explique souvent par ce fichier, et la sortie de lsuser peut sembler incohérente si la valeur est mal formée et pas simplement restrictive.

Le contrôle d'accès à base de rôles amélioré (Enhanced Role Based Access Control, RBAC) est le mécanisme d'AIX pour déléguer des commandes privilégiées précises sans donner un accès root complet : lsattr -El sys0 -a enhanced_RBAC indique s'il est actif ; lssecattr -F -c <path> vérifie si une commande possède déjà une association de privilège ou de rôle avant d'en créer une personnalisée ; un rôle s'affiche avec lsrole -f <rolename> et s'attribue avec chuser roles=<rolename> <user>. Les modifications des rôles ou des entrées de commandes privilégiées n'atteignent le noyau qu'après l'exécution de setkst ; l'utilisateur active ensuite un rôle attribué avec swrole <rolename>, qui demande le mot de passe de cet utilisateur.

Pourquoi c'est important

Considérer /etc/passwd comme la vue complète fait passer à côté des contrôles qui régissent réellement l'accès : un compte verrouillé, une restriction horaire ou un indicateur de changement forcé peuvent chacun bloquer une connexion alors que /etc/passwd paraît banal. Le RBAC permet d'exécuter une tâche d'exploitation sans mot de passe root partagé, mais seulement si l'administrateur vérifie d'abord l'existence d'un privilège ou d'un rôle : en dupliquer un expose à des autorisations contradictoires.

Comment l'appliquer

• Créer les comptes avec mkuser (en root), puis définir un mot de passe initial et s'assurer que ADMCHG est positionné (pwdadm -q <user>, sinon pwdadm -f ADMCHG <user>), afin que le mot de passe temporaire ne devienne jamais l'identifiant durable du compte.
• Lorsqu'une connexion échoue de façon inattendue, examiner la base de données de sécurité et pas seulement /etc/passwd : lsuser -a logintimes <user> et un examen direct de la strophe correspondante dans /etc/security/user.
• Avant de scripter un rôle RBAC personnalisé pour une commande, vérifier avec lssecattr -F -c /path/to/command si elle en possède déjà un.
• Confirmer le mode Enhanced RBAC avant de s'appuyer sur les rôles : lsattr -El sys0 -a enhanced_RBAC.

Pièges

• Supposer qu'un nouveau compte créé avec mkuser est utilisable immédiatement ; il n'a pas de mot de passe tant qu'on n'en définit pas un.
• Lire uniquement /etc/passwd et passer à côté d'une restriction logintimes ou similaire dans /etc/security/user.
• Créer un nouveau rôle RBAC pour une commande qui dispose déjà d'une autorisation, ce qui produit deux chemins redondants vers le même privilège.