From: kmra...@rockwellcollins.com [mailto:kmra...@rockwellcollins.com] > > Did you read my email above? Let me explain again. Server advertises > > supported authentication schemes, for example Microsoft IIS: > > [[[ > > C: GET / HTTP/1.1 > > S: HTTP/1.1 401 Authorization Required > > S: WWW-Authenticate: NTLM > > S: WWW-Authenticate: Negotiate > > S: WWW-Authenticate: Basic > > ]]] > > > > Then client decide which authentication scheme to use. Serf tries to > > Negotiate, then Basic. But with proposed patch serf will try > > Negotiate, then Basic and then NTLM again, which is wrong because NTLM > > authentication already handled inside Negotiate protocol. This is one > > of the reasons why I vetoed this patch. > > > > My point is that serf should use NTLM *only* if server doesn't > > advertise support Negotiate. > > The problem is that most clients will choose Kerberos instead of > NTLM during the Negotiate phase (which they should because it is > considered more secure), but there may be things that cause > Kerberos to fail, such as mis-configure SPNs in active directory > or a mis-configured Java VM options on the client. In most of > these cases NTLM "just works", but the serf client never tries it > like neon did. This is why most installations will be set to > offer NTLM only and not Negotiate. > > As stated, the correct action is to have Serf use NTLM if that > is the only thing the server offers. Not just fail like > it does today.
+1 [Quoting Ivan] > > I'm going to try to plug NTLM properly in the current serf auth > > architecture on the next week. +10 I have a slightly cleaned up version of the original patch on http://b.qqn.nl/f/serf-ntlm.patch for if you would like to use that patch as a starting point. (I plugged some memory and handle leaks in the old ra_serf code that I copied and wrapped errors to apr errors instead of the generic APR_EGENERAL) Bert > > Kevin R. >
