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 1470916 - ipa client pointing to replica shows KDC has no support for encryption type
Summary: ipa client pointing to replica shows KDC has no support for encryption type
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ipa
Version: 7.4
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: rc
: ---
Assignee: IPA Maintainers
QA Contact: ipa-qe
URL:
Whiteboard:
: 1543464 (view as bug list)
Depends On:
Blocks: 1565520
TreeView+ depends on / blocked
 
Reported: 2017-07-14 01:54 UTC by Scott Poore
Modified: 2022-03-13 14:21 UTC (History)
15 users (show)

Fixed In Version: ipa-4.6.4-1.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1565520 (view as bug list)
Environment:
Last Closed: 2018-10-30 10:56:00 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:3187 0 None None None 2018-10-30 10:56:48 UTC

Description Scott Poore 2017-07-14 01:54:45 UTC 
Description of problem:


We are seeing issues again with ipa commands (install and cert related at least)    throwing no support for encryption type errors.

[root@client ~]# ipa cert-request --principal=HTTP/client.testrelm.test /tmp/http-func-services.csr
ipa: ERROR: Major (851968): Unspecified GSS failure.  Minor code may provide more information, Minor (2529638926): KDC has no support for encryption type

When I switch /etc/ipa/default.conf to point to the IPA Master, it works.

[root@client ~]# vi /etc/ipa/default.conf
[root@client ~]# ipa cert-request --principal=HTTP/client.testrelm.test /tmp/http-func-services.csr
  Issuing CA: ipa
  Certificate: MIIEGjCCAwKgAwIBAgIBDzANBgkqhkiG9w0BAQsFADA4MRYwFAYDVQQKDA1URVNUUkVMTS5URVNUMR4wHAYDVQQDDBVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMTcwNzE0MDEyMDMxWhcNMTkwNzE1MDEyMDMxWjA3MRYwFAYDVQQKDA1URVNUUkVMTS5URVNUMR0wGwYDVQQDDBRjbGllbnQudGVzdHJlbG0udGVzdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOt/fp2oOdEMOq6X4ZTqeXXrnv32DtPbOTtVbKqKJxsiIN5lXpJHRf3cc7uRy1llChrcgidXz6Jz27n+eLCZDAZd0FmUe3zb2U3OXNPr9cCJ89uAQTcxl7lYierRDOiXM7iEpvL1mZ7nwlbJjvZ4Xg6DFr/2DO5VZWUUcIdtC7FRFSjrauPTw1t9bu2AltNSKlMUF05wWEmvOZFBXi8893cwe0GpcSQbNs2uCdyZkpM2JaH4PA99WZITRnKQCaKB+TFemB5QfI5DPoxw9Pupvnbbi78q9qkN/VEse6g6hMR3DPv5PiVIGVM2U7bSad5Vy9D7FfhcbOHNzhMfSHkdV8sCAwEAAaOCAS4wggEqMB8GA1UdIwQYMBaAFECRrHwc4Jg3c+9UvPYXCahECDtzMD8GCCsGAQUFBwEBBDMwMTAvBggrBgEFBQcwAYYjaHR0cDovL2lwYS1jYS50ZXN0cmVsbS50ZXN0L2NhL29jc3AwDgYDVR0PAQH/BAQDAgTwMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjB4BgNVHR8EcTBvMG2gNaAzhjFodHRwOi8vaXBhLWNhLnRlc3RyZWxtLnRlc3QvaXBhL2NybC9NYXN0ZXJDUkwuYmluojSkMjAwMQ4wDAYDVQQKDAVpcGFjYTEeMBwGA1UEAwwVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB0GA1UdDgQWBBTTr3znXEQ2j5MWBmCbOFPo20HlLzANBgkqhkiG9w0BAQsFAAOCAQEATEeSYOQgbfGK+69pqOBeXWn2wPmAPZUY4bVSz0L1Qsal+9OybQGfR4Njr/rIV6/zZbvf/MBqupXmVLg5xT9Ob58hG4y9sxBUBB+v9lvOw8rCXCcd813ZpRtkHRVAuJxwy91a8u+vpBcf8/Rk6rEenTTQh2RIaOnaX6EMnyUz/gNx0pSMASUzhvn3W3EBJW1tLWqA2V5kwFKKhcv/Ypl76Mzm0wOOJ/yimjMJ1YBfcNR53wciaqT2ISv0XboN3NVF06FiA6ruGrmJ0Hqfs79XRDnpnmRLFffisl8oZccABSjh/onthgVqUiZ6tZPiH5NVtfGoUu26A88uFMEPtoV7Qg==
  Subject: CN=client.testrelm.test,O=TESTRELM.TEST
  Issuer: CN=Certificate Authority,O=TESTRELM.TEST
  Not Before: Fri Jul 14 01:20:31 2017 UTC
  Not After: Mon Jul 15 01:20:31 2019 UTC
  Serial number: 15
  Serial number (hex): 0xF


We also saw this during an ipa-client-insta

