Hello everyone,
We are currently trying to establish a simple cross-realm between an IPA and an
AD domain (not a trust). This is due the specific setup we have: we already
have an external source of users and groups information exporting to both
domains, hence we don't really have a need for the features the trust provides.
Clients can just lookup any user/group information from their own domain's
identity manager.
The only thing we would need is for AD users to be able to access IPA-managed
services. But since clients usually only have one available credential cache at
a time, we need at least a one-way Kerberos-level cross-realm.
Apparently, we are not the first ones facing the issue described
hereafter[1][2], but I couldn't find any trace of a successful outcome.
This is our setup:
- IPA
- Version: 4.8.7
- Realm:
IPA.EXAMPLE.COM
- DNS domain:
ipa.example.com
- Server:
server01.ipa.example.com
- AD
- Functional level: Windows Server 2008 R2
- Realm:
AD.EXAMPLE.COM
- DNS domain:
ad.example.com
- Domain controller:
dc01.ad.example.com
The configuration of the cross-realm was done this way (same password on both
domains):
On
dc01.ad.example.com AD domain controller:
===
ksetup /addkdc
IPA.EXAMPLE.COM server01.ipa.example.com
netdom trust
IPA.EXAMPLE.COM /domain:ad.example.com /add /realm /passwordt:XXXXX
ksetup /SetEncTypeAttr
IPA.EXAMPLE.COM AES256-CTS-HMAC-SHA1-96
===
On
server01.ipa.example.com IPA server (the "ipa-setup-override-restrictions"
argument seems to be mandatory[3]):
===
kadmin.local -x ipa-setup-override-restrictions
kadmin.local: add_principal -requires_preauth -e
'aes256-cts-hmac-sha1-96,aes128-cts-hmac-sha1-96' -pw XXXXX
krbtgt/IPA.EXAMPLE.COM(a)AD.EXAMPLE.COM
===
The cross-realm TGT is visible in LDAP:
===
$ ldapsearch -LLL -o ldif-wrap=no -QY GSSAPI -H
ldaps://server01.ipa.example.com
krbCanonicalName=krbtgt/IPA.EXAMPLE.COM(a)AD.EXAMPLE.COM
dn:
krbPrincipalName=krbtgt/IPA.EXAMPLE.COM(a)AD.EXAMPLE.COM,cn=IPA.EXAMPLE.COM,cn=kerberos,dc=ipa,dc=example,dc=com
objectClass: krbprincipal
objectClass: krbprincipalaux
objectClass: krbTicketPolicyAux
objectClass: top
krbPrincipalName: krbtgt/IPA.EXAMPLE.COM(a)AD.EXAMPLE.COM
krbCanonicalName: krbtgt/IPA.EXAMPLE.COM(a)AD.EXAMPLE.COM
krbLastPwdChange: 20210318113328Z
krbTicketFlags: 128
krbExtraData:: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX==
krbPwdPolicyReference: cn=Default Kerberos Service Password Policy,cn=Kerberos Service
Password Policy,cn=IPA.EXAMPLE.COM,cn=kerberos,dc=ipa,dc=example,dc=com
===
We configured an AD test client :
===
[libdefaults]
default_realm =
AD.EXAMPLE.COM
ticket_lifetime = 25h
renew_lifetime = 120h
dns_lookup_realm = false
dns_lookup_kdc = false
forwardable = true
[domain_realm]
.ipa.example.com =
IPA.EXAMPLE.COM
.ad.example.com =
AD.EXAMPLE.COM
[realms]
IPA.EXAMPLE.COM = {
admin_server =
server01.ipa.example.com
kpasswd_server =
server01.ipa.example.com
kdc =
server01.ipa.example.com
}
AD.EXAMPLE.COM = {
kpasswd_server =
dc01.ad.example.com
admin_server =
dc01.ad.example.com
kdc =
dc01.ad.example.com
}
[capaths]
AD.EXAMPLE.COM = {
IPA.EXAMPLE.COM = .
}
IPA.EXAMPLE.COM = {
AD.EXAMPLE.COM = .
}
===
We authenticate as an AD user and request an IPA service ticket:
===
$ kinit me(a)AD.EXAMPLE.COM
$ KRB5_TRACE=/dev/stderr kvno HTTP/server01.ipa.example.com(a)IPA.EXAMPLE.COM
: Getting credentials me(a)AD.EXAMPLE.COM ->
HTTP/server01.ipa.example.com(a)IPA.EXAMPLE.COM using ccache FILE:/tmp/krb5cc_0_8LQSGjNfp4
: Retrieving me(a)AD.EXAMPLE.COM -> HTTP/server01.ipa.example.com(a)IPA.EXAMPLE.COM from
FILE:/tmp/krb5cc_0_8LQSGjNfp4 with result: -1765328243/Matching credential not found
(filename: /tmp/krb5cc_0_8LQSGjNfp4)
: Retrieving me(a)AD.EXAMPLE.COM -> krbtgt/IPA.EXAMPLE.COM(a)IPA.EXAMPLE.COM from
FILE:/tmp/krb5cc_0_8LQSGjNfp4 with result: -1765328243/Matching credential not found
(filename: /tmp/krb5cc_0_8LQSGjNfp4)
: Retrieving me(a)AD.EXAMPLE.COM -> krbtgt/AD.EXAMPLE.COM(a)AD.EXAMPLE.COM from
FILE:/tmp/krb5cc_0_8LQSGjNfp4 with result: 0/Success
: Starting with TGT for client realm: me(a)AD.EXAMPLE.COM ->
krbtgt/AD.EXAMPLE.COM(a)AD.EXAMPLE.COM
: Retrieving me(a)AD.EXAMPLE.COM -> krbtgt/IPA.EXAMPLE.COM(a)IPA.EXAMPLE.COM from
FILE:/tmp/krb5cc_0_8LQSGjNfp4 with result: -1765328243/Matching credential not found
(filename: /tmp/krb5cc_0_8LQSGjNfp4)
: Requesting TGT krbtgt/IPA.EXAMPLE.COM(a)AD.EXAMPLE.COM using TGT
krbtgt/AD.EXAMPLE.COM(a)AD.EXAMPLE.COM
: Generated subkey for TGS request: aes256-cts/053B
: etypes requested in TGS request: aes256-cts, aes128-cts, aes256-sha2, aes128-sha2,
rc4-hmac, camellia128-cts, camellia256-cts
: Encoding request body and padata into FAST request
: Sending request (1747 bytes) to
AD.EXAMPLE.COM
: Resolving hostname
dc01.ad.example.com
: Initiating TCP connection to stream XXXX:XXXX:XXX:XX::XXX:XXX:88
: Initiating TCP connection to stream XXX.XXX.XX.XXX:88
: Sending TCP request to stream XXX.XXX.XX.XXX:88
: Received answer (1660 bytes) from stream XXX.XXX.XX.XXX:88
: Terminating TCP connection to stream XXXX:XXXX:XXX:XX::XXX:XXX:88
: Terminating TCP connection to stream XXX.XXX.XX.XXX:88
: Response was not from master KDC
: Decoding FAST response
: FAST reply key: aes256-cts/B731
: TGS reply is for me(a)AD.EXAMPLE.COM -> krbtgt/IPA.EXAMPLE.COM(a)AD.EXAMPLE.COM with
session key aes256-cts/A6B0
: TGS request result: 0/Success
: Storing me(a)AD.EXAMPLE.COM -> krbtgt/IPA.EXAMPLE.COM(a)AD.EXAMPLE.COM in
FILE:/tmp/krb5cc_0_8LQSGjNfp4
: Received TGT for service realm: krbtgt/IPA.EXAMPLE.COM(a)AD.EXAMPLE.COM
: Requesting tickets for HTTP/server01.ipa.example.com(a)IPA.EXAMPLE.COM, referrals on
: Generated subkey for TGS request: aes256-cts/6AFE
: etypes requested in TGS request: aes256-cts, aes128-cts, aes256-sha2, aes128-sha2,
rc4-hmac, camellia128-cts, camellia256-cts
: Encoding request body and padata into FAST request
: Sending request (1754 bytes) to
IPA.EXAMPLE.COM
: Resolving hostname
server01.ipa.example.com
: Initiating TCP connection to stream XXXX:XXXX:XXX:XX::XXX:XXX:88
: Sending TCP request to stream XXXX:XXXX:XXX:XX::XXX:XXX:88
: Received answer (479 bytes) from stream XXXX:XXXX:XXX:XX::XXX:XXX:88
: Terminating TCP connection to stream XXXX:XXXX:XXX:XX::XXX:XXX:88
: Response was not from master KDC
: Decoding FAST response
: TGS request result: -1765328324/KDC returned error string: HANDLE_AUTHDATA
: Requesting tickets for HTTP/server01.ipa.example.com(a)IPA.EXAMPLE.COM, referrals off
: Generated subkey for TGS request: aes256-cts/EB57
: etypes requested in TGS request: aes256-cts, aes128-cts, aes256-sha2, aes128-sha2,
rc4-hmac, camellia128-cts, camellia256-cts
: Encoding request body and padata into FAST request
: Sending request (1754 bytes) to
IPA.EXAMPLE.COM
: Resolving hostname
server01.ipa.example.com
: Initiating TCP connection to stream XXXX:XXXX:XXX:XX::XXX:XXX:88
: Sending TCP request to stream XXXX:XXXX:XXX:XX::XXX:XXX:88
: Received answer (479 bytes) from stream XXXX:XXXX:XXX:XX::XXX:XXX:88
: Terminating TCP connection to stream XXXX:XXXX:XXX:XX::XXX:XXX:88
: Response was not from master KDC
: Decoding FAST response
: TGS request result: -1765328324/KDC returned error string: HANDLE_AUTHDATA
kvno: KDC returned error string: HANDLE_AUTHDATA while getting credentials for
HTTP/server01.ipa.example.com(a)IPA.EXAMPLE.COM
$ klist -def
Ticket cache: FILE:/tmp/krb5cc_0_8LQSGjNfp4
Default principal: me(a)AD.EXAMPLE.COM
Valid starting Expires Service principal
03/18/2021 15:38:40 03/19/2021 01:38:40 krbtgt/AD.EXAMPLE.COM(a)AD.EXAMPLE.COM
renew until 03/23/2021 15:38:32, Flags: FRIA
Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 , AD types:
03/18/2021 15:38:49 03/19/2021 01:38:40 krbtgt/IPA.EXAMPLE.COM(a)AD.EXAMPLE.COM
Flags: FA, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 ,
AD types:
===
This is what the error looks like on the IPA KDC side:
===
TGS_REQ : handle_authdata (22)
TGS_REQ (7 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),
aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19),
DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), camellia256-cts-cmac(26)})
XXXX:XXXX:XXX:XX::XXX:XXX: HANDLE_AUTHDATA: authtime 1616078320, etypes
{rep=UNSUPPORTED:(0)} me(a)AD.EXAMPLE.COM for HTTP/server01.ipa.example.com(a)IPA.EXAMPLE.COM,
Invalid argument
closing down fd 12
TGS_REQ : handle_authdata (22)
TGS_REQ (7 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),
aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19),
DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), camellia256-cts-cmac(26)})
XXXX:XXXX:XXX:XX::XXX:XXX: HANDLE_AUTHDATA: authtime 1616078320, etypes
{rep=UNSUPPORTED:(0)} me(a)AD.EXAMPLE.COM for HTTP/server01.ipa.example.com(a)IPA.EXAMPLE.COM,
Invalid argument
closing down fd 12
===
Do you think a vanilla cross-realm between IPA and AD is possible? If yes, does
someone have an idea why the handle_authdata function[4] is failing? Are we
missing something in the configuration?
Kind regards,
Julien Rische
CERN
[1]
http://kerberos.996246.n3.nabble.com/HANDLE-AUTHDATA-error-when-trying-to...
[2]
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
[3]
https://bugzilla.redhat.com/show_bug.cgi?id=1035494
[4]
https://github.com/krb5/krb5/blob/krb5-1.18.2-final/src/kdc/kdc_authdata....