Re: [EXT] 'HANDLE_AUTHDATA' error when trying to setup Kerberos trust between AD and FreeIPA

Robert Sturrock <[email protected]>
Newsgroups gmane.comp.encryption.kerberos.general
Message-ID <[email protected]>
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 ‘winsync’ arrangement 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 ‘kinit' to another kerberos realm.

So I’m interested in establishing a trust at the Kerberos level only.  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 ‘HANDLE_AUTHDATA’ error might be?

Regards,

Robert.


> On 15 Jun 2020, at 11:00 pm, Dmitri Pal <[email protected]> wrote:
> 
> 
> 
> UoM notice: External email. Be cautious of links, attachments, or impersonation attempts.
> On Mon, Jun 15, 2020 at 2:39 AM Robert Sturrock <[email protected]> wrote:
> Hi All,
> 
> I’m trying to create a (one-way) Kerberos trust between AD and a FreeIPA installation, such that user TGTs from AD can be used to access resources in the IPA realm.
> 
> I followed some (non-IPA related) steps for setting up Kerberos trusts between AD and MIT Kerberos - essentially creating a common TGT principal in both systems with a common password.  This works to a point (ie. I can get the TGT for IPA using the AD TGT), but when I try to fetch a service ticket in the IPA domain I get a ‘HANDLE_AUTHDATA’ error.
> 
> Was there any reason not to follow IPA steps for setting trusts?
> They are very straightforward.
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/installing_identity_management/installing-trust-between-idm-and-ad_installing-identity-management
> 
>  
> 
> Here is what I’m seeing:
> 
>  (AD domain = ‘STAFF.LOCALREALM'; IPA domain = ‘PALLAS.LOCALREALM')
> 
>  # Get AD TGT:
>  Password for [email protected]: XXXXXXXXX
> 
>  $ klist
>  Ticket cache: KEYRING:persistent:10846:10846
>  Default principal: [email protected]
> 
>  Valid starting     Expires            Service principal
>  11/06/20 13:34:19  11/06/20 23:34:19  krbtgt/[email protected]
>          renew until 12/06/20 13:34:18
> 
>  # Use AD TGT to get an IPA TGT:
>  $ kvno krbtgt/[email protected]
>  krbtgt/[email protected]: kvno = 0
> 
>  $ klist
>  Ticket cache: KEYRING:persistent:10846:10846
>  Default principal: [email protected]
> 
>  Valid starting     Expires            Service principal
>  11/06/20 13:34:24  11/06/20 23:34:19  krbtgt/[email protected]
>          renew until 12/06/20 13:34:18
>  11/06/20 13:34:19  11/06/20 23:34:19  krbtgt/[email protected]
>          renew until 12/06/20 13:34:18
> 
>  # Try to fetch an IPA service ticket:
>  $ kvno host/[email protected]
>  kvno: KDC returned error string: HANDLE_AUTHDATA while getting credentials for host/[email protected]
> 
> Can anyone provide some idea as to what’s going on here and how I resolve this?  I don’t really know what ‘HANDLE_AUTHDATA’ indicates and I’m not able to find a lot of documentation explaining this.
> 
> Thanks!
> 
> Robert.
> 
> ________________________________________________
> Kerberos mailing list           [email protected]
> https://mailman.mit.edu/mailman/listinfo/kerberos
> 
> 
> -- 
> Thank you,
> Dmitri Pal
> Director, Software Engineering
> Red Hat Enterprise Linux Platform Security and Identity Management
> [email protected]
> 


________________________________________________
Kerberos mailing list           [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.