[38768] in Kerberos

home help back first fref pref prev next nref lref last post

Re: [EXT] 'HANDLE_AUTHDATA' error when trying to setup Kerberos trust

daemon@ATHENA.MIT.EDU (Robbie Harwood)
Tue Jun 16 07:09:33 2020

From: Robbie Harwood <rharwood@redhat.com>
To: Robert Sturrock <rns@unimelb.edu.au>, Dmitri Pal <dpal@redhat.com>
In-Reply-To: <CEC232C0-EE38-4ADB-8671-8D4D462C249A@unimelb.edu.au>
Date: Tue, 16 Jun 2020 07:06:39 -0400
Message-ID: <jlg7dw7l16o.fsf@redhat.com>
MIME-Version: 1.0
Cc: "kerberos@mit.edu" <kerberos@mit.edu>
Content-Type: multipart/mixed; boundary="===============5242177720341212047=="
Errors-To: kerberos-bounces@mit.edu

--===============5242177720341212047==
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha512; protocol="application/pgp-signature"

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Robert Sturrock <rns@unimelb.edu.au> writes:

> Hi Dmitri,
>
> Sorry - I did not give all the background in the interests of brevity.
> We do not want to establish a full trust between AD and IPA (at this
> stage).  This is for a number of reasons, but is primarily a
> reluctance to bring a very large and entirely irrelevant set of AD
> groups across to IPA-enrolled hosts.
>
> The IPA installation is running in a =E2=80=98winsync=E2=80=99 arrangemen=
t with AD,
> but as a convenience for the users it would be useful if a TGT from AD
> were sufficient to access services in the IPA realm, to save them
> having to =E2=80=98kinit' to another kerberos realm.
>
> So I=E2=80=99m interested in establishing a trust at the Kerberos level o=
nly.
> We have done this successfully between a legacy MIT kerberos service
> and IPA, so I hoped we could also set one up between AD and IPA,
> before running into the error I described.
>
> Any clues as to what the reason for the =E2=80=98HANDLE_AUTHDATA=E2=80=99=
 error might be?

For context, the full error is:

    kvno: KDC returned error string: HANDLE_AUTHDATA while getting credenti=
als for host/palladium1.localdomain@PALLAS.LOCALREALM

Anyway, first step is to check the KDC logs (since that's who generated
the error) - there's possibly more information there.

Thanks,
--Robbie

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEA5qc6hnelQjDaHWqJTL5F2qVpEIFAl7op78ACgkQJTL5F2qV
pEKwJBAAss6lb7zovh5bZg3L3Ua0YxKxDBTx9pFseVZSGPXSDM3yfAJ4sDsAlRFu
ikJkDmFuaAj/JsCLxS/b9b/fQ3bDdjdE1Uj1v+0t5K4BwrY9S9Y7Zh7Y816hCxla
hm1GIapgcCWL1lXNCprEHCUH1N8Uo56P5ceBN8hRAoSeygDGjrbenzx0rbbWqwMB
KVScMhZFhmtno9+LR/wYVZY7WSsgrv1Pm0ZZTFs6IWQIOzvTboLxxTNq3xtPovPl
dHR1ZGMG9+BdLb/9HWN3xPhv4OGDic3bY45Arm96Fpq/0+MonYx3hhdGu3stM+8q
wQV/IH+1gcMMES9rD4FxwQxRZhzuXI2ed4+7/5tMoPTIpfs5VXMmR1ghEk5IzZOC
mTKoZXKSxYjUcWaIjRbr5ih51uOpIGVmBBrV3oLklx7biHWB4E1DepUsVUD/579b
k7+HTzS+I+twKdEK/R2QtxHIV2LV3o1cJuBQsld8UTEW4MEBaXMgiSaF7Hb9S+mU
274Q/xjSdZe/y4kPK/MXq6kJXJPhK9dafrmAUBKhQdq5hjwEhmIYI7KHcCvhRnaH
1g0HPux99SgjxHQ8fOR39d0ZQRd1NGFCBx8A+Q8rr6y2eSbasNgkB/lWHMob36QB
g4JZ1qLVw7ugU1XPM8O3Ls+aN679aPl3JzQC+FzPoAIS5QmwuuY=
=MWfQ
-----END PGP SIGNATURE-----
--=-=-=--

--===============5242177720341212047==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============5242177720341212047==--

home help back first fref pref prev next nref lref last post