#6077 [RFE] Support One-Way Trust authenticated by trust secret
Closed: fixed by cheimes. Opened by pvoborni.

Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 7): Bug 1345975

Description of problem:
Access Denied error when created a one-way trust using a trust-secret and
attempting to validate on the Active Directory side (last step of trust
procedure).
Version-Release number of selected component (if applicable):
ipa-server-trust-ad-4.2.0-15.el7_2.15.x86_64
ipa-python-4.2.0-15.el7_2.15.x86_64
ipa-admintools-4.2.0-15.el7_2.15.x86_64
ipa-server-4.2.0-15.el7_2.15.x86_64
ipa-client-4.2.0-15.el7_2.15.x86_64
Red Hat Enterprise Linux Server release 7.2 (Maipo)
How reproducible:
Very
Steps to Reproduce:
1.The documentation advises to create the trust on the windows side with these
steps:
   The Trust Type is Forest trust.
   The Direction of Trust is One-way.
   The Sides of Trust is This domain only.
   The Outgoing Trust Authentication Level is Forest-wide authentication.(not
this option does not exist on a one-way trust as noted in the document)
   Set the Trust Password.
2. ipa trust-add --type=ad --trust-secret domain.test
3. ipa trust-fetch-domains
4. Domain Controller-> Trust Console -> trust-> properties-> "name suffix
routing"-> Refresh
5. prompted for credentials (Not expected),
6. credentials for IPA domain do not work
7. Eventually errors out with "Access Denied"
Expected results:
4. Domain Controller-> Trust Console -> trust-> properties-> "name suffix
routing"-> Refresh
5. "Name Suffix Routing" being populated
6. Trust setup-complete
Additional info:
When I select a *two-way* trust on the Active Directory side, I was able to
achieve the trust including the "Name Suffix Routing" being populated when I
hit refresh. As expected this worked without any prompt for credentials.
However the noted procedure does not work for a one-way trust using a
trust-secret. I have additional information from Alexander who was assisting
debug this issue:
"The following was found in the samba logs:
[2016/06/13 08:06:44.098299,  3, pid=31436, effective(1817800000, 1817800000),
real(1817800000, 0), class=rpc_srv]
../source3/rpc_server/srv_pipe.c:1450(api_rpcTNP)
api_rpcTNP: rpc command: NETR_DSRGETFORESTTRUSTINFORMATION
[2016/06/13 08:06:44.098304,  6, pid=31436, effective(1817800000, 1817800000),
real(1817800000, 0), class=rpc_srv]
../source3/rpc_server/srv_pipe.c:1469(api_rpcTNP)
api_rpc_cmds[43].fn == 0x7f90496d38d0
[2016/06/13 08:06:44.098318,  1, pid=31436, effective(1817800000, 1817800000),
real(1817800000, 0)] ../librpc/ndr/ndr.c:439(ndr_print_function_debug)
      netr_DsRGetForestTrustInformation: struct
netr_DsRGetForestTrustInformation
         in: struct netr_DsRGetForestTrustInformation
             server_name              : *
                 server_name              : '\\f24-master.ipa.ad.test'
             trusted_domain_name      : NULL
             flags                    : 0x00000000 (0)
[2016/06/13 08:06:44.098334,  4, pid=31436, effective(1817800000, 1817800000),
real(1817800000, 0), class=rpc_srv]
../source3/rpc_server/srv_pipe.c:1480(api_rpcTNP)
api_rpcTNP: fault(5) return.
The fault(5) is librpc/idl/dcerpc.idl:          DCERPC_FAULT_ACCESS_DENIED =
0x00000005,
something is missing in the access token when IPA admin credentials are used to
connect to retrieve forest trust information from AD side "

This one cannot currently be fixed. We have fundamental issue with it as
it looks like we are unable to trick AD into validation with one-way
shared secret from our side but we cannot tell people to do validation
from AD side because it does not work due to some SASL incompatibilities
between CyrusSASL and AD client code.

Is there a workaround that can/needs to be documented?

A workaround is to use administrator credentials to establish one-way trust. We also would generate cryptographically strong trust secret in this case. Another workaround is to use two-way trust, which would work fine with a manually specified trust secret.

(#5683) was closed as a duplicate of this bug.

Metadata Update from @pvoborni:
- Issue assigned to abbra
- Issue set to the milestone: FreeIPA 4.5 backlog

As noted in https://bugzilla.redhat.com/show_bug.cgi?id=1345975#c11, this is actually a full RFE, title should be changed to "[RFE] Support One-Way Trust authenticated by trust secret"

Metadata Update from @mkosek:
- Issue close_status updated to: None

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

master:

  • 2a8176ee03318f208a86d25bd9320f885b16d112 Add design page for one-way trust to AD with shared secret
  • 120bab0d9c9970979d109583329a13fc3e4949f3 trust: allow trust agents to read POSIX identities of trust
  • dc8f074cc7ba647644b96785590f1645e5661a93 trusts: add support for one-way shared secret trust
  • 18cb30d4638c0fecf5f02735f2b4794be5d97b67 upgrade: upgrade existing trust agreements to new layout
  • dca901c05ef6dde69145963d3ea51b994b568740 upgrade: add trust upgrade to actual upgrade code

ipa-4-6:

  • 9a453619c8c46322fc652f57376e4e834f957f57 Replace hard-coded paths with path constants
  • 076d89429d838b472782f20da483841847e435b5 Support Samba 4.9
  • b70e4d19d8bb610fedc50c8ad17cb7b61229247f Add design page for one-way trust to AD with shared secret
  • 7a7ef33fa8d1e800467e7bda5e23170edbabb4a2 trust: allow trust agents to read POSIX identities of trust
  • b2bac94c2486523f180a16068c5c07df8169aa1f trusts: add support for one-way shared secret trust
  • 7476953c85eddd92e7a2f010a34a3ba421c91965 upgrade: upgrade existing trust agreements to new layout
  • 9ce3a29915fa691369fff8401b5995e0f7f06e06 upgrade: add trust upgrade to actual upgrade code

ipa-4-7:

  • 50c0d6dc7b93abe2448ecc499e32e11bf5e3e7f5 Add design page for one-way trust to AD with shared secret
  • f6183c80826c90a8b0c051284d66cb0a2378cdc1 trust: allow trust agents to read POSIX identities of trust
  • 0b5ae1bd00c336c1963efdb28891780fb61af17e trusts: add support for one-way shared secret trust
  • 2a7731c5ae8d3f7fad9ee20584e271100d090557 upgrade: upgrade existing trust agreements to new layout
  • 595f42af25f882fe5d45b0e08bdd5300d7267fdb upgrade: add trust upgrade to actual upgrade code

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

master:

  • 3f02fc945e6306e8fb656db680d5a553683fabc4 ipatests: new tests for establishing one-way AD trust with shared secret

ipa-4-6:

  • 2a773cb8eae7502b4db2d4ee5ae94fdee55b0093 ipatests: new tests for establishing one-way AD trust with shared secret

ipa-4-7:

  • ac7b1b1027a249b6f136d18ec69881d94dfe77e3 ipatests: new tests for establishing one-way AD trust with shared secret
Metadata