[Freeipa-devel] [PATCH] 0197 client referral support for trusted domain principal

[Alexander Bokovoy]

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