[Freeipa-users] Cross-Realm authentification

Wed Feb 18 10:53:07 UTC 2015

On 5.12.2014 22:24, Petr Spacek wrote:
> On 5.12.2014 21:53, Alexander Bokovoy wrote:
>> 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.
> 
> For build instructions please see
> http://www.freeipa.org/page/Build

For the record/Google:

Following fix was commited to ipa-4-1 branch and should be included in FreeIPA
4.1.3 release so should be able to use the released version for experiments.

commit 0d3b4cd3ec1caa209534314bfa5720f0f8bce89f
Author: Alexander Bokovoy <abokovoy at redhat.com>
Date:   Fri Dec 5 21:22:23 2014 +0200

    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.

    https://fedorahosted.org/freeipa/ticket/4791

    Reviewed-By: Sumit Bose <sbose at redhat.com>
    Reviewed-By: Simo Sorce <ssorce at redhat.com>

-- 
Petr^2 Spacek