GSSAPI / SSPI call for help

[Bruce Wells]

Hello Douglas,
Thanx for responding. There's still something that I'm not quite getting and
that is that from the documentation that I've read there seems to be an
assumption that the credentials will be gathered using kinit. What if you're
operating WITHIN an application that needs to establish the credentials for
several users over the course of it's lifetime.  Should I make a krb5 call
to get the TGT and then drop into GSS to acquire the password or is this
redundant? Somehow I have to get the user's credentials cached on that
machine. What's the best way to go about that programmatically?


On 1/7/05 2:21 PM, in article 41DEEF64.7030805 at anl.gov, ""Douglas E.
Engert"" <deengert at anl.gov> wrote:

> 
> 
> swbell wrote:
> 
>> in article BE03D4FB.1A83%bewskeet at mac.com, Bruce Wells at bewskeet at mac.com
>> wrote on 1/7/05 5:56 AM:
>> 
>> 
>>> Hello To All,
>>> I've been working with Kerberos in a Windows / Linux environment. The KDC is
>>> being run by a W2003 machine. My clients can reside on both Windows and
>>> Linux. These are my questions:
>>> 
>>> 1.) When a client is running on Windows acquiring the credentials are
>>> straight forward. The assumption is that the user that is currently logged
>>> on is the user whose credentials we will be acquiring. My question is this:
>>> What exactly is going on under the hood when you're on a Linux box and
>>> you're logged on as User A running  and you want to run an application as
>>> User B?. 
> 
> Current Kerberos implementation on Unix will use the KRB5CCNAME
> environment variable to find the user's credentials, or assume
> something like /tmp/krb5cc_<uid> as the default.
> 
> login, PAM or sshd will store your credentials or delegated credentials
> and may set KRB5CCNAME for you.
> 
> There is no tight association between the local unix userid you are running
> under and the kerberos principal for which you may have credentials.
> You may have many credentials, in separate cache files.
> 
> So if you are logged on as local user A and using credentials for
> A at realm if you know the Kerberos password for B at realm, you could
> get new credentials for B at realm and have them stored in a different
> cache, then set the KRB5CCNAME to point to it. Then when you run
> the application, the gssapi will use these new credentials.
> 
>>> Let's say that you're required to enter your username / password.
>>> How does one go about getting the credentials for User B so that the program
>>> can carry on a GSSAPI exchange with a GSSAPI service running on Linux?
> 
> On unix I have an alias:
>   k5cc    setenv KRB5CCNAME FILE:/tmp/krb5cc_dee.!:1
> 
> So I can switch back and forth if needed. I wil need to do
> a kinit to get the credentials.
> 
> 
>>> When
>>> you call gss_acquire_cred, I'm assuming that the gsss / kerberos libraries
>>> are going back to the Windows KDC to get the handles to the credentials,
>>> correct?
> 
> Not really gss_acquire_cred get the credentials that are already available
> on the local machine that you would already have in place from login, or a
> kinit.
> it will use the KRB5CNAME.
> 
>>> If all I'm getting back from the Windows KDC is a HANDLE to the
>>> credentials, do I really need to gather the password from the user?
> 
> No kinit would have done this. There was some talk of adding this type
> of function to the gssapi, but that may not be a good idea accept in
> some special situations. If you can use kinit that would be better.
> 
>>> Or when you call gss_acquire_cred, is it assuming that credential
>>> information has already been imported into the local krb5.keytab file?
> 
> krb5.keytab is for the services on the machine not the users.
> If service that uses gssapi would use access a keytab for the keys for the
> service. User's don't normally have keytabs but could. Its almost equivelent
> to storing their password in a file. You don't want to do it.
> 
>>> If
>>> this is the case, are we saying that I must have keytab cred info for every
>>> user that's in setup in Windows Active Directory?
> 
> NO!
> 
>>> Is there way to force the
>>> libraries to go back to the Windows KDC to get the credential information?
> 
> ??
> 
>>> 
>>> For the record, I can kinit any Windows from Linux (provided I know their
>>> password) and get their TGT as verified by klist so I know that the config
>>> file is set up correctly to use Windows 2003 as the KDC.
> 
> Well then you are almost there. If you kinit and use the KRB5CCNAME
> with kinit and an alpplicaiton, then I believe you have what you needed.
> 
>>> 
>>> TIA for any and all help,
>>> Bruce.
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> You should see if you can use gss_krb5_ccache_name.  This can be used to
>> make gssapi stuff work with credentials other than the logged in user (user
>> with creds in the default cache).
>> 
>> Use krb5_cc_resolve, and krb5_get_init_creds_password to set up an alternate
>> credentials cache for your other user.
>> 
>> ________________________________________________
>> Kerberos mailing list           Kerberos at mit.edu
>> https://mailman.mit.edu/mailman/listinfo/kerberos
>> 
>> 
>>