Re: gss-client error - Kerberos

This is a discussion on Re: gss-client error - Kerberos ; "lizhong" writes: > SGkgYWxsLA0KICAgIEkgYW0gdXNpbmcgZ3NzLWNsaWVudCB0by Bjb25uZWN0IHRvIG15IGdzcy1z > ZXJ2ZXIuSSBoYXZlIDMgbGludXggbWFjaGluZXMgLG1hY2hpbm UgQSBpcyBydW5uaW5nIGtkYyxt > YWNoaW5lIEIgaXMgcnVubmluZyBnc3Mtc2VydmVyLGFuZCBtYW NoaW5lIEMgaXMgcnVubmluZyBn > c3MtY2xpZW50Lg0KICAgIEkgaGF2ZSBjcmVhdGVkIHRlc3QvZ2 Nub2RlMDI5QHRlc3QuY29tIGZv .... which contains this: .... > [root@gcnode029 gss-sample]# klist -k > Keytab name: FILE:/etc/krb5.keytab > KVNO Principal > ---- -------------------------------------------------------------------------- > 5 test/gcnode029@test.com .... > [root@gcnode026 ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Re: gss-client error

  1. Re: gss-client error

    "lizhong" writes:
    > SGkgYWxsLA0KICAgIEkgYW0gdXNpbmcgZ3NzLWNsaWVudCB0by Bjb25uZWN0IHRvIG15IGdzcy1z
    > ZXJ2ZXIuSSBoYXZlIDMgbGludXggbWFjaGluZXMgLG1hY2hpbm UgQSBpcyBydW5uaW5nIGtkYyxt
    > YWNoaW5lIEIgaXMgcnVubmluZyBnc3Mtc2VydmVyLGFuZCBtYW NoaW5lIEMgaXMgcnVubmluZyBn
    > c3MtY2xpZW50Lg0KICAgIEkgaGF2ZSBjcmVhdGVkIHRlc3QvZ2 Nub2RlMDI5QHRlc3QuY29tIGZv

    ....

    which contains this:
    ....
    > [root@gcnode029 gss-sample]# klist -k
    > Keytab name: FILE:/etc/krb5.keytab
    > KVNO Principal
    > ---- --------------------------------------------------------------------------
    > 5 test/gcnode029@test.com

    ....
    > [root@gcnode026 gss-sample]# klist -k
    > Keytab name: FILE:/etc/krb5.keytab
    > KVNO Principal
    > ---- --------------------------------------------------------------------------
    > 6 test/gcnode029@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@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  2. 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@test.com test/admin@test.com test/test@test.com
    And now I found something very strange, as follows:
    First, I ran gss-server on machine B:
    [root@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@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@test.com was added!
    [root@gcnode026 gss-sample]# klist
    Ticket cache: FILE:/tmp/krb5cc_0
    Default principal: aa/aa@test.com

    Valid starting Expires Service principal
    08/23/06 21:42:48 08/24/06 07:42:48 krbtgt/test.com@test.com
    renew until 08/24/06 21:42:55


    Kerberos 4 ticket cache: /tmp/tkt0
    klist: You have no tickets cached
    [root@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@gcnode026 gss-sample]# klist
    Ticket cache: FILE:/tmp/krb5cc_0
    Default principal: aa/aa@test.com

    Valid starting Expires Service principal
    08/23/06 21:42:48 08/24/06 07:42:48 krbtgt/test.com@test.com
    renew until 08/24/06 21:42:55
    08/23/06 21:42:56 08/24/06 07:42:48 test/gcnode026@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@test.com on machine B, which was running gss-server, I found a new service princical called test/gcnode029@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@test.com is a wrong principal, and the right one should be test/gcnode029@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"
    To:
    Sent: Wednesday, August 23, 2006 5:41 PM
    Subject: Re: gss-client error


    > "lizhong" writes:
    >> SGkgYWxsLA0KICAgIEkgYW0gdXNpbmcgZ3NzLWNsaWVudCB0by Bjb25uZWN0IHRvIG15IGdzcy1z
    >> ZXJ2ZXIuSSBoYXZlIDMgbGludXggbWFjaGluZXMgLG1hY2hpbm UgQSBpcyBydW5uaW5nIGtkYyxt
    >> YWNoaW5lIEIgaXMgcnVubmluZyBnc3Mtc2VydmVyLGFuZCBtYW NoaW5lIEMgaXMgcnVubmluZyBn
    >> c3MtY2xpZW50Lg0KICAgIEkgaGF2ZSBjcmVhdGVkIHRlc3QvZ2 Nub2RlMDI5QHRlc3QuY29tIGZv

    > ...
    >
    > which contains this:
    > ...
    >> [root@gcnode029 gss-sample]# klist -k
    >> Keytab name: FILE:/etc/krb5.keytab
    >> KVNO Principal
    >> ---- --------------------------------------------------------------------------
    >> 5 test/gcnode029@test.com

    > ...
    >> [root@gcnode026 gss-sample]# klist -k
    >> Keytab name: FILE:/etc/krb5.keytab
    >> KVNO Principal
    >> ---- --------------------------------------------------------------------------
    >> 6 test/gcnode029@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@mit.edu
    > https://mailman.mit.edu/mailman/listinfo/kerberos
    >
    >


    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  3. Re: gss-client error

    btw.I made a mistake in the description in the last letter. In fact ,the added test/gcnode026@test.com and test/gcnode029@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"
    To: ; "Marcus Watts"
    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@test.com test/admin@test.com test/test@test.com
    > And now I found something very strange, as follows:
    > First, I ran gss-server on machine B:
    > [root@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@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@test.com was added!
    > [root@gcnode026 gss-sample]# klist
    > Ticket cache: FILE:/tmp/krb5cc_0
    > Default principal: aa/aa@test.com
    >
    > Valid starting Expires Service principal
    > 08/23/06 21:42:48 08/24/06 07:42:48 krbtgt/test.com@test.com
    > renew until 08/24/06 21:42:55
    >
    >
    > Kerberos 4 ticket cache: /tmp/tkt0
    > klist: You have no tickets cached
    > [root@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@gcnode026 gss-sample]# klist
    > Ticket cache: FILE:/tmp/krb5cc_0
    > Default principal: aa/aa@test.com
    >
    > Valid starting Expires Service principal
    > 08/23/06 21:42:48 08/24/06 07:42:48 krbtgt/test.com@test.com
    > renew until 08/24/06 21:42:55
    > 08/23/06 21:42:56 08/24/06 07:42:48 test/gcnode026@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@test.com on machine B, which was running gss-server, I found a new service princical called test/gcnode029@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@test.com is a wrong principal, and the right one should be test/gcnode029@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"
    > To:
    > Sent: Wednesday, August 23, 2006 5:41 PM
    > Subject: Re: gss-client error
    >
    >
    >> "lizhong" writes:
    >>> SGkgYWxsLA0KICAgIEkgYW0gdXNpbmcgZ3NzLWNsaWVudCB0by Bjb25uZWN0IHRvIG15IGdzcy1z
    >>> ZXJ2ZXIuSSBoYXZlIDMgbGludXggbWFjaGluZXMgLG1hY2hpbm UgQSBpcyBydW5uaW5nIGtkYyxt
    >>> YWNoaW5lIEIgaXMgcnVubmluZyBnc3Mtc2VydmVyLGFuZCBtYW NoaW5lIEMgaXMgcnVubmluZyBn
    >>> c3MtY2xpZW50Lg0KICAgIEkgaGF2ZSBjcmVhdGVkIHRlc3QvZ2 Nub2RlMDI5QHRlc3QuY29tIGZv

    >> ...
    >>
    >> which contains this:
    >> ...
    >>> [root@gcnode029 gss-sample]# klist -k
    >>> Keytab name: FILE:/etc/krb5.keytab
    >>> KVNO Principal
    >>> ---- --------------------------------------------------------------------------
    >>> 5 test/gcnode029@test.com

    >> ...
    >>> [root@gcnode026 gss-sample]# klist -k
    >>> Keytab name: FILE:/etc/krb5.keytab
    >>> KVNO Principal
    >>> ---- --------------------------------------------------------------------------
    >>> 6 test/gcnode029@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@mit.edu
    >> https://mailman.mit.edu/mailman/listinfo/kerberos
    >>
    >>

    >
    > ________________________________________________
    > Kerberos mailing list Kerberos@mit.edu
    > https://mailman.mit.edu/mailman/listinfo/kerberos
    >
    >


    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


+ Reply to Thread