Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Negotiate WinSSPI
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Maksym Tkachov via curl-users <curl-users_at_lists.haxx.se>
Date: Mon, 9 May 2022 17:33:47 +0200
Hi
At my job I faced an issue while running a *WebService* locally and doing
authentication into it also locally. *WebService* uses *Waffle* with *SSPI*
through *JNA* and expects *Negotiate* mech to be used for auth and from
the client side I use *Java's* *HttpClient (Apache)* with configured to use
*WindowsNegotiateScheme* which uses *SSPI* through *JNA*. While doing
*Wireshark* I found that under *Negotiate* *NTLM* is being used and second
call on the client side into *InitializeSecurityContext* returns an invalid
token which cannot be parsed by *Wireshark* and is said to be invalid by
the *WebService* with an error *SEC_INVALID_TOKEN*, but the call to
*InitializeSecurityContext* returned *SEC_I_CONTINUE_NEEDED*.
First thing I've tried is to use our client written in *C#* to do the same
thing and it succeeds. The second token returned from the client in
*Wireshark* is valid and is accepted by the *WebService* to the auth
continues and succeeds. In *C#* client we are using *WebClient* with
default creds.
Second thing I've tried to generate manually the token interacting directly
with *Secur32* lib from a *C++* test app, but I've just reproduced the
error. So by this I would say *JNA* is not the issue.
I've also tried different *ISC_REQ flags* while calling
*InitializeSecurityContext*, but nothing helped.
Third thing I've tried to use cUrl which turned out to be working and doing
the auth.
I've gone through cUrl sources to understand what is the difference to my
C++ code, but I couldn't find any.
Can you suggest something?
Thank you in advance
Maksym
Date: Mon, 9 May 2022 17:33:47 +0200
Hi
At my job I faced an issue while running a *WebService* locally and doing
authentication into it also locally. *WebService* uses *Waffle* with *SSPI*
through *JNA* and expects *Negotiate* mech to be used for auth and from
the client side I use *Java's* *HttpClient (Apache)* with configured to use
*WindowsNegotiateScheme* which uses *SSPI* through *JNA*. While doing
*Wireshark* I found that under *Negotiate* *NTLM* is being used and second
call on the client side into *InitializeSecurityContext* returns an invalid
token which cannot be parsed by *Wireshark* and is said to be invalid by
the *WebService* with an error *SEC_INVALID_TOKEN*, but the call to
*InitializeSecurityContext* returned *SEC_I_CONTINUE_NEEDED*.
First thing I've tried is to use our client written in *C#* to do the same
thing and it succeeds. The second token returned from the client in
*Wireshark* is valid and is accepted by the *WebService* to the auth
continues and succeeds. In *C#* client we are using *WebClient* with
default creds.
Second thing I've tried to generate manually the token interacting directly
with *Secur32* lib from a *C++* test app, but I've just reproduced the
error. So by this I would say *JNA* is not the issue.
I've also tried different *ISC_REQ flags* while calling
*InitializeSecurityContext*, but nothing helped.
Third thing I've tried to use cUrl which turned out to be working and doing
the auth.
I've gone through cUrl sources to understand what is the difference to my
C++ code, but I couldn't find any.
Can you suggest something?
Thank you in advance
Maksym
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-users Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2022-05-09