RUNCMD: /usr/sbin/ipa-client-install -U --principal admin --password Secret123
STDOUT: WARNING: ntpd time&date synchronization service will not be configured as
conflicting service (chronyd) is enabled
Use --force-ntpd option to disable it and force configuration of ntpd



STDERR: Discovery was successful!
Client hostname: client.testrelm.test
Realm: TESTRELM.TEST
DNS Domain: testrelm.test
IPA Server: replica.testrelm.test
BaseDN: dc=testrelm,dc=test
Skipping synchronizing time with NTP server.
Successfully retrieved CA cert
    Subject:     CN=Certificate Authority,O=TESTRELM.TEST
    Issuer:      CN=Certificate Authority,O=TESTRELM.TEST
    Valid From:  2017-07-13 13:42:10
    Valid Until: 2037-07-13 13:42:10

Enrolled in IPA realm TESTRELM.TEST
Created /etc/ipa/default.conf
New SSSD config will be created
Configured sudoers in /etc/nsswitch.conf
Configured /etc/sssd/sssd.conf
Configured /etc/krb5.conf for IPA realm TESTRELM.TEST
trying https://replica.testrelm.test/ipa/json
Major (851968): Unspecified GSS failure.  Minor code may provide more information, Minor (2529638926): KDC has no support for encryption type
The ipa-client-install command failed. See /var/log/ipaclient-install.log for more information

TIME: 13:51:38
ipa-client-install failed with error code=1


[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) 


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


How reproducible:
Unknown.  This has been seen in automated tests but, I'm unsure we have reproduced it manually.

Steps to Reproduce:
1.  install ipa master with dns
2.  install ipa replica with dns
3.  point client to replica for dns
4.  stop ipa on master to make sure it's not used
5.  install ipa client 
6.  run ipa cert-request

Actual results:

ipa-client-install fails or cert-request fails

Expected results:

no failures

Additional info:
Comment 5 Scott Poore 2017-07-14 16:23:45 UTC 
A little more information, 

More ipa commands than just cert-request are failing here.

It seems that on the client that's failing, if I set krb5.conf to point directly to the replica and get a new ticket, ipa commands work again.  So, it "seems" like when kerberos gets master as KDC (via DNS) and ipa client is pointed to replica, it's failing.  however, when I try to manually reproduce that on local VM's it's not failing.
Comment 7 Scott Poore 2017-07-14 18:30:04 UTC 
Interesting...I see two services for replica on the broken env:

[root@master log]# ipa service-find HTTP/replica.testrelm.test
------------------
2 services matched
------------------
  Principal name: HTTP/replica.testrelm.test
  Principal alias: HTTP/replica.testrelm.test
  Certificate: MII...
  Subject: CN=replica.testrelm.test,O=TESTRELM.TEST
  Serial Number: 12
  Serial Number (hex): 0xC
  Issuer: CN=Certificate Authority,O=TESTRELM.TEST
  Not Before: Fri Jul 14 02:50:02 2017 UTC
  Not After: Mon Jul 15 02:50:02 2019 UTC
  Fingerprint (SHA1): 0a:7f:cc:c8:6e:05:13:2c:8a:7d:c7:89:be:ae:a0:18:89:ce:53:bd
  Fingerprint (SHA256): 17:36:1b:75:26:d2:c6:e4:8a:f5:79:31:ff:5e:ea:67:e5:49:6e:39:f5:d0:c4:63:88:af:b5:55:52:22:e0:0d
  Keytab: False

  Principal name: HTTP/replica.testrelm.test
  Principal alias: HTTP/replica.testrelm.test
  Keytab: True
----------------------------
Number of entries returned 2
----------------------------
[root@master log]#
Comment 9 Martin Babinsky 2017-07-18 10:53:59 UTC 
We already investigated this with Michal Reznik and opened an upstream issue https://pagure.io/freeipa/issue/7041. I our case this occured in more complex multi-replica deployment. The root cause remains the same, HTTP/ principal is added multiple times (once when requesting keytab, once during cert-request) during replica install breaking framework on the replica.

However this should not happen anymore when deploying first replica. I will investigate this further but not this week as I am already tied up in other things.

Keeping needinfo flag set on this BZ so that I do not forget to return to it.
Comment 11 Petr Vobornik 2017-07-28 16:51:01 UTC 
Upstream ticket:
https://pagure.io/freeipa/issue/7041
Comment 14 Florence Blanc-Renaud 2018-03-15 16:12:37 UTC 
*** Bug 1543464 has been marked as a duplicate of this bug. ***
Comment 15 Florence Blanc-Renaud 2018-03-21 08:38:22 UTC 
Fixed upstream
master:
https://pagure.io/freeipa/c/0f31564b35aac250456233f98730811560eda664
Comment 16 Florence Blanc-Renaud 2018-03-22 09:08:00 UTC 
Fixed upstream
ipa-4-6:
https://pagure.io/freeipa/c/75d8ba8e4c9dbdec6b2a0de2a58b763e31198f04
Comment 17 Florence Blanc-Renaud 2018-03-22 10:04:54 UTC 
Fixed upstream
ipa-4-5:
https://pagure.io/freeipa/c/490ebcea522ef12920d81dc9405c8a62ae5dcb6e
Comment 34 Michal Reznik 2018-07-24 08:47:53 UTC 
Reported steps are passing however as the Bug was a race condition it is more sanity only (upstream test_replication_layouts::TestLineTopology was also used to verify):

