Decrypt integrity check failed

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Decrypt integrity check failed

Jon R.
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           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Decrypt integrity check failed

Richard Silverman
>>>>> "jonr" == jonr  <[hidden email]> 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
  [hidden email]

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Decrypt integrity check failed

Jon R.
Quoting "Richard E. Silverman" <[hidden email]>:

> >>>>> "jonr" == jonr  <[hidden email]> 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           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Decrypt integrity check failed

Richard Silverman
>>>>> "jonr" == jonr  <[hidden email]> writes:

    jonr> Quoting "Richard E. Silverman" <[hidden email]>:
    >> >>>>> "jonr" == jonr <[hidden email]> 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/[hidden email]

$ kvno host/[hidden email]
host/[hidden email]: kvno = 14

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

# kadmin
Password for you/[hidden email]:
kadmin: ktadd -k /etc/krb5.keytab host/[hidden email]

--
  Richard Silverman
  [hidden email]

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Decrypt integrity check failed

Marcus Watts
"Richard E. Silverman" <[hidden email]> writes:
...

> Check the key version number:
>
> # klist -k /etc/krb5.keytab
> Keytab name: FILE:/etc/krb5.keytab
> KVNO Principal
> ---- --------------------------------------------------------------------------
>   14 host/[hidden email]
>
> $ kvno host/[hidden email]
> host/[hidden email]: kvno = 14
>
> Make sure they match.  If they don't, re-extact the key:
>
> # kadmin
> Password for you/[hidden email]:
> kadmin: ktadd -k /etc/krb5.keytab host/[hidden email]

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/[hidden email] (Triple DES cbc mode with HMAC/sha1)
           3 08/19/04 03:56:25 imap/[hidden email] (DES cbc mode with CRC-32)
           3 03/22/06 04:01:29 pop/[hidden email] (Triple DES cbc mode with HMAC/sha1)
           3 03/22/06 04:01:29 pop/[hidden email] (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/[hidden email]

        Valid starting     Expires            Service principal
        07/11/06 00:45:16  07/12/06 00:45:16  krbtgt/[hidden email]
                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/[hidden email], 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/[hidden email] for krbtgt/[hidden email]
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           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos