Administración de usuarios en AIX: mkuser/chuser/lsuser, /etc/security/user y cómo forzar el cambio de contraseña

Qué es

AIX reparte los datos de las cuentas de usuario en más archivos de los que supone el modelo mental de Linux basado solo en /etc/passwd. mkuser, chuser y lsuser son los comandos admitidos para crear, modificar y listar cuentas; escriben en /etc/passwd y en la base de datos de seguridad, principalmente /etc/security/user (atributos de política por usuario, como las restricciones de horario de acceso) y /etc/security/passwd (hash de la contraseña e indicadores). El historial de contraseñas se guarda aparte, en /etc/security/pwdhist. mkuser deliberadamente no establece una contraseña: según la página del manual, no crea información de contraseña para el usuario, de modo que una cuenta recién creada tiene un asterisco en el campo de contraseña y no puede iniciar sesión con contraseña hasta que un administrador defina una, normalmente con passwd o pwdadm.

pwdadm administra los indicadores relacionados con la contraseña por separado del valor de la contraseña en sí: pwdadm -f ADMCHG <user> obliga a cambiarla en el siguiente inicio de sesión, independientemente de que se asigne una contraseña concreta (una contraseña establecida por un administrador ya suele llevar este indicador), y pwdadm -q <user> muestra los indicadores actuales. /etc/security/user también contiene restricciones de acceso como logintimes, que limita cuándo puede iniciar sesión una cuenta. Como ese atributo reside fuera de /etc/passwd, un fallo de inicio de sesión sin causa evidente en /etc/passwd suele remontarse a este archivo, y la salida de lsuser puede parecer incoherente si el valor está mal formado y no es simplemente restrictivo.

El control de acceso basado en roles mejorado (Enhanced Role Based Access Control, RBAC) es el mecanismo de AIX para delegar comandos privilegiados concretos sin dar acceso completo de root: lsattr -El sys0 -a enhanced_RBAC indica si está activo; lssecattr -F -c <path> comprueba si un comando ya tiene una asociación de privilegio o rol antes de crear una personalizada; un rol se muestra con lsrole -f <rolename> y se asigna con chuser roles=<rolename> <user>. Los cambios en roles o en entradas de comandos privilegiados solo llegan al kernel después de ejecutar setkst; a continuación, el usuario activa un rol asignado con swrole <rolename>, que solicita la contraseña de ese usuario.

Por qué importa

Si se considera que /etc/passwd refleja toda la información, se pasan por alto los controles que realmente regulan el acceso: una cuenta bloqueada, una restricción horaria o un indicador de cambio forzado pueden impedir un inicio de sesión mientras /etc/passwd parece normal. RBAC permite ejecutar una tarea operativa sin compartir la contraseña de root, pero solo si el administrador comprueba antes si ya existe un privilegio o rol; duplicarlo da lugar a autorizaciones en conflicto.

Cómo aplicarlo

• Cree las cuentas con mkuser (como root), establezca después una contraseña inicial y asegúrese de que ADMCHG esté activo (pwdadm -q <user>; si no lo está, pwdadm -f ADMCHG <user>), de modo que la contraseña temporal nunca sea la credencial definitiva de la cuenta.
• Cuando un inicio de sesión falle de forma inesperada, revise la base de datos de seguridad y no solo /etc/passwd: lsuser -a logintimes <user> y un vistazo directo a /etc/security/user, en el stanza de ese usuario.
• Antes de automatizar un rol RBAC personalizado para un comando, compruebe con lssecattr -F -c /path/to/command si ya tiene uno.
• Confirme el modo Enhanced RBAC antes de depender de los roles: lsattr -El sys0 -a enhanced_RBAC.

Trampas

• Suponer que una cuenta nueva creada con mkuser se puede usar de inmediato; no tiene contraseña hasta que se establece una.
• Leer solo /etc/passwd y pasar por alto logintimes u otra restricción similar en /etc/security/user.
• Crear un rol RBAC nuevo para un comando que ya tiene una autorización, lo que genera dos vías superpuestas hacia el mismo privilegio.