Null realms and servers

Jeffrey Altman jaltman at secure-endpoints.com
Sat Dec 16 10:08:11 EST 2006


Nicolas Williams wrote:
> On Fri, Dec 15, 2006 at 09:27:16PM -0500, Sam Hartman wrote:
>>>>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> writes:
>>     Nicolas> Just a few days ago I discussed with Sam an alternative
>>     Nicolas> fallback host2realm resolution that Solaris will likely
>>     Nicolas> soon sport:
>>
>>
>> Right.  I said at the time I was not thrilled by this strategy, but
>> didn't see a problem.  Note that I still see no problem with this
>> strategy for client side mapping to realms.
> 
> And how is krb5_sname_to_principal() to know that it's being called
> client-side vs. server-side?

Its not supposed to know.  The reason for the NULL realm being returned
by krb5_sname_to_principal is for client applications that currently
call it to be given a principal name in return that triggers the use
of Kerberos referrals without requiring that all the applications in
the world be re-written.

The issue Sam has raised is that now that NULL realms are being returned
the internal library behavior has changed in places where
krb5_sname_to_principal is called.  The first question is whether in the
keytab code in particular "should the keytab code be modified to restore
the previous behavior or is there a new behavior that is preferred?"
The second question is "given how close 1.6 is to shipping, does this
change whatever it ends up being need to be implemented now?"  In other
words, is it a show stopper bug that prevents the release.

I don't think that there is going to be any answer that results in all
use cases working out of the box with zero configuration.  For clients
we want the configuration to be on the servers and for them to use
referrals.  That is what brought us to this decision point.  Now we
need to determine what happens for services which will not be using
referrals.

I believe the solution Sam has described is acceptable given the
constraint that you don't want clients to be forced to be re-written
in order to benefit from the referrals code.

Jeffrey Altman






More information about the krbdev mailing list