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 1442233 - IPA client commands fail when pointing to replica
Summary: IPA client commands fail when pointing to replica
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ipa
Version: 7.4
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: IPA Maintainers
QA Contact: Abhijeet Kasurde
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-04-13 20:07 UTC by Scott Poore
Modified: 2017-08-01 09:48 UTC (History)
11 users (show)

Fixed In Version: ipa-4.5.0-15.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-08-01 09:48:56 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
var log from replica (864.11 KB, application/x-gzip)
2017-04-13 20:14 UTC, Scott Poore 		no flags Details
var log from master (1.11 MB, application/x-gzip)
2017-04-13 20:15 UTC, Scott Poore 		no flags Details
var log from client (421.74 KB, application/x-gzip)
2017-04-13 20:15 UTC, Scott Poore 		no flags Details
verification_console.log (17.99 KB, text/plain)
2017-06-09 04:41 UTC, Abhijeet Kasurde 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:2304 0 normal SHIPPED_LIVE ipa bug fix and enhancement update 2017-08-01 12:41:35 UTC

Description Scott Poore 2017-04-13 20:07:01 UTC 
Description of problem:

If an IPA client is pointing to a replica, ipa commands fail with the following error:

[root@vm3 ~]# ipa user-find
ipa: ERROR: Major (851968): Unspecified GSS failure.  Minor code may provide more information, Minor (2529638926): KDC has no support for encryption type


Version-Release number of selected component (if applicable):
ipa-client-4.5.0-6.el7.x86_64
ipa-server-4.5.0-6.el7.x86_64


How reproducible:
unknown.  seems consistent in my testing on local VMs.

Steps to Reproduce:
1.  Install IPA Master
2.  Install IPA Replica
3.  Install IPA Client
4.  redirect client to point to replica in /etc/ipa/default.conf
5.  ipa user-find

Actual results:

fails as shown above.

Expected results:

No failure expected.

Additional info:
Comment 2 Scott Poore 2017-04-13 20:14:10 UTC 
Also, I just noticed this:

[root@master ~]# klist -ke
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   2 host/master.testrelm.test (aes256-cts-hmac-sha1-96) 
   2 host/master.testrelm.test (aes128-cts-hmac-sha1-96) 
   2 host/master.testrelm.test (des3-cbc-sha1) 
   2 host/master.testrelm.test (arcfour-hmac) 
   2 host/master.testrelm.test (camellia128-cts-cmac) 
   2 host/master.testrelm.test (camellia256-cts-cmac) 


[root@replica ~]# klist -ke
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   1 host/replica.testrelm.test (aes256-cts-hmac-sha1-96) 
   1 host/replica.testrelm.test (aes128-cts-hmac-sha1-96) 


[root@client ~]# klist -ke
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   1 host/client.testrelm.test (aes256-cts-hmac-sha1-96) 
   1 host/client.testrelm.test (aes128-cts-hmac-sha1-96)
Comment 3 Scott Poore 2017-04-13 20:14:51 UTC 
Created attachment 1271540 [details]
var log from replica
Comment 4 Scott Poore 2017-04-13 20:15:16 UTC 
Created attachment 1271541 [details]
var log from master
Comment 5 Scott Poore 2017-04-13 20:15:40 UTC 
Created attachment 1271542 [details]
var log from client
Comment 6 Scott Poore 2017-04-26 18:28:39 UTC 
Ok, I'm marking this a regression after confirming this bug didn't seem to exist in RHEL7.3 versions. 

[root@vm-idm-011 ipa]# rpm -q ipa-client
ipa-client-4.4.0-14.el7_3.7.x86_64


[root@vm-idm-011 ipa]# ipa user-find
--------------
1 user matched
--------------
  User login: admin
  Last name: Administrator
  Home directory: /home/admin
  Login shell: /bin/bash
  Principal alias: admin
  UID: 396200000
  GID: 396200000
  Account disabled: False
----------------------------
Number of entries returned 1
----------------------------

Also note that I see the same keytypes in RHEL7.3 for master/replicas:

Master:

[root@vm-idm-012 ~]# klist -ke
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   2 host/vm-idm-012.testrelm.test (aes256-cts-hmac-sha1-96) 
   2 host/vm-idm-012.testrelm.test (aes128-cts-hmac-sha1-96) 
   2 host/vm-idm-012.testrelm.test (des3-cbc-sha1) 
   2 host/vm-idm-012.testrelm.test (arcfour-hmac) 
   2 host/vm-idm-012.testrelm.test (camellia128-cts-cmac) 
   2 host/vm-idm-012.testrelm.test (camellia256-cts-cmac) 


Replica:

[root@vm-idm-010 ~]# klist -ke
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   1 host/vm-idm-010.testrelm.test (aes256-cts-hmac-sha1-96) 
   1 host/vm-idm-010.testrelm.test (aes128-cts-hmac-sha1-96)
Comment 11 Petr Vobornik 2017-04-28 13:29:12 UTC 
Upstream ticket:
https://pagure.io/freeipa/issue/6867
Comment 17 Martin Babinsky 2017-05-10 11:48:09 UTC 
The reason this happens is that during replica install we actually add HTTP/ principal twice:

1.) once using local LDAP during "setting up httpd keytab" step, and then

2.) when requesting HTTP cert using certmonger: in this case the certmonger forwards the request to remote master. If the principal added locally in step 1 is not replicated back by the time this step happens, HTTP principal is added again on the remote master leading to conflicting entries when the replication finally catches up after installation.

We really need to ensure that there is only one place to add LDAP entries at all times, or we need to verify that the entries are being replicated back to the master before attempting any remote operations.
Comment 18 Martin Babinsky 2017-05-30 10:55:07 UTC 
the root cause of this issue was fixed upstream:

master:
https://pagure.io/freeipa/c/ab71cd5a1693c221950bdfa9ffdfb99b9c317004
ipa-4-5:
https://pagure.io/freeipa/c/9871bc08f8b8f51e2a05c4dfa18d844f9c141b8d
Comment 20 Abhijeet Kasurde 2017-06-09 04:40:31 UTC 
Verified using IPA version :: ipa-server-4.5.0-16.el7.x86_64

Marking BZ as verified. See attachment for console.log.
Comment 21 Abhijeet Kasurde 2017-06-09 04:41:11 UTC 
Created attachment 1286302 [details]
verification_console.log
Comment 22 errata-xmlrpc 2017-08-01 09:48:56 UTC 
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-2017:2304
Note You need to log in before you can comment on or make changes to this bug.