An alternative plan for principal mapping

Henry B. Hotz hotz at
Thu Aug 3 14:27:07 EDT 2006

On Aug 2, 2006, at 7:35 PM, Sam Hartman wrote:

>>>>>> "Will" == Will Fiveash <William.Fiveash at> writes:
>     Will> On Tue, Aug 01, 2006 at 10:46:33AM -0700, Henry B. Hotz
>     Will> wrote:
>>> On Aug 1, 2006, at 9:03 AM, krbdev-request at wrote:
>>> ...
>>>> This relates to something I brought up before on this list
>>> and that is > support for login policy plugins (LPP).  Note,
>>> this is distinct from > password policy.  The KDC would
>>> interact with a LPP in two ways:
>>> In effect this is an authorization policy, not an
>>> authentication policy.
>     Will> Essentially that is correct.
> It's important that we don't create a situation where services expect
> the KDC to perform authorization checks and fail insecurely if that  
> does not happen.
> PAC like behavior is fine because a service can tell if the PAC is not
> present.  However something where a service expects a KDC only to
> grant tickets to authorized users would be a really bad idea, because
> it would mean the service is only secure with certain KDCs.
> --Sam

That's a very correct technical position to take.  That's why I  
called attention to the issue.

OTOH (at the risk of starting another long thread with Greg W. like I  
did once before) the only thing people really care about is  
authorization.  I already have problems with people believing that  
having a Kerberos ticket is sufficient to access things.  A standard  
way to solve the authorization problem without requiring another  
independent implementation/integration effort would be very nice.

The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at, or hbhotz at

More information about the krbdev mailing list