Chrome, Negotiate authentication and Mac OS X

[Mark O'Loughlin]

Hello,

I am working in an Apple environment and we are using squid proxy and
kerberos (Negotiate) authentication but are experiencing problems
setting it up with Chrome.

We either experience one of two different results.

On some systems chrome ignores the auth request and just can't get
out. Digging into this I have
- Put debug on in squid can see it sending the shows the auth header
"::fixHeader: Sending type:38 header: 'Negotiate'"
- Turning on debug logging in chrome (--enable-logging --v=3) and I
see a message "Unable to create AuthHandler. Status:
net::ERR_UNSUPPORTED_AUTH_SCHEME Challenge: Negotiate"
I have white listed everything from the command line too '--auth-
server-whitelist="*" --auto-negotiate-delegate-whitelist="*" ' and
ensured that only negotiate is supported '--auth-schemes="negotiate"
', however still seeing the same problem.
It appears as if chrome is not supporting negotiate, this is
happening on two of our test systems. The first has Mac OS X Snow
Leopard (10.6) and Chrome 16, the next one has Mac OS X Lion and
Chrome 19.0.1084.56.
It looks like something is missing on these systems but they all have
a valid kerberos ticket and the libgssapi_krb5.dylib library exists.

On the other systems we have tested with Chrome is attempting to
perform kerberos negotiation, but just see an error in the squid log
"authenticateNegotiateHandleReply: Error validating user via
Negotiate. Error returned 'BH gss_accept_sec_context() failed:
Unspecified GSS failure. Minor code may provide more information.
Wrong principal in request'"
So it looks like is not generating the correct SPN, the connection to
the proxy server is just an ip address so the principal in the keytab
for squid is just HTTP/1.2.3.4@REALM (where 1.2.3.4 is the ip address
of the proxy server).
This works for Firefox and Safari, but does chrome require it to be a
fqdn?
This happens on three test systems all Mac OS X Lion (10.7) and
different versions of chrome (16, 17 and 19).

Anyone have an ideas or thoughts on what could be an issue with either
scenario?

Thanks
Mark

[Chris Bentzel]

Adding asanka, who has been helping out with this.

Given the details you provide, it may help to create new bugs in our tracker to help catch this. Go to new.crbug.com. If you don't get to it, I will try to enter them.

On Mon, Jun 25, 2012 at 5:10 AM, Mark O'Loughlin <ma...@oloughlin.eu> wrote:

Hello,

I am working in an Apple environment and we are using squid proxy and
kerberos (Negotiate) authentication but are experiencing problems
setting it up with Chrome.

We either experience one of two different results.

On some systems chrome ignores the auth request and just can't get
out.  Digging into this I have
 - Put debug on in squid can see it sending the shows the auth header
"::fixHeader: Sending type:38 header: 'Negotiate'"
 - Turning on debug logging in chrome (--enable-logging --v=3) and I
see a message "Unable to create AuthHandler. Status:
net::ERR_UNSUPPORTED_AUTH_SCHEME Challenge: Negotiate"
I have white listed everything from the command line too '--auth-
server-whitelist="*" --auto-negotiate-delegate-whitelist="*" ' and
ensured that only negotiate is supported '--auth-schemes="negotiate"
', however still seeing the same problem.
It appears as if chrome is not supporting negotiate,  this is
happening on two of our test systems.  The first has Mac OS X Snow
Leopard (10.6) and Chrome 16, the next one has Mac OS X Lion and
Chrome 19.0.1084.56.
It looks like something is missing on these systems but they all have
a valid kerberos ticket and the libgssapi_krb5.dylib library exists.

If it's ERR_UNSUPPORTED_AUTH_SCHEME at this point, we may be having troubles dynamically loading the GSSAPI lib, or there may be problems initializing.

 

On the other systems we have tested with Chrome is attempting to
perform kerberos negotiation, but just see an error in the squid log
"authenticateNegotiateHandleReply: Error validating user via
Negotiate. Error returned 'BH gss_accept_sec_context() failed:
Unspecified GSS failure.  Minor code may provide more information.
Wrong principal in request'"
So it looks like is not generating the correct SPN, the connection to
the proxy server is just an ip address so the principal in the keytab
for squid is just HTTP/1.2.3.4@REALM  (where 1.2.3.4 is the ip address
of the proxy server).
This works for Firefox and Safari, but does chrome require it to be a
fqdn?
This happens on three test systems all Mac OS X Lion (10.7) and
different versions of chrome (16, 17 and 19).

This is likely - we may not require an FQDN (a single label would be sufficient) but may not correctly handle IPv4 or IPv6 literals.

  

Anyone have an ideas or thoughts on what could be an issue with either
scenario?

Thanks

Mark

--
Chromium Discussion mailing list: chromium...@chromium.org
View archives, change email options, or unsubscribe:
   http://groups.google.com/a/chromium.org/group/chromium-discuss

[Asanka]

Were there any log entries of the form "Unable to bind function..." or "Unable to find a compatible GSSAPI library"?

 

On the other systems we have tested with Chrome is attempting to
perform kerberos negotiation, but just see an error in the squid log
"authenticateNegotiateHandleReply: Error validating user via
Negotiate. Error returned 'BH gss_accept_sec_context() failed:
Unspecified GSS failure.  Minor code may provide more information.
Wrong principal in request'"
So it looks like is not generating the correct SPN, the connection to
the proxy server is just an ip address so the principal in the keytab
for squid is just HTTP/1.2.3.4@REALM  (where 1.2.3.4 is the ip address
of the proxy server).
This works for Firefox and Safari, but does chrome require it to be a
fqdn?
This happens on three test systems all Mac OS X Lion (10.7) and
different versions of chrome (16, 17 and 19).

This is likely - we may not require an FQDN (a single label would be sufficient) but may not correctly handle IPv4 or IPv6 literals.

Could you run 'klist' before and after the authentication attempt to see which service ticket is acquired by Chrome?

[Mark O'Loughlin]

No, just gone through the debug and can't see anything about function or library in the debug log. 

 

On the other systems we have tested with Chrome is attempting to
perform kerberos negotiation, but just see an error in the squid log
"authenticateNegotiateHandleReply: Error validating user via
Negotiate. Error returned 'BH gss_accept_sec_context() failed:
Unspecified GSS failure.  Minor code may provide more information.
Wrong principal in request'"
So it looks like is not generating the correct SPN, the connection to
the proxy server is just an ip address so the principal in the keytab
for squid is just HTTP/1.2.3.4@REALM  (where 1.2.3.4 is the ip address
of the proxy server).
This works for Firefox and Safari, but does chrome require it to be a
fqdn?
This happens on three test systems all Mac OS X Lion (10.7) and
different versions of chrome (16, 17 and 19).

This is likely - we may not require an FQDN (a single label would be sufficient) but may not correctly handle IPv4 or IPv6 literals.

Could you run 'klist' before and after the authentication attempt to see which service ticket is acquired by Chrome?

Running a klist before shows that the user principal (username@REALM) issued by:

krbtgt/REALM@REALM

After chrome attempts to authenticate I see it issued by both:

krbtgt/REALM@REALM

HTTP/proxy@REALM

I can also see the ticket being issued in the kdc logs.

Jun 26 11:59:50 ah1-ldap-fs01 krb5kdc[1187](info): TGS_REQ (4 etypes {18 17 16 23}) 1.2.3.5: ISSUE: authtime 1340708360, etypes {rep=18 tkt=16 ses=18}, username@REALM for HTTP/proxy@REALM

So it is getting this far.  But squid is then throwing the error about wrong principal in request at the final stage.   Anyway I can see what is going wrong on this final stage.  I did put the kerberos squid plugin in a strace but couldn't see anything.

[Asanka Herath]

Those log entries would likely only show up once, while the log entry with ERR_UNSPPORTED_AUTH_SCHEME could show up multiple times.

Entered http://crbug.com/134682 to track this issue.

 On the other systems we have tested with Chrome is attempting to

perform kerberos negotiation, but just see an error in the squid log
"authenticateNegotiateHandleReply: Error validating user via
Negotiate. Error returned 'BH gss_accept_sec_context() failed:
Unspecified GSS failure.  Minor code may provide more information.
Wrong principal in request'"
So it looks like is not generating the correct SPN, the connection to
the proxy server is just an ip address so the principal in the keytab
for squid is just HTTP/1.2.3.4@REALM  (where 1.2.3.4 is the ip address
of the proxy server).
This works for Firefox and Safari, but does chrome require it to be a
fqdn?
This happens on three test systems all Mac OS X Lion (10.7) and
different versions of chrome (16, 17 and 19).

This is likely - we may not require an FQDN (a single label would be sufficient) but may not correctly handle IPv4 or IPv6 literals.

Could you run 'klist' before and after the authentication attempt to see which service ticket is acquired by Chrome?

Running a klist before shows that the user principal (username@REALM) issued by:

krbtgt/REALM@REALM

After chrome attempts to authenticate I see it issued by both:

krbtgt/REALM@REALM

HTTP/proxy@REALM

I can also see the ticket being issued in the kdc logs.

Jun 26 11:59:50 ah1-ldap-fs01 krb5kdc[1187](info): TGS_REQ (4 etypes {18 17 16 23}) 1.2.3.5: ISSUE: authtime 1340708360, etypes {rep=18 tkt=16 ses=18}, username@REALM for HTTP/proxy@REALM

So it is getting this far.  But squid is then throwing the error about wrong principal in request at the final stage.   Anyway I can see what is going wrong on this final stage.  I did put the kerberos squid plugin in a strace but couldn't see anything.

Entered http://crbug.com/134684 for this issue.