keberos/KL apis

Alexandra Ellwood lxs at MIT.EDU
Tue Jan 13 15:56:14 EST 2004 

>Hi,
>
>We are experiencing some strange behavior with kerberos/KL apis 
>between Jaguar/Panther.
>Here is the gist of the problem:
>
>-- We need our kerberos enabled apps to run in Jaguar and Panther
>-- We have to support multiple realms (dev/test/maint etc.)
>-- We have to support multiple userids  logged in potentially under 
>all the realms simultaneously
>-- Our apps have to coexist in client machines where kerberos realms 
>not known to us might be configured in edu/mit file
>-- We use KL apis to get  login and get service tickets.
>
>Ideally when our client app runs we would like to restrict the realm 
>visibility to just the current realm the app is configured for.

In general, we recommend that sites have a single Kerberos realm per 
site.  If that is not feasible and all the Kerberos realms at the 
site are v5-only, then we recommend using cross-realm trust between 
the site's realms so that users only need to get a single ticket 
granting ticket to use site services.  Kerberos v4 cross-realm trust 
is a security hole and should not be turned on.

Cross-realm trust works like this: if realms A and B are configured 
to trust each other, then a user with a TGT from realm A will be able 
to get service tickets for realm B and vice versa.  For instance, 
ATHENA.MIT.EDU and ANDREW.CMU.EDU have v5 cross-realm trust enabled. 
As a result, I can do the following using kvno, a tool which gets 
service tickets:

FILIA:~ lxs$ klist
Kerberos 5 ticket cache: 'API:Initial default ccache'
Default Principal: lxs at ATHENA.MIT.EDU
Valid Starting     Expires            Service Principal
01/13/04 15:49:52  01/14/04 12:49:52  krbtgt/ATHENA.MIT.EDU at ATHENA.MIT.EDU
01/13/04 15:49:56  01/14/04 12:49:52  afs/athena.mit.edu at ATHENA.MIT.EDU

Kerberos 4 ticket cache: 'Initial default ccache'
Default Principal: lxs at ATHENA.MIT.EDU
Issued             Expires            Service Principal
01/13/04 14:34:33  01/14/04 12:49:52  krbtgt.ATHENA.MIT.EDU at ATHENA.MIT.EDU

FILIA:~ lxs$ kvno afs at ANDREW.CMU.EDU
afs at ANDREW.CMU.EDU: kvno = 0
FILIA:~ lxs$ klist
Kerberos 5 ticket cache: 'API:Initial default ccache'
Default Principal: lxs at ATHENA.MIT.EDU
Valid Starting     Expires            Service Principal
01/13/04 15:49:52  01/14/04 12:49:52  krbtgt/ATHENA.MIT.EDU at ATHENA.MIT.EDU
01/13/04 15:49:56  01/14/04 12:49:52  afs/athena.mit.edu at ATHENA.MIT.EDU
01/13/04 15:50:02  01/14/04 12:49:52  krbtgt/ANDREW.CMU.EDU at ATHENA.MIT.EDU
01/13/04 15:50:02  01/14/04 12:49:52  afs at ANDREW.CMU.EDU

Kerberos 4 ticket cache: 'Initial default ccache'
Default Principal: lxs at ATHENA.MIT.EDU
Issued             Expires            Service Principal
01/13/04 14:34:33  01/14/04 12:49:52  krbtgt.ATHENA.MIT.EDU at ATHENA.MIT.EDU


As you can see, I was able to get a "afs at ANDREW.CMU.EDU" ticket. 
This allows me to attempt to view files on CMU's AFS (Andrew File 
System) servers.  As you can see, I also had a similar ticket to view 
the "athena.mit.edu" AFS servers from the ATHENA.MIT.EDU realm 
because MIT also uses AFS.

Note: Kerberos is an authentication system, not an authorization 
system.  For instance, it is the job of CMU's AFS servers to 
determine whether they want to allow lxs at ATHENA.MIT.EDU to view or 
modify files.  All the service ticket does is say who I am.  Once you 
turn on cross-realm trust, you may need to revisit your application 
server authorization policies.

