cross realm : decrypt integrity check failed - Kerberos

This is a discussion on cross realm : decrypt integrity check failed - Kerberos ; So, I'm trying to set up one way cross realm auth. We have two realms... realmA and realmB On both KDCs, we have created the principal krbtgt/realmB@realmA with the same kvno and the same password. I can even kinit krbtgt/realmB@realmA ...

+ Reply to Thread
Results 1 to 13 of 13

Thread: cross realm : decrypt integrity check failed

  1. cross realm : decrypt integrity check failed

    So, I'm trying to set up one way cross realm auth.

    We have two realms... realmA and realmB

    On both KDCs, we have created the principal krbtgt/realmB@realmA with the same
    kvno and the same password.

    I can even kinit krbtgt/realmB@realmA (which talks to the realmA server) and
    get a ticket as that principal.

    So, here's where things go wacky...

    I kinit user@realmA - fine

    I then try to do something (ssh for example) that requires a ticket in realm B.

    Failure with the following error: Decrypt Integrity Check Failed - this error
    also shows up in the realmB kdc log.

    a klist shows:
    krbtgt/realmA@realmA
    krbtgt/realmB@realmB

    but, of course, no service ticket.

    Any thoughts on what to try/look at? As best I can tell, this should just work,
    but clearly it isn't.

    I haven't figured out if there is a way to kinit krbtgt/realmB@realmA to
    realmB's servers to verify it isn't somehow mangling the password -- is there a
    way to do this?

    realmB is rhel4u4 - krb5-server-1.3.4-33

    I don't know what realmA is as I don't control that KDC.

    Thanks!

    --
    ********************************
    David William Botsch
    Programmer/Analyst
    CNF Computing
    botsch@cnf.cornell.edu
    ********************************
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  2. Re: cross realm : decrypt integrity check failed

    >On both KDCs, we have created the principal krbtgt/realmB@realmA with the same
    >kvno and the same password.


    I know that you said you did that .... buuuuttt ...

    >Failure with the following error: Decrypt Integrity Check Failed - this error
    >also shows up in the realmB kdc log.


    This error is a classic "keys don't match between the two KDCs" problem.

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


  3. Re: cross realm : decrypt integrity check failed

    On Wed, Nov 08, 2006 at 02:07:00PM -0500, Ken Hornstein wrote:
    >
    > This error is a classic "keys don't match between the two KDCs" problem.
    >
    > --Ken


    and yet, I don't know how many ways I can paste/type in the same password again
    and again and again.

    Could it be something w.r.t. unicode/character encoding?

    --
    ********************************
    David William Botsch
    Programmer/Analyst
    CNF Computing
    botsch@cnf.cornell.edu
    ********************************
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  4. Re: cross realm : decrypt integrity check failed

    >> This error is a classic "keys don't match between the two KDCs" problem.
    >>
    >> --Ken

    >
    >and yet, I don't know how many ways I can paste/type in the same password again
    >and again and again.
    >
    >Could it be something w.r.t. unicode/character encoding?


    Well ... I dunno. I think you said you're using Heimdal, right? I
    would think that it would work; are you running the same version of
    Kerberos on each KDC? Dumb question time; did you run kinit after
    changing your password to clear out your cached tickets?

    You could try a really simple password, like "a" that isn't easy to
    fat-finger.

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


  5. Re: cross realm : decrypt integrity check failed

    MIT on both sides.

    So, I know I've got the right password... I can manually kinit
    krbtgt/realmB@realmA using the supplied cross-realm password -- that works

    So, I can take that same password, copy it to the clipboard so that I know I
    don't fat-finger it, paste it in to the cross realm principal on realmB... and
    I get that error.

    I'm wondering if it's like I said a unicode weirdness (which doesn't make
    sense) or if it's somehow using the wrong enctype (even though the enctypes
    supposedly match).

    and yes... kdestroy/kinit

    On Wed, Nov 08, 2006 at 02:39:34PM -0500, Ken Hornstein wrote:
    > >> This error is a classic "keys don't match between the two KDCs" problem.
    > >>
    > >> --Ken

    > >
    > >and yet, I don't know how many ways I can paste/type in the same password again
    > >and again and again.
    > >
    > >Could it be something w.r.t. unicode/character encoding?

    >
    > Well ... I dunno. I think you said you're using Heimdal, right? I
    > would think that it would work; are you running the same version of
    > Kerberos on each KDC? Dumb question time; did you run kinit after
    > changing your password to clear out your cached tickets?
    >
    > You could try a really simple password, like "a" that isn't easy to
    > fat-finger.
    >
    > --Ken


    --
    ********************************
    David William Botsch
    Programmer/Analyst
    CNF Computing
    botsch@cnf.cornell.edu
    ********************************
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  6. Re: cross realm : decrypt integrity check failed

    >So, I know I've got the right password... I can manually kinit
    >krbtgt/realmB@realmA using the supplied cross-realm password -- that works


    Okay ... but unless you did some magic, you weren't sending that request
    to realm B, you only sent that to realm A.

    >So, I can take that same password, copy it to the clipboard so that I know I
    >don't fat-finger it, paste it in to the cross realm principal on realmB... and
    >I get that error.
    >
    >I'm wondering if it's like I said a unicode weirdness (which doesn't make
    >sense) or if it's somehow using the wrong enctype (even though the enctypes
    >supposedly match).


    Okay, one other thing comes to mind. Is it possible that the default
    key _salts_ are different between the two realms? Do a getprinc on both
    principals in both realms, and make sure the key salts (listed in the enctypes
    after every key) are the same. The keys should also be in the same order
    (although I don't remember if mis-ordering results in this error). When
    I create cross-realm keys, I specify the enctype:salt pairs manually so
    they will match and have the correct ordering.

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


  7. Re: cross realm : decrypt integrity check failed

    On Wed, Nov 08, 2006 at 02:54:38PM -0500, Ken Hornstein wrote:
    > >So, I know I've got the right password... I can manually kinit
    > >krbtgt/realmB@realmA using the supplied cross-realm password -- that works

    >
    > Okay ... but unless you did some magic, you weren't sending that request
    > to realm B, you only sent that to realm A.


    Right. I've been trying to figure out if there's a way to do this kinit to
    realmB with some sort of magic, but no luck so far. It would certainly be a
    useful test.

    >
    >
    > Okay, one other thing comes to mind. Is it possible that the default
    > key _salts_ are different between the two realms? Do a getprinc on both
    > principals in both realms, and make sure the key salts (listed in the enctypes
    > after every key) are the same. The keys should also be in the same order
    > (although I don't remember if mis-ordering results in this error). When
    > I create cross-realm keys, I specify the enctype:salt pairs manually so
    > they will match and have the correct ordering.
    >


    I believe they match... well, one of them does at any rate. If I understand
    things, on realmA, it's set up with just one enc/salt type where I've got three
    on this end. One of those three is the one. I've tried recreating the principal
    with just the one and no luck.


    > --Ken


    --
    ********************************
    David William Botsch
    Programmer/Analyst
    CNF Computing
    botsch@cnf.cornell.edu
    ********************************
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  8. Re: cross realm : decrypt integrity check failed



    Dave Botsch wrote:
    > So, I'm trying to set up one way cross realm auth.
    >
    > We have two realms... realmA and realmB
    >
    > On both KDCs, we have created the principal krbtgt/realmB@realmA with the same
    > kvno and the same password.


    And same e-types?

    >
    > I can even kinit krbtgt/realmB@realmA (which talks to the realmA server) and
    > get a ticket as that principal.
    >
    > So, here's where things go wacky...
    >
    > I kinit user@realmA - fine
    >
    > I then try to do something (ssh for example) that requires a ticket in realm B.
    >
    > Failure with the following error: Decrypt Integrity Check Failed - this error
    > also shows up in the realmB kdc log.
    >
    > a klist shows:
    > krbtgt/realmA@realmA
    > krbtgt/realmB@realmB


    Is the above correct? The second one should be krbtgt/realmB@realmA
    i.e. ticket issued by A but usable at realm B.

    >
    > but, of course, no service ticket.
    >
    > Any thoughts on what to try/look at? As best I can tell, this should just work,
    > but clearly it isn't.
    >
    > I haven't figured out if there is a way to kinit krbtgt/realmB@realmA to
    > realmB's servers to verify it isn't somehow mangling the password -- is there a
    > way to do this?
    >
    > realmB is rhel4u4 - krb5-server-1.3.4-33
    >
    > I don't know what realmA is as I don't control that KDC.


    Then how do you know the key was added correctly? Is realm A Windows AD?

    As Ken said, sounds like keys don't match.


    >
    > Thanks!
    >


    --

    Douglas E. Engert
    Argonne National Laboratory
    9700 South Cass Avenue
    Argonne, Illinois 60439
    (630) 252-5444
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  9. Re: cross realm : decrypt integrity check failed

    Well.. we seem to have got it working.

    What did we do different? Two things...

    1. changed the order of the supported enctypes in kdc.conf so that the one being used in both places is listed first.
    2. recreated the principal with -e to specify only the enctype being used in both places (doing 2 by itself before had not fixed the issue).

    >From my understand of Kerberos, this should not matter... interesting.


    On Wed, Nov 08, 2006 at 03:00:38PM -0500, Dave Botsch wrote:
    > On Wed, Nov 08, 2006 at 02:54:38PM -0500, Ken Hornstein wrote:
    > > >So, I know I've got the right password... I can manually kinit
    > > >krbtgt/realmB@realmA using the supplied cross-realm password -- that works

    > >
    > > Okay ... but unless you did some magic, you weren't sending that request
    > > to realm B, you only sent that to realm A.

    >
    > Right. I've been trying to figure out if there's a way to do this kinit to
    > realmB with some sort of magic, but no luck so far. It would certainly be a
    > useful test.
    >
    > >
    > >
    > > Okay, one other thing comes to mind. Is it possible that the default
    > > key _salts_ are different between the two realms? Do a getprinc on both
    > > principals in both realms, and make sure the key salts (listed in the enctypes
    > > after every key) are the same. The keys should also be in the same order
    > > (although I don't remember if mis-ordering results in this error). When
    > > I create cross-realm keys, I specify the enctype:salt pairs manually so
    > > they will match and have the correct ordering.
    > >

    >
    > I believe they match... well, one of them does at any rate. If I understand
    > things, on realmA, it's set up with just one enc/salt type where I've got three
    > on this end. One of those three is the one. I've tried recreating the principal
    > with just the one and no luck.
    >
    >
    > > --Ken

    >
    > --
    > ********************************
    > David William Botsch
    > Programmer/Analyst
    > CNF Computing
    > botsch@cnf.cornell.edu
    > ********************************
    > ________________________________________________
    > Kerberos mailing list Kerberos@mit.edu
    > https://mailman.mit.edu/mailman/listinfo/kerberos


    --
    ********************************
    David William Botsch
    Programmer/Analyst
    CNF Computing
    botsch@cnf.cornell.edu
    ********************************
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  10. Re: cross realm : decrypt integrity check failed

    The normal salt uses the realm and principal components, so in realmA the salt
    is realmAkrbtgtrealmB and in realmB the salt is realmBkrbtgtrealmA. You need to
    create them without a salt or the same salt.

    With the Heimdal kadmin you can add a principal with -key DES-key in hex,
    which avoids the salt issues.



    Dave Botsch wrote:

    > On Wed, Nov 08, 2006 at 02:54:38PM -0500, Ken Hornstein wrote:
    >
    >>>So, I know I've got the right password... I can manually kinit
    >>>krbtgt/realmB@realmA using the supplied cross-realm password -- that works

    >>
    >>Okay ... but unless you did some magic, you weren't sending that request
    >>to realm B, you only sent that to realm A.

    >
    >
    > Right. I've been trying to figure out if there's a way to do this kinit to
    > realmB with some sort of magic, but no luck so far. It would certainly be a
    > useful test.
    >
    >
    >>
    >>Okay, one other thing comes to mind. Is it possible that the default
    >>key _salts_ are different between the two realms? Do a getprinc on both
    >>principals in both realms, and make sure the key salts (listed in the enctypes
    >>after every key) are the same. The keys should also be in the same order
    >>(although I don't remember if mis-ordering results in this error). When
    >>I create cross-realm keys, I specify the enctype:salt pairs manually so
    >>they will match and have the correct ordering.
    >>

    >
    >
    > I believe they match... well, one of them does at any rate. If I understand
    > things, on realmA, it's set up with just one enc/salt type where I've got three
    > on this end. One of those three is the one. I've tried recreating the principal
    > with just the one and no luck.
    >
    >
    >
    >>--Ken

    >
    >


    --

    Douglas E. Engert
    Argonne National Laboratory
    9700 South Cass Avenue
    Argonne, Illinois 60439
    (630) 252-5444
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  11. Re: cross realm : decrypt integrity check failed

    >1. changed the order of the supported enctypes in kdc.conf so that the one
    >being used in both places is listed first.


    This list (assuming you're talking about supported_enctypes) is actually
    just a default. -e should override it.

    >2. recreated the principal with -e to specify only the enctype being used in
    >both places (doing 2 by itself before had not fixed the issue).


    I find it odd that this didn't fix it before.

    >From my understand of Kerberos, this should not matter... interesting.


    Well, remember that with cross-realm, you're really dealing with _keys_,
    not passwords. I think what you were running into was the fact that
    the keys didn't match, even though the passwords did.

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


  12. Re: cross realm : decrypt integrity check failed

    >
    > Well, remember that with cross-realm, you're really dealing with _keys_,
    > not passwords. I think what you were running into was the fact that
    > the keys didn't match, even though the passwords did.


    Which is interesting as the same key (well, the same enc/salt type "created"
    with the same password) was present -- only key on the realmA kdc and the 3rd
    of three listed via a getprinc on the realmB kdc.

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


    --
    ********************************
    David William Botsch
    Programmer/Analyst
    CNF Computing
    botsch@cnf.cornell.edu
    ********************************
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  13. Re: cross realm : decrypt integrity check failed

    >Which is interesting as the same key (well, the same enc/salt type "created"
    >with the same password) was present -- only key on the realmA kdc and the 3rd
    >of three listed via a getprinc on the realmB kdc.


    When you're dealing with KEYS, remember that the salt type is NOT
    communicated when you're doing TGS_REQs (it's only negotiated as part
    of an AS_REQ ... when kinit happens). If you had, for example, three
    single-DES salt types, they're considered the same as far as the KDC is
    concerned for service principals (even though they are NOT the same
    key). Realm B's KDC would simply pick the first ENCTYPE that matched
    the enctype in the ticket from realm A. If they have a dissimilar
    salt, then they keys won't match.

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


+ Reply to Thread