Null realms and servers

Nicolas Williams Nicolas.Williams at sun.com
Thu Dec 28 17:45:10 EST 2006


On Wed, Dec 27, 2006 at 03:16:36PM -0500, Sam Hartman wrote:
>     Nicolas> Now, servers don't need domain_realm relations, so this
>     Nicolas> is not an issue for servers.
> 
> Servers do need domain_realm relations today.  Everyone who has stated
> an opinion seems to believe that default_realm is more accurate than
> trimming the hostname off the domain and upcasing the result (our
> current behavior).

I don't agree; I see from the below that you read the rest of my reply,
so you understand that there is a way to deal with not having a default
realm or any domain_realm relations on a server.

> I think you're saying that you want some behavior that does not depend
> on a default realm being set.  It's hard to tell because you are
> confusing (at least in what you write) client and server behavior.

Given that you recognize (below) my alternative to servers' need for
domain_realm relations I can't understand why you'd think I'm confused
about client and server roles.

> So, I'm going to assume that we are discussing what happens when there
> is no default realm set on a server.

Let's :)

> First, I'll point out that we both agree that servers need keytabs.

We'd have to :)

> Software that installs the keytab could set a default realm based on
> the realm in the keytab if there is not already a default realm set.

Q:  What do servers need a default realm or any domain_realm relations for?
A1: So krb5_sname_to_principal() + krb5_kt_get_entry() can handle
    user/admin-entered principal names w/o the realm name.
A2: They don't if they use a better interface that can match the
    user/admin-entered name against the list of principal names found in
    the keytab.
A3: If we're willing to resort to the sort of hack you're using in 1.6
    (and note: I am willing to) we can even do matching against the
    keytab without needing to resort to new APIs.

Note that a simple default realm won't help a server with acceptor creds
in multiple realms, and even domain_realm relations wouldn't help a
server with multiple acceptor creds for the same principal name in
different realms.

> Alternatively, as you point out, in the case where no default realm is
> set you could run your algorithm against the principals in the keytab.

Exactly.

> so, I conclude that the proposed 1.6 behavior of using the default
> realm is an impprovement and does not preclude future directions we'd
> like to follow.

I don't see how you arrive at this conclusion, but I also don't think it
matters.  My objection to the 1.6 behaviour is primarily about the
process by which backwards compatibility issues are dealt with by MIT,
particularly since I can think of different solutions the backwards
compatibility of which might be easier to ascertain, were there to be
some sort of public discussion of the matter ahead of the change.

Nico
-- 



More information about the krbdev mailing list