btw.I made a mistake in the description in the last letter. In fact ,the added test/[EMAIL PROTECTED] and test/[EMAIL PROTECTED] 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" <[EMAIL PROTECTED]> To: <[email protected]>; "Marcus Watts" <[EMAIL PROTECTED]> 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/[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 > > ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
