[root@dhcp207-185 ~]# ipa-restore /var/lib/ipa/backup/ipa-full-2014-11-14-18-48-29/ Directory Manager (existing master) password: Preparing restore from /var/lib/ipa/backup/ipa-full-2014-11-14-18-48-29/ on dhcp207-185.testrelm.test Restoring data will overwrite existing live data. Continue to restore? [no]: yes Each master will individually need to be re-initialized or re-created from this one. The replication agreements on masters running IPA 3.1 or earlier will need to be manually re-enabled. See the man page for details. Disabling all replication. Stopping IPA services Systemwide CA database updated. Restoring files Systemwide CA database updated. Restoring from userRoot in TESTRELM-TEST Restoring from ipaca in TESTRELM-TEST Starting IPA services Restarting SSSD The ipa-restore command was successful [root@dhcp207-185 ~]# kdestroy -A [root@dhcp207-185 ~]# echo Secret123|kinit admin Password for admin@TESTRELM.TEST: [root@dhcp207-185 ~]# ipa -vv user-find ipa: INFO: trying https://dhcp207-185.testrelm.test/ipa/json ipa: INFO: Forwarding 'user_find' to json server 'https://dhcp207-185.testrelm.test/ipa/json' ipa: INFO: Request: { "id": 0, "method": "user_find", "params": [ [ null ], { "all": false, "no_members": false, "pkey_only": false, "raw": false, "version": "2.108", "whoami": false } ] } ipa: INFO: Response: { "error": { "code": 2100, "message": "Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Decrypt integrity check failed)", "name": "ACIError" }, "id": null, "principal": "UNKNOWN", "result": null, "version": "4.1.0" } ipa: ERROR: Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Decrypt integrity check failed) [root@dhcp207-185 ~]#
No log for above in /var/log/httpd/error_log
[root@dhcp207-185 ~]# tail -f /var/log/httpd/error_log [Fri Nov 14 18:47:17.169214 2014] [:error] [pid 4649] ipa: INFO: [jsonserver_session] admin@TESTRELM.TEST: user_find(None, whoami=False, all=False, raw=False, version=u'2.108', no_members=False, pkey_only=False): SUCCESS [Fri Nov 14 18:48:15.709438 2014] [mpm_prefork:notice] [pid 4646] AH00170: caught SIGWINCH, shutting down gracefully [Fri Nov 14 19:09:09.550373 2014] [core:notice] [pid 9485] SELinux policy enabled; httpd running as context system_u:system_r:httpd_t:s0 [Fri Nov 14 19:09:09.551518 2014] [suexec:notice] [pid 9485] AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) [Fri Nov 14 19:09:10.080299 2014] [auth_digest:notice] [pid 9485] AH01757: generating secret for digest authentication ... [Fri Nov 14 19:09:10.081396 2014] [lbmethod_heartbeat:notice] [pid 9485] AH02282: No slotmem from mod_heartmonitor [Fri Nov 14 19:09:10.088609 2014] [mpm_prefork:notice] [pid 9485] AH00163: Apache/2.4.6 (Red Hat Enterprise Linux) mod_auth_kerb/5.4 mod_nss/2.4.6 NSS/3.15.4 Basic ECC mod_wsgi/3.4 Python/2.7.5 configured -- resuming normal operations [Fri Nov 14 19:09:10.088645 2014] [core:notice] [pid 9485] AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND' [Fri Nov 14 19:09:16.642444 2014] [:error] [pid 9488] ipa: INFO: *** PROCESS START *** [Fri Nov 14 19:09:16.656971 2014] [:error] [pid 9487] ipa: INFO: *** PROCESS START ***
user_find in above log is before the ipa-backup.
But httpd service status shows error seen
[root@dhcp207-185 ~]# systemctl status httpd.service -l ... ..... Nov 14 19:09:08 dhcp207-185.testrelm.test systemd[1]: Starting The Apache HTTP Server... Nov 14 19:09:10 dhcp207-185.testrelm.test systemd[1]: Started The Apache HTTP Server. Nov 14 20:04:39 dhcp207-185.testrelm.test httpd[9488]: GSSAPI client step 1 Nov 14 20:04:39 dhcp207-185.testrelm.test httpd[9488]: GSSAPI client step 1 Nov 14 20:04:39 dhcp207-185.testrelm.test httpd[9488]: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Decrypt integrity check failed) [root@dhcp207-185 ~]#
Fix description.
Alexander, do we know the root cause? I know you investigated this one.
No root cause yet, we need someone to reproduce it or get on the machine if that one is available.
I suspected memcached session contained old key and negotiating between HTTPD and a client was not happening right but checks on /etc/httpd/conf/ipa.keytab show that it can be used to authenticate against KDC just fine. Users can get tickets to HTTP/hostname just fine as well. HTTP/hostname can talk to ldap/hostname without any issue.
hostname
Very similar to #4084
after running:
sudo -u apache kdestroy
ipa user-find was successful
we should probably call
{{{httpinstance.remove_httpd_ccache()}}}
at the end of ipa-restore
Taking over the review, I can test together with another B/R patch.
master:
ipa-4-1:
Metadata Update from @ksiddiqu: - Issue assigned to pvoborni - Issue set to the milestone: FreeIPA 4.1.2
Login to comment on this ticket.