keberos/KL apis
Prabhakaran vaidya
prab at apple.com
Tue Jan 13 18:40:56 EST 2004
On Jan 13, 2004, at 12:56 PM, Alexandra Ellwood wrote:
>> 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.
>
Unfortunately our realms are for Test, dev and prod etc where realms
should not trust each other.
>> 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?
via programatically. (note it is not the kerberos login UI but our
custom UI app modified under the covers to call
KLAcquireInitTickets...() with password)
Within an app if KRB5_CONFIG environment variable is set to say file
/myconfig/A, then to file /myconfig/B the behavior is different between
Jaguar. If the file name is same
but the contents are updated then it does not take effect in Jaguar.
If the app is already running and we add a realm/change a host/port for
that realm
things don't take effect (some static caching going on.).
> 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).
>
Since we install our custom app in all desktops where users might have
there own kerberos realms defined, We do not modify edu.mit.kerberos
file. we add the realms we support
to another separate file and have the KRB5_CONFIG variable point to
that instead.
>> 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).
>
We did not want to switch active users since if two or more apps
simultaneously try to get service tickets for different users each
process then has to
worry about locking etc. So we try to leave the cache as it is. Unless
user decides to switch the active user we do not change them. Now
getting tickets for a user
that is not currently active can depend on many factors though we
supply realm etc. I believe there was some cache syncing that had to be
done to get this all working.
(sync_gssapi_cache_with_cred_cache).
> 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/
> -----------------------------------------------------------------------
> ------
> --
Thanks for the reply...
-prab
More information about the krbdev
mailing list