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:


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


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:2304 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@TESTRELM.TEST (aes256-cts-hmac-sha1-96) 
   2 host/master.testrelm.test@TESTRELM.TEST (aes128-cts-hmac-sha1-96) 
   2 host/master.testrelm.test@TESTRELM.TEST (des3-cbc-sha1) 
   2 host/master.testrelm.test@TESTRELM.TEST (arcfour-hmac) 
   2 host/master.testrelm.test@TESTRELM.TEST (camellia128-cts-cmac) 
   2 host/master.testrelm.test@TESTRELM.TEST (camellia256-cts-cmac) 


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


[root@client ~]# klist -ke
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   1 host/client.testrelm.test@TESTRELM.TEST (aes256-cts-hmac-sha1-96) 
   1 host/client.testrelm.test@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@TESTRELM.TEST
  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@TESTRELM.TEST (aes256-cts-hmac-sha1-96) 
   2 host/vm-idm-012.testrelm.test@TESTRELM.TEST (aes128-cts-hmac-sha1-96) 
   2 host/vm-idm-012.testrelm.test@TESTRELM.TEST (des3-cbc-sha1) 
   2 host/vm-idm-012.testrelm.test@TESTRELM.TEST (arcfour-hmac) 
   2 host/vm-idm-012.testrelm.test@TESTRELM.TEST (camellia128-cts-cmac) 
   2 host/vm-idm-012.testrelm.test@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@TESTRELM.TEST (aes256-cts-hmac-sha1-96) 
   1 host/vm-idm-010.testrelm.test@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.