I left something out: the original issue of this thread. Inline.
On Thu, May 17, 2001 at 09:04:05AM -0400, Nicolas Williams wrote:
> Perhaps we can specify the behaviour of PAM_KRB5:account. Here I go:
>
> - pam_krb5:authenticate() MUST record the fact that it's been called
> and its return value in pam data
>
> - pam_krb5:authenticate() MUST records, in pam data, wether the user's
> password is expired
>
> - IF pam_krb5:authenticate() returned PAM_SUCCESS and the user's
> password IS NOT expired then pam_krb5:acct_mgmt() MUST check the user
> principal's access to the PAM_USER account as usual
>
> - if pam_krb5:authenticate() returned PAM_SUCCESS and the user's
> password IS expired then pam_krb5:acct_mgmt() MUST return
> PAM_NEW_AUTHTOK_REQD
>
> - if pam_krb5:authenticate() returned an error, then
> pam_krb5:acct_mgmt() MUST NOT return PAM_SUCCESS
>
> - if pam_krb5:authenticate() returned an PAM_IGNORE then
> pam_krb5:acct_mgmt() MUST return PAM_IGNORE.
- if pam_krb5:authenticate() was not called then pam_krb5:acct_mgmt()
MUST return PAM_IGNORE.
This item changes radically if we do the thing that SEAM's PAM_KRB5
does. I.e., if PAM is used in the case of kerberos-network-
authenticated telnet (and the like) then the authenticated user
principal name MUST be made available to pam_krb5:acct_mgmt()
somehow (PAM_RUSER?).
> NOTE: pam_krb5:chauthtok() MUST re-authenticate and authorize the user
> after changing an expired password. This is because with Kerberos
> authentication cannot happen until the expired password is
> changed. The easiest way to do this is to call
> pam_krb5:authenticate() and pam_krb5:acct_mgmt() from within
> pam_krb5:chauthtok() after changing the expired password.
>
> NOTE: pam_krb5:authenticate() MUST reset those state flags when it
> starts as it can be called more than once (i.e., if the app calls
> pam_authenticate() more than once on the sam pam handle). It does
> not currently make sense to stack pam_krb5 more than once in a pam
> stack.
Cheers,
Nico
--
