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.

--
/ Alexander Bokovoy

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

Reply via email to