alex1818 / serf

Automatically exported from code.google.com/p/serf
Apache License 2.0
0 stars 0 forks source link

Can't authenticate with Negotiate/Kerberos to a proxy when reverse dns is not set up correctly #125

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Environment:
On my development network, I have a kerberos server hosted at lgo-ubuntu1.dev. 
From my wifi router it gets the domain name of my provider assigned, so if I do 
a reverse lookup of the IP address of that server I get 
lgo-ubuntu1.myhostingprovider.be .

While this is not ideal for a Kerberos setup, MIT kerberos allows me disable 
reverse lookup in its configuration, so if I configure this in my krb5.conf 
file (on the server):
[libdefaults]
        default_realm = DEV
        rdns = false
kinit on my client can successfully get the initial ticket-granting ticket for 
my account lgo@DEV.

Problem:
The problem is that serf insists on doing a reverse lookup of the proxy's ip 
address. So if I run:
$ test/serf_get -p lgo-ubuntu1.dev:8080 http://google.com
...
[2013-08-17T17:17:10.870232+02] [l:192.168.1.113:63973 r:192.168.1.112:8080] 
auth/auth.c: Proxy authz required. Response header(s): Negotiate oQcwBaADCgEC
[2013-08-17T17:17:10.870247+02] [l:192.168.1.113:63973 r:192.168.1.112:8080] 
auth/auth.c: Client supports: Negotiate
[2013-08-17T17:17:10.870259+02] [l:192.168.1.113:63973 r:192.168.1.112:8080] 
auth/auth.c: ... matched: Negotiate
[2013-08-17T17:17:10.870465+02] auth/auth_spnego_gss.c: Get principal for 
HTTP@lgo-ubuntu1.myhostingprovider.be
[2013-08-17T17:17:10.870508+02] auth/auth_spnego_gss.c: Error during Kerberos 
handshake (d0000,100007): SPNEGO failed to negotiate a mechanism
[2013-08-17T17:17:10.870517+02] [l:192.168.1.113:63973 r:192.168.1.112:8080] 
auth/auth.c: Negotiate authentication failed.
Error running context: (120190) An error occurred during authentication

serf will use lgo-ubuntu1.myhostingprovider.be as hostname for the principal.

I have only tested on mac os x with gssapi, the code responsible for this 
behaviour was introduced in r1667. On Windows where SSPI is used it looks like 
the above setup will fail both for authn to host and proxy, since r1460.

Suggestion for solution
Ideally serf can support my not-100% -correctly-setup network, with an option, 
or maybe it's possible to check of MIT Kerberos is configured to not do reverse 
lookups.

Original issue reported on code.google.com by lieven.govaerts@gmail.com on 17 Aug 2013 at 3:29

GoogleCodeExporter commented 9 years ago
Have you actually tried not to perform the lookup yourself but let MIT/Heimdal 
do it on its own? Leave the hostname as-is. I can test a patch with MIT on Red 
Hat and Heimdal on FreeBSD if desired.

Original comment by 1983-01...@gmx.net on 7 Oct 2013 at 8:41

GoogleCodeExporter commented 9 years ago
This issue was fixed in r2312 and back ported to 1.3.5.

Original comment by lieven.govaerts@gmail.com on 27 Apr 2014 at 9:19