[Freeipa-users] Cross-Realm authentification

Alexander Bokovoy abokovoy at redhat.com
Fri Dec 5 12:56:37 UTC 2014


On Fri, 05 Dec 2014, Andreas Ladanyi wrote:
>
>> I'm also getting errors but they are different to yours. Here is what I
>> did:
>>
>> (on master.f21.test, realm F21.TEST):
>> [root at master ~]# kadmin.local -x ipa-setup-override-restrictions -r
>> F21.TEST
>> Authenticating as principal root/admin at F21.TEST with password.
>> kadmin.local:  addprinc -requires_preauth krbtgt/IPA5.TEST
>> WARNING: no policy specified for krbtgt/IPA5.TEST at F21.TEST; defaulting
>> to no policy
>> Enter password for principal "krbtgt/IPA5.TEST at F21.TEST": Re-enter
>> password for principal "krbtgt/IPA5.TEST at F21.TEST": Principal
>> "krbtgt/IPA5.TEST at F21.TEST" created.
>> kadmin.local:  addprinc -requires_preauth krbtgt/F21.TEST at IPA5.TEST
>> WARNING: no policy specified for krbtgt/F21.TEST at IPA5.TEST; defaulting
>> to no policy
>> Enter password for principal "krbtgt/F21.TEST at IPA5.TEST": Re-enter
>> password for principal "krbtgt/F21.TEST at IPA5.TEST": Principal
>> "krbtgt/F21.TEST at IPA5.TEST" created.
>> kadmin.local:  q
>>
>> added following to the /etc/krb5.conf:
>> [libdefaults]
>> dns_lookup_realm = true
>>
>> [domain_realms]
>> .ipa5.test = IPA5.TEST
>> ipa5.test = IPA5.TEST
>Why only one domain and one realm if you have two REALMs ?
Because this is what I _added_. The F21.TEST entries were already in
place.

>On this position i have another question:
>
>I have 2 REALMs and one DNS domain.
>
>.domainname_X = REALM A
>domainname_X = REALM A
>.domainname_X = REALM B
>domainname_X = REALM B
>
>Could this work clear ?
No. What realm would it select if the domain name is the same? Either
you define explicitly per each host which realm the host belongs to or
you'd have different DNS domains for the realms.

>> "krbtgt/IPA5.TEST at F21.TEST" created.
>> kadmin.local:  q
>>
>Ok, i see one difference: i didnt use the "-requires_preauth" flag. Why
>did you use them ?
Because this is recommended by MIT documentation. The link between
realms has to be protected well, including preauth and good passwords
for the cross-realm principals.

