GSSAPI / SSPI call for help

[Douglas E. Engert]

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
> 
> 
> 

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444