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

[Martin Basti]

On 10/08/2015 01:18 PM, Sumit Bose wrote:
> 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 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.
>>>
>> Summit, Alexander, is this patch ACKed or not?
> yes, ACK, I'll file the tickets mentioned above.
>
> bye,
> Sumit
>
>> Martin
Pushed to:
master: 766438aba018037cffadadaf11eb92024be4fe01
ipa-4-2: 47a8d4fdf177cf6f4a061cdd24f66ac8153b3fcb