Hide Forgot
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@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) 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:
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.
Interesting...I see two services for replica on the broken env: [root@master log]# ipa service-find HTTP/replica.testrelm.test@TESTRELM.TEST ------------------ 2 services matched ------------------ Principal name: HTTP/replica.testrelm.test@TESTRELM.TEST Principal alias: HTTP/replica.testrelm.test@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@TESTRELM.TEST Principal alias: HTTP/replica.testrelm.test@TESTRELM.TEST Keytab: True ---------------------------- Number of entries returned 2 ---------------------------- [root@master log]#
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.
Upstream ticket: https://pagure.io/freeipa/issue/7041
*** Bug 1543464 has been marked as a duplicate of this bug. ***
Fixed upstream master: https://pagure.io/freeipa/c/0f31564b35aac250456233f98730811560eda664
Fixed upstream ipa-4-6: https://pagure.io/freeipa/c/75d8ba8e4c9dbdec6b2a0de2a58b763e31198f04
Fixed upstream ipa-4-5: https://pagure.io/freeipa/c/490ebcea522ef12920d81dc9405c8a62ae5dcb6e
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
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