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@ipa-05-m ~]# kinit admin >>> Password for ad...@ipa5.test: [root@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.t...@f21.test >>> [16101] 1417810641.449750: Getting credentials ad...@ipa5.test -> >>> host/master.f21.t...@f21.test using ccache KEYRING:persistent:0:0 >>> [16101] 1417810641.449888: Retrieving ad...@ipa5.test -> >>> host/master.f21.t...@f21.test from KEYRING:persistent:0:0 with result: >>> -1765328243/Matching credential not found >>> [16101] 1417810641.449946: Retrieving ad...@ipa5.test -> >>> krbtgt/f21.t...@ipa5.test from KEYRING:persistent:0:0 with result: >>> -1765328243/Matching credential not found >>> [16101] 1417810641.450065: Retrieving ad...@ipa5.test -> >>> krbtgt/ipa5.t...@ipa5.test from KEYRING:persistent:0:0 with result: >>> 0/Success >>> [16101] 1417810641.450095: Starting with TGT for client realm: >>> ad...@ipa5.test -> krbtgt/ipa5.t...@ipa5.test >>> [16101] 1417810641.450144: Retrieving ad...@ipa5.test -> >>> krbtgt/f21.t...@ipa5.test from KEYRING:persistent:0:0 with result: >>> -1765328243/Matching credential not found >>> [16101] 1417810641.450171: Requesting TGT krbtgt/f21.t...@ipa5.test using >>> TGT krbtgt/ipa5.t...@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 ad...@ipa5.test -> >>> krbtgt/f21.t...@ipa5.test with session key aes256-cts/2C28 >>> [16101] 1417810641.452453: TGS request result: 0/Success >>> [16101] 1417810641.452479: Removing ad...@ipa5.test -> >>> krbtgt/f21.t...@ipa5.test from KEYRING:persistent:0:0 >>> [16101] 1417810641.452509: Storing ad...@ipa5.test -> >>> krbtgt/f21.t...@ipa5.test in KEYRING:persistent:0:0 >>> [16101] 1417810641.452572: Received TGT for service realm: >>> krbtgt/f21.t...@ipa5.test >>> [16101] 1417810641.452600: Requesting tickets for >>> host/master.f21.t...@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 ad...@ipa5.test -> >>> host/master.f21.t...@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.t...@f21.test >>> [16101] 1417810641.456522: Removing ad...@ipa5.test -> >>> host/master.f21.t...@f21.test from KEYRING:persistent:0:0 >>> [16101] 1417810641.456564: Storing ad...@ipa5.test -> >>> host/master.f21.t...@f21.test in KEYRING:persistent:0:0 >>> host/master.f21.t...@f21.test: kvno = 2 >>> >>> [root@ipa-05-m ~]# klist -edf >>> Ticket cache: KEYRING:persistent:0:0 >>> Default principal: ad...@ipa5.test >>> >>> Valid starting Expires Service principal >>> 05.12.2014 22:17:10 06.12.2014 22:17:10 host/master.f21.t...@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.t...@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.t...@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 <aboko...@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 <sb...@redhat.com> Reviewed-By: Simo Sorce <sso...@redhat.com> -- Petr^2 Spacek -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project