One more question WRT gssapi...

[Jeffrey Altman]

The server should be calling gss_accept_context and does not obtain
its own initial ticket.  It uses the key stored in the keytab file
to decrypt the service ticket delivered by the client as part of the
authentication negotiation.

Have you examined the source code to the gss-client and gss-server
sample applications?

Jeffrey Altman


Jiva DeVoe wrote:

> I have a long-running service... (like an ftp server, or a web server 
> or whatever, though it's a program I am writing myself)... and users 
> will access it using a client program (like an ftp client).
> 
> Now I assume the user would kinit prior to running the client  program,
> so I can see how that works.  But in the case of the server,  I am
> confused about how the server process gains it's initial TGT.
> 
> I understand that I can use a keytab file for the server process, but 
> doesn't it still need to call kinit (say in it's startup script)  prior
> to calling gss_acquire_cred() ?
> 
> Is there an API call for that kinit?  In my program, I've been  calling
> the kinit cmd line program prior to running the program.  Do  I need to
> put that into my startup script?  (This is all on Linux BTW).
> 
> On an unrelated note: Is it possible for a server process to have 
> multiple TGT for different principals?  (Why?  For unit tests for my 
> code - simulating the user client process/credentials and the server 
> process/credentials).
> 
> On Jul 26, 2005, at 6:02 PM, Jeffrey Altman wrote:
> 
>> Jiva:
>>
>> Why don't you explain to us what you are attempting to accomplish?
>>
>> Does one of your two endpoints represent an end-user?
>> Or are both of your endpoints services that represent machines?
>>
>> When using GSSAPI Kerberos, the initiator of the authentication must
>> have an initial credential (aka a Ticket Granting Ticket) prior to
>> the call to gss_acquire_cred() or gss_init_context().  If the  initiator
>> represents an end user, the user typically obtains a TGT either a  login
>> or via a kinit call.  The user provides her principal name and a
>> password or smart card or another form of proof of identity and the
>> Kerberos KDC issues an initial TGT to the user.
>>
>> If the initiator does not represent a user or is running as a detached
>> long term background process, the process may be given access to a
>> keytab containing the long term key for the initiators principal.   This
>> keytab is then used with a kinit call to obtain an initial TGT.
>>
>> The TGT is used during the gss_init_context() call to obtain a  Kerberos
>> service ticket for the service you are attempting to authenticate to.
>>
>> Jeffrey Altman
>>
>>
>> Jiva DeVoe wrote:
>>
>>
>>> Aha!
>>>
>>> Is this documented somewhere I can read up on it?  I clearly don't
>>> understand the inner workings of this, and I'd like to.
>>>
>>>
>>> On Jul 26, 2005, at 5:17 PM, Nicolas Williams wrote:
>>>
>>>
>>>> On Tue, Jul 26, 2005 at 05:04:07PM -0400, Jiva DeVoe wrote:
>>>>
>>>>
>>>>> Hmm, my tests do not bare this out...
>>>>>
>>>>> Specifically, I find I MUST issue a kinit -t /etc/krb5.keytab  
>>>>> service/
>>>>> host at foo.com before attempting running my application which then  does
>>>>> a gss_acquire_cred.
>>>>>
>>>>> Is this correct?
>>>>>
>>>>>
>>>>
>>>> For an initiator cred, yes.
>>>>
>>>>
>>>
>>> -- 
>>> Jiva DeVoe
>>> http://www.devoesquared.com
>>> PowerCard - Intuitive Project Management Software for Mac OS X
>>>
>>>
>>> ---------------------------------------------------------------------
>>> ---
>>>
>>> _______________________________________________
>>> krbdev mailing list             krbdev at mit.edu
>>> https://mailman.mit.edu/mailman/listinfo/krbdev
>>
>>
> 
> -- 
> Jiva DeVoe
> http://www.devoesquared.com
> PowerCard - Intuitive Project Management for Mac OS X
> 
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2707 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20050726/e817d34a/attachment.bin