Thank you Maxim. We are using Kerberos, on Linux. And per-request authentication, we are not trying to use session-level authentication. Would the ntlm module help here? We are already using spnego-http-auth-nginx-module to help with SPNego/GSSAPI. So our issue/incompatibility seems to be between backend / nginx with spnego-http-auth-nginx-module / client. The first two sending/passing the extra headers on the response and the client getting confused by it. As you say, nginx is a generic HTTP proxy here, so we will have to figure things out with our server / client / spnego-http-auth-nginx-module. Are there any other suggested approaches regarding using nginx and Kerberos?
FYI, this is the output of "nginx -V": nginx version: nginx/1.14.0 built by gcc 7.3.0 (GCC) built with OpenSSL 1.1.0h 27 Mar 2018 TLS SNI support enabled configure arguments: --without-http_rewrite_module --without-http_gzip_module --with-http_stub_status_module --with-ld-opt='-L /efs/dist/kerberos/mit/1.14.6/exec/lib' --add-module=spnego-http-auth-nginx-module --with-http_ssl_module --with-openssl=/home/gnica/nginx/1.14.0_2/common/usr/lib/openssl --prefix=/home/gnica/nginx/1.14.0_2/common/usr -----Original Message----- From: Maxim Dounin [mailto:mdou...@mdounin.ru] Sent: Friday, September 14, 2018 7:19 PM To: Nica, George via nginx <nginx@nginx.org> Cc: Nica, George <gheorghe.n...@baml.com> Subject: Re: WWW-Authenticate in 200 OK response Hello! On Fri, Sep 14, 2018 at 08:59:16PM +0000, Nica, George via nginx wrote: > I am currently working on a multi-tier application, trying to use nginx as > load balancer. > The issue is that nginx seems to be adding WWW-Authenticate in the 200 OK > response after the Kerberos authentication has taken place, which confuses > the client. (The client could potentially ignore it, but that's possibly > another issue.) > Not sure this is expected... Any suggestion on how to avoid or work around > this? > > [2018-09-14 14:46:14.471] root INFO: @@@@@@ Connecting to: > 'https://urldefense.proofpoint.com/v2/url?u=http-3A__host1-3A39609_url1&d=DwIBAg&c=SFszdw3oxIkTvaP4xmzq_apLU3uL-3SxdAPNkldf__Q&r=bLrGf3qOPfa7FwixFKSI5EuEAlEuxbglrK8414lC4wY&m=kmzwidjXfoCyejfnDKRo7J4AmvdWhFwVMc3SrQ5G24k&s=Jgva48bCRs_t1VOn7OxsyjgTLgIcBsIoFnzP9GHdtBI&e=' > send: 'GET /url1 HTTP/1.1\r\nX-Client-User-Name: uname1\r\nAccept-Encoding: > gzip\r\nConnection: close\r\nAccept: application/json\r\nUser-Agent: > qz.qzdev.run\r\nHost: host1:39609\r\nX-Client-Host-Name: > host2\r\nContent-Type: application/json\r\n\r\n' > reply: 'HTTP/1.1 401 Unauthorized\r\n' > header: Server: nginx/1.14.0 > header: Date: Fri, 14 Sep 2018 18:46:14 GMT > header: Content-Type: text/html > header: Content-Length: 195 > header: Connection: close > header: WWW-Authenticate: Negotiate > header: WWW-Authenticate: Basic realm="" > header: Access-Control-Allow-Credentials: true > send: 'GET /url1 HTTP/1.1\r\nX-Client-User-Name: uname1\r\nAccept-Encoding: > gzip\r\nConnection: close\r\nAccept: application/json\r\nUser-Agent: > qz.qzdev.run\r\nHost: host1:39609\r\nX-Client-Host-Name: > host2\r\nContent-Type: application/json\r\nAuthorization: Negotiate > YII........................ AghEw==\r\n\r\n' > reply: 'HTTP/1.1 200 OK\r\n' > header: Server: nginx/1.14.0 > header: Date: Fri, 14 Sep 2018 18:46:14 GMT > header: Content-Type: application/json > header: Content-Length: 430908 > header: Connection: close > header: WWW-Authenticate: Negotiate YI .....gA== > header: WWW-Authenticate: Basic realm="" > header: Set-Cookie: session=ey...ZW4; HttpOnly; Path=/ > header: Access-Control-Allow-Credentials: true > [2018-09-14 14:46:14.779] client_http_auth CRITICAL: GSSAPI failed! It looks like you are trying to use "WWW-Authenticate: Negotiate" AKA Integrated Windows Authentication, AKA NTLM authentication. Unfortunately, this authentication scheme was designed without following HTTP basic concepts, and authenticates a connection instead of requests. As such, this authentication scheme cannot work though a generic HTTP proxy. For NTLM authentication to work though a proxy, it needs to keep connections to the backend server alive and bound to corresponding client connections. The best solution would be to avoid using NTLM authentication for anything more complex than directly connected servers in intranets. If you can't do this for some reason, consider using the "ntlm" directive, which is available as part of our commercial version, see https://urldefense.proofpoint.com/v2/url?u=http-3A__nginx.org_r_ntlm&d=DwIBAg&c=SFszdw3oxIkTvaP4xmzq_apLU3uL-3SxdAPNkldf__Q&r=bLrGf3qOPfa7FwixFKSI5EuEAlEuxbglrK8414lC4wY&m=kmzwidjXfoCyejfnDKRo7J4AmvdWhFwVMc3SrQ5G24k&s=V7CbzPjbpkSiNhNIaDR5P5la1fLfM5-MC6MO-KmhKj8&e=. -- Maxim Dounin https://urldefense.proofpoint.com/v2/url?u=http-3A__mdounin.ru_&d=DwIBAg&c=SFszdw3oxIkTvaP4xmzq_apLU3uL-3SxdAPNkldf__Q&r=bLrGf3qOPfa7FwixFKSI5EuEAlEuxbglrK8414lC4wY&m=kmzwidjXfoCyejfnDKRo7J4AmvdWhFwVMc3SrQ5G24k&s=56j1udQaqKDK12PhW-jGwz89_8ZMgUhTZ2tCfJDAaSc&e= ---------------------------------------------------------------------- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message. _______________________________________________ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
