Bug 1421869
| Summary: | Unable to re-add broken AD trust - Unexpected Information received | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Geoff Gatward <ggatward> | ||||||||||||||
| Component: | ipa | Assignee: | IPA Maintainers <ipa-maint> | ||||||||||||||
| Status: | CLOSED ERRATA | QA Contact: | Kaleem <ksiddiqu> | ||||||||||||||
| Severity: | low | Docs Contact: | |||||||||||||||
| Priority: | unspecified | ||||||||||||||||
| Version: | 7.3 | CC: | abokovoy, fhanzelk, gkaihoro, orion, pasik, pvoborni, rcritten, ricardo.arguello, rmahique | ||||||||||||||
| Target Milestone: | rc | ||||||||||||||||
| Target Release: | --- | ||||||||||||||||
| Hardware: | x86_64 | ||||||||||||||||
| OS: | Linux | ||||||||||||||||
| Whiteboard: | |||||||||||||||||
| Fixed In Version: | ipa-4.5.4-7.el7 | Doc Type: | If docs needed, set a value | ||||||||||||||
| Doc Text: | Story Points: | --- | |||||||||||||||
| Clone Of: | Environment: | ||||||||||||||||
| Last Closed: | 2018-04-10 16:40:25 UTC | Type: | Bug | ||||||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||||||
| Documentation: | --- | CRM: | |||||||||||||||
| Verified Versions: | Category: | --- | |||||||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||||
| Embargoed: | |||||||||||||||||
| Bug Depends On: | |||||||||||||||||
| Bug Blocks: | 1627814 | ||||||||||||||||
| Attachments: |
|
||||||||||||||||
Created attachment 1250037 [details]
Samba log
Upstream ticket: https://fedorahosted.org/freeipa/ticket/6666 Created attachment 1250170 [details]
proposed patch
Geoff, could you please try this patch against your system?
1. Download the patch, say, fix.patch
2. cd /usr/lib/python2.7/site-packages/
3. patch -p1 <fix.patch
4. restart httpd, systemctl restart httpd
5. Re-establish trust.
Unfortunately that didn't do the trick... [root@auth1 site-packages]# patch -p1 < /tmp/fix.patch patching file ipaserver/dcerpc.py [root@auth1 site-packages]# systemctl restart httpd [root@auth1 site-packages]# kinit admin Password for admin.ORG: [root@auth1 site-packages]# ipa trust-show ad.home.gatwards.org ipa: ERROR: ad.home.gatwards.org: trust not found [root@auth1 site-packages]# ipa trust-add --type=ad ad.home.gatwards.org --admin Administrator --two-way=true Active Directory domain administrator's password: ipa: ERROR: an internal error has occurred Created attachment 1250328 [details]
error_log after applying patch
Thanks, this is what I worried. It seems we hit following error condition from MS-LSAD "3.1.4.7.16.1 Forest Trust Collision Generation" section: ----- * A top-level name must not be superior to an enabled top-level name for another trusted domain object, unless the current trusted domain object has a corresponding exclusion record. ------ However, I'm puzzled why we get NT_STATUS_INVALID_PARAMETER rather than collision information. For a second test, could you please try the following? Just copy attached dcerpc.py over the one in /usr/lib/python2.7/site-packages/ipaserver/. It changes ordering of the exclusion entry we send -- first we would send exclusion entry and then actual TLN for us, in case the order makes difference for Windows Server. I expect this will not be working either, but before I move to a heavier fix, it is worth trying to re-order entries first. Created attachment 1250341 [details]
updated dcerpc.py
Updated dcerpc.py, just overwrite the old one.
Tested with the update dcerpc.py - still fails as you suspected. Attaching log. So the issue is that the IPA domain was created first and then the AD domain was an add-on in this environment and AD does not like to be a subdomain of the IPA domain? I guess in most enterprise environments IPA will be an add-on to existing AD domains which explains why this hasn't been an issue before... Created attachment 1250784 [details]
error log after latest dcerpc.py change
Yes, this seems to be the case. Ok, looks like a fix will be more involved. Geoff, I submitted a proposed fix as https://github.com/freeipa/freeipa/pull/1179. This fix filters out subdomains of our primary forest root domain because those would already be covered by *.<forest root> top level name in the topology we send to AD. master:
443ecbc adtrust: filter out subdomains when defining our topology to AD
ipa-4-5:
704cf5d adtrust: filter out subdomains when defining our topology to AD
ipa-4-6:
1490e9c adtrust: filter out subdomains when defining our topology to AD
Following conversation in irc the issue that is fixed in the patch is following: We have 'ipa realmdomains' where we record DNS domains that belong to our realm. When we add a DNS subdomain, we add it to realmdomains too. So when trust is established, we tell AD DCs that these subdomains belong to our realm so that AD knows who is responsible for Kerberos authentication for machines in those DNS subdomains. So if we have ipa.example.com and then add DNS domain ipa2.example.com, AD knows they both are part of IPA.EXAMPLE.COM realm. We add these DNS subdomains also when we create sub.ipa.example.com. From AD perspective sub.ipa.example.com is already covered by ipa.example.com Kerberos route so it causes an error. According to that steps for verification are: 1. Install ipa.example.com 2. Add DNS zone ipa2.example.com 3. Create a host machine.ipa2.example.com 4. Create DNS zone ipa3.ipa.example.com 5. Create a host machine.ipa3.ipa.example.com 6. Add a trust to AD forest 7. Check as AD users, kinit user, kvno -S host machine.ipa2.example.com Expected result: it should give ticket to host/machine.ipa2.example.com.COM 8. Check as AD users, kinit user, kvno -S host machine.ipa3.ipa.example.com Expected result:it should give ticket to host/machine.ipa3.ipa.example.com.COM Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:0918 |
Created attachment 1250036 [details] httpd error_log I am having a problem with my lab setup (replicates a customer env) in that I seem to have a problem with the trust established to the AD servers. This was previously set up as a two-way trust on ipa 4.3 and was working - I cannot pinpoint exactly when it broke, but now running ipa 4.4 (AD is 2012r2) Problem manifests itself in that users in the AD can no longer authenticate to IdM resources. [root@auth1 ~]# ipa trust-show ad.home.gatwards.org Realm name: ad.home.gatwards.org Domain NetBIOS name: AD Domain Security Identifier: S-1-5-21-2491084655-2534020579-1020697545 Trust direction: Two-way trust Trust type: Active Directory domain On the AD side, nltest /domain_trusts /v shows a Direct Inbound trust for my IdM realm However I am unable to list the trusted domains: [root@auth1 ~]# ipa trust-fetch-domains ad.home.gatwards.org ipa: ERROR: AD domain controller complains about communication sequence. It may mean unsynchronized time on both sides, for example And trying to re-add (refresh) the trust throws internal error: [root@auth1 ~]# ipa trust-add --type ad --two-way true ad.home.gatwards.org --admin Administrator Active Directory domain administrator's password: ipa: ERROR: an internal error has occurred As discussed with Alexander Bokovoy, I removed the trusts from the AD side (mmc snap-in) and tried again with the same result, catching debug logs of the issue.