Bug 1322433

Summary: katello-installer overwrites SSO configuration
Product: Red Hat Satellite Reporter: Paul Armstrong <parmstro>
Component: InstallerAssignee: satellite6-bugs <satellite6-bugs>
Status: CLOSED WORKSFORME QA Contact: Katello QA List <katello-qa-list>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.1.8CC: stbenjam
Target Milestone: UnspecifiedKeywords: Triaged
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-08-23 17:49:54 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Paul Armstrong 2016-03-30 13:42:07 UTC
Description of problem:

With Satellite configured for IdM integration, katello-installer overwrites SSO configuration in /etc/httpd/conf.d/05-foreman-ssl.d/auth_kerb.conf setting the Krb5KeyTab value to the foreman-proxy keytab value.

The foreman-proxy keytab is not an HTTP service keytab, rather a user keytab and apparently doesn't work (works for foreman-proxy)

Version-Release number of selected component (if applicable):
6.1.8

How reproducible:
Unknown - it is difficult for me to replicate as I don't have a snapshot to test against.

Steps to Reproduce:
1. configure idm integration
2. configure idm integration for foreman-proxy
3. configure SSO integration
   a) Create an HTTP service for the Satellite Server FQDN in IDM
          ipa service-add HTTP/sat6.parmstro.redhat.com
   b) Retrieve the HTTP service keytab
          ipa-getkeytab --server idm2.parmstro.redhat.com \
             --principal HTTP/sat6.parmstro.redhat.com \
             --keytab /etc/httpd/httpd.keytab

   c) ensure that the keytab is owned by apache 
          chown apache:apache /etc/httpd/httpd.keytab

   d) ensure that the httpd configuration loads kerberos
          check /etc/httpd/conf.d/auth_kerb.load to see that 
          it loads the mod_auth_kerb.so
   
   e)check /etc/httpd/conf.d/05-foreman-ssl.d/auth_kerb.conf 
     to ensure it is confiugured to look something like:

<Location /users/extlogin>
  SSLRequireSSL
  AuthType Kerberos
  AuthName "Kerberos Login"
  KrbMethodNegotiate On
  KrbMethodK5Passwd Off
  KrbAuthRealms PARMSTRO.REDHAT.COM
  Krb5KeyTab /etc/httpd/httpd.keytab
  KrbLocalUserMapping On
  require valid-user
  # require pam-account satellite-prod
  ErrorDocument 401 '<html><meta http-equiv="refresh" content="0; URL=/users/login"><body>Kerberos authentication did not pass.</body></html>'
  # The following is needed as a workaround for https://bugzilla.redhat.com/show_bug.cgi?id=1020087
  ErrorDocument 500 '<html><meta http-equiv="refresh" content="0; URL=/users/login"><body>Kerberos authentication did not pass.</body></html>'
</Location>

   f) restart the httpd daemon
        systemctl restart httpd

 4) kinit as an authorized user
    sso login should work

**5) katello-service stop
     yum check-update
     yum update
     katello-installer --upgrade
     systemctl reboot
 

 6) Access web admin URL

Actual results:

"Kerberos authentication did not pass"
Presented with standard login
IdM login functions
SSO login does not

Krb5KeyTab points to /etc/foreman-proxy/freeipa.keytab

Expected results:

SSO login functions normally

Additional info:

Comment 1 Bryan Kearney 2016-07-26 19:00:46 UTC
Moving 6.2 bugs out to sat-backlog.

Comment 2 Stephen Benjamin 2016-08-23 17:49:54 UTC
This works for me, maybe you specified the keytab in the wrong installer options?

The two settings are separate, even in separate puppet modules entirely in the installer:

    --foreman-http-keytab         Path to keytab to be used for Kerberos authentication on the WebUI (default: "/etc/httpd/conf/http.keytab")
    --foreman-proxy-realm-keytab  Kerberos keytab path to authenticate realm updates (default: "/etc/foreman-proxy/freeipa.keytab")

Comment 3 Paul Armstrong 2016-08-23 22:15:43 UTC
No, didn't provide the wrong installer options. It was already configured and I ran an upgrade. It was the upgrade that stomped it.

Today, I would agree on the upgrade. Now works much better in new release. Moving from 6.1.9 -> 6.2.0 worked fine. Didn't break things.

If you check this upgrading from 6.1.x -> 6.1.8 it was broken. 
So now, looks good... don't know how important it is to go back and fix anything.

Thanks for looking into it.

Cheers,

Paul