>> and similar changes to /etc/krb5.conf.
>>
>> Then I tried to get a ticket to host/master.f21.test at F21.TEST while
>> being an admin at IPA5.TEST:
>I tried out this on the IPA box to connect to the non IPA box (foreign
>realm).
>>
>> [root at ipa-05-m ~]# kinit admin
>> Password for admin at IPA5.TEST: [root at ipa-05-m ~]#
>> KRB5_TRACE=/dev/stderr kvno -S host master.f21.test
>> [22351] 1417689782.154516: Convert service host (service with host as
>> instance) on host master.f21.test to principal
>> [22351] 1417689782.158724: Remote host after forward canonicalization:
>> master.f21.test
>> [22351] 1417689782.158814: Remote host after reverse DNS processing:
>> master.f21.test
>> [22351] 1417689782.158849: Get host realm for master.f21.test
>> [22351] 1417689782.158899: Use local host master.f21.test to get host
>> realm
>> [22351] 1417689782.158946: Look up master.f21.test in the domain_realm
>> map
>> [22351] 1417689782.158999: Look up .f21.test in the domain_realm map
>> [22351] 1417689782.159023: Temporary realm is F21.TEST
>> [22351] 1417689782.159044: Got realm F21.TEST for host master.f21.test
>> [22351] 1417689782.159071: Got service principal
>> host/master.f21.test at F21.TEST
>> [22351] 1417689782.159098: Getting credentials admin at IPA5.TEST ->
>> host/master.f21.test at F21.TEST using ccache KEYRING:persistent:0:0
>> [22351] 1417689782.159237: Retrieving admin at IPA5.TEST ->
>> host/master.f21.test at F21.TEST from KEYRING:persistent:0:0 with result:
>> -1765328243/Matching credential not found
>> [22351] 1417689782.159297: Retrieving admin at IPA5.TEST ->
>> krbtgt/F21.TEST at IPA5.TEST from KEYRING:persistent:0:0 with result:
>> -1765328243/Matching credential not found
>> [22351] 1417689782.159411: Retrieving admin at IPA5.TEST ->
>> krbtgt/IPA5.TEST at IPA5.TEST from KEYRING:persistent:0:0 with result:
>> 0/Success
>> [22351] 1417689782.159453: Starting with TGT for client realm:
>> admin at IPA5.TEST -> krbtgt/IPA5.TEST at IPA5.TEST
>> [22351] 1417689782.159502: Retrieving admin at IPA5.TEST ->
>> krbtgt/F21.TEST at IPA5.TEST from KEYRING:persistent:0:0 with result:
>> -1765328243/Matching credential not found
>> [22351] 1417689782.159530: Requesting TGT krbtgt/F21.TEST at IPA5.TEST
>> using TGT krbtgt/IPA5.TEST at IPA5.TEST
>> [22351] 1417689782.159576: Generated subkey for TGS request:
>> aes256-cts/54E6
>> [22351] 1417689782.159628: etypes requested in TGS request:
>> aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts,
>> camellia256-cts
>> [22351] 1417689782.159726: Encoding request body and padata into FAST
>> request
>> [22351] 1417689782.159784: Sending request (890 bytes) to IPA5.TEST
>> [22351] 1417689782.159909: Sending initial UDP request to dgram
>> 192.168.5.109:88
>> [22351] 1417689782.161823: Received answer from dgram 192.168.5.109:88
>> [22351] 1417689782.161925: Response was from master KDC
>> [22351] 1417689782.162011: Decoding FAST response
>> [22351] 1417689782.162084: FAST reply key: aes256-cts/EBCE
>> [22351] 1417689782.162127: TGS reply is for admin at IPA5.TEST ->
>> krbtgt/F21.TEST at IPA5.TEST with session key aes256-cts/822B
>> [22351] 1417689782.162159: TGS request result: 0/Success
>> [22351] 1417689782.162185: Removing admin at IPA5.TEST ->
>> krbtgt/F21.TEST at IPA5.TEST from KEYRING:persistent:0:0
>> [22351] 1417689782.162207: Storing admin at IPA5.TEST ->
>> krbtgt/F21.TEST at IPA5.TEST in KEYRING:persistent:0:0
>> [22351] 1417689782.162268: Received TGT for service realm:
>> krbtgt/F21.TEST at IPA5.TEST
>> [22351] 1417689782.162296: Requesting tickets for
>> host/master.f21.test at F21.TEST, referrals on
>> [22351] 1417689782.162322: Generated subkey for TGS request:
>> aes256-cts/61A2
>> [22351] 1417689782.162359: etypes requested in TGS request:
>> aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts,
>> camellia256-cts
>> [22351] 1417689782.162413: Encoding request body and padata into FAST
>> request
>> [22351] 1417689782.162460: Sending request (855 bytes) to F21.TEST
>> [22351] 1417689782.162493: Resolving hostname master.f21.test
>> [22351] 1417689782.163213: Sending initial UDP request to dgram
>> 192.168.5.169:88
>> [22351] 1417689782.165439: Received answer from dgram 192.168.5.169:88
>> [22351] 1417689782.165516: Response was from master KDC
>In my case:
>
>[31580] 1417773156.446922: TGS request result: -1765328324/KDC returned
>error string: PROCESS_TGS
>
>There is no Decoding FAST response.
This is a detail of your foreign KDC configuration, what features it
exposes and requires.

