This bug was initially created as a copy of Bug #1764558 I am copying this bug because: reasons Description of problem: Authentication attempts are failing with Request Header Authentication Provider Version-Release number of selected component (if applicable): 4.1.0 How reproducible: Always in the customer environment. Steps to Reproduce: 1. Configure Request Header authentication provider as documented in ocp 4.1 DOCS. Auth proxy (httpd) conf is provided in Additional info below. 2. Try to login from console or via oc cli as the SSO user 3. Actual results: Authentication attempts via UI are failing and must-gather logs do not show any specific reason. must-gather attached along with logs from the httpd proxy. OC Cli login attempts result "unexpected response: 500". cli-login-linux.txt is attached. If cusomer tries to authenticate directly with oauth-openshift providing the creds and certificates. request-header-config.txt is attached. Expected results: Successful authentication via UI and CLI. Additional info: Customer claims that the same procedure worked in 3.11 Customers httpd auth proxy config is as below: ############# SSLProxyCACertificateFile /pki/authproxyca.crt SSLCACertificateFile /pki/smartcard.crt SSLVerifyClient require SSLVerifyDepth 4 SSLOptions +ExportCertData ############# Here is the new file ############################################################ LoadModule request_module modules/mod_request.so ServerName <other_stuff> LogLevel trace6 LISTEN 8443 <VirtualHost *:8443> DocumentRoot /var/www/html SSLEngine on SSLCertificateFile /pki/web.crt SSLCertificateKeyFile /pki/web.key SSLCACertificateFile /pki/ca.crt SSLProxyEngine on SSLProxyCACertificateFile /pki/ca.crt # It's critical to enforce client certificates on the Master. Otherwise # requests could spoof the X-Remote-User header by accessing the Master's # /oauth/authorize endpoint directly. SSLProxyMachineCertificateFile /pki/authproxy.pem # Send all requests to the console RewriteEngine On RewriteRule ^/console(.*)$ https://%{HTTP_HOST}/console$1 [R,L] # In order to using the challenging-proxy an X-Csrf-Token must be present. RewriteCond %{REQUEST_URI} ^/challenging-proxy RewriteCond %{HTTP:X-Csrf-Token} ^$ [NC] RewriteRule ^.* - [F,L] <Location /challenging-proxy/oauth/authorize> ProxyPass https://<stuff>:443/oauth/authorize AuthName "SSO Login" # For Kerberos AuthType GSSAPI Require valid-user RequestHeader set X-Remote-User %{REMOTE_USER}s GssapiCredStore keytab:/krb5/auth-proxy.keytab GssapiBasicAuth On GssapiImpersonate On GssapiConnectionBound On </Location> <Location /login-proxy/oauth/authorize> ProxyPass https://<stuff>:443/oauth/authorize AuthName "SSO Login" AuthType GSSAPI Require valid-user RequestHeader set X-Remote-User %{REMOTE_USER}s GssapiUseSessions On Session On SessionCookieName os_gssapi_session path=/private;httponly;secure; GssapiCredStore keytab:/krb5/auth-proxy.keytab GssapiBasicAuth On GssapiImpersonate On GssapiConnectionBound On ErrorDocument 401 '<html><meta http-equiv="refresh" content="0; URL=/login-proxy/oauth/authorize"><body>Kerberos authentication did not pass.</body></html>' </Location> </VirtualHost> RequestHeader unset X-Remote-User
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-2019:3869