New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
curl can't connect thought NTLM proxy with --proxy-any option #876
Comments
The proxy supports Negotiate which is prefered over NTLM so curl tries using GSSAPI and it fails. |
Ok, why needed this mode. Some companies have corporate politics use Microsoft Forefront TMG. And when we begin install Linux the problems begin. Many programs use the curl, but to tell them that they must use --proxy-ntlm option is impossible.
What we want? We want that Linux workstation can work in Windows network. Able update via package manager (yum, dnf, aptitude, etc) download files via wget, send bug reports via gnome-abrt, and of course expected if it was a server all server software php, python etc able work via curl (SOAP) with external services of course without rewriting this software. Here needed yet another option in environment which would be ignore GSSAPI faiure or ignore GSSAPI faiure by default. Thanks. |
On Tuesday, June 14, 2016 10:19:05 Mikhail wrote:
Thank you for providing the background info. Could this be resolved Kamil
|
Unfortunately we can not affect admins which tuning the proxy server. If we could we already agreed about opening required ports to the Internet. We have already found a workaround this is cntlm proxy which installed on our side and pass all queries to NTLM proxy. But I would like that curl can do it directly. Linux should to be more friendlier and more comfortable this only way breaks through the way to desktop. What is wrong with cntlm? Main problem is installation this package, because package managers couldn't work (they use of course curl, but curl by default not work with NTLM), also not work wget. Only one way to install cntlm is manually download it with command curl --proxy-ntlm -O https://kojipkgs.fedoraproject.org/packages/cntlm/0.92.3/9.fc24/x86_64/cntlm-0.92.3-9.fc24.x86_64.rpm Second problem for downloading cntlm package we must know full url to it. For compare with Windows, for starting work enough enter proxy address and credentials. |
That should of course be enough clues for libcurl to decide that it should rather try another allowed authentication mechanism... |
Please see a possible fix for HTTP (works for me): It is a bit ugly because we clear 'data->state.authhost.avail' once we pick one auth from all the available ones (supported by the server), however we still have this info in 'data->info.httpauthavail'. |
Hmm, I think this patch assumes Negotiate header is the first header. |
I've pushed a fix that I think addresses #718 for the most part which was built off some work I was doing back in March that I have recently pushed - However in this fix I have assumed we should let GSS-API based empty user names through as the user will be coming from the credientals cache. I understand that even then it could fail so we could modify either this function or the new Curl_auth_is_spnego_supported() function to try and attempt to generate a token. |
Does anyone know why we clear this here? It's been baffling me for a few days now! |
I don't recall exactly, but I think it may just be a precaution for the next request using the same easy handle? |
Yea, maybe we can call gss_inquire_cred() in the new Curl_auth_is_spnego_supported() check. |
Actually, maybe it's better to attempt to generate a token instead of calling gss_inquire_cred() because it would help to detect possible failure due to improper target name, e.g. when IP is used instead of hostname (and no reverse dns available). |
Any updates here? For me problem still actual for use Linux in Windows environment (AD + NTLM proxy). |
NTLM works for me if SPEGNO isn't compiled in, and I don't use the any-proxy option. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Please not close this without fixing. |
Unless someone steps up and work on this issue, it will be added to KNOWN_BUGS and closed within soon. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Please not close this without fixing. |
We will most likely close this and add a note to |
If you can provide a reproducible test for this then the likelyhood that a developer will look at it increases dramatically. |
That would require a test environment with an ntlm proxy, do any developers
have one? Or can acquire one?
…On Sun., 28 Oct. 2018, 2:30 am Daniel Gustafsson, ***@***.***> wrote:
Please not close this without fixing.
If you can provide a reproducible test for this then the likelyhood that a
developer will look at it increases dramatically.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#876 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABkgS8qyFGjvRC2zxF6rR3JhOZ2t79Ajks5upKY3gaJpZM4I1dPY>
.
|
Without a reproducible test case we can't move anywhere on this issue and keeping it open by commenting every 6 months just annoys us all. I would strongly urge everyone who experiences this bug to work on setting up an easily reproducible set in order to get someone else to help out with debugging.
This is not a complete command line. |
It not easy because such proxies only inhabit in Windows domain. So it also means that is impossible connect outside to such proxies. Therefore, I don’t even know how to help you. I think I will try to find somewhere Microsoft Forefront distribution to deploy it in our network.
All proxy settings are configured via environment variables.
|
I've never set up an ntlm proxy,
Only suffered a long way down stream from them.
I did spin up a Microsoft cloud computer to test an sql server issue,
Does anyone know if we could get forefront running on something like that?
or whatever the proxy software is called.
Perhaps if the curl website could put out a call to some friendly corporate
supporter to help in this regard?
Microsoft has Ubuntu running on Windows now, perhaps an opportunity there?
I don't have the personal connections to help set up an environment you
could use for a test case,
But hopefully the curl software is so popular that there is some connection
that way?
…On Wed., 7 Nov. 2018, 4:56 pm Mikhail ***@***.*** wrote:
Without a reproducible test case we can't move anywhere on this issue and
keeping it open by commenting every 6 months just annoys us all. I would *strongly
urge* everyone who experiences this bug to work on setting up an easily
reproducible set in order to get someone else to help out with debugging.
It not easy because such proxies only inhabit in Windows domain. So it
also means that is impossible connect outside to such proxies.
Usually as Linux integrator we have a problem when we install our system
in an organization where admins have a principled standpoint not to let
anything pass to internet directly.
And we have no choice but to deal with Microsoft Forefront, which only
auth by NTLM.
Therefore, I don’t even know how to help you. I think I will try to find
somewhere Microsoft Forefront distribution to deploy it in our network.
$ LD_LIBRARY_PATH=/home/synergy/curl/curl/lib/.libs curl -v --proxy-any
http://google.com
This is not a complete command line. --proxy-any asks for NTLM with the
proxy, but you must also specify the proxy to use etc.
All proxy settings are configured via environment variables.
***@***.***:8080
https_proxy=$http_proxy
export http_proxy
export https_proxy
no_proxy=127.0.0.1,10.18.1.57
export no_proxy
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#876 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABkgS67kOdSespEWAZGxTApKLI4pNQp4ks5usqBLgaJpZM4I1dPY>
.
|
On 7 Nov 2018, at 14:05, paulharris ***@***.***> wrote:
Perhaps if the curl website could put out a call to some friendly corporate
supporter to help in this regard?
I’m not sure how effective that would be to be honest, the individuals who has the ability to set something like this us might not be casually browsing the curl website.
More effective is probably if those affected by this could raise such a call for participation on the curl-library mailing list, and then spread the word linking to the discussion there. The odds of “the right people” being subscribed to the mailinglist is probably higher.
|
Regarding the email, it would be better if it came from the developers who
will be running these tests.
What do you guys need ? What will you work with?
If I email the list, I'll be acting as middle man, because what I would
like is probably not what you would like.
I only hack on libcurl when I need to move past a bug, but this environment
is required for the longer term.
Also I want to point out that in a Windows environment, the user should not
have to specify a proxy.
Windows has a proxy detection system, and as a result, users likely don't
know what the proxy is.
Example of how to do it is here:
https://github.com/paulharris/libdetectproxy
On Wed, 7 Nov 2018 at 21:17, Daniel Gustafsson <notifications@github.com>
wrote:
… > On 7 Nov 2018, at 14:05, paulharris ***@***.***> wrote:
> Perhaps if the curl website could put out a call to some friendly
corporate
> supporter to help in this regard?
I’m not sure how effective that would be to be honest, the individuals who
has the ability to set something like this us might not be casually
browsing the curl website.
More effective is probably if those affected by this could raise such a
call for participation on the curl-library mailing list, and then spread
the word linking to the discussion there. The odds of “the right people”
being subscribed to the mailinglist is probably higher.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#876 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABkgS1ONkW9PGMxcd1XyCMNJouo0FvOXks5ust1ygaJpZM4I1dPY>
.
|
My recommendation here is that we close this issue as a known bug since we clearly aren't making any progress. The next step is to await someone sending an email to curl-library@ soliciting for access to an environment where this can be reproduced. If noone else sends it I suggest that either of you send it @paulharris @NTMan, being stakeholders in this. All we can do then is to hope that someone steps up and helps out. I'll go ahead and open a PR for the |
Add the identified issue with --proxy-any and proxy servers which advertise authentication schemes other than the supported one. Closes curl#876 Reported-by: NTMan on Github
curl can't connect thought NTLM proxy with --proxy-any option
Operating system Fedora 23 and RHEL 7.
This problem occurred if curl compiled with
--with-gssapi
option.The text was updated successfully, but these errors were encountered: