gss-client error

[lizhong]

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