AIX-Benutzerverwaltung: mkuser/chuser/lsuser, /etc/security/user und erzwungene Passwortänderung

Worum es geht

AIX verteilt die Daten von Benutzerkonten auf mehr Dateien, als es ein Linux-Modell erwartet, das nur von /etc/passwd ausgeht. mkuser, chuser und lsuser sind die unterstützten Befehle zum Anlegen, Ändern und Auflisten von Konten. Sie schreiben in /etc/passwd und in die Security-Datenbank, vor allem in /etc/security/user (Richtlinienattribute pro Benutzer, etwa Einschränkungen der Login-Zeiten) und /etc/security/passwd (Passwort-Hash und Flags). Die Passwort-Historie wird separat in /etc/security/pwdhist geführt. mkuser setzt bewusst kein Passwort: Laut Man-Page legt es keine Passwortinformationen für einen Benutzer an. Ein frisch angelegtes Konto hat daher ein Sternchen im Passwortfeld und erlaubt keinen Passwort-Login, bis ein Administrator ein Passwort setzt, üblicherweise mit passwd oder pwdadm.

pwdadm verwaltet passwortbezogene Flags getrennt vom Passwortwert selbst: pwdadm -f ADMCHG <user> erzwingt eine Änderung beim nächsten Login, unabhängig davon, ob ein bestimmtes Passwort gesetzt wird (ein von einem Administrator gesetztes Passwort trägt dieses Flag normalerweise bereits). pwdadm -q <user> zeigt die aktuellen Flags an. /etc/security/user enthält ausserdem Login-Einschränkungen wie logintimes, das festlegt, wann sich ein Konto anmelden darf. Da dieses Attribut ausserhalb von /etc/passwd liegt, lässt sich ein Login-Fehler, für den in /etc/passwd keine Ursache erkennbar ist, oft auf diese Datei zurückführen. Die Ausgabe von lsuser kann widersprüchlich wirken, wenn der Wert fehlerhaft formatiert ist und nicht bloss einschränkend.

Enhanced Role Based Access Control (RBAC) ist der AIX-Mechanismus, um einzelne privilegierte Befehle zu delegieren, ohne volle Root-Rechte zu vergeben. lsattr -El sys0 -a enhanced_RBAC zeigt, ob er aktiv ist. lssecattr -F -c <path> prüft, ob ein Befehl bereits eine Zuordnung zu Privilegien oder Rollen hat, bevor eine eigene angelegt wird. Eine Rolle wird mit lsrole -f <rolename> angezeigt und mit chuser roles=<rolename> <user> zugewiesen. Änderungen an Rollen oder Einträgen für privilegierte Befehle gelangen erst nach setkst in den Kernel. Anschliessend aktiviert der Benutzer eine zugewiesene Rolle mit swrole <rolename>, was nach dem Passwort dieses Benutzers fragt.

Warum es wichtig ist

Wer /etc/passwd für das vollständige Bild hält, übersieht die Kontrollen, die den Zugang tatsächlich steuern: Ein gesperrtes Konto, eine Tageszeit-Einschränkung oder ein Flag für erzwungene Änderung können einen Login verhindern, obwohl /etc/passwd unauffällig aussieht. RBAC erlaubt es, eine betriebliche Aufgabe ohne gemeinsames Root-Passwort auszuführen, aber nur, wenn der Administrator zuvor prüft, ob bereits eine Privilegien- bzw. Rollenzuordnung existiert. Eine doppelte Zuordnung begünstigt widersprüchliche Autorisierungen.

So wird es angewendet

• Konten mit mkuser (als root) anlegen, dann ein Initialpasswort setzen und sicherstellen, dass ADMCHG gesetzt ist (pwdadm -q <user>, andernfalls pwdadm -f ADMCHG <user>), damit das temporäre Passwort nie das dauerhafte Credential des Kontos ist.
• Bei unerwartet fehlschlagendem Login nicht nur /etc/passwd, sondern die Security-Datenbank prüfen: lsuser -a logintimes <user> sowie ein direkter Blick in /etc/security/user auf die Stanza dieses Benutzers.
• Vor dem Skripten einer eigenen RBAC-Rolle für einen Befehl mit lssecattr -F -c /path/to/command prüfen, ob dafür bereits eine existiert.
• Vor dem Einsatz von Rollen den Enhanced-RBAC-Modus bestätigen: lsattr -El sys0 -a enhanced_RBAC.

Stolpersteine

• Annehmen, ein neues mit mkuser angelegtes Konto sei sofort nutzbar; es hat kein Passwort, bis eines gesetzt wird.
• Nur /etc/passwd lesen und dabei logintimes oder eine ähnliche Einschränkung in /etc/security/user übersehen.
• Eine neue RBAC-Rolle für einen Befehl anlegen, der bereits eine Autorisierung hat, und so zwei sich überschneidende Wege zum selben Privileg schaffen.