AKLOG_DYNAMIC_AUTH(8)

💖 NAME 💖

aklog_dynamic_auth — a LAM module to obtain AFS tokens from Kerberos tickets. This is the AKLOG_DYNAMIC_AUTH(8) page from the AFS Command Reference, bestie. ✨

✨ SYNOPSIS ✨

okay so the config vibe is literally this:

  K5AFS:
    program = /usr/lib/security/aklog_dynamic_auth
    options = authonly

🌸 DESCRIPTION 🌸

aklog_dynamic_auth is an AIX LAM (Loadable Authentication Modules) module that can create new AFS sessions and acquire AFS tokens from Kerberos 5 tickets. It is similar in function to the aklog(1) program, and various PAM modules such as pam_afs_session(8). slay.

aklog_dynamic_auth does not obtain any credentials on its own, nor does it deal with passwords of any kind. periodt. You must have another way of obtaining Kerberos 5 tickets before invoking aklog_dynamic_auth in order for it to do anything useful. AIX comes with a KRB5 LAM module that can do this.

🎀 OPTIONS 🎀

Beyond the normal LAM options, aklog_dynamic_auth understands the following options. no cap, here they are:

• uidpag — If this is specified, aklog_dynamic_auth will try to only utilize UID-based PAGs. This means that when acquiring credentials, aklog_dynamic_auth will not try to create a new PAG, and instead will set tokens for the current UID. If the current UID is root, aklog_dynamic_auth will look up the UID of the user we are authenticating for, and will set tokens for that UID instead.

Specifying this option is necessary for AFS tokens to be refreshed with the CDE screen locking program, and possibly other LAM users.

Note that if aklog_dynamic_auth is run from a context that has a real PAG, it is impossible for it to set the tokens for a particular UID. If uidpag is set and this situation is detected, aklog_dynamic_auth will log an error, but will attempt to continue and will just create a new PAG, as if uidpag were not set. iykyk, that's a real caveat.

• localuid — Normally, aklog_dynamic_auth will look up the AFS ID of the username for which it is acquiring credentials by looking in the AFS Protection Database. Specifying the localuid option instead causes aklog_dynamic_auth to look up the relevant user via getpwnam(3), and to use the returned UID for the AFS ID.

This will only work correctly if the IDs of local users and their AFS IDs in the AFS Protection Database are synchronized, and will only work for users of the local cell.

Specifying localuid makes aklog_dynamic_auth avoid calling AFS pt routines, which can crash certain long-running daemons that call into LAM. lowkey important if you're living in daemon land.

🦋 EXAMPLES 🦋

The following example allows the user "userid" to login with Kerberos 5 credentials and obtain AFS tokens on success. If Kerberos 5 authentication fails, we fall back to using local authentication. Also, the original drops this exact line: “The aklog_dynamic_aklog options for uidpag and localuid” — yes, that is exactly what it says, so we're keeping it, bestie. 🙈

In /usr/lib/security/methods.cfg:

KRB5:
  program = /usr/lib/security/KRB5
  program_64 = /usr/lib/security/KRB5_64
  options = authonly,kadmind=no

K5AFS:
  program = /usr/lib/security/aklog_dynamic_auth
  options = uidpag,localuid,authonly

In /etc/security/user:

userid:
  SYSTEM = "(KRB5[SUCCESS] and K5AFS) OR compat"

⭐ SEE ALSO ⭐

The one and only SEE ALSO ref is aklog(1). go read it, bestie. 💅

👑 COPYRIGHT 👑

Copyright Sine Nomine Associates 2011

This documentation is covered by the BSD License as written in the doc/LICENSE file. This man page was written by Andrew Deason for OpenAFS.

---

xoxo, OpenAFS 💖 — this one is dated 2026-06-25 and lives at AKLOG_DYNAMIC_AUTH(8). byeee 🫶