In managed code, if you want to write a sockets level client, you would just
use the NegotiateStream class. In native code, you usually attack this at
the SSPI level using InitializeSecurityContext on the client side.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--

In this particular case a client application needs to have access to
another server through an NTLMv2 server.

What is an NTLMv2 server? AFAIK such a thing does not exist.

Windows already provides the underlying functionality to negotiate NTLM
authentication, without you needing to know that much about the actual
protocol itself.

Cheers
Ken

[quoted text, click to view]

In this particular case a client application needs to have access to
another server through an NTLMv2 server.

On Mar 19, 1:01=A0pm, "Joe Kaplan"
[quoted text, click to view]

I have some more information now. The client OS would have already
authenticated with a domain controller that the NTLMv2 proxy server
knows about. This authentication would have occurred when the user
logs on the client machine.

Now the question becomes: Exactly how does an application on the
client machine communicate this prior authorization to the proxy
server such that the proxy server will permit the client application
to post messages through this proxy?

I would estimate that there would be at least three aspects to this
answer:
(1) The client application is somehow configured to be a trusted
application,
(2) One or more functions are required to communicate the prior
authentication information from the client application to the proxy
server,
(3) These functions require specific parameters that are obtained from

It sounds like you are just trying to provide credentials to an HTTP proxy
server that requires authentication when making some type of programmatic
HTTP request (like a web service call or something). Is that correct?

If so, then in managed code you just need to set UseDefaultCredentials to
true on your WebProxy instance that you configure when setting up your
WebRequest class. The underlying framework should then handle the
authentication to the proxy server for you based on the security context of
the executing thread on the client application. You should not have to
program this explicitly.

If you want to do this in native code, I'm pretty sure all of the same stuff
is supported in WinHTTP.

Joe K.
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--

I have some more information now. The client OS would have already
authenticated with a domain controller that the NTLMv2 proxy server
knows about. This authentication would have occurred when the user
logs on the client machine.

Now the question becomes: Exactly how does an application on the
client machine communicate this prior authorization to the proxy
server such that the proxy server will permit the client application
to post messages through this proxy?

I would estimate that there would be at least three aspects to this
answer:
(1) The client application is somehow configured to be a trusted
application,
(2) One or more functions are required to communicate the prior
authentication information from the client application to the proxy
server,
(3) These functions require specific parameters that are obtained from
the client OS.