[17465] in Kerberos_V5_Development
Re: idea about modifying pam_krb5 use of krb5_verify_init_creds
daemon@ATHENA.MIT.EDU (Russ Allbery)
Sun Jan 22 20:25:09 2012
From: Russ Allbery <rra@stanford.edu>
To: MIT Kerberos Dev List <krbdev@mit.edu>
In-Reply-To: <20120123011736.GA15450@oracle.com> (Will Fiveash's message of
"Sun, 22 Jan 2012 19:17:36 -0600")
Date: Sun, 22 Jan 2012 17:25:06 -0800
Message-ID: <87pqebxlal.fsf@windlord.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
Will Fiveash <will.fiveash@oracle.com> writes:
> People may have addressed this already but for Solaris when one has
> provisioned a krb5.keytab with a host princ and is using pam-krb5 in the
> pam.conf auth stack, if the hostname changes the pam-krb5 will fail to
> verify a user's initial krb cred unless there is a host service princ in
> the krb5.keytab that matches the new hostname. What I'm thinking would
> be a better way for pam-krb5 to verify a user's initial krb cred is to
> use a service princ found in the existing keytab and call
> krb5_verify_init_creds() using that instead of using
> krb5_sname_to_princ(). In fact, pam-krb5 could get a list of all unique
> service princ names for the default realm in the keytab and call
> krb5_verify_init_creds() in a loop until either one succeeds or they all
> fail. Thoughts?
My preference, rather than putting code into pam-krb5 to read the keytab,
would be for there to be some way to tell krb5_verify_init_creds to
internally switch to this behavior.
This seems similar to, although distinct from, the discussion a while back
(with patches by Luke Howard) to use principal canonicalization.
--
Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
