Automatic Prompting for Tickets on Windows

[Jeffrey Altman]

<ldv3cccfafh.fsf at cathode-dark-space.mit.edu> 
<3FC3C16D.4040507 at columbia.edu> <3FC554FA.3010707 at columbia.edu> 
<p06010208bbf16bcd5f72@[18.18.1.23]>
In-Reply-To: <p06010208bbf16bcd5f72@[18.18.1.23]>
Content-Type: text/plain 

Alexandra Ellwood wrote:

>  You can certainly add your own windows-specific code to
>  krb5int_cc_default().  However, if you want to avoid changes to the
>  krb5 library, you could define USE_LOGIN_LIBRARY and then implement
>  the small number of functions in the KLL which are used by krb5.  A
>  KLPrincipal is just a wrapped krb5_principal, and KLDisposeString is
>  just a wrapper around free().  This would constrain all your
>  Windows-specific code to the Windows sources.

The Windows Leash API has an appropriate set of private functions which
I felt were adequate to use from within the private krb5int_cc_default().

>  Note that the call to KLRenewInitialTickets() is just in case you have
>  some operation (usually checking for mail) that's running frequently
>  enough that it notices the tickets expired in the 5 minute window
>  where they appear expired to the client but are really still legal.
>  At the time this function was written, I didn't realize that you
>  couldn't renew expired tickets -- you can probably leave it out in
>  your implementation if you want.

Auto-ticket renewal is handled by the Leash Ticket Manager on an
on-going basis.  However, the call to renew tickets within the five
minute window is worth adding.

: One thing you should note:

>  There is a deficiency in the GSSAPI implementation (RT 1579 "GSS not
>  noticing changes in active principal?") which is exposed when
>  automatic prompting is turned on.  The krb5_context used by GSSAPI has
>  a cached copy of the current ccache name and current ccache
>  principal.  Because the krb5_context is global, the name and principal
>  get cached when the library initializes.  This means that the library
>  always uses whatever the default ccache was as the time the
>  application launched.  Changing the system default ccache (whether by
>  CCAPI v3+ or by the Windows registry stuff -- see get_from_os() in
>  ccdefname.c) has no impact on the ccache the application uses.

One could make a very strong argument that changing the default ccache
after an application launches SHOULD NOT alter the ccache used by an
application.  If an application creates its
own ccache that should not be altered by the user changing the default
ccache in another
application such as the ticket manager.

Of course, for the Logon Library neither the context nor the desired
credential cache name is passed to the
__KLInternalAcquireInitialTicketsForCache.  Therefore, there is no way
for the Logon Library to know the preference of the application other
than by using the current default ccache or examining the environment
variable.

In the Leash calls, a krb5_context can be optionally provided.  If it is
provided, it indicates which ccache should be used for the application.

>  As you might have noticed, Fetch and some other GSSAPI applications on
>  the Mac don't actually have this behavior.  The reason for this is
>  that they can work around the problem by using the private API
>  gss_krb5_ccache_name() to manually reset the ccache name in GSSAPI's
>  krb5_context.  The problem is, gss_krb5_ccache_name() is a private API
>  -- not even part of the GSSAPI C Bindings -- and really should be
>  avoided.

There does need to be a mechanism which allows a GSSAPI application to
specify which ccache it wants to use.  If that is not performed by a
private function, then it must be done via the environment variable:
KRB5_ENV_CCNAME.

>  So after talking to the rest of the team, we agreed that we should fix
>  this problem for 1.3.2 so that Windows doesn't end up with the same
>  private API usage that we have on the Mac.

Unlike on the Mac, Windows does not yet have support for managing
multiple ccache's in the Leash Ticket Manager.  This functionality will
not be added until the KfW 3.0 release.  I am not sure that we have to
push a fix through for the KfW 2.5.1 (Krb5 1.3.2) release.

>  Since we already have automatic popup implemented on the Mac -- making
>  it easy to test -- I will offer to do the work to fix it.  Sam
>  suggested syncing with the system default (ie: calling
>  krb5_cc_set_default_name(context, NULL)) inside krb5int_cc_default(),
>  but I may be forced to do it inside gss_acquire_cred() or
>  kg_get_defcred() because krb5_fwd_tgt_creds() calls
>  krb5int_cc_default(), but shouldn't be picking up the system default
>  ccache -- it would be arguably a bug to connect with one set of creds
>  and end up forwarding another set...

This code already exists within krb5int_cc_default() for USE_LOGON_LIBRARY:

     /* Try to make sure a krb5 tgt is in the cache */
     err = __KLInternalAcquireInitialTicketsForCache (desiredPrincipal, NULL,
                                         krb5_cc_default_name (context),

     if (err == klNoErr) {
             /* This function tries to get tickets and put them in the
     specified
                cache, however, if the cache does not exist, it may
     choose to put
                them elsewhere (ie: the system default) so we set that
     here */
             if (strcmp (krb5_cc_default_name (context), outCacheName) !=
     0) {
                     krb5_cc_set_default_name (context, outCacheName);
             }
             KLDisposeString (outCacheName);
     }

Therefore, if the cache name was altered the synchronization is already
performed.  This is true for 1.3.1.


Jeffrey Altman