On Thu, Oct 08, 2015 at 01:12:56PM +0200, Martin Basti wrote: > > > On 10/08/2015 12:36 PM, Alexander Bokovoy wrote: > >On Mon, 05 Oct 2015, Sumit Bose wrote: > >>On Thu, Sep 03, 2015 at 06:22:05PM +0300, Alexander Bokovoy wrote: > >>>On Thu, 03 Sep 2015, Alexander Bokovoy wrote: > >>>>Hi, > >>>> > >>>>attached patch adds support for issuing client referrals when FreeIPA > >>>>KDC is asked to give a TGT for a principal from a trusted forest. > >>>> > >>>>We return a matching forest name as a realm and KDC then returns an > >>>>error pointing a client to a direction of that realm. You can see how > >>>it > >>>>looks with http://fpaste.org/263064/14412849/ -- it shows behavior for > >>>>both 'kinit -E -C' and 'kinit -E'. > >>>> > >>>>Note that current MIT Kerberos KDC has a bug that prevents us from > >>>>responding with a correct client referral. A patched version for > >>>Fedora > >>>>22 is available in COPR abbra/krb5-test, a fix to upstream krb5 is > >>>>https://github.com/krb5/krb5/pull/323/ and I'm working on filing bugs > >>>to > >>>>Fedora and RHEL versions. > >>>> > >>>>With the version in my abbra/krb5-test COPR you can test the patch > >>>with > >>>>the help of kinit like fpaste URL above shows. > >>>After discussing with Simo and Sumit, here is updated patch that > >>>operates directly on 'search_for' krb5_principal and avoids > >>>strchr()/strrchr() and additional memory allocations -- it uses > >>>memrchr() to find '@' in the last component of the search_for principal > >>>and considers the part of the component after '@' as an enterprise > >>>realm > >>>to check. > >> > >>The patch looks good and works as advertised. I've tested in a IPA > >>domain which trusts two different forests. All requests to the forest > >>roots and child domains where properly redirected. I tested with your > >>krb5 test build and with MIT Kerberos 1.14 which contains the needed > >>fix. > >> > >>Nevertheless there are a view points I want to discuss: > >> > >>- missing support for AD's Alternative Domain Suffixes, this is > >> important to allow AD users to login in with their "Email-Address" > >> (which is the typical reference for a user name with an alternative > >> domain suffix). I think this is not strictly related to the given > >> ticket, so it can be solved in the context of a new ticket, do you > >> agree? > >Yes, please add a separate ticket. We need to do a bit more here: > >- extend schema to allow adding the attribute for alternative domain > > suffixes > >- switch to use different DCE RPC call to retrieve forest trust > > information. We can do it now that we have a call-out mechanism and > > can isolate access to TDO credentials (this is long standing issue > > first identified by Metze as part of cross-forest trust support for > > Samba 4.3) > >- Make possible to associate alternative domain suffixes with IPA > > realm. We have support for realm domains already but we don't allow > > to use them yet for the same call as in the above item. > > > >>- referrals from outside. If I call 'kinit -E admin@IPA.DOMAIN' from a > >> client in a trusted AD forest I get a 'Client not found in database' > >> error because AD tends to use lower case domain names in the referal > >> response. The request is still properly send to the IPA KDC because > >> DNS does not care about the case. The IPA KDC processes the request > >> with the principal 'user\@IPA.DOMAIN@ipa.domain' until > >> ipadb_is_princ_from_trusted_realm() returns KRB5_KDB_NOENTRY becasue > >> it detects that the principal is from the local realm. I think it > >> would be good to enhance your patch to handle this case. > >This is a separate bug too. Please file a ticket. > > > > > >>- S4U2Self. MIT Kerberos 1.14 can now properly handle S4U2Self across > >> domain and forest boundaries (I tested this in a setup with 2 AD > >> forests with request going from a child domain to a child domain in > >> the other forest. Unfortunately it is currently not working with IPA > >> in neither direction (I guess the case issue from above might be the > >> reason for the incoming request to fail). Here I think a new ticket > >> would to good as well because some research might be needed and the > >> issue might even be in the MIT code. (If you want to run some tests I > >> can give you access to my test environment.) > >I think we want to have this working, thus a ticket is due here. This is > >something we'll most likely require for some advanced 2FA operations for > >AD users. > > > >>Let me know if you prefer to handle the issues with other tickets, then > >>I would ACK the patch as it is. > >Please file separate tickets. > > > > Summit, Alexander, is this patch ACKed or not?
yes, ACK, I'll file the tickets mentioned above. bye, Sumit > > Martin -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code