bug: krb5_get_host_realm() no longer uses DNS

Nicolas Williams Nicolas.Williams at oracle.com
Mon May 17 17:07:21 EDT 2010


On Mon, May 17, 2010 at 04:32:51PM -0400, Richard Silverman wrote:
> On Mon, 17 May 2010, Greg Hudson wrote:
> >> If a server determines its realm via
> >> a TXT record, e.g. for gss_acquire_cred(), then it now fails where it
> >> worked in earlier versions (this has bitten me with OpenSSH).
> >
> > Is there a reason your server needs to use gss_acquire_cred with a
> > specified name, as opposed to just passing null credentials to
> > gss_accept_sec_context, or a null name to gss_acquire_cred?
> 
> Well, often this is not possible; many servers have determination of their
> service principal hard-wired.  In this particular case it is possible,
> since my OpenSSH build has a GSSAPIStrictAcceptorCheck parameter.
> However, then ideally I should place a copy of the host principal in an
> OpenSSH-specific keytab.  OpenSSH does not have a parameter for keytab
> location, so I have to modify the startup process to set
> KRB5_KTNAME... and so on.

You can always use GSS_C_NO_CREDENTIAL and then inquire the established
security context's acceptor principal name to see that it matches what
you expected.  In fact, that's what I recommend.  Ideally the GSS-API
should allow adding elements for multiple principals to credential
handles, but we're not there.  The krb5 mechanism should get fixed, and
it could be fixed without fixing the underlying krb5 API.

Nico
-- 



More information about the Kerberos mailing list