>
>> [22351] 1417689782.165572: Decoding FAST response
>> [22351] 1417689782.165643: TGS request result: -1765328372/KDC policy
>> rejects request
>> [22351] 1417689782.165680: Requesting tickets for
>> host/master.f21.test at F21.TEST, referrals off
>> [22351] 1417689782.165714: Generated subkey for TGS request:
>> aes256-cts/FEA9
>> [22351] 1417689782.165751: etypes requested in TGS request:
>> aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts,
>> camellia256-cts
>> [22351] 1417689782.165799: Encoding request body and padata into FAST
>> request
>> [22351] 1417689782.165847: Sending request (855 bytes) to F21.TEST
>> [22351] 1417689782.165875: Resolving hostname master.f21.test
>> [22351] 1417689782.166084: Sending initial UDP request to dgram
>> 192.168.5.169:88
>> [22351] 1417689782.167602: Received answer from dgram 192.168.5.169:88
>> [22351] 1417689782.167642: Response was from master KDC
>In my case at this position:
>
>[31580] 1417773156.449640: TGS request result: -1765328324/KDC returned
>error string: PROCESS_TGS
>kvno: KDC returned error string: PROCESS_TGS while getting credentials for
>
>I found out that at the non IPA KDC (the foreign KDC) isnt a Port 88
>available (closed). The ports 464+749 are available.
>
>On the IPA KDC there are ports 88+464+749
Port 88 is the standard KDC port. One can choose to use another ports
but all machines in the realm then should have the required ports
configured properly. 88 is the port for the normal Kerberos
communication, 464 is the port for kpasswd, 749 is kadmin.

See more on
http://web.mit.edu/kerberos/krb5-latest/doc/admin/appl_servers.html#conf-firewall


>There is no Decoding FAST response.
>
>> [22351] 1417689782.167669: Decoding FAST response
>> [22351] 1417689782.167709: TGS request result: -1765328372/KDC policy
>> rejects request
>> kvno: KDC policy rejects request while getting credentials for
>> host/master.f21.test at F21.TEST
>> [root at ipa-05-m ~]#
>> And /var/log/krb5kdc.log on master.f21.test (KDC for F21.TEST) I can
>> see:
>> Dec 04 12:41:52 master.f21.test krb5kdc[1131](info): bad realm transit
>> path from 'admin at IPA5.TEST' to 'host/master.f21.test at F21.TEST' via ''
>> Dec 04 12:41:52 master.f21.test krb5kdc[1131](info): TGS_REQ (6 etypes
>> {18 17 16 23 25 26}) 192.168.5.109: BAD_TRANSIT: authtime 1417689777,
>> admin at IPA5.TEST for host/master.f21.test at F21.TEST, KDC policy rejects
>> request
>> Dec 04 12:41:52 master.f21.test krb5kdc[1131](info): bad realm transit
>> path from 'admin at IPA5.TEST' to 'host/master.f21.test at F21.TEST' via ''
>> Dec 04 12:41:52 master.f21.test krb5kdc[1131](info): TGS_REQ (6 etypes
>> {18 17 16 23 25 26}) 192.168.5.109: BAD_TRANSIT: authtime 1417689777,
>> admin at IPA5.TEST for host/master.f21.test at F21.TEST, KDC policy rejects
>> request
>>
>> And this is correct for FreeIPA 3.3 or later because we limit trust to
>> those domains we defined in cn=ad,cn=trusts,$SUFFIX with filter
>> (objectclass=ipaNTTrustedDomain). For the rest we return
>> KRB5KRB_AP_ERR_ILL_CR_TKT error code which is visible as 'KDC policy
>> rejects request'.
>Is it possible or a good idea to add my trust domain, which isnt a AD
>domain, manualy to IPA 3.3 ?
Well, you can hack of course, that's up to you. I haven't checked that
myself and cannot give you definitive answer on this path, though.

>>
>>
>> We may reconsider this check and instead of KRB5KRB_AP_ERR_ILL_CR_TKT
>> return KRB5_PLUGIN_NO_HANDLE to allow fallback to krb5.conf-defined
>> capaths but I remember we had some issues with krb5 versions prior to
>> 1.12 where capaths from krb5.conf were blocking work of the DAL driver.
>I use MIT Kerberos 1.6 from OpenCSW on Solaris and FreeIPA 3.3.5. So
>this shouldnt be a problem ?!
1.6 does not support cross-realm communication as support for RFC6806
was added only in 1.7. So I don't think your setup would have any chance
to work at all.


-- 
/ Alexander Bokovoy




More information about the Freeipa-users mailing list