Steve,

> > [...] However, I'm still not absolutely sure whether
> > this is really a libcurl problem or whether some configuration issues
> > on the proxy side at least contribute to the problem.
>
> Sure - if it is a problem in libcurl I would like to be able to
> resolve it as well. So any assistance you can provide in identifying
> the issue would be great.

In any case I will give feedback here.

> I could be wrong here but I believe that:
>
> a) The SSPI builds when no user name is supplied will use the current
> user credentials and as such the domain will be included
>
> b) If the username is specified in the SSPI build then the domain is
> optional - if no domain is included then the server should default to
> one.
>
> c) If the non-SSPI build is used then the user has to be specified but
> the domain is also optional - if no domain is included then the server
> should default to one just like with b).

Looking up the wrong domain could certainly be part of the problem, but on
the proxy side, not libcurl.

> Do you know if this is a multi-domain/forest setup?

The Windows client machines are certainly set up in different domains in
different countries. However, the user ids are unique for the whole company
worldwide. Active Directory is used for looking up user credentials.

> Are the 70+ users that you are having difficulty with, in different
> domains to that of the proxy servers?

I don't think so, but I don't know for sure.

> I've not played around with multi-domains too much myself apart from a
> little testing here and there so I'm not sure how a server would pick
> the correct domain to use. From my own testing of GSSAPI (Kerberos v5
> authentication) that I've added for the email protocols in the
> upcoming release, the domain *had* to be included when specifying the
> username manually but it is optional with NTLM.

I hope the IT guy watching the proxy side tomorrow will be able to check this.

> I take it both IE and Firefox users are prompted for their credentials
> and as such single sign-on isn't used?

As far as I know the company switched to single sign-on not too long ago.
And that could be part of the problem, because the Internet access problems
for my users started thereafter.

> In the SSPI code the call to process the type-2 and generate the
> type-3 is done in a single call InitializeSecurityContext() so from
> here at least, it is quite difficult to know what failed. Only the
> base-64 decoding of the message is performed by libcurl in this
> instance. We would need to examine the "status" variable to have a
> better idea but I'm guessing there was something in the type-2 that
> the local machine (that running your app/libcurl) didn't like -
> whether that is unmatched security settings such as encryption level,
> a difference in supported protocol versions (NTLM vs NTLMv2 for
> example) or something else I can't say.

Maybe I manage to add some debug messages to the code.

> > I'll take a look tomorrow and will prepare several versions for the tests on
> > Wednesday (SSPI, non-SSPI, additional messages ...). I really have to get
> > this working somehow ...
>
> Cool - I would also recommend you test the SSPI builds with and
> without single sign-on support.

That's the plan. I'll try to prepare several test scenarios to get as much
information from the tests as possible.

> Also out of interest what Proxy Server software is the client using?

As far as I know on most proxy servers McAfee Web Gateway is used.

> Is it the same across all of the servers?

I guess not. I got a log today from a user located in the U.S.A. For him the
NTLM authentication worked. He uses a different proxy server, and it seems
that the proxy server software is not McAfee Web Gateway.

Regards,

Ulrich

-- 
E-Mail privat:  Ulrich.Telle_at_gmx.de
World Wide Web: http://www.telle-online.de
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html