gss-client error

[lizhong]

btw.I made a mistake in the description in the last letter. In fact ,the added test/gcnode026 at test.com and test/gcnode029 at test.com were already created in the kdc database, they were not newly created after running gss-client. But they were automaticly added to the ticket cache of machine B and C.
----- Original Message ----- 
From: "lizhong" <lizhong at ncic.ac.cn>
To: <kerberos at mit.edu>; "Marcus Watts" <mdw at umich.edu>
Sent: Wednesday, August 23, 2006 10:08 PM
Subject: Re: gss-client error 


> Thank you for your help!
> The machine A: gcnode028, the kdc server
> The machine B: gcnode029, where the gss-server is running
> The machine C: gcnode026, where the gss-client is running
> 
> I delete the old principals and keytab files,and create many new principals,such as aa/aa at test.com test/admin at test.com test/test at test.com
> And now I found something very strange, as follows:
> First, I ran gss-server on machine B:
> [root at gcnode029 gss-sample]# ./gss-server test
> And the gss-server started normally.
> Then on the machine C running gss-client, I ran the gss-client like this. First I kinit aa/aa at test.com, and used klist to check it. Then, I started the gss-client and surely failed, and an error message was generated by the gss-server "GSS-API error accepting context: Wrong principal in request". After this, I checked the principals on machine C again, and found that a new service principal called test/gcnode026 at test.com was added!
> [root at gcnode026 gss-sample]# klist
> Ticket cache: FILE:/tmp/krb5cc_0
> Default principal: aa/aa at test.com
> 
> Valid starting     Expires            Service principal
> 08/23/06 21:42:48  08/24/06 07:42:48  krbtgt/test.com at test.com
>        renew until 08/24/06 21:42:55
> 
> 
> Kerberos 4 ticket cache: /tmp/tkt0
> klist: You have no tickets cached
> [root at gcnode026 gss-sample]# ./gss-client gcnode029.cap test "halo"
> host:gcnode029.cap   port:4444
> Sending init_sec_context token (size=467)...continue needed...reading token flags: 0 bytes read
> error
> [root at gcnode026 gss-sample]# klist
> Ticket cache: FILE:/tmp/krb5cc_0
> Default principal: aa/aa at test.com
> 
> Valid starting     Expires            Service principal
> 08/23/06 21:42:48  08/24/06 07:42:48  krbtgt/test.com at test.com
>        renew until 08/24/06 21:42:55
> 08/23/06 21:42:56  08/24/06 07:42:48  test/gcnode026 at test.com
>        renew until 08/24/06 21:42:55
> 
> Kerberos 4 ticket cache: /tmp/tkt0
> klist: You have no tickets cached
> 
> When I tried this with kiniting princical called test/test at test.com on machine B, which was running gss-server, I found a new service princical called test/gcnode029 at test.com was created. I think the error message offered by the gss-server "GSS-API error accepting context: Wrong principal in request" means that the principal called test/gcnode026 at test.com is a wrong principal, and the right one should be test/gcnode029 at test.com, for the gcnode029 is the machine where gss-server is running, not gcnode026.
> But why did this happen? I always think that the sample gss-server/client are not designed to run on the same machine but on two different Linux machines.
> Am I wrong? Or what I did was not proper?Why were the new principals added automaticly?
> Thank you for any help!!
> 
> 
> ----- Original Message ----- 
> From: "Marcus Watts" <mdw at umich.edu>
> To: <kerberos at mit.edu>
> Sent: Wednesday, August 23, 2006 5:41 PM
> Subject: Re: gss-client error 
> 
> 
>> "lizhong" <lizhong at ncic.ac.cn> writes:
>>> SGkgYWxsLA0KICAgIEkgYW0gdXNpbmcgZ3NzLWNsaWVudCB0byBjb25uZWN0IHRvIG15IGdzcy1z
>>> ZXJ2ZXIuSSBoYXZlIDMgbGludXggbWFjaGluZXMgLG1hY2hpbmUgQSBpcyBydW5uaW5nIGtkYyxt
>>> YWNoaW5lIEIgaXMgcnVubmluZyBnc3Mtc2VydmVyLGFuZCBtYWNoaW5lIEMgaXMgcnVubmluZyBn
>>> c3MtY2xpZW50Lg0KICAgIEkgaGF2ZSBjcmVhdGVkIHRlc3QvZ2Nub2RlMDI5QHRlc3QuY29tIGZv
>> ...
>> 
>> which contains this:
>> ...
>>> [root at gcnode029 gss-sample]# klist -k
>>> Keytab name: FILE:/etc/krb5.keytab
>>> KVNO Principal
>>> ---- --------------------------------------------------------------------------
>>>    5 test/gcnode029 at test.com
>> ...
>>> [root at gcnode026 gss-sample]# klist -k
>>> Keytab name: FILE:/etc/krb5.keytab
>>> KVNO Principal
>>> ---- --------------------------------------------------------------------------
>>>    6 test/gcnode029 at test.com
>> ...
>> 
>> Looks to me like you extracted the same principal on 2 machines.  When
>> you extracted the 2nd keytab, you rendered the 1st useless.  From your
>> accompanying description, it sounds like you observed different
>> behavior - but that may be due to doing part of your testing before you
>> extracted the 2nd keytab.  Tickets you got for the principal before you
>> extracted the newer keytab would have worked against a server using the
>> older keytab.  The kvno is also larger than the usual initial default -
>> you must have created other keytabs or otherwise reset the key extra
>> times before you did this round of testing.
>> 
>> In general, if you want to use the same principal on more than one
>> machine, copy it externally, don't extract it again.  Better yet, use a
>> different principal for each machine.  You generally extract a new
>> keytab from the kdc when you intend old keytabs to no longer work.  You
>> can use ktutil to merge the old & new together if you intend to issue
>> new service keys but also want to honor outstanding tickets until they
>> expire.
>> 
>> It is usually better to include fully qualified host names in principal
>> names.  If your environment is large enough, somebody on the other side
>> of campus will want to create a "gcnode029" machine as well.
>> 
>> -Marcus
>> ________________________________________________
>> Kerberos mailing list           Kerberos at mit.edu
>> https://mailman.mit.edu/mailman/listinfo/kerberos
>> 
>>
> 
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
> 
>