Decrypt integrity check failed - Kerberos

This is a discussion on Decrypt integrity check failed - Kerberos ; I have a slave kdc and am trying to get the master to kprop the db to the slave. I continually get this error: kprop: Decrypt integrity check failed while getting initial ticket >From what I have read it is ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Decrypt integrity check failed

  1. Decrypt integrity check failed

    I have a slave kdc and am trying to get the master to kprop the db to the slave.
    I continually get this error:
    kprop: Decrypt integrity check failed while getting initial ticket


    >From what I have read it is a wrong password for one of the hosts in the

    database. I have removed from the DB both of the hosts and readded them back in
    using kadmin, then ktadd to extract the host keytab, but I recieve the same
    error.

    I have become horribly confused at this point, how do I add the hosts and get
    the correct password? Do I need to run kdb5_util create -s on the slave, I
    don't think I should have to but I am grasoing for straws at this point. Are
    all that is needed for the slave is a kdc.conf and a krb5.conf file?

    Thanks for any help,

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


  2. Re: Decrypt integrity check failed

    >>>>> "jonr" == jonr writes:

    jonr> I have a slave kdc and am trying to get the master to kprop the
    jonr> db to the slave. I continually get this error: kprop: Decrypt
    jonr> integrity check failed while getting initial ticket


    >> From what I have read it is a wrong password for one of the hosts
    >> in the

    jonr> database.

    No; the problem here is probably the key of the master kdc's host
    principal, on the slave. The slave uses it to authenticate the peer and
    compare to kpropd.conf, which lists the hosts allowed to update the
    slave's copy of the KDB.

    --
    Richard Silverman
    res@qoxp.net


  3. Re: Decrypt integrity check failed

    Quoting "Richard E. Silverman" :

    > >>>>> "jonr" == jonr writes:

    >
    > jonr> I have a slave kdc and am trying to get the master to kprop the
    > jonr> db to the slave. I continually get this error: kprop: Decrypt
    > jonr> integrity check failed while getting initial ticket
    >
    >
    > >> From what I have read it is a wrong password for one of the hosts
    > >> in the

    > jonr> database.
    >
    > No; the problem here is probably the key of the master kdc's host
    > principal, on the slave. The slave uses it to authenticate the peer and
    > compare to kpropd.conf, which lists the hosts allowed to update the
    > slave's copy of the KDB.


    Thanks for the help Richard, I have been slowly slipping into madness trying to
    grasp kerberos. The file that the slave looks in to validate is the
    kadm5.keytab file, is that correct? I have tried scp'ing this file to my slave
    thinking that would have the correct permissions, this did not work, same
    error.

    How do I fix this error? If you just have a document or a link that would
    explain how to recover from such an error, I will do all the reading to figure
    it out for myself. But I have not found anything that tells me how to fix this
    error in a way that I understand.

    Thanks again for the help,

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


  4. Re: Decrypt integrity check failed

    >>>>> "jonr" == jonr writes:

    jonr> Quoting "Richard E. Silverman" :
    >> >>>>> "jonr" == jonr writes:

    >>

    jonr> I have a slave kdc and am trying to get the master to kprop the
    jonr> db to the slave. I continually get this error: kprop: Decrypt
    jonr> integrity check failed while getting initial ticket
    >>
    >>
    >> >> From what I have read it is a wrong password for one of the

    >> hosts >> in the

    jonr> database.
    >> No; the problem here is probably the key of the master kdc's host
    >> principal, on the slave. The slave uses it to authenticate the
    >> peer and compare to kpropd.conf, which lists the hosts allowed to
    >> update the slave's copy of the KDB.


    jonr> Thanks for the help Richard, I have been slowly slipping into
    jonr> madness trying to grasp kerberos. The file that the slave looks
    jonr> in to validate is the kadm5.keytab file, is that correct?

    No; at least, in my setup, kpropd looks in the system keytab
    /etc/krb5.keytab (or similar). kadm5.keytab is for kadmin(d), a different
    set of programs.

    jonr> I have tried scp'ing this file to my slave thinking that would have the
    jonr> correct permissions, this did not work, same error.

    jonr> How do I fix this error?

    Actually, I misspoke above. I should have said: the problem is likely
    that the master kdc's host principal key stored in the KDB does not match
    the one in the its system keytab. kprop does a kinit with the host
    principal, and then uses that to obtain a ticket for the slave host, in
    order to authenticate itself to kpropd on the slave. The error means that it
    could not decrypt the KDC's response with its key, indicating a mismatch.
    Check the key version number:

    # klist -k /etc/krb5.keytab
    Keytab name: FILE:/etc/krb5.keytab
    KVNO Principal
    ---- --------------------------------------------------------------------------
    14 host/foo.bar.com@BAR.COM

    $ kvno host/foo.bar.com@BAR.COM
    host/foo.bar.com@BAR.COM: kvno = 14

    Make sure they match. If they don't, re-extact the key:

    # kadmin
    Password for you/admin@BAR.COM:
    kadmin: ktadd -k /etc/krb5.keytab host/foo.bar.com@BAR.COM

    --
    Richard Silverman
    res@qoxp.net


  5. Re: Decrypt integrity check failed

    "Richard E. Silverman" writes:
    ....
    > Check the key version number:
    >
    > # klist -k /etc/krb5.keytab
    > Keytab name: FILE:/etc/krb5.keytab
    > KVNO Principal
    > ---- --------------------------------------------------------------------------
    > 14 host/foo.bar.com@BAR.COM
    >
    > $ kvno host/foo.bar.com@BAR.COM
    > host/foo.bar.com@BAR.COM: kvno = 14
    >
    > Make sure they match. If they don't, re-extact the key:
    >
    > # kadmin
    > Password for you/admin@BAR.COM:
    > kadmin: ktadd -k /etc/krb5.keytab host/foo.bar.com@BAR.COM


    Couple of things.

    There is another way to check out whether a keytab works: kinit.
    This is good because it's not impossible to get a keytab that *appears*
    to have the same kvno but doesn't work. (for instance, delete the
    principal, then recreate it.)

    For instance:

    spam# klist -ekt /etc/krb5.keytab
    Keytab name: FILE:/etc/krb5.keytab
    KVNO Timestamp Principal
    ---- ----------------- --------------------------------------------------------
    3 08/19/04 03:56:25 imap/spam.ifs.umich.edu@UMICH.EDU (Triple DES cbc mode with HMAC/sha1)
    3 08/19/04 03:56:25 imap/spam.ifs.umich.edu@UMICH.EDU (DES cbc mode with CRC-32)
    3 03/22/06 04:01:29 pop/spam.ifs.umich.edu@UMICH.EDU (Triple DES cbc mode with HMAC/sha1)
    3 03/22/06 04:01:29 pop/spam.ifs.umich.edu@UMICH.EDU (DES cbc mode with CRC-32)
    spam#
    tells me I have 2 principals, each with 2 encryption types,
    (and when those keytab entries were written, if you care.)
    spam# kinit -k -t /etc/krb5.keytab imap/spam.ifs.umich.edu
    spam# klist -5fea
    Ticket cache: FILE:/tmp/krb5cc_25131_eVt6pe
    Default principal: imap/spam.ifs.umich.edu@UMICH.EDU

    Valid starting Expires Service principal
    07/11/06 00:45:16 07/12/06 00:45:16 krbtgt/UMICH.EDU@UMICH.EDU
    Flags: FPI, Etype (skey, tkt): Triple DES cbc mode with HMAC/sha1, Triple DES cbc mode with HMAC/sha1
    Addresses: (none)
    spam#
    tells me that I have a keytab entry that actually works for
    imap/spam.ifs.umich.edu@UMICH.EDU, also it looks likely that I
    used 3des to get that key (plus some other information of no particular
    consequence here.)

    Another clue that's sometimes useful is log file entries, in this case,
    in krb5kdc's log:
    Jul 11 00:45:16 AS_REQ (7 etypes {18 17 16 23 1 3 2}) 141.211.1.36: ISSUE: authtime 1152593116, etypes {rep=16 tkt=16 ses=16}, imap/spam.ifs.umich.edu@UMICH.EDU for krbtgt/UMICH.EDU@UMICH.EDU
    For instance, that can tell you which principal you were actually trying to authenticate
    as.

    Secondly, in this case, since it appears that "jonr" is trying to
    set up replication, it's important to be very careful about configuration
    files. Specifically, you probably don't want krb5.conf entries (or DNS
    entries) that point to slaves until you have replication working to those slaves.
    If you're somehow trying to get a ticket from a slave that has an old
    copy of the database, there's definitely opportunity for confusion.

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


+ Reply to Thread