On Wed, 17 Aug 2016, Martin Babinsky wrote:
On 08/08/2016 01:27 PM, Alexander Bokovoy wrote:
Attached two patches attempt to fix some of the issues we see with child
SSSD only 'sees' users from child domains if there is an ID range for
each of them. However, after refactoring of trust code when external
trust was introduced, part of the range creation had wrong assumption
that if a trusted domain exists, its range also exists. This is now
fixed to try to create range even if the domain exists. In fact, because
the older code was not going to the range creation for trusted domains
which already existed, adding ranges was done incorrectly: ID ranges use
full domain name and don't need <parent>-<child> hierarchy, but the code
was passing both parent and the child names. As result, an attempt to
create an ID range for parent was done instead of the child. Parent ID
range already existed so we never got to create child ID ranges at all
in that case.
Finally, there is a fix in SSSD to properly generate CA paths so that
libkrb5 can calculate correct trust path via forest root (parent)
domain. While looking at that, I also decided to simplify logic in
ipa-kdb driver because for cross-forest trust we never can transit to
the child domain directly, we always have to use the forest root domain.
However, old code could actually set a immediate domain's parent instead
of the forest root for deep level trust relationship within the forest
we trust. As we still cannot get to second level or beyond directly or
via their actual parent domain, we always have to go through the forest
root domain. The simplified code enforces this logic.
ACK, but patch 215 needs rebase for ipa-4-3 and ipa-4-2.
Rebased version attached.
/ Alexander Bokovoy
From 62f3af93ca780921355d8ed17ab6d9c42e452cb3 Mon Sep 17 00:00:00 2001
From: Alexander Bokovoy <aboko...@redhat.com>
Date: Sat, 6 Aug 2016 11:12:13 +0300
Subject: [PATCH 1/3] trust: make sure ID range is created for the child domain
even if it exists
ID ranges for child domains of a forest trust were created incorrectly
in FreeIPA 4.4.0 due to refactoring of -- if the domain was already
existing, we never attempted to create the ID range for it.
At the same time, when domain was missing, we attempted to add ID range
and passed both forest root and the child domain names to add_range().
However, add_range() only looks at the first positional argument which
was the forest root name. That ID range always exists (it is created
before child domains are processed).
Modify the code to make sure child domain name is passed as the first
positional argument. In addition, the oddjob helper should explicitly
set context='server' so that idrange code will be able to see and use
install/oddjob/com.redhat.idm.trust-fetch-domains | 2 +-
ipalib/plugins/trust.py | 13 +++++++++----
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/install/oddjob/com.redhat.idm.trust-fetch-domains
index 4c50c43..f5ec8d7 100755
@@ -75,7 +75,7 @@ env._bootstrap(context='server', debug=options.debug,
# Initialize the API with the proper debug level
-api.bootstrap(context='server', debug=env.debug, log=None)
+api.bootstrap(in_server=True, debug=env.debug, log=None, context='server')
# Only import trust plugin after api is initialized or internal imports
diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py
index 8672669..c2e5745 100644
@@ -1592,14 +1592,19 @@ def add_new_domains_from_trust(myapi, trustinstance,
trust_entry, domains, **opt
if 'raw' in options:
dom['raw'] = options['raw']
- res = myapi.Command.trustdomain_add(trust_name, name, **dom)
+ res = myapi.Command.trustdomain_add(trust_name, name, **dom)
+ except errors.DuplicateEntry:
+ # Ignore updating duplicate entries
if idrange_type != u'ipa-ad-trust-posix':
range_name = name.upper() + '_id_range'
dom['range_type'] = u'ipa-ad-trust'
- add_range(myapi, trustinstance, range_name,
- trust_name, name, **dom)
+ add_range(myapi, trustinstance,
+ range_name, dom['ipanttrusteddomainsid'],
+ name, **dom)
# Ignore updating duplicate entries
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code