[Freeipa-users] Cross-Realm authentification

Fri Dec 5 21:24:25 UTC 2014

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

-- 
Petr^2 Spacek