stopping login screen from poping up all times

Tue Jul 13 14:39:09 EDT 2004

Hi,

  Is there a way to programatically stop the login screen from popping up every time. I tried setting up the environment variable 
KERBEROSLOGIN_NEVER_PROMPT using putenv and SetEnvironmentVariable functions  in windows , but it doesnot seem to work.

Is there any other way to turn this off.

Thanks,

Shivakeshav Santi

Programmer Analyst/Senior

Cornell Information Technologies
120 Maple Avenue
Cornell University
Tel :6072551916(O)

Ability may get you to the top, but only character
will keep you there .....

---------------------------------
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!!From hartmans at MIT.EDU Tue Jul 13 15:27:57 2004
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.12.8p2/8.12.8) with ESMTP id i6DJRvl1021747
	for <krbdev at PCH.mit.edu>; Tue, 13 Jul 2004 15:27:57 -0400 (EDT)
Received: from cz.mit.edu (STRATTON-TWO-EIGHTY-TWO.MIT.EDU [18.187.6.27])
	i6DJRsM4022066
	for <krbdev at mit.edu>; Tue, 13 Jul 2004 15:27:54 -0400 (EDT)
Received: by cz.mit.edu (Postfix, from userid 8042)
	id 54E39E0051; Tue, 13 Jul 2004 15:28:00 -0400 (EDT)
To: krbdev at MIT.EDU
From: Sam Hartman <hartmans at MIT.EDU>
Date: Tue, 13 Jul 2004 15:28:00 -0400
Message-ID: <tsliscr7lmn.fsf at cz.mit.edu>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: Credential cache searching, ccapi and file caches
X-BeenThere: krbdev at mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: Kerberos Developers Mailing List <krbdev.mit.edu>
List-Help: <mailto:krbdev-request at mit.edu?subject=help>
List-Post: <mailto:krbdev at mit.edu>
List-Subscribe: <https://mailman.mit.edu/mailman/listinfo/krbdev>,
	<mailto:krbdev-request at mit.edu?subject=subscribe>
List-Archive: <http://mailman.mit.edu/pipermail/krbdev>
List-Unsubscribe: <https://mailman.mit.edu/mailman/listinfo/krbdev>,
	<mailto:krbdev-request at mit.edu?subject=unsubscribe>
X-List-Received-Date: Tue, 13 Jul 2004 19:27:58 -0000

Currently, you can only have one client principal active at a time.
If you try to authenticate to a service then the library will try and
get tickets for that client principal and for the requested service
principal  using cross-realm authentication as necessary.  There are a
number of cases where people may have principals in multiple realms
and would like better automatic behavior.  

The desired user experience is that if you attempt to authenticate to
a service and have a principal in the realm of that service for which
you have tickets then that client principal will be used.  If you have
no tickets in the realm of the service and if cross-realm is
unavailable, then you will be asked to obtain tickets in that realm.

There are two issues I'm ignoring in this message.  We're quite well
aware of them and do acknowledge they need to be solved.  The first is
how to manage API changes to allow you to call gss_init_sec_context
and/or krb5_mk_req_ext  without a client principal already specified.
The second is how this all interacts with cross-realm authentication.

What I do want to discuss is how this interacts with CCAPI and
credential caches and how these tickets get stored.  I believe Jeffrey
Altman and Alexis have already discussed these issues, but there
discussion is not archived.  Hopefully I'll come to similar
conclusions; if not they can set me on the right path.

I'd like to start with a brief summary of how CCAPI works now to
confirm my understanding and to bring people not familiar with CCAPI
up to speed.  A CCAPI cache collection is a set of caches that live in
one cache server process.  Caches contain a set of credentials for
both v4 and v5  and associated with the credentials is a principal.
That is, all tickets in a single ccapi cache are expected to  have the
same client principal.  For the most part there is at most one cache
with a particular client principal at any given time.  

There is a system default cache  which is the default cache used by
the ccapi.  I'll pretend for the rest of this message that there's
also a system default principal; think of it as the principal of the
system default cache.

File caches work differently.  I'm only going to think about v5 file
caches.  A v5 file cache contains a principal and a set of
credentials.  There is no requirement that the client principal be the
same for credentials in the cache nor that it be related to the
default principal of the cache.

                             Requirements

KFM--particularly KLL and Kerberos.app would require significant
revision if we change how CCAPI works.  They expect to be able to
enumerate through all the caches , to have one cache per principal,
and for a given cache to enumerate all the credentials in a cache.

The Kerberos library also  would require significant revision if we
change its idea of how caches work.  The krb5 library assumes that
most operations have a single krb5 ccache object that refers to all
the tickets that might be needed by that operation.  

                               Proposal

First,  I think we should mandate that at most one ccapi cache refer
to a given principal at a given time.  A lot of the code sort of
assumes this is true and I think it will make things easier to make
this an invariant.

I think that we should change the interface between the krb5 library
and the ccapi.  The krb5 ccache type corresponding to a ccapi cache
should correspond to a cache collection rather than a single cache.
If you ask this cache for its default principal then it would
give you the system default principal.  If you  enumerate tickets,
then you would get all the tickets in all the ccapi caches.  Note that
I'm not talking about changing ccapi, just how the krb5 library views ccapi.

File based caches already basically map onto ccapi cache collections.
I think that in order to allow Kerberos.app to view file based caches,
you would want a ccache operation that enumerated all the principals
in use in a given cache.  You already have an operation to get all the
credentials with a given client principal.

What do people think?