Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1533803

Summary: Seeing "ipa: ERROR: an internal error has occurred" during ipa trust-add command
Product: Red Hat Enterprise Linux 7 Reporter: Varun Mylaraiah <mvarun>
Component: ipaAssignee: IPA Maintainers <ipa-maint>
Status: CLOSED NOTABUG QA Contact: ipa-qe <ipa-qe>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.5CC: abokovoy, amarecek, mvarun, pasik, pvoborni, rcritten, tscherf
Target Milestone: rcKeywords: Regression
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-01-17 07:10:44 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:
Attachments:
Description Flags
httpd_error_log none

Description Varun Mylaraiah 2018-01-12 09:35:21 UTC
Created attachment 1380359 [details]
httpd_error_log

Description of problem:
ipa trust-add command is failing after adding dns record. 

Version-Release number of selected component (if applicable):
ipa-server-4.5.4-8.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Install IPA server.
2. Establish trust 
3. Add dnszone for xyz.test domain
4. create a _kerberos TXT record for xyz.test domain
5. modify realmdomain (ipa realmdomains-mod --add-domain xyz.test)
6. Try to re-establish trust


[root@auto-hv-02-guest06 ~]# echo Secret123 | ipa trust-add ipaad2016.test --admin Administrator --password
-----------------------------------------------
Re-established trust to domain "ipaad2016.test"
-----------------------------------------------
  Realm name: ipaad2016.test
  Domain NetBIOS name: IPAAD2016
  Domain Security Identifier: S-1-5-21-813110839-3732285123-1597101681
  Trust direction: Trusting forest
  Trust type: Active Directory domain
  Trust status: Established and verified
  
  
[root@auto-hv-02-guest06 ~]# ipa dnszone-show freeipa.test
  Zone name: freeipa.test.
  Active zone: TRUE
  Authoritative nameserver: auto-hv-02-guest06.realm120118.test.
  Administrator e-mail address: hostmaster
  SOA serial: 1515741245
  SOA refresh: 3600
  SOA retry: 900
  SOA expire: 1209600
  SOA minimum: 3600
  Allow query: any;
  Allow transfer: none;
  
[root@auto-hv-02-guest06 ~]# ipa realmdomains-mod --add-domain freeipa.test
ipa: ERROR: invalid 'domain': The realm of the following domains could not be detected: freeipa.test. If these are domains that belong to the this realm, please create a _kerberos TXT record containing "REALM120118.TEST" in each of them.

[root@auto-hv-02-guest06 ~]# ipa dnsrecord-add freeipa.test _kerberos --txt-data=REALM120118.TEST 
  Record name: _kerberos
  TXT record: REALM120118.TEST
  
[root@auto-hv-02-guest06 ~]# ipa realmdomains-mod --add-domain freeipa.test
ipa: WARNING: The _kerberos TXT record from domain freeipa.test could not be created (no modifications to be performed).
This can happen if the zone is not managed by IPA. Please create the record manually, containing the following value: 'REALM120118.TEST'
  Domain: realm120118.test, freeipa.test
  
[root@auto-hv-02-guest06 ~]# ipa realmdomains-show
  Domain: realm120118.test, freeipa.test
  
[root@auto-hv-02-guest06 ~]# echo Secret123 | ipa trust-add ipaad2016.test --admin Administrator --password
ipa: ERROR: an internal error has occurred


[root@auto-hv-02-guest06 ~]#  ipa realmdomains-mod --del-domain freeipa.test
  Domain: realm120118.test
[root@auto-hv-02-guest06 ~]# systemctl stop sssd; rm -f /var/lib/sss/{db,mc}/*; systemctl start sssd
[root@auto-hv-02-guest06 ~]# 
[root@auto-hv-02-guest06 ~]# 
[root@auto-hv-02-guest06 ~]# echo Secret123 | ipa trust-add ipaad2016.test --admin Administrator --password
-----------------------------------------------
Re-established trust to domain "ipaad2016.test"
-----------------------------------------------
  Realm name: ipaad2016.test
  Domain NetBIOS name: IPAAD2016
  Domain Security Identifier: S-1-5-21-813110839-3732285123-1597101681
  Trust direction: Trusting forest
  Trust type: Active Directory domain
  Trust status: Established and verified



Actual results:
getting ipa: ERROR: an internal error has occurred

Expected results:
Trust should re-established 

Additional info:
Attached httpd_error_log

Comment 3 Alexander Bokovoy 2018-01-15 15:29:45 UTC
Looking at the error_log, I can see we get a collision with some other forest this AD forest trusts. 'vuser2017.test' is reported as being in conflict by its name with whatever we reported to AD as belonging to us (we haven't reported any vuser2017.test namespace at all). When trying to correct this conflict, we get another error. 

     lsa_lsaRSetForestTrustInformation: struct lsa_lsaRSetForestTrustInformation
        out: struct lsa_lsaRSetForestTrustInformation
            collision_info           : *
                collision_info           : *
                    collision_info: struct lsa_ForestTrustCollisionInfo
                        count                    : 0x00000001 (1)
                        entries                  : *
                            entries: ARRAY(1)
                                entries                  : *
                                    entries: struct lsa_ForestTrustCollisionRecord
                                        index                    : 0x00000001 (1)
                                        type                     : LSA_FOREST_TRUST_COLLISION_TDO (0)
                                        flags                    : 0x00000004 (4)
                                               0: LSA_TLN_DISABLED_NEW     
                                               0: LSA_TLN_DISABLED_ADMIN   
                                               1: LSA_TLN_DISABLED_CONFLICT
                                               0: LSA_SID_DISABLED_ADMIN   
                                               0: LSA_SID_DISABLED_CONFLICT
                                               1: LSA_NB_DISABLED_ADMIN    
                                               0: LSA_NB_DISABLED_CONFLICT 
                                        name: struct lsa_String
                                            length                   : 0x001c (28)
                                            size                     : 0x001e (30)
                                            string                   : *
                                                string                   : 'vuser2017.test'
            result                   : NT_STATUS_OK

Looks like vuser2017.test claims some of our TLNs on its own side but we don't know which one. In addition, one of NetBIOS namespaces claimed by vuser2017.test is disabled by the AD's administrator.

I think we have couple issues here but to look at what to solve, I need additional data: what is the topology of vuser2017.test? use nltest on Windows side.

Comment 4 Rob Crittenden 2018-01-15 18:59:23 UTC
Upstream ticket:
https://pagure.io/freeipa/issue/7370

Comment 5 Varun Mylaraiah 2018-01-17 07:10:44 UTC
Not able to reproduce anymore, After cleanup domains from "Active Directory Domain and Trust"