> While that was certainly the goal for the Solaris modules pam_krb5's
> hardcoded behaviour is equivalent to what you used to get with
> try_first_pass. I know we discussed this and I'm pretty sure it is
> documented why in the PSARC cases that approved the changes; I'll need
> to look it up though.
PSARC/2002/469 Kerberos PAM module (pam_krb5) updates
for Ann-Marie certainly removes all the use/try stuff
from pam_krb5(5). It also states:
pam_sm_authenticate()
=====================
authenticates a user principal though the
Kerberos authentication service by fetching the user's initial credentials
with his/her Kerberos password and verifying them.
These credentials are stored in pam_krb5's internal kmd structure, and not
written to the user's credential cache file.
Old behaviour:
- authenticates the user with a Kerberos password
- writes or overwrites the user's credential cache file with the
new Kerberos credentials
New behaviour:
- authenticates the user with a Kerberos password, without storing
the user's credentials in a cache file.
- does not modify the user's credential cache file
(ie: does not create, destroy or write to the credential cache file)
- this is part of the fix to bug 4516537 "pam_krb5 does not conform
to the PAM standards set forth in pam(3PAM)"
pam_krb5(5):
pam_sm_authenticate() authenticates a user principal though the
Kerberos authentication service. If the authentication request is
successful, the authentication service sends a ticket-granting
ticket (tgt) back to the pam_krb5.so.1 module, which then verifies
that the TGT came from a valid KDC by attempting to get a service
ticket for the local host service. For this to succeed, the local
host's keytab file (/etc/krb5/krb5.keytab) must contain the entry
for the local host service (for example, host/hostname.com at REALM
where hostname.com is the fully qualified local hostname and REALM
is the default realm of the local host as defined in
/etc/krb5/krb5.conf). Once the TGT is verified, these
initial credentials are stored internally for the pam_sm_setcred()
function. If the host entry is not found in the keytab file, the
authentication fails.
The way I read both of these extracts from the case, neither imply
to me any prompting by pam_krb5.so. We even discussed announcing
the removal of try/use in a patch so they could get nuked in S10.
Perhaps I'm misreading them. If pam_krb5.so should be prompting,
then pam_authtok_get doesn't belong stacked above it in the
pam stack.
Gary..
