kinit -S and krb 1.6

Mark Phalan Mark.Phalan at Sun.COM
Tue Jul 31 07:53:23 EDT 2007

On Tue, 2007-07-31 at 00:03 +0200, Mark Phalan wrote:
> On 30 Jul 2007, at 23:37, Sam Hartman wrote:
> >>>>>> "Mark" == Mark Phalan <Mark.Phalan at Sun.COM> writes:
> >
> >     Mark> Unless the krb5.conf file is properly populated (and no
> >     Mark> fallbacks are being used) "kinit -S" is essentially rendered
> >     Mark> useless.
> >
> >
> > I've always viewed kinit -s as an incredibly special purpose function
> > that required you have complete control of the resulting credentials
> > and their use.
> >
> The problem is not confined to kinit -S. Its true of any application  
> obtaining an initial service ticket and then trying to use the cached  
> ticket later on. That initial cached ticket will be stored with the  
> realm set. Later searches of the cred-cache will fail if a fallback  
> method for realm determination is being used.

Looking at this a bit more closely, it seems the applications themselves
can take care of this issue. As krb5_get_init_creds() doesn't actually
store the credential, applications calling this can be smart about what
they actually cache. This is not ideal as the application must become
"fallback" aware but workable - at least in the case of kadmin on
Solaris. There may be portability issues with other kerberos

"kadmin -S" is slightly more tricky as it provides a generic way to
acquire a service ticket - it's not aware of the type of service ticket
requested (host-based, not host-based).
Nico's solution works well here: just store both varients in the cred

I can provide a patch for kadmin.


More information about the krbdev mailing list