[root@replica1 ~]# rpm -qa | grep ipa-server
ipa-server-dns-4.6.4-2.el7.noarch
ipa-server-4.6.4-2.el7.x86_64
ipa-server-common-4.6.4-2.el7.noarch

[root@client ~]# rpm -qa | grep ipa-client
ipa-client-4.6.4-2.el7.x86_64
ipa-client-common-4.6.4-2.el7.noarch

Steps:
1.  install ipa master with dns
2.  install ipa replica with dns
3.  point client to replica for dns
    $ echo "nameserver <replica-ip>" >> /etc/resolve.conf  (on client)

4.  stop ipa on master to make sure it's not used
5.  install ipa client
6.  run ipa cert-request

Actual result:

[root@client ~]# ipa cert-request --principal=HTTP/client.ipa.test http.csr
  Issuing CA: ipa
  Certificate: MIIEIDCCAwigAwIBAgIED/8AAjANBgkqhkiG9w0BAQsFADAzMREwDwYDVQQKDAhJUEEuVEVTVDEeMBwGA1UEAwwVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE4MDcyNDA4MTY1M1oXDTIwMDcyNDA4MTY1M1owLTERMA8GA1UECgwISVBBLlRFU1QxGDAWBgNVBAMMD2NsaWVudC5pcGEudGVzdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANiDjKxd8CvvCXbkfqoABWgNnX6LLiJ8bMm47ZpLUBNV6Vl74nXmbZrCIJ3WF2K9GU7mtjoO7z0yrhlg+MJyYWN8/dpJJy+yRW5rL7Rm97L8/HOl7lMYvbMlKpUrAHj7Nj81okQ3w/Y0HImqEXhMz2VmbPO5h7z/IaxfgA/Vab9Pdo8vF/ZrZc0zaIgrCUXVhdle0HSzpNGqHMZklsbL1KMkcqAOIPAY7lNRkYkAELJWNfl+YAZQqcwQCRHYt8Te0X/pkz5W25VYLOWq8IuMS6E5FOHQAYlnnBQ98DKG/rsNW+Z62udEgQoxmwhbomqUc3RJh63EH2mmKuFswn6Gm2ECAwEAAaOCAUAwggE8MB8GA1UdIwQYMBaAFM+6SnQznEA9yPqQ0zGWLOCi2qOZMDoGCCsGAQUFBwEBBC4wLDAqBggrBgEFBQcwAYYeaHR0cDovL2lwYS1jYS5pcGEudGVzdC9jYS9vY3NwMA4GA1UdDwEB/wQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwcwYDVR0fBGwwajBooDCgLoYsaHR0cDovL2lwYS1jYS5pcGEudGVzdC9pcGEvY3JsL01hc3RlckNSTC5iaW6iNKQyMDAxDjAMBgNVBAoMBWlwYWNhMR4wHAYDVQQDDBVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHQYDVR0OBBYEFKVCZzz2biPKvtzWDVsNHqmdEaM9MBoGA1UdEQQTMBGCD2NsaWVudC5pcGEudGVzdDANBgkqhkiG9w0BAQsFAAOCAQEAdQ4td4MKb7EzfHFtFdLruPX/LHZyALq30bIHR7grgsnrMD+TeCPNK0q6YcJrYevS2iVEG7rrg6N2zw9OwcGCVumaewF0XD9R5fGU0HQTp1jkTJFbUGYwvHStQ3ROZwLFr94yoiPVnfbGkRKYR8rXKeMfd9TZB+75br5LWpbMPtEtaRiVzYbE9Jn5I8Ztay2tXX6P38A9kzR3wp0MBYkmiYV/Sym77bIqVoh+LtezRtAaizWzRUDYMbhEGt9bbnSu0DvgFmxOLd1iy0oHiomigLvY1BhRbz5rJB3G8K3lMcLPko6l6Mr+6iAGZ8P1GTFPFXega1OvCICBHV0M4ySV6g==
  Subject: CN=client.ipa.test,O=IPA.TEST
  Subject DNS name: client.ipa.test
  Issuer: CN=Certificate Authority,O=IPA.TEST
  Not Before: Tue Jul 24 08:16:53 2018 UTC
  Not After: Fri Jul 24 08:16:53 2020 UTC
  Serial number: 268369922
  Serial number (hex): 0xFFF0002
Comment 36 errata-xmlrpc 2018-10-30 10:56:00 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-2018:3187
Note You need to log in before you can comment on or make changes to this bug.