🚀 go-pugleaf

   From: kctreima@eos.ncsu.edu (Kenneth C. Treimann)
   Reply-To: kctreima@eos.ncsu.edu (Kenneth C. Treimann)

   Is there a way to verify a userid and password without getting a
   new ticket-granting-ticket?

By definition, no.  "Verifying a userid and a password" under Kerberos
is defined as asking the Kerberos server for a tgt and having it
successfully decrypted by the kinit/login program, using the password
provided by the user.  The Kerberos server neither knows nor cares
whether the request is valid.

   All I want to do is pass a name to a function, make sure that
   Kerberos knows the principal, prompt for the password, verify it,
   and return a yes or no type answer (or k_errno).  I do NOT want to
   use krb_get_pw_in_tkt, because it replaces the existing tickets,

Well, that is a different question.  :-)  What you want to do is get a
tgt and not store it in the ticket file (aka credential cache).

krb_get_pw_in_tkt (in lib/krb/get_in_tkt.c) is mostly a wrapper for
the real workhorse function, krb_get_in_tkt (in krb_get_in_tkt.c).
The body of that function actually acquires the ticket, decrypts it,
checks it out, et cetera, and at the VERY END contains the following
code:

    /* initialize ticket cache */ 
    if (in_tkt(user,instance) != KSUCCESS)
	return(INTK_ERR);

    /* stash ticket, session key, etc. for future use */ 
    if (kerror = save_credentials(s_name, s_instance, rlm, ses,
				  lifetime, kvno, tkt,
				  t_local.tv_sec))
	return(kerror);

    return(INTK_OK);
}

It would appear that if you really want to get a ticket WITHOUT
stashing it in the cache, you could just copy all the code from
krb_get_in_tkt into a new function (say, krb_get_in_tkt_nosave) that
does *not* call in_tkt or save_credentials, and call the new function
instead.

DISCLAIMER: I haven't tried this, I just glanced at the source code.

This, of course, is a DIGUSTING KLUDGE but appears to be all you can
do within Kerberos V4.  The API for Kerberos V5 (which will be in beta
test soon, see previous message on this list) is considerably more
versatile and (presumably) does not have this problem.

I hope this helps.

Barr3y Jaspan, bjaspan@mit.edu
MIT Student Information Processing Board
Watchmaker Computing (bjaspan@watch.com)