>In Panther it does not work unless we put all the realms in one file 
>and change the default realm. (first time a ticket is obtained for 
>the dev realm, second time test realm is tried and it gets unknown 
>realm though the file is changed to reflect the new realm) Also the 
>KRB5_CONFIG variable does not take effect once the app is launched 
>and first time some KL apis are called.
>
>In Jaguar the file seems to have been cached and not take effect 
>unless we change the KRB5_CONFIG env to different file name. In 
>Panther the file name has to be constant once the process is 
>launched and does not take effect if we
>change the KRB5_CONFIG env. Many failures can be seen only when we 
>have the cache populated with various service tickets and TGTs for 
>different users/realms thus making the compatibility between Jaguar 
>and Panther a nightmare. Fix for one OS the other will break !

I don't understand what behavior difference you are referring to.

Are you referring to the appearance of the realm popup menu in the 
Authenticate to Kerberos (Kerberos Login) dialog?

How are you generating that dialog?  Are you generating the dialog as 
a side-effect of a call to krb5/gss, via Kerberos.app or 
programmatically through the KLL?

Note that you should not be messing with the edu.mit.Kerberos file or 
the favorite realms list.  The edu.mit.Kerberos file should always 
contain all the realms the user uses (either directly or via 
cross-realm).  The favorite realms list should contain all the realms 
the user wishes to appear in the realm popup list in the 
"Authenticate to Kerberos" dialog.  The edu.mit.Kerberos file should 
be the same site-wide and the favorite realms list should be 
configured per user (it's a user preference).

>How is default realm definition from edu mit file used ?

The default realm is used whenever you do not specify a realm -- 
either programmatically or via a command line application.  If my 
default realm is "ATHENA.MIT.EDU", "kinit lxs" would get me tickets 
for "lxs at ATHENA.MIT.EDU".  If I call KLCreatePrincipalFromString 
("lxs", kerberosVersion_V5, &principal), then I will get a principal 
for "lxs" in the realm "ATHENA.MIT.EDU".

In addition, the Authenticate to Kerberos (Kerberos Login) dialog 
always fills in the default realm into the realm popup so that there 
is at least one realm in the list.  You can change what realms appear 
in the list with the KLL APIs, however the default realm will always 
appear there.

>I am wondering if there is a reliable way I can programmatically set 
>the realms (not depending on config files) in Jaguar and Panther so 
>that KL, gss, ccache apis all work predictably.

KfM does support getting tickets for multiple realms which do not 
have cross-realm trust.  To use this support, the user needs to get a 
ticket granting ticket for each realm.  The user can either do this 
manually with Kerberos.app, or you can write a program which runs at 
login which calls KLAcquireTickets() for each principal in each realm 
which the user needs to get tickets as.

Once the user has all the ticket granting tickets they need, then the 
user and/or the application must select which tickets to use.  The 
user can select the tickets by changing the "active user" in 
Kerberos.app or with "kswitch".  This "active" set of tickets is the 
"system default" ccache (ie: the ccache returned by 
cc_context_get_default_ccache_name).

When a GSSAPI or krb5 application launches it will start using the 
current "system default" ccache.  The application can then 
programmatically switch to another ccache using 
gss_krb5_ccache_name() (GSSAPI) or krb5_cc_set_default_name() (krb5). 
If you don't want the user to have to switch tickets manually for 
each of your applications, then your applications will need to 
identify which ccache contains the tickets they need.

If you know the full principal the user will use for each realm, then 
you can use KLL to get the ccache name for you.  All KLL APIs which 
manipulate credentials take a KLPrincipal structure.  This structure 
contains a realm field.  So if you know the name and the realm, you 
can build the user's principal with KLCreatePrincipalFromTriplet 
(username, "", realm, &principal) and then find the ccache for it 
with KLCacheHasValidTickets() or KLAcquireTickets().  If you only 
know the realm, then you will need to walk the ccaches looking for 
tickets from the realm you care about and then use the principal of 
the tickets in that realm.

Yes, I realize this is a lot of work for the application programmer. 
We don't expect sites to need to do this because we expect sites to 
have a single Kerberos realm or use cross-realm trust.


Hope this helps,

--lxs
-- 
-----------------------------------------------------------------------------
Alexandra Ellwood                                               <lxs at mit.edu>
MIT Information Systems                               http://mit.edu/lxs/www/
-----------------------------------------------------------------------------
--

More information about the krbdev mailing list