Greetings,

It turns out that interaction between the epam helper and pam_krb5 *is*
to blame here. I've been fighting an ejabberd node that refuses to send
presence notification requests to clients for a few years, and after
discovering this bug and trying one last thing... I found it.

https://github.com/processone/ejabberd/blob/2.1.x/src/pam/epam.c

From my log when attempting to request presence notification from an
account on my node to another node:

Jan 14 19:45:51 fritz epam: pam_krb5(ejabberd:account): pam_sm_acct_mgmt: entry
(0x0)
Jan 14 19:45:51 fritz epam: pam_krb5(ejabberd:account): skipping non-Kerberos
login
Jan 14 19:45:51 fritz epam: pam_krb5(ejabberd:account): pam_sm_acct_mgmt: exit
(ignore)

When used for auth, everything works because the password is supplied
and credentials are gained. the acct_mgmt call (used somewhere when
receiving things like presence requests), however, does not work because
no credentials are available. From what I can tell, you have to do the
account check during the same transaction as the auth check. This does
not appear to be incorrect behavior for a pam module:

http://www.linux-pam.org/Linux-PAM-html/adg-interface-by-app-expected.html#adg-pam_acct_mgmt

        "The pam_acct_mgmt function is used to determine if the users
        account is valid. It checks for authentication token and account
        expiration and verifies access restrictions. It is typically
        called after the user has been authenticated."

I'm not sure using a pam account check is correct, or if using pam_krb5
effectively requires using another service for the account db (the
default /is/ to check if users exist in the user db before allowing
auth). A seemingly sufficient workaround (assuming NSS users are all
valid for ejabberd, probably a valid assumption if bare pam_krb5 is
being used without something like pam_ldap) is to use the pam_unix
module, ignoring shadow errors:

        account sufficient pam_unix.so broken_shadow

So, I'm not sure if this is a bug in ejabberd (incorrect use of PAM), or
merely local configuration error (that perhaps ought to be documented
better in the pam_krb5 docs, since there are comments in the source
indicating that this is a *very* common misconfiguration).

I hope this helps figure out the correct resolution... two years of
chasing red herrings, ack.

-- 
<Morty_md> My mind boggled.
* tim_m shakes morty's mind, hoping for a different combination of letters
<Morty_md> Sometimes my mind yahtzees instead.

Attachment: pgpxy7XLM9aLX.pgp
Description: PGP signature

Reply via email to