On to, 18 maalis 2021, Julien Rische via FreeIPA-users wrote:
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.
Will not work, sorry. You have to establish trust because both IPA and
AD expect MS-PAC record in the tickets to accept them. Lack of MS-PAC
leads to rejection that you can see as handle_authdata error. [MS-KILE]
spec says that KILE-compatible client always requests PAC padata type
when generating KRB_AS-REQ message (3.2.5.5) and during during
KRB_TGS-REQ request (3.2.5.7).
IPA's implementation of the KDB driver relies on the trust object
records in LDAP database when creating and signing PAC records for
tickets to be created over cross-realm trust because these records
contain required additional details otherwise not available in Kerberos
principals for cross-realm TGTs.
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
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
_______________________________________________
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
