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 -- 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