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/[EMAIL PROTECTED] test/[EMAIL PROTECTED] test/[email protected] And now I found something very strange, as follows: First, I ran gss-server on machine B: [EMAIL PROTECTED] 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/[EMAIL PROTECTED], 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/[EMAIL PROTECTED] was added! [EMAIL PROTECTED] gss-sample]# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: aa/[EMAIL PROTECTED] Valid starting Expires Service principal 08/23/06 21:42:48 08/24/06 07:42:48 krbtgt/[EMAIL PROTECTED] renew until 08/24/06 21:42:55 Kerberos 4 ticket cache: /tmp/tkt0 klist: You have no tickets cached [EMAIL PROTECTED] 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 [EMAIL PROTECTED] gss-sample]# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: aa/[EMAIL PROTECTED] Valid starting Expires Service principal 08/23/06 21:42:48 08/24/06 07:42:48 krbtgt/[EMAIL PROTECTED] renew until 08/24/06 21:42:55 08/23/06 21:42:56 08/24/06 07:42:48 test/[EMAIL PROTECTED] 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/[email protected] on machine B, which was running gss-server, I found a new service princical called test/[EMAIL PROTECTED] 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/[EMAIL PROTECTED] is a wrong principal, and the right one should be test/[EMAIL PROTECTED], 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" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Wednesday, August 23, 2006 5:41 PM Subject: Re: gss-client error > "lizhong" <[EMAIL PROTECTED]> writes: >> SGkgYWxsLA0KICAgIEkgYW0gdXNpbmcgZ3NzLWNsaWVudCB0byBjb25uZWN0IHRvIG15IGdzcy1z >> ZXJ2ZXIuSSBoYXZlIDMgbGludXggbWFjaGluZXMgLG1hY2hpbmUgQSBpcyBydW5uaW5nIGtkYyxt >> YWNoaW5lIEIgaXMgcnVubmluZyBnc3Mtc2VydmVyLGFuZCBtYWNoaW5lIEMgaXMgcnVubmluZyBn >> c3MtY2xpZW50Lg0KICAgIEkgaGF2ZSBjcmVhdGVkIHRlc3QvZ2Nub2RlMDI5QHRlc3QuY29tIGZv > ... > > which contains this: > ... >> [EMAIL PROTECTED] gss-sample]# klist -k >> Keytab name: FILE:/etc/krb5.keytab >> KVNO Principal >> ---- >> -------------------------------------------------------------------------- >> 5 test/[EMAIL PROTECTED] > ... >> [EMAIL PROTECTED] gss-sample]# klist -k >> Keytab name: FILE:/etc/krb5.keytab >> KVNO Principal >> ---- >> -------------------------------------------------------------------------- >> 6 test/[EMAIL PROTECTED] > ... > > 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 [email protected] > https://mailman.mit.edu/mailman/listinfo/kerberos > > ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
