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/[email protected]
===
The cross-realm TGT is visible in LDAP:
===
$ ldapsearch -LLL -o ldif-wrap=no -QY GSSAPI -H
ldaps://server01.ipa.example.com
krbCanonicalName=krbtgt/[email protected]
dn:
krbPrincipalName=krbtgt/[email protected],cn=IPA.EXAMPLE.COM,cn=kerberos,dc=ipa,dc=example,dc=com
objectClass: krbprincipal
objectClass: krbprincipalaux
objectClass: krbTicketPolicyAux
objectClass: top
krbPrincipalName: krbtgt/[email protected]
krbCanonicalName: krbtgt/[email protected]
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 [email protected]
$ KRB5_TRACE=/dev/stderr kvno HTTP/[email protected]
: Getting credentials [email protected] ->
HTTP/[email protected] using ccache
FILE:/tmp/krb5cc_0_8LQSGjNfp4
: Retrieving [email protected] ->
HTTP/[email protected] from
FILE:/tmp/krb5cc_0_8LQSGjNfp4 with result: -1765328243/Matching credential not
found (filename: /tmp/krb5cc_0_8LQSGjNfp4)
: Retrieving [email protected] -> krbtgt/[email protected] from
FILE:/tmp/krb5cc_0_8LQSGjNfp4 with result: -1765328243/Matching credential not
found (filename: /tmp/krb5cc_0_8LQSGjNfp4)
: Retrieving [email protected] -> krbtgt/[email protected] from
FILE:/tmp/krb5cc_0_8LQSGjNfp4 with result: 0/Success
: Starting with TGT for client realm: [email protected] ->
krbtgt/[email protected]
: Retrieving [email protected] -> krbtgt/[email protected] from
FILE:/tmp/krb5cc_0_8LQSGjNfp4 with result: -1765328243/Matching credential not
found (filename: /tmp/krb5cc_0_8LQSGjNfp4)
: Requesting TGT krbtgt/[email protected] using TGT
krbtgt/[email protected]
: 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 [email protected] -> krbtgt/[email protected]
with session key aes256-cts/A6B0
: TGS request result: 0/Success
: Storing [email protected] -> krbtgt/[email protected] in
FILE:/tmp/krb5cc_0_8LQSGjNfp4
: Received TGT for service realm: krbtgt/[email protected]
: Requesting tickets for HTTP/[email protected],
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/[email protected],
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/[email protected]
$ klist -def
Ticket cache: FILE:/tmp/krb5cc_0_8LQSGjNfp4
Default principal: [email protected]
Valid starting Expires Service principal
03/18/2021 15:38:40 03/19/2021 01:38:40 krbtgt/[email protected]
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/[email protected]
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)} [email protected] for
HTTP/[email protected], 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)} [email protected] for
HTTP/[email protected], 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-setup-Kerberos-trust-between-AD-and-FreeIPA-td50000.html
[2]
https://lists.fedorahosted.org/archives/list/[email protected]/thread/LP5CLT6BUTGZ4LYJPMINEUL6HRGURKCZ/
[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.c#L806
_______________________________________________
FreeIPA-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/[email protected]
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
