[Freeipa-users] Cross-Realm authentification

Fri Dec 5 20:53:07 UTC 2014

On Fri, 05 Dec 2014, Alexander Bokovoy wrote:
>On Fri, 05 Dec 2014, Petr Spacek wrote:
>>On 5.12.2014 15:21, Andreas Ladanyi wrote:
>>>Am 05.12.2014 um 14:04 schrieb Alexander Bokovoy:
>>>>
>>>>>>>
>>>>>>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.
>>>>>
>>>>>
>>>>>>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.
>>>At this time i havent an idea off the steps in detail how to do that.
>>>>>
>>>>>>>
>>>>>>>
>>>>>>>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 ?!
>>>Sorry i made a little typing mistake. The foreign realm ist MIT Kerberos
>>>1.9.2 and not 1.6
>>>>>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.
>>>>Hm.. on the other hand, 1.6 documentation talks about it:
>>>>http://web.mit.edu/kerberos/krb5-1.6/krb5-1.6.3/doc/krb5-admin.html#Cross_002drealm-Authentication
>>>>
>>>>So may be their changelogs aren't as complete as they should be. :)
>>>>
>>>>With the link above you can also see with disabling preauth on the
>>>>cross-realm krbtgt records is recommended.
>>>>
>>>>But I think most of your issues were because of the 88 port not being
>>>>available and no other means to traverse firewall were configured.
>>>I will look particular for that.
>>>
>>>There is no firewall between the two KDCs.
>>>
>>>>That
>>>>is, aside from the fact that IPA will reject cross-realm tickets because
>>>>of how we programmed DAL driver as I explained above.
>>>
>>>
>>>I dont know in detail what DAL is doing.
>>>
>>>OK, it sounds like with IPA my setup wont be very easy :-)
>>
>>I guess that Alexander or Simo could point you to the line in the source code
>>you have to change (or send you one-line patch?) but you will have to
>>recompile the driver from source.
>>
>>Do you want to try this way?
>Attached please find a patch that solves the issue of cross-realm trust
>for me:
>[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
>[16101] 1417810641.441614: Convert service host (service with host as instance) on host master.f21.test to principal
>[16101] 1417810641.449424: Remote host after forward canonicalization: master.f21.test
>[16101] 1417810641.449501: Remote host after reverse DNS processing: master.f21.test
>[16101] 1417810641.449549: Get host realm for master.f21.test
>[16101] 1417810641.449593: Use local host master.f21.test to get host realm
>[16101] 1417810641.449630: Look up master.f21.test in the domain_realm map
>[16101] 1417810641.449655: Look up .f21.test in the domain_realm map
>[16101] 1417810641.449677: Temporary realm is F21.TEST
>[16101] 1417810641.449697: Got realm F21.TEST for host master.f21.test
>[16101] 1417810641.449724: Got service principal host/master.f21.test at F21.TEST
>[16101] 1417810641.449750: Getting credentials admin at IPA5.TEST -> host/master.f21.test at F21.TEST using ccache KEYRING:persistent:0:0
>[16101] 1417810641.449888: Retrieving admin at IPA5.TEST -> host/master.f21.test at F21.TEST from KEYRING:persistent:0:0 with result: -1765328243/Matching credential not found
>[16101] 1417810641.449946: Retrieving admin at IPA5.TEST -> krbtgt/F21.TEST at IPA5.TEST from KEYRING:persistent:0:0 with result: -1765328243/Matching credential not found
>[16101] 1417810641.450065: Retrieving admin at IPA5.TEST -> krbtgt/IPA5.TEST at IPA5.TEST from KEYRING:persistent:0:0 with result: 0/Success
>[16101] 1417810641.450095: Starting with TGT for client realm: admin at IPA5.TEST -> krbtgt/IPA5.TEST at IPA5.TEST
>[16101] 1417810641.450144: Retrieving admin at IPA5.TEST -> krbtgt/F21.TEST at IPA5.TEST from KEYRING:persistent:0:0 with result: -1765328243/Matching credential not found
>[16101] 1417810641.450171: Requesting TGT krbtgt/F21.TEST at IPA5.TEST using TGT krbtgt/IPA5.TEST at IPA5.TEST
>[16101] 1417810641.450216: Generated subkey for TGS request: aes256-cts/3A06
>[16101] 1417810641.450267: etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
>[16101] 1417810641.450364: Encoding request body and padata into FAST request
>[16101] 1417810641.450422: Sending request (890 bytes) to IPA5.TEST
>[16101] 1417810641.450559: Sending initial UDP request to dgram 192.168.5.109:88
>[16101] 1417810641.452191: Received answer from dgram 192.168.5.109:88
>[16101] 1417810641.452241: Response was from master KDC
>[16101] 1417810641.452273: Decoding FAST response
>[16101] 1417810641.452366: FAST reply key: aes256-cts/ADA3
>[16101] 1417810641.452420: TGS reply is for admin at IPA5.TEST -> krbtgt/F21.TEST at IPA5.TEST with session key aes256-cts/2C28
>[16101] 1417810641.452453: TGS request result: 0/Success
>[16101] 1417810641.452479: Removing admin at IPA5.TEST -> krbtgt/F21.TEST at IPA5.TEST from KEYRING:persistent:0:0
>[16101] 1417810641.452509: Storing admin at IPA5.TEST -> krbtgt/F21.TEST at IPA5.TEST in KEYRING:persistent:0:0
>[16101] 1417810641.452572: Received TGT for service realm: krbtgt/F21.TEST at IPA5.TEST
>[16101] 1417810641.452600: Requesting tickets for host/master.f21.test at F21.TEST, referrals on
>[16101] 1417810641.452626: Generated subkey for TGS request: aes256-cts/599E
>[16101] 1417810641.452662: etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
>[16101] 1417810641.452707: Encoding request body and padata into FAST request
>[16101] 1417810641.452754: Sending request (855 bytes) to F21.TEST
>[16101] 1417810641.452805: Resolving hostname master.f21.test
>[16101] 1417810641.453031: Sending initial UDP request to dgram 192.168.5.169:88
>[16101] 1417810641.456205: Received answer from dgram 192.168.5.169:88
>[16101] 1417810641.456285: Response was from master KDC
>[16101] 1417810641.456318: Decoding FAST response
>[16101] 1417810641.456380: FAST reply key: aes256-cts/E5C4
>[16101] 1417810641.456422: TGS reply is for admin at IPA5.TEST -> host/master.f21.test at F21.TEST with session key aes256-cts/5D01
>[16101] 1417810641.456456: TGS request result: 0/Success
>[16101] 1417810641.456479: Received creds for desired service host/master.f21.test at F21.TEST
>[16101] 1417810641.456522: Removing admin at IPA5.TEST -> host/master.f21.test at F21.TEST from KEYRING:persistent:0:0
>[16101] 1417810641.456564: Storing admin at IPA5.TEST -> host/master.f21.test at F21.TEST in KEYRING:persistent:0:0
>host/master.f21.test at F21.TEST: kvno = 2
>
>[root at ipa-05-m ~]# klist -edf
>Ticket cache: KEYRING:persistent:0:0
>Default principal: admin at IPA5.TEST
>
>Valid starting       Expires              Service principal
>05.12.2014 22:17:10  06.12.2014 22:17:10  host/master.f21.test at F21.TEST
>	Flags: FAT, Etype (skey, tkt): aes256-cts-hmac-sha1-96, 
>aes256-cts-hmac-sha1-96 05.12.2014 22:17:21  06.12.2014 22:17:14  
>krbtgt/F21.TEST at IPA5.TEST
>	Flags: FAT, Etype (skey, tkt): aes256-cts-hmac-sha1-96, 
>aes256-cts-hmac-sha1-96 05.12.2014 22:17:17  06.12.2014 22:17:14  
>krbtgt/IPA5.TEST at IPA5.TEST
>	Flags: FIA, Etype (skey, tkt): aes256-cts-hmac-sha1-96, 
>aes256-cts-hmac-sha1-96
>
>Of course, the fact that Kerberos tickets can get issued doesn't mean
>that user can login and gain certain privileges. After all, SSSDs on IPA
>hosts will not be able to map these Kerberos principals to anything
>locally unless you would explicitly instruct libkrb5 via /etc/krb5.conf
>on each IPA host.
Patch attached.
-- 
/ Alexander Bokovoy
-------------- next part --------------
From d7d73e1e34aaa8c7042c332d09853a96955f6635 Mon Sep 17 00:00:00 2001
From: Alexander Bokovoy <abokovoy at redhat.com>
Date: Fri, 5 Dec 2014 21:22:23 +0200
Subject: [PATCH] WIP: ipa-kdb: when processing transitions, hand over unknown
 ones to KDC

When processing cross-realm trust transitions, let the KDC to handle
those we don't know about. Admins might define the transitions as
explicit [capaths] in krb5.conf.

This is work-in-progress fix for
https://fedorahosted.org/freeipa/ticket/4791
---
 daemons/ipa-kdb/ipa_kdb_mspac.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c
index a73a3cb..39fa583 100644
--- a/daemons/ipa-kdb/ipa_kdb_mspac.c
+++ b/daemons/ipa-kdb/ipa_kdb_mspac.c
@@ -2680,7 +2680,8 @@ krb5_error_code ipadb_check_transited_realms(krb5_context kcontext,
 		}
 	}
 
-	ret = KRB5KRB_AP_ERR_ILL_CR_TKT;
+	/* Tell to KDC that we don't handle this transition so that rules in krb5.conf could play its role */
+	ret = KRB5_PLUGIN_NO_HANDLE;
 	if (has_client_realm && has_transited_contents && has_server_realm) {
 		ret = 0;
 	}
-- 
2.1.0

