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:
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
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
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
Fedora and RHEL versions.
With the version in my abbra/krb5-test COPR you can test the patch
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
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
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
Yes, please add a separate ticket. We need to do a bit more here:
- extend schema to allow adding the attribute for alternative domain
- 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
- 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
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.
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code