Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1686302 - ipa trust fetch-domains, server parameter ignored
Summary: ipa trust fetch-domains, server parameter ignored
Keywords:
Status: ON_QA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ipa
Version: 7.6
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: IPA Maintainers
QA Contact: ipa-qe
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-03-07 08:30 UTC by Luc de Louw
Modified: 2019-04-04 15:38 UTC (History)
8 users (show)

Fixed In Version: ipa-4.6.5-4.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Fedora Pagure freeipa/issue/7895 None None None 2019-03-31 08:17:45 UTC

Description Luc de Louw 2019-03-07 08:30:01 UTC
Description of problem:

In most Active directory environments, not all servers are reachable on every physical site/location.

The _ldap and _kerberos (and other) SRV DNS records are always presented for all AD servers. That means, if trying to establish a cross domain trust or more specifically fetching the domains after the trust is established, the --server parameter is to be used to communicate with a specific server. 

While the ipa trust-add --server=ad.example.com respects the --server parameter, ipa trust fetch-domains does not. The later is automatically done by ipa trust-add. 

At the end, the trust is established but not working.


Version-Release number of selected component (if applicable):
4.6

How reproducible:
Always

Steps to Reproduce:
1. ipa trust-add --server ad.example.com AD.EXAMPLE.COM

ipa: ERROR: error on server 'ipaserver.example.com': Fetching domains from trusted forest failed. See details in the error_log


Actual results:
ipa: ERROR: error on server 'ipaserver.example.com': Fetching domains from trusted forest failed. See details in the error_log

Expected results:

Added Active Directory trust for realm "ad.example.com"
-------------------------------------------------
Realm name: ad.example.com
Domain NetBIOS name: AD-EXAMPLE-COM
Domain Security Identifier: S-1-5-21-ZZZZZZZZZ-YYYYYYYY-XXXXXXXXX
SID blacklist incoming: 
 [..snip..]
Trust direction: One-way trust
Trust type: Active Directory domain
Trust status: Established and verified


Additional info:

In Environments where only a few AD servers are not available for IPA, just try multiple times until you hit a server which is reachable. Not a nice workaround, its rather boring

Comment 2 Alexander Bokovoy 2019-03-07 09:15:36 UTC
Looks relatively easy to fix by extending https://pagure.io/freeipa/blob/master/f/install/oddjob/etc/oddjobd.conf.d/oddjobd-ipa-trust.conf to pass more than one argument to the helper. Oddjobd itself treats anything passed to the helper on the command line as arguments up to the specified value. So if we add --server name option that would be two arguments in addition to the forest name. I think it makes sense to just set arguments number high enough (10-20) to allow future option extensibility.

Then we can change IPA helper https://pagure.io/freeipa/blob/master/f/install/oddjob/com.redhat.idm.trust-fetch-domains.in (it has hardcoded 1 argument) and IPA callers to pass the options.

IPA callers: 
 - dbus helper is https://pagure.io/freeipa/blob/master/f/ipaserver/plugins/trust.py#_421 (only accepts one argument for the forest name)
 - actual call from trust_add.execute() is https://pagure.io/freeipa/blob/master/f/ipaserver/plugins/trust.py#_776
 - actual call from trust_fetch_domains.execute() is https://pagure.io/freeipa/blob/master/f/ipaserver/plugins/trust.py#_1782

Also, passing existing discovered server should be preferred too. If we established trust with a specific server, we most likely should be using that for the helper runs as well because it would allow us to avoid possible replication delays on AD side and do not run discovery of AD DCs again and again.

Comment 3 Alexander Bokovoy 2019-03-31 08:16:23 UTC
Clonet to upstream: https://pagure.io/freeipa/issue/7895

Comment 4 Alexander Bokovoy 2019-03-31 08:16:42 UTC
Pull request: https://github.com/freeipa/freeipa/pull/2965

Comment 5 Christian Heimes 2019-04-01 11:28:35 UTC
Fixed upstream
master:
https://pagure.io/freeipa/c/de4a9875d410c68ae4f9602b70c753a11034b31b

Comment 6 Christian Heimes 2019-04-01 13:54:26 UTC
Fixed upstream
ipa-4-7:
https://pagure.io/freeipa/c/12bc3fd16370788edbf1b66e9aa08fd307cf9e7f

Comment 7 Tibor Dudlák 2019-04-02 10:09:10 UTC
Fixed upstream
ipa-4-6:
https://pagure.io/freeipa/c/916d4f3cd0bf26e96f696903bd6fb19693437712


Note You need to log in before you can comment on or make changes to this bug.