#7895 ipa trust fetch-domains, server parameter ignored
Closed: fixed by tdudlak. Opened by abbra.

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:

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


Metadata Update from @abbra:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1686302

Metadata Update from @abbra:
- Issue assigned to abbra
- Issue set to the milestone: FreeIPA 4.6

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.

Pull request: https://github.com/freeipa/freeipa/pull/2965

master:

  • de4a9875d410c68ae4f9602b70c753a11034b31b oddjob: allow to pass options to trust-fetch-domains

Failed to apply patches onto origin/ipa-4-6. Manual backport is needed.

ipa-4-7:

  • 12bc3fd16370788edbf1b66e9aa08fd307cf9e7f oddjob: allow to pass options to trust-fetch-domains

ipa-4-6:

  • 916d4f3cd0bf26e96f696903bd6fb19693437712 oddjob: allow to pass options to trust-fetch-domains

Metadata Update from @tdudlak:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

master:

  • 6c9fcccfbcbb78b49b65c12bf05b2647f1522609 trust-fetch-domains: make sure we use right KDC when --server is specified

ipa-4-6:

  • 076cb69f00db734a378a74f50f5b4b74321c0fa4 trust-fetch-domains: make sure we use right KDC when --server is specified

ipa-4-7:

  • 2dcf15b990e374cf616e1a55c112fe34779006cf trust-fetch-domains: make sure we use right KDC when --server is specified

master:

  • 843f57abe431bcf493e0bcce8ef07255be986435 ipatests: new test for trust with partially unreachable AD topology

ipa-4-6:

  • e0da5f7ecec12dcf3e4db721a63ab6ac1485b021 ipatests: new test for trust with partially unreachable AD topology

ipa-4-7:

  • 0ae30092e7f64b1f5814d82c722a5fa747ff46f7 ipatests: new test for trust with partially unreachable AD topology

ipa-4-8:

  • 14407bb904c2015d0ec7dbe45e95590aad981eda ipatests: new test for trust with partially unreachable AD topology

ipa-4-6:

  • 795a973c00c2fe862b1eff8bd851d8eafe9d970a ipatests: provide AD admin password when trying to establish trust

master:

  • aae30eb708b04c54807bc226b93ca14e09561b87 ipatests: provide AD admin password when trying to establish trust

ipa-4-8:

  • 814b47e85c87bc3c80c91ebd0aa9085ac06b521e ipatests: provide AD admin password when trying to establish trust

ipa-4-7:

  • db1b9fc428d8932f4fa9da79501ff2be8e4e7cc2 ipatests: provide AD admin password when trying to establish trust
Metadata