Re: NTLM proxy authentication...
On Fri, 2014-03-21 at 12:03 -0400, Ray Williams Robinson Valiente wrote:
Hi again:
Problem is in company proxy configuration I guess. I have tried setting no
proxy domain and it worked fine. For some reason HttpClient fails to
authenticate when the proxy domain is set (even when I'm pretty sure it's
correct, since it's the same proxy domain I have in cntlm configuration).
Is there any reason for this?
Ray,
There is only one person on the project who understands NTLM protocol.
You might want to post your question to the dev list along with a
wireshark packet dump and kindly ask for help there.
Oleg
2014-03-21 11:48 GMT-04:00 Ray Williams Robinson Valiente
shaka.shad...@gmail.com:
Hi:
Code remains the same, here is the logging output:
2014/03/21 11:43:44:075 EDT [DEBUG] RequestAddCookies - CookieSpec
selected: best-match
2014/03/21 11:43:44:105 EDT [DEBUG] RequestAuthCache - Auth cache not set
in the context
2014/03/21 11:43:44:106 EDT [DEBUG] PoolingHttpClientConnectionManager -
Connection request: [route: {tls}-http://proxy.hab.desoft.cu:3128-
https://www.google.com.cu:443][total kept alive: 0; route allocated: 0
of 2; total allocated: 0 of 20]
2014/03/21 11:43:44:122 EDT [DEBUG] PoolingHttpClientConnectionManager -
Connection leased: [id: 0][route: {tls}-http://proxy.hab.desoft.cu:3128-
https://www.google.com.cu:443][total kept alive: 0; route allocated: 1
of 2; total allocated: 1 of 20]
2014/03/21 11:43:44:129 EDT [DEBUG] MainClientExec - Opening connection
{tls}-http://proxy.hab.desoft.cu:3128-https://www.google.com.cu:443
2014/03/21 11:43:44:132 EDT [DEBUG] HttpClientConnectionOperator -
Connecting to proxy.hab.desoft.cu/10.176.0.2:3128
2014/03/21 11:43:44:141 EDT [DEBUG] HttpClientConnectionOperator -
Connection established 10.176.0.170:54967-10.176.0.2:3128
2014/03/21 11:43:44:143 EDT [DEBUG] headers - http-outgoing-0 CONNECT
www.google.com.cu:443 HTTP/1.1
2014/03/21 11:43:44:143 EDT [DEBUG] headers - http-outgoing-0 Host:
www.google.com.cu
2014/03/21 11:43:44:143 EDT [DEBUG] headers - http-outgoing-0
Proxy-Connection: Keep-Alive
2014/03/21 11:43:44:146 EDT [DEBUG] headers - http-outgoing-0 HTTP/1.0
407 Proxy Authentication Required
2014/03/21 11:43:44:146 EDT [DEBUG] headers - http-outgoing-0 Server:
squid/3.1.20
2014/03/21 11:43:44:146 EDT [DEBUG] headers - http-outgoing-0
Mime-Version: 1.0
2014/03/21 11:43:44:146 EDT [DEBUG] headers - http-outgoing-0 Date:
Fri, 21 Mar 2014 15:44:01 GMT
2014/03/21 11:43:44:146 EDT [DEBUG] headers - http-outgoing-0
Content-Type: text/html
2014/03/21 11:43:44:146 EDT [DEBUG] headers - http-outgoing-0
Content-Length: 3177
2014/03/21 11:43:44:146 EDT [DEBUG] headers - http-outgoing-0
X-Squid-Error: ERR_CACHE_ACCESS_DENIED 0
2014/03/21 11:43:44:146 EDT [DEBUG] headers - http-outgoing-0
Proxy-Authenticate: NTLM
2014/03/21 11:43:44:146 EDT [DEBUG] headers - http-outgoing-0 X-Cache:
MISS from proxy.hab.desoft.cu
2014/03/21 11:43:44:146 EDT [DEBUG] headers - http-outgoing-0
X-Cache-Lookup: NONE from proxy.hab.desoft.cu:3128
2014/03/21 11:43:44:147 EDT [DEBUG] headers - http-outgoing-0 Via: 1.0
proxy.hab.desoft.cu (squid/3.1.20)
2014/03/21 11:43:44:147 EDT [DEBUG] headers - http-outgoing-0
Connection: close
2014/03/21 11:43:44:148 EDT [DEBUG] HttpAuthenticator - Authentication
required
2014/03/21 11:43:44:148 EDT [DEBUG] HttpAuthenticator -
proxy.hab.desoft.cu:3128 requested authentication
2014/03/21 11:43:44:148 EDT [DEBUG] ProxyAuthenticationStrategy -
Authentication schemes in the order of preference: [negotiate, Kerberos,
NTLM, Digest, Basic]
2014/03/21 11:43:44:148 EDT [DEBUG] ProxyAuthenticationStrategy -
Challenge for negotiate authentication scheme not available
2014/03/21 11:43:44:148 EDT [DEBUG] ProxyAuthenticationStrategy -
Challenge for Kerberos authentication scheme not available
2014/03/21 11:43:44:152 EDT [DEBUG] ProxyAuthenticationStrategy -
Challenge for Digest authentication scheme not available
2014/03/21 11:43:44:152 EDT [DEBUG] ProxyAuthenticationStrategy -
Challenge for Basic authentication scheme not available
2014/03/21 11:43:44:152 EDT [DEBUG] HttpAuthenticator - Selected
authentication options: [NTLM]
2014/03/21 11:43:44:153 EDT [DEBUG] DefaultManagedHttpClientConnection -
http-outgoing-0: Close connection
2014/03/21 11:43:44:153 EDT [DEBUG] HttpClientConnectionOperator -
Connecting to proxy.hab.desoft.cu/10.176.0.2:3128
2014/03/21 11:43:44:155 EDT [DEBUG] HttpClientConnectionOperator -
Connection established 10.176.0.170:54968-10.176.0.2:3128
2014/03/21 11:43:44:155 EDT [DEBUG] HttpAuthenticator - Generating
response to an authentication challenge using ntlm scheme
2014/03/21 11:43:44:164 EDT [DEBUG] headers - http-outgoing-0 CONNECT
www.google.com.cu:443 HTTP/1.1
2014/03/21 11:43:44:164 EDT [DEBUG] headers - http-outgoing-0 Host:
www.google.com.cu
Re: NTLM proxy authentication...
Hi:
Code remains the same, here is the logging output:
2014/03/21 11:43:44:075 EDT [DEBUG] RequestAddCookies - CookieSpec
selected: best-match
2014/03/21 11:43:44:105 EDT [DEBUG] RequestAuthCache - Auth cache not set
in the context
2014/03/21 11:43:44:106 EDT [DEBUG] PoolingHttpClientConnectionManager -
Connection request: [route: {tls}-http://proxy.hab.desoft.cu:3128-
https://www.google.com.cu:443][total kept alive: 0; route allocated: 0 of
2; total allocated: 0 of 20]
2014/03/21 11:43:44:122 EDT [DEBUG] PoolingHttpClientConnectionManager -
Connection leased: [id: 0][route: {tls}-http://proxy.hab.desoft.cu:3128-
https://www.google.com.cu:443][total kept alive: 0; route allocated: 1 of
2; total allocated: 1 of 20]
2014/03/21 11:43:44:129 EDT [DEBUG] MainClientExec - Opening connection
{tls}-http://proxy.hab.desoft.cu:3128-https://www.google.com.cu:443
2014/03/21 11:43:44:132 EDT [DEBUG] HttpClientConnectionOperator -
Connecting to proxy.hab.desoft.cu/10.176.0.2:3128
2014/03/21 11:43:44:141 EDT [DEBUG] HttpClientConnectionOperator -
Connection established 10.176.0.170:54967-10.176.0.2:3128
2014/03/21 11:43:44:143 EDT [DEBUG] headers - http-outgoing-0 CONNECT
www.google.com.cu:443 HTTP/1.1
2014/03/21 11:43:44:143 EDT [DEBUG] headers - http-outgoing-0 Host:
www.google.com.cu
2014/03/21 11:43:44:143 EDT [DEBUG] headers - http-outgoing-0
Proxy-Connection: Keep-Alive
2014/03/21 11:43:44:146 EDT [DEBUG] headers - http-outgoing-0 HTTP/1.0
407 Proxy Authentication Required
2014/03/21 11:43:44:146 EDT [DEBUG] headers - http-outgoing-0 Server:
squid/3.1.20
2014/03/21 11:43:44:146 EDT [DEBUG] headers - http-outgoing-0
Mime-Version: 1.0
2014/03/21 11:43:44:146 EDT [DEBUG] headers - http-outgoing-0 Date: Fri,
21 Mar 2014 15:44:01 GMT
2014/03/21 11:43:44:146 EDT [DEBUG] headers - http-outgoing-0
Content-Type: text/html
2014/03/21 11:43:44:146 EDT [DEBUG] headers - http-outgoing-0
Content-Length: 3177
2014/03/21 11:43:44:146 EDT [DEBUG] headers - http-outgoing-0
X-Squid-Error: ERR_CACHE_ACCESS_DENIED 0
2014/03/21 11:43:44:146 EDT [DEBUG] headers - http-outgoing-0
Proxy-Authenticate: NTLM
2014/03/21 11:43:44:146 EDT [DEBUG] headers - http-outgoing-0 X-Cache:
MISS from proxy.hab.desoft.cu
2014/03/21 11:43:44:146 EDT [DEBUG] headers - http-outgoing-0
X-Cache-Lookup: NONE from proxy.hab.desoft.cu:3128
2014/03/21 11:43:44:147 EDT [DEBUG] headers - http-outgoing-0 Via: 1.0
proxy.hab.desoft.cu (squid/3.1.20)
2014/03/21 11:43:44:147 EDT [DEBUG] headers - http-outgoing-0
Connection: close
2014/03/21 11:43:44:148 EDT [DEBUG] HttpAuthenticator - Authentication
required
2014/03/21 11:43:44:148 EDT [DEBUG] HttpAuthenticator -
proxy.hab.desoft.cu:3128 requested authentication
2014/03/21 11:43:44:148 EDT [DEBUG] ProxyAuthenticationStrategy -
Authentication schemes in the order of preference: [negotiate, Kerberos,
NTLM, Digest, Basic]
2014/03/21 11:43:44:148 EDT [DEBUG] ProxyAuthenticationStrategy - Challenge
for negotiate authentication scheme not available
2014/03/21 11:43:44:148 EDT [DEBUG] ProxyAuthenticationStrategy - Challenge
for Kerberos authentication scheme not available
2014/03/21 11:43:44:152 EDT [DEBUG] ProxyAuthenticationStrategy - Challenge
for Digest authentication scheme not available
2014/03/21 11:43:44:152 EDT [DEBUG] ProxyAuthenticationStrategy - Challenge
for Basic authentication scheme not available
2014/03/21 11:43:44:152 EDT [DEBUG] HttpAuthenticator - Selected
authentication options: [NTLM]
2014/03/21 11:43:44:153 EDT [DEBUG] DefaultManagedHttpClientConnection -
http-outgoing-0: Close connection
2014/03/21 11:43:44:153 EDT [DEBUG] HttpClientConnectionOperator -
Connecting to proxy.hab.desoft.cu/10.176.0.2:3128
2014/03/21 11:43:44:155 EDT [DEBUG] HttpClientConnectionOperator -
Connection established 10.176.0.170:54968-10.176.0.2:3128
2014/03/21 11:43:44:155 EDT [DEBUG] HttpAuthenticator - Generating response
to an authentication challenge using ntlm scheme
2014/03/21 11:43:44:164 EDT [DEBUG] headers - http-outgoing-0 CONNECT
www.google.com.cu:443 HTTP/1.1
2014/03/21 11:43:44:164 EDT [DEBUG] headers - http-outgoing-0 Host:
www.google.com.cu
2014/03/21 11:43:44:164 EDT [DEBUG] headers - http-outgoing-0
Proxy-Connection: Keep-Alive
2014/03/21 11:43:44:164 EDT [DEBUG] headers - http-outgoing-0
Proxy-Authorization: NTLM
TlRMTVNTUAABAYIIogAoACgFASgKDw==
2014/03/21 11:43:44:166 EDT [DEBUG] headers - http-outgoing-0 HTTP/1.0
407 Proxy Authentication Required
2014/03/21 11:43:44:166 EDT [DEBUG] headers - http-outgoing-0 Server:
squid/3.1.20
2014/03/21 11:43:44:166 EDT [DEBUG] headers - http-outgoing-0
Mime-Version: 1.0
2014/03/21 11:43:44:166 EDT [DEBUG] headers - http-outgoing-0 Date: Fri,
21 Mar 2014 15:44:01 GMT
2014/03/21 11:43:44:166 EDT [DEBUG] headers - http-outgoing-0
Content-Type: text/html
2014/03/21 11:43:44:166 EDT [DEBUG] headers - http-outgoing-0
Content-Length: 3275
2014/03/21 11:43:44:166 EDT [DEBUG] headers - http-outgoing-0
X-Squid-Error:
Re: NTLM proxy authentication...
Hi again:
Problem is in company proxy configuration I guess. I have tried setting no
proxy domain and it worked fine. For some reason HttpClient fails to
authenticate when the proxy domain is set (even when I'm pretty sure it's
correct, since it's the same proxy domain I have in cntlm configuration).
Is there any reason for this?
2014-03-21 11:48 GMT-04:00 Ray Williams Robinson Valiente
shaka.shad...@gmail.com:
Hi:
Code remains the same, here is the logging output:
2014/03/21 11:43:44:075 EDT [DEBUG] RequestAddCookies - CookieSpec
selected: best-match
2014/03/21 11:43:44:105 EDT [DEBUG] RequestAuthCache - Auth cache not set
in the context
2014/03/21 11:43:44:106 EDT [DEBUG] PoolingHttpClientConnectionManager -
Connection request: [route: {tls}-http://proxy.hab.desoft.cu:3128-
https://www.google.com.cu:443][total kept alive: 0; route allocated: 0
of 2; total allocated: 0 of 20]
2014/03/21 11:43:44:122 EDT [DEBUG] PoolingHttpClientConnectionManager -
Connection leased: [id: 0][route: {tls}-http://proxy.hab.desoft.cu:3128-
https://www.google.com.cu:443][total kept alive: 0; route allocated: 1
of 2; total allocated: 1 of 20]
2014/03/21 11:43:44:129 EDT [DEBUG] MainClientExec - Opening connection
{tls}-http://proxy.hab.desoft.cu:3128-https://www.google.com.cu:443
2014/03/21 11:43:44:132 EDT [DEBUG] HttpClientConnectionOperator -
Connecting to proxy.hab.desoft.cu/10.176.0.2:3128
2014/03/21 11:43:44:141 EDT [DEBUG] HttpClientConnectionOperator -
Connection established 10.176.0.170:54967-10.176.0.2:3128
2014/03/21 11:43:44:143 EDT [DEBUG] headers - http-outgoing-0 CONNECT
www.google.com.cu:443 HTTP/1.1
2014/03/21 11:43:44:143 EDT [DEBUG] headers - http-outgoing-0 Host:
www.google.com.cu
2014/03/21 11:43:44:143 EDT [DEBUG] headers - http-outgoing-0
Proxy-Connection: Keep-Alive
2014/03/21 11:43:44:146 EDT [DEBUG] headers - http-outgoing-0 HTTP/1.0
407 Proxy Authentication Required
2014/03/21 11:43:44:146 EDT [DEBUG] headers - http-outgoing-0 Server:
squid/3.1.20
2014/03/21 11:43:44:146 EDT [DEBUG] headers - http-outgoing-0
Mime-Version: 1.0
2014/03/21 11:43:44:146 EDT [DEBUG] headers - http-outgoing-0 Date:
Fri, 21 Mar 2014 15:44:01 GMT
2014/03/21 11:43:44:146 EDT [DEBUG] headers - http-outgoing-0
Content-Type: text/html
2014/03/21 11:43:44:146 EDT [DEBUG] headers - http-outgoing-0
Content-Length: 3177
2014/03/21 11:43:44:146 EDT [DEBUG] headers - http-outgoing-0
X-Squid-Error: ERR_CACHE_ACCESS_DENIED 0
2014/03/21 11:43:44:146 EDT [DEBUG] headers - http-outgoing-0
Proxy-Authenticate: NTLM
2014/03/21 11:43:44:146 EDT [DEBUG] headers - http-outgoing-0 X-Cache:
MISS from proxy.hab.desoft.cu
2014/03/21 11:43:44:146 EDT [DEBUG] headers - http-outgoing-0
X-Cache-Lookup: NONE from proxy.hab.desoft.cu:3128
2014/03/21 11:43:44:147 EDT [DEBUG] headers - http-outgoing-0 Via: 1.0
proxy.hab.desoft.cu (squid/3.1.20)
2014/03/21 11:43:44:147 EDT [DEBUG] headers - http-outgoing-0
Connection: close
2014/03/21 11:43:44:148 EDT [DEBUG] HttpAuthenticator - Authentication
required
2014/03/21 11:43:44:148 EDT [DEBUG] HttpAuthenticator -
proxy.hab.desoft.cu:3128 requested authentication
2014/03/21 11:43:44:148 EDT [DEBUG] ProxyAuthenticationStrategy -
Authentication schemes in the order of preference: [negotiate, Kerberos,
NTLM, Digest, Basic]
2014/03/21 11:43:44:148 EDT [DEBUG] ProxyAuthenticationStrategy -
Challenge for negotiate authentication scheme not available
2014/03/21 11:43:44:148 EDT [DEBUG] ProxyAuthenticationStrategy -
Challenge for Kerberos authentication scheme not available
2014/03/21 11:43:44:152 EDT [DEBUG] ProxyAuthenticationStrategy -
Challenge for Digest authentication scheme not available
2014/03/21 11:43:44:152 EDT [DEBUG] ProxyAuthenticationStrategy -
Challenge for Basic authentication scheme not available
2014/03/21 11:43:44:152 EDT [DEBUG] HttpAuthenticator - Selected
authentication options: [NTLM]
2014/03/21 11:43:44:153 EDT [DEBUG] DefaultManagedHttpClientConnection -
http-outgoing-0: Close connection
2014/03/21 11:43:44:153 EDT [DEBUG] HttpClientConnectionOperator -
Connecting to proxy.hab.desoft.cu/10.176.0.2:3128
2014/03/21 11:43:44:155 EDT [DEBUG] HttpClientConnectionOperator -
Connection established 10.176.0.170:54968-10.176.0.2:3128
2014/03/21 11:43:44:155 EDT [DEBUG] HttpAuthenticator - Generating
response to an authentication challenge using ntlm scheme
2014/03/21 11:43:44:164 EDT [DEBUG] headers - http-outgoing-0 CONNECT
www.google.com.cu:443 HTTP/1.1
2014/03/21 11:43:44:164 EDT [DEBUG] headers - http-outgoing-0 Host:
www.google.com.cu
2014/03/21 11:43:44:164 EDT [DEBUG] headers - http-outgoing-0
Proxy-Connection: Keep-Alive
2014/03/21 11:43:44:164 EDT [DEBUG] headers - http-outgoing-0
Proxy-Authorization: NTLM
TlRMTVNTUAABAYIIogAoACgFASgKDw==
2014/03/21 11:43:44:166 EDT [DEBUG] headers - http-outgoing-0 HTTP/1.0
407 Proxy Authentication Required
2014/03/21
Re: NTLM proxy authentication...
On Wed, 2014-03-19 at 14:46 -0400, Ray Williams Robinson Valiente wrote: Hi: I'm a fairly new with HttpClient. I'm trying to test it against a NTLM proxy but I'm getting error 407 over and over again. What should be the correct way to do it? My current code looks like (with proper values for declared constants): Ray, I see nothing wrong with your code. Please try running your application with wire / context logging on. There is a chance there might be clues in the logs as to what is causing the authentication failure. http://hc.apache.org/httpcomponents-client-4.3.x/logging.html Oleg - To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
NTLM proxy authentication...
Hi:
I'm a fairly new with HttpClient. I'm trying to test it against a NTLM
proxy but I'm getting error 407 over and over again. What should be
the correct way to do it? My current code looks like (with proper
values for declared constants):
import java.io.BufferedReader;
import java.io.InputStreamReader;
import java.io.PrintWriter;
import java.net.InetAddress;
import java.net.UnknownHostException;
import java.security.cert.CertificateException;
import java.security.cert.X509Certificate;
import javax.net.ssl.SSLContext;
import org.apache.http.HttpHost;
import org.apache.http.HttpResponse;
import org.apache.http.auth.AuthScope;
import org.apache.http.auth.NTCredentials;
import org.apache.http.client.CredentialsProvider;
import org.apache.http.client.HttpClient;
import org.apache.http.client.config.RequestConfig;
import org.apache.http.client.methods.HttpGet;
import org.apache.http.client.methods.HttpRequestBase;
import org.apache.http.conn.ssl.SSLConnectionSocketFactory;
import org.apache.http.conn.ssl.SSLContexts;
import org.apache.http.conn.ssl.TrustStrategy;
import org.apache.http.impl.client.BasicCookieStore;
import org.apache.http.impl.client.BasicCredentialsProvider;
import org.apache.http.impl.client.HttpClientBuilder;
import org.apache.http.impl.client.LaxRedirectStrategy;
import org.jsoup.Jsoup;
import org.jsoup.nodes.Document;
import org.jsoup.nodes.Element;
import org.jsoup.select.Elements;
public class HttpJsoupTest {
private static HttpClient httpClient;
private static final String url =
https://www.google.com.cu/search?sclient=psy-abq=netbeans+plugin+djangobtnG=Buscar;;
private static final String USER_AGENT = Mozilla/5.0 (Windows NT
6.1; rv:25.0) Gecko/20100101 Firefox/25.0;
private static final String PROXY_HOST = ;
private static final String PROXY_DOMAIN = ;
private static final int PROXY_PORT = 3128;
private static final String PROXY_USERNAME = ;
private static final String PROXY_PASSWORD = ;
private static final PrintWriter pw = new PrintWriter(System.out, true);
private static final HttpHost PROXY = new HttpHost(PROXY_HOST,
PROXY_PORT);
public static void main(String[] args) throws Exception {
httpClient = HttpClientBuilder
.create()
.setRedirectStrategy(new LaxRedirectStrategy())
.setDefaultCookieStore(new BasicCookieStore())
.setSSLSocketFactory(builConnectionSocketFactory())
.setDefaultCredentialsProvider(getProxyAuthCredentialsProvider())
.build();
String pageContent = doGetAsString(url);
...
perform some work with page content
...
}
private static CredentialsProvider getProxyAuthCredentialsProvider()
throws UnknownHostException {
CredentialsProvider credentialsProvider = new
BasicCredentialsProvider();
credentialsProvider.setCredentials(
new AuthScope(PROXY_HOST, PROXY_PORT,
AuthScope.ANY_REALM, ntlm),
new NTCredentials(PROXY_USERNAME,
PROXY_PASSWORD,
InetAddress.getLocalHost().getHostName(), PROXY_DOMAIN));
return credentialsProvider;
}
private static SSLConnectionSocketFactory builConnectionSocketFactory()
throws Exception {
SSLContext sslcontext = SSLContexts.custom()
.loadTrustMaterial(null, new TrustStrategy() {
@Override
public boolean isTrusted(final
X509Certificate[] chain,
final String authType)
throws CertificateException {
return true;
}
}).build();
SSLConnectionSocketFactory sslsf = new
SSLConnectionSocketFactory(
sslcontext,
SSLConnectionSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER);
return sslsf;
}
private static void setProxyHost(HttpRequestBase request) {
RequestConfig config =
RequestConfig.custom().setProxy(PROXY).build();
request.setConfig(config);
}
public static String doGetAsString(String URL) throws Exception {
pw.printf(Sending 'GET' request to URL : %s\n, url);
HttpGet request = new HttpGet(url);
setProxyHost(request);
request.setHeader(User-Agent, USER_AGENT);
request.setHeader(Accept-Encoding, gzip, deflate);
request.setHeader(Connection,
Re: NTLM proxy authentication is failing with McAfee web gateway proxy server
On Wed, 2013-02-06 at 08:29 +0530, Deepak Mishra wrote: Had attached the log files but not able to see them on mail thread, so attaching the same again. thank you, deepak Deepak I see nothing wrong on the HTTP level. There must be some kind of incompatibility at the NTLM protocol level. Please capture both sessions with Wireshart (it has to be Wireshark), raise a JIRA and attach both packet dumps to it. Hopefully Karl will be kind enough to take a look. Oleg -- Forwarded message -- From: Deepak Mishra dkmishra...@gmail.com Date: Wed, Feb 6, 2013 at 6:27 AM Subject: NTLM proxy authentication is failing with McAfee web gateway proxy server To: HttpClient User Discussion httpclient-users@hc.apache.org Hi, We are using HttpClient 4.2.3 to communicate to an internet URL through a proxy server. Proxy server has NTLM authentication integrated with an Active Directory. We are able to do NTLM authentication with Ubuntu 12.04 Squid proxy server but not able to do NTLM authentication with McAfee webgateway proxy server. I am attaching HttpClient debug log for both the cases. Can some one please take a look at the logs and tell me why NTLM authentication is failing with McAfee webgateway proxy server. I am using same code to communicate with both of them. Following is the code. DefaultHttpClientclient = new DefaultHttpClient(); HttpHost host = new HttpHost(proxyServer, port); client.getParams().setParameter(ConnRoutePNames.DEFAULT_PROXY, host); NTCredentials creds = new NTCredentials(userName, password, InetAddress.getLocalHost().getHostName(), domain); client.getCredentialsProvider().setCredentials(new AuthScope(host, AuthScope.ANY_REALM, AuthPolicy.NTLM), creds); HttpGet httpMethod = new HttpGet(url); HttpResponse response = client.execute(httpMethod); BasicResponseHandler responseHandler = new BasicResponseHandler(); return responseHandler.handleResponse(response); thank you for help, deepak - To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org - To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
Re: NTLM proxy authentication is failing with McAfee web gateway proxy server
Try using jcifs jar . I had the same issue which got resolved using jcifs jar. On Wed, Feb 6, 2013 at 5:45 PM, Oleg Kalnichevski ol...@apache.org wrote: On Wed, 2013-02-06 at 08:29 +0530, Deepak Mishra wrote: Had attached the log files but not able to see them on mail thread, so attaching the same again. thank you, deepak Deepak I see nothing wrong on the HTTP level. There must be some kind of incompatibility at the NTLM protocol level. Please capture both sessions with Wireshart (it has to be Wireshark), raise a JIRA and attach both packet dumps to it. Hopefully Karl will be kind enough to take a look. Oleg -- Forwarded message -- From: Deepak Mishra dkmishra...@gmail.com Date: Wed, Feb 6, 2013 at 6:27 AM Subject: NTLM proxy authentication is failing with McAfee web gateway proxy server To: HttpClient User Discussion httpclient-users@hc.apache.org Hi, We are using HttpClient 4.2.3 to communicate to an internet URL through a proxy server. Proxy server has NTLM authentication integrated with an Active Directory. We are able to do NTLM authentication with Ubuntu 12.04 Squid proxy server but not able to do NTLM authentication with McAfee webgateway proxy server. I am attaching HttpClient debug log for both the cases. Can some one please take a look at the logs and tell me why NTLM authentication is failing with McAfee webgateway proxy server. I am using same code to communicate with both of them. Following is the code. DefaultHttpClientclient = new DefaultHttpClient(); HttpHost host = new HttpHost(proxyServer, port); client.getParams().setParameter(ConnRoutePNames.DEFAULT_PROXY, host); NTCredentials creds = new NTCredentials(userName, password, InetAddress.getLocalHost().getHostName(), domain); client.getCredentialsProvider().setCredentials(new AuthScope(host, AuthScope.ANY_REALM, AuthPolicy.NTLM), creds); HttpGet httpMethod = new HttpGet(url); HttpResponse response = client.execute(httpMethod); BasicResponseHandler responseHandler = new BasicResponseHandler(); return responseHandler.handleResponse(response); thank you for help, deepak - To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org - To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
NTLM proxy authentication is failing with McAfee web gateway proxy server
Hi, We are using HttpClient 4.2.3 to communicate to an internet URL through a proxy server. Proxy server has NTLM authentication integrated with an Active Directory. We are able to do NTLM authentication with Ubuntu 12.04 Squid proxy server but not able to do NTLM authentication with McAfee webgateway proxy server. I am attaching HttpClient debug log for both the cases. Can some one please take a look at the logs and tell me why NTLM authentication is failing with McAfee webgateway proxy server. I am using same code to communicate with both of them. Following is the code. DefaultHttpClientclient = new DefaultHttpClient(); HttpHost host = new HttpHost(proxyServer, port); client.getParams().setParameter(ConnRoutePNames.DEFAULT_PROXY, host); NTCredentials creds = new NTCredentials(userName, password, InetAddress.getLocalHost().getHostName(), domain); client.getCredentialsProvider().setCredentials(new AuthScope(host, AuthScope.ANY_REALM, AuthPolicy.NTLM), creds); HttpGet httpMethod = new HttpGet(url); HttpResponse response = client.execute(httpMethod); BasicResponseHandler responseHandler = new BasicResponseHandler(); return responseHandler.handleResponse(response); thank you for help, deepak - To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
Re: Problems with NTLM proxy authentication and SystemDefaultHttpClient
On 13 December 2012 09:24, Oleg Kalnichevski ol...@apache.org wrote: On Wed, 2012-12-12 at 09:28 -0700, Daz DeBoer wrote: Hi First of all thanks for the great library. As a core Gradle developer, I really appreciate the power and flexibility that comes with HttpClient. (Gradle made the switch from java.net.URL based downloading to using HttpClient over a year ago.) While it seems to work most of the time, occasionally we have users who are not able to authenticate to a proxy using NTLM. (We are using JCIFS-based NTLMEngine). At first I thought this was just a protocol problem, but working with a user recently I'm not so sure. This user reports that they are able to authenticate to their proxy over NTLM with test code using the DefaultHttpClient, but are not able to using the SystemDefaultHttpClient after setting what look like the correct properties. They are also unable to use Gradle to authenticate to the proxy. Since Gradle is using the SystemDefaultHttpClient under the covers, I'm interested in how this could make a difference, and whether this could be the cause of this user's problems with Gradle. The relevant code and output is here: --- Using org.apache.http.impl.client.DefaultHttpClient (working) * Code : https://gist.github.com/77f7f4278612d38cb554 * Logs : https://gist.github.com/42057219f8903f3b92d2 Using org.apache.http.impl.client.SystemDefaultHttpClient * Code : https://gist.github.com/99f166b73f60176bab39 * Logs : https://gist.github.com/7f2c4af8b6532f8e9d0c The input proxy credentials are same for both the tests. I've looked at the code/output but I'm not sure what could be causing the differences. My suspicion is ProxySelectorRoutePlanner, but I don't know how that could affect authentication. Any hints? Thanks Hi Daz I may have found the culprit. Could you please see if the 'http.keepAlive' system property on your system is set to anything other than 'true'? The user has confirmed that NTLM authentication works correctly with http.keepAlive='true'. When we upgrade Gradle to HttpClient 4.3 we'll be sure to correct this issue. Thanks again for helping us track this down, Oleg. cheers Daz - To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
Re: Problems with NTLM proxy authentication and SystemDefaultHttpClient
On Wed, 2012-12-12 at 09:28 -0700, Daz DeBoer wrote: Hi First of all thanks for the great library. As a core Gradle developer, I really appreciate the power and flexibility that comes with HttpClient. (Gradle made the switch from java.net.URL based downloading to using HttpClient over a year ago.) While it seems to work most of the time, occasionally we have users who are not able to authenticate to a proxy using NTLM. (We are using JCIFS-based NTLMEngine). At first I thought this was just a protocol problem, but working with a user recently I'm not so sure. This user reports that they are able to authenticate to their proxy over NTLM with test code using the DefaultHttpClient, but are not able to using the SystemDefaultHttpClient after setting what look like the correct properties. They are also unable to use Gradle to authenticate to the proxy. Since Gradle is using the SystemDefaultHttpClient under the covers, I'm interested in how this could make a difference, and whether this could be the cause of this user's problems with Gradle. The relevant code and output is here: --- Using org.apache.http.impl.client.DefaultHttpClient (working) * Code : https://gist.github.com/77f7f4278612d38cb554 * Logs : https://gist.github.com/42057219f8903f3b92d2 Using org.apache.http.impl.client.SystemDefaultHttpClient * Code : https://gist.github.com/99f166b73f60176bab39 * Logs : https://gist.github.com/7f2c4af8b6532f8e9d0c The input proxy credentials are same for both the tests. I've looked at the code/output but I'm not sure what could be causing the differences. My suspicion is ProxySelectorRoutePlanner, but I don't know how that could affect authentication. Any hints? Thanks Hi Daz I may have found the culprit. Could you please see if the 'http.keepAlive' system property on your system is set to anything other than 'true'? Oleg - To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
Problems with NTLM proxy authentication and SystemDefaultHttpClient
Hi First of all thanks for the great library. As a core Gradle developer, I really appreciate the power and flexibility that comes with HttpClient. (Gradle made the switch from java.net.URL based downloading to using HttpClient over a year ago.) While it seems to work most of the time, occasionally we have users who are not able to authenticate to a proxy using NTLM. (We are using JCIFS-based NTLMEngine). At first I thought this was just a protocol problem, but working with a user recently I'm not so sure. This user reports that they are able to authenticate to their proxy over NTLM with test code using the DefaultHttpClient, but are not able to using the SystemDefaultHttpClient after setting what look like the correct properties. They are also unable to use Gradle to authenticate to the proxy. Since Gradle is using the SystemDefaultHttpClient under the covers, I'm interested in how this could make a difference, and whether this could be the cause of this user's problems with Gradle. The relevant code and output is here: --- Using org.apache.http.impl.client.DefaultHttpClient (working) * Code : https://gist.github.com/77f7f4278612d38cb554 * Logs : https://gist.github.com/42057219f8903f3b92d2 Using org.apache.http.impl.client.SystemDefaultHttpClient * Code : https://gist.github.com/99f166b73f60176bab39 * Logs : https://gist.github.com/7f2c4af8b6532f8e9d0c The input proxy credentials are same for both the tests. I've looked at the code/output but I'm not sure what could be causing the differences. My suspicion is ProxySelectorRoutePlanner, but I don't know how that could affect authentication. Any hints? Thanks -- Darrell (Daz) DeBoer Principal Engineer, Gradleware http://www.gradleware.com - To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
Re: Problems with NTLM proxy authentication and SystemDefaultHttpClient
On Wed, 2012-12-12 at 09:28 -0700, Daz DeBoer wrote: Hi First of all thanks for the great library. As a core Gradle developer, I really appreciate the power and flexibility that comes with HttpClient. (Gradle made the switch from java.net.URL based downloading to using HttpClient over a year ago.) While it seems to work most of the time, occasionally we have users who are not able to authenticate to a proxy using NTLM. (We are using JCIFS-based NTLMEngine). At first I thought this was just a protocol problem, but working with a user recently I'm not so sure. This user reports that they are able to authenticate to their proxy over NTLM with test code using the DefaultHttpClient, but are not able to using the SystemDefaultHttpClient after setting what look like the correct properties. They are also unable to use Gradle to authenticate to the proxy. Since Gradle is using the SystemDefaultHttpClient under the covers, I'm interested in how this could make a difference, and whether this could be the cause of this user's problems with Gradle. The relevant code and output is here: --- Using org.apache.http.impl.client.DefaultHttpClient (working) * Code : https://gist.github.com/77f7f4278612d38cb554 * Logs : https://gist.github.com/42057219f8903f3b92d2 Using org.apache.http.impl.client.SystemDefaultHttpClient * Code : https://gist.github.com/99f166b73f60176bab39 * Logs : https://gist.github.com/7f2c4af8b6532f8e9d0c The input proxy credentials are same for both the tests. I've looked at the code/output but I'm not sure what could be causing the differences. My suspicion is ProxySelectorRoutePlanner, but I don't know how that could affect authentication. Any hints? Thanks Hi Daz ProxySelectorRoutePlanner appears to be the most likely culprit but I cannot spot anything obviously wrong from the logs. My recommendation would be to stop using SystemDefaultHttpClient (it will be deprecated in 4.3 anyway) and apply system settings selectively once by one in order to narrow down possible causes. I'll try to have a closer look at the logs in the coming days. Oleg - To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
Re: Issue with NTLM proxy authentication over Https
Thanks For your reply Oleg.
I tried out ProxyClient as mentioned by you and it seems to work :).
But i get the following lines in as warnings in my log files :-
*2012-10-12 16:17:56,539 WARN [http-8443-Processor68]
protocol.RequestProxyAuthentication - NEGOTIATE authentication error:
Invalid name provided (Mechanism level: Could not load configuration file
C:\Windows\krb5.ini (The system cannot find the file specified))*
*2012-10-12 16:17:56,540 WARN [http-8443-Processor68]
protocol.RequestProxyAuthentication - KERBEROS authentication error:
Invalid name provided (Mechanism level: Could not load configuration file
C:\Windows\krb5.ini (The system cannot find the file specified))*
*
*
Can you please let me know if there is some problem in the following code.
..
* org.apache.http.impl.client.ProxyClient pc = new
org.apache.http.impl.client.ProxyClient();*
* org.apache.http.HttpHost proxyHost = new
org.apache.http.HttpHost(tcp.getProxyHost(), tcp.getProxyPort());*
* org.apache.http.HttpHost targetHost = new org.apache.http.HttpHost(host,
port, https);*
* org.apache.http.auth.Credentials credentials =
getNTCredentials(tcp.getProxyUser(), tcp.getProxyPassword());*
* socket = pc.tunnel(proxyHost, targetHost, credentials);*
* if (socket.isConnected())*
* {*
* return socket;*
* }*
...
Thanks,
Anirban
On Thu, Oct 11, 2012 at 8:37 PM, Oleg Kalnichevski ol...@apache.org wrote:
On Thu, 2012-10-11 at 16:44 +0530, anir . wrote:
Hi Dave,
Thanks for your reply but i can't use the cron job in my present
environment .
I was looking for some workaround (if any) using httpClient itself.
Moreover this is a pretty generalized code for all AuthSchemes and so i
don't want to break
the uniformity.
Thanks for your help .
Regards,
Anirban
Anirban
NTLM scheme is significantly more complex that basic or digest schemes
and requires a sequence of three request / response exchanges over a
persistent connection. You probably should consider using ProxyClient
provided with HttpClient as of release 4.2 or take up on Dave's offer.
Oleg
-
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org
Re: Issue with NTLM proxy authentication over Https
On 12 October 2012 12:10, anir . anir1...@gmail.com wrote:
Thanks For your reply Oleg.
I tried out ProxyClient as mentioned by you and it seems to work :).
But i get the following lines in as warnings in my log files :-
*2012-10-12 16:17:56,539 WARN [http-8443-Processor68]
protocol.RequestProxyAuthentication - NEGOTIATE authentication error:
Invalid name provided (Mechanism level: Could not load configuration file
C:\Windows\krb5.ini (The system cannot find the file specified))*
The above message should be a big clue to what is wrong with your setup.
*2012-10-12 16:17:56,540 WARN [http-8443-Processor68]
protocol.RequestProxyAuthentication - KERBEROS authentication error:
Invalid name provided (Mechanism level: Could not load configuration file
C:\Windows\krb5.ini (The system cannot find the file specified))*
Does the file exist?
*
*
Can you please let me know if there is some problem in the following code.
..
* org.apache.http.impl.client.ProxyClient pc = new
org.apache.http.impl.client.ProxyClient();*
* org.apache.http.HttpHost proxyHost = new
org.apache.http.HttpHost(tcp.getProxyHost(), tcp.getProxyPort());*
* org.apache.http.HttpHost targetHost = new org.apache.http.HttpHost(host,
port, https);*
* org.apache.http.auth.Credentials credentials =
getNTCredentials(tcp.getProxyUser(), tcp.getProxyPassword());*
* socket = pc.tunnel(proxyHost, targetHost, credentials);*
* if (socket.isConnected())*
* {*
* return socket;*
* }*
...
Thanks,
Anirban
On Thu, Oct 11, 2012 at 8:37 PM, Oleg Kalnichevski ol...@apache.org wrote:
On Thu, 2012-10-11 at 16:44 +0530, anir . wrote:
Hi Dave,
Thanks for your reply but i can't use the cron job in my present
environment .
I was looking for some workaround (if any) using httpClient itself.
Moreover this is a pretty generalized code for all AuthSchemes and so i
don't want to break
the uniformity.
Thanks for your help .
Regards,
Anirban
Anirban
NTLM scheme is significantly more complex that basic or digest schemes
and requires a sequence of three request / response exchanges over a
persistent connection. You probably should consider using ProxyClient
provided with HttpClient as of release 4.2 or take up on Dave's offer.
Oleg
-
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org
-
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org
RE: Issue with NTLM proxy authentication over Https
On Thu, 2012-10-11 at 11:53 -0500, Godbey, David J. (HQ-LM020)[DIGITAL MANAGEMENT INC.] wrote: Oleg, Wow, you have a proxy client? I should give that a look. Anirban: My problem was this: 1. My JAXWS client for the EWS service does not manage authentication because JAXWS itself does not manage authentication. 2. To authenticate, I used java.net.Authenticator. However, the Authenticator does not support NTLMv2. My solution was this: 1. Created a local endpoint (servlet) for the JAXWS client instead of the EWS service (EWS endpoint is SSL with NTLMv2). 2. The servlet (using HttpClient 4.2) received the raw SOAP request and the list of headers. 3. Using httpclient (4.2) pack up a post with the SOAP request, bring over the relevant headers, and send the post to the EWS endpoint. 4. The servlet succeeds and receives the SOAP response that it then returns to the JAXWS client. With that, I am back in business. Oleg, Can I remove my local endpoint servlet, return the JAXWS client to point directly to the EWS SSL NTLMv2 service, and set java -D directives to specify an authenticating proxy that I will build from HttpClient ProxyClient? Can this work? Dave Dave, ProxyClient is probably not a very good name. SSL tunnel client should be descriptive. The purpose of this client is to create a tunnel through an HTTP proxy for non-HTTP protocols such as SSH or SMTP. Naturally, it could also be used for tunneling HTTP messages though an SSL tunnel but I see very little sense in doing so, as that would give you no advantage over HttpClient. What you have is a very reasonable solution based on a reverse proxy pattern. You should probably stick to it. Oleg - To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
RE: Issue with NTLM proxy authentication over Https
Anirban,
I have a cron job working that successfully connects to an Exchange Web Service
via JAXWS protected by NTLMv2. I can post my code if you think it will help.
Dave
-Original Message-
From: anir . [mailto:anir1...@gmail.com]
Sent: Thursday, October 11, 2012 1:20 AM
To: httpclient-users@hc.apache.org
Subject: Issue with NTLM proxy authentication over Https
Hi,
I am trying to return a secure socket connection from my code if the
authentication through a proxy is successful.
My code is something like this :-
.
*if (tcp.getProxyUser() != null tcp.getProxyPassword() != null) {
*
*// add basic authentication header for the proxy*
*authstring = Basic *
*+ XMLUtils.base64encode((tcp.getProxyUser() + : + tcp
*
*.getProxyPassword()).getBytes());*
*}*
*
*
* //try 3 times*
* for (int i = 0; i = 2; i++) {*
*
*
*repondChallange(out, connect, authstring);*
*
*
*if (processProxyResponse(is)) {*
*return socket;*
*}*
*Header[] headers = extractHeaders(is);*
*authstring = getAuthString(tcp, port, host, headers);*
*while (is.available() 0 is.read() 0) {*
*// read all*
*}*
*if (closeConnection(headers)) {*
*socket.close();*
*socket = new Socket(tcp.getProxyHost(), proxyPort, null,
0);*
*socket.setTcpNoDelay(true);*
*socket.setSoTimeout(0);*
*is = new BufferedInputStream(socket.getInputStream(),
2048);*
*out = new BufferedOutputStream(socket.getOutputStream(),
2048);*
*}*
.
The RespondChallange Method writes to the output stream with headers like
User-Agent: , Proxy-Authorization: .
The method* processProxyResponse(is) *checks for the reply from the proxy
server and returns true only if status code of 200 is encountered.
The getAuthString method basically is a generic method which returns the string
based on the authentication Scheme selected and serves as the value for
*Proxy-Authorization: *header :-
.
*ConnectMethod method = new ConnectMethod();*
*authstring = authscheme.authenticate(credentials, method);*
.
My code works fine for Basic,Digest Authentication but fails for NTLM scheme
with Error code :- 407.
Using the JCIFS library it works though.
Just wanted to know if this is a known problem with apache commons httclient ??
Is there a workaround for this ,since i am not too keen on using JCIFS library
??
Thanks,
Anirban
-
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org
Re: Issue with NTLM proxy authentication over Https
Hi Dave,
Thanks for your reply but i can't use the cron job in my present
environment .
I was looking for some workaround (if any) using httpClient itself.
Moreover this is a pretty generalized code for all AuthSchemes and so i
don't want to break
the uniformity.
Thanks for your help .
Regards,
Anirban
On Thu, Oct 11, 2012 at 4:33 PM, Godbey, David J. (HQ-LM020)[DIGITAL
MANAGEMENT INC.] david.j.god...@nasa.gov wrote:
Anirban,
I have a cron job working that successfully connects to an Exchange Web
Service via JAXWS protected by NTLMv2. I can post my code if you think it
will help.
Dave
-Original Message-
From: anir . [mailto:anir1...@gmail.com]
Sent: Thursday, October 11, 2012 1:20 AM
To: httpclient-users@hc.apache.org
Subject: Issue with NTLM proxy authentication over Https
Hi,
I am trying to return a secure socket connection from my code if the
authentication through a proxy is successful.
My code is something like this :-
.
*if (tcp.getProxyUser() != null tcp.getProxyPassword() != null)
{
*
*// add basic authentication header for the proxy*
*authstring = Basic *
*+ XMLUtils.base64encode((tcp.getProxyUser() + : +
tcp
*
*.getProxyPassword()).getBytes());*
*}*
*
*
* //try 3 times*
* for (int i = 0; i = 2; i++) {*
*
*
*repondChallange(out, connect, authstring);*
*
*
*if (processProxyResponse(is)) {*
*return socket;*
*}*
*Header[] headers = extractHeaders(is);*
*authstring = getAuthString(tcp, port, host, headers);*
*while (is.available() 0 is.read() 0) {*
*// read all*
*}*
*if (closeConnection(headers)) {*
*socket.close();*
*socket = new Socket(tcp.getProxyHost(), proxyPort, null,
0);*
*socket.setTcpNoDelay(true);*
*socket.setSoTimeout(0);*
*is = new BufferedInputStream(socket.getInputStream(),
2048);*
*out = new BufferedOutputStream(socket.getOutputStream(),
2048);*
*}*
.
The RespondChallange Method writes to the output stream with headers like
User-Agent: , Proxy-Authorization: .
The method* processProxyResponse(is) *checks for the reply from the proxy
server and returns true only if status code of 200 is encountered.
The getAuthString method basically is a generic method which returns the
string based on the authentication Scheme selected and serves as the value
for
*Proxy-Authorization: *header :-
.
*ConnectMethod method = new ConnectMethod();*
*authstring = authscheme.authenticate(credentials, method);*
.
My code works fine for Basic,Digest Authentication but fails for NTLM
scheme with Error code :- 407.
Using the JCIFS library it works though.
Just wanted to know if this is a known problem with apache commons
httclient ??
Is there a workaround for this ,since i am not too keen on using JCIFS
library ??
Thanks,
Anirban
-
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org
Re: Issue with NTLM proxy authentication over Https
On Thu, 2012-10-11 at 16:44 +0530, anir . wrote: Hi Dave, Thanks for your reply but i can't use the cron job in my present environment . I was looking for some workaround (if any) using httpClient itself. Moreover this is a pretty generalized code for all AuthSchemes and so i don't want to break the uniformity. Thanks for your help . Regards, Anirban Anirban NTLM scheme is significantly more complex that basic or digest schemes and requires a sequence of three request / response exchanges over a persistent connection. You probably should consider using ProxyClient provided with HttpClient as of release 4.2 or take up on Dave's offer. Oleg - To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
RE: Issue with NTLM proxy authentication over Https
Oleg, Wow, you have a proxy client? I should give that a look. Anirban: My problem was this: 1. My JAXWS client for the EWS service does not manage authentication because JAXWS itself does not manage authentication. 2. To authenticate, I used java.net.Authenticator. However, the Authenticator does not support NTLMv2. My solution was this: 1. Created a local endpoint (servlet) for the JAXWS client instead of the EWS service (EWS endpoint is SSL with NTLMv2). 2. The servlet (using HttpClient 4.2) received the raw SOAP request and the list of headers. 3. Using httpclient (4.2) pack up a post with the SOAP request, bring over the relevant headers, and send the post to the EWS endpoint. 4. The servlet succeeds and receives the SOAP response that it then returns to the JAXWS client. With that, I am back in business. Oleg, Can I remove my local endpoint servlet, return the JAXWS client to point directly to the EWS SSL NTLMv2 service, and set java -D directives to specify an authenticating proxy that I will build from HttpClient ProxyClient? Can this work? Dave -Original Message- From: Oleg Kalnichevski [mailto:ol...@apache.org] Sent: Thursday, October 11, 2012 11:07 AM To: HttpClient User Discussion Subject: Re: Issue with NTLM proxy authentication over Https On Thu, 2012-10-11 at 16:44 +0530, anir . wrote: Hi Dave, Thanks for your reply but i can't use the cron job in my present environment . I was looking for some workaround (if any) using httpClient itself. Moreover this is a pretty generalized code for all AuthSchemes and so i don't want to break the uniformity. Thanks for your help . Regards, Anirban Anirban NTLM scheme is significantly more complex that basic or digest schemes and requires a sequence of three request / response exchanges over a persistent connection. You probably should consider using ProxyClient provided with HttpClient as of release 4.2 or take up on Dave's offer. Oleg - To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
NTLM proxy authentication
Hello,
I am having a problem with getting HttpClient to send requests through a proxy
demanding NTLM authentication, which I understand should be possible.
My code for trying to accomplish this:
Credentials credentials;
try {
credentials = new NTCredentials(proxyUsername, proxyPassword,
InetAddress.getLocalHost().getHostName(), proxyDomain);
} catch (Exception e) {
throw new SessionException(Unable to create NTLM credentials for
proxy authentication, e);
}
client.getCredentialsProvider().setCredentials(new AuthScope(proxyHostname,
proxyPort), credentials);
HttpHost proxyHost = new HttpHost(proxyHostname, proxyPort);
client.getParams().setParameter(ConnRoutePNames.DEFAULT_PROXY, proxyHost);
AuthScheme proxyAuthScheme = new
NTLMSchemeFactory().newInstance(client.getParams());
authCache.put(proxyHost, proxyAuthScheme);
But I am apparently missing something, since it does not work.
The authCache is later added to the context used in the execute call. Without
this, I get an error about missing an ini-file - looks like an attempt to use
Kerberos.
The full log of the interaction is pasted below. As can also be seen in the
log, I am using HttpClient v. 4.1.3.
Best regards,
Telenor
Thomas Vestergaard
Ekstern konsulent
Technology
Frederikskaj, DK-1780. København V
Tel: +45 52 18 92 18 // e-mail: cget...@telenor.dkmailto:cget...@telenor.dk
Web: http://www.telenor.dkhttp://www.telenor.dk/
DEBUG [org.apache.http.impl.conn.SingleClientConnManager] Get connection for
route HttpRoute[{}-http://tmgproxy.telenor.dk:8080-http://hc.apache.org:80]
DEBUG [org.apache.http.impl.conn.DefaultClientConnectionOperator] Connecting to
tmgproxy.telenor.dk:8080
DEBUG [org.apache.http.client.protocol.RequestAddCookies] CookieSpec selected:
best-match
DEBUG [org.apache.http.client.protocol.RequestAuthCache] Re-using cached 'ntlm'
auth scheme for http://tmgproxy.telenor.dk:8080
DEBUG [org.apache.http.impl.client.DefaultHttpClient] Attempt 1 to execute
request
DEBUG [org.apache.http.impl.conn.DefaultClientConnection] Sending request: GET
http://hc.apache.org:80/httpcomponents-client-ga/tutorial/html/authentication.html
HTTP/1.1
DEBUG [org.apache.http.headers] GET
http://hc.apache.org:80/httpcomponents-client-ga/tutorial/html/authentication.html
HTTP/1.1
DEBUG [org.apache.http.headers] Host: hc.apache.org:80
DEBUG [org.apache.http.headers] Proxy-Connection: Keep-Alive
DEBUG [org.apache.http.headers] User-Agent: Apache-HttpClient/4.1.3 (java
1.5)
DEBUG [org.apache.http.impl.conn.DefaultClientConnection] Receiving response:
HTTP/1.1 407 Proxy Authentication Required ( Forefront TMG requires
authorization to fulfill the request. Access to the Web Proxy filter is denied.
)
DEBUG [org.apache.http.headers] HTTP/1.1 407 Proxy Authentication Required (
Forefront TMG requires authorization to fulfill the request. Access to the Web
Proxy filter is denied. )
DEBUG [org.apache.http.headers] Via: 1.1 IVABTMG02
DEBUG [org.apache.http.headers] Proxy-Authenticate: Negotiate
DEBUG [org.apache.http.headers] Proxy-Authenticate: Kerberos
DEBUG [org.apache.http.headers] Proxy-Authenticate: NTLM
DEBUG [org.apache.http.headers] Connection: Keep-Alive
DEBUG [org.apache.http.headers] Proxy-Connection: Keep-Alive
DEBUG [org.apache.http.headers] Pragma: no-cache
DEBUG [org.apache.http.headers] Cache-Control: no-cache
DEBUG [org.apache.http.headers] Content-Type: text/html
DEBUG [org.apache.http.headers] Content-Length: 3670
DEBUG [org.apache.http.impl.client.DefaultHttpClient] Connection can be kept
alive indefinitely
DEBUG [org.apache.http.impl.client.DefaultHttpClient] Proxy requested
authentication
DEBUG [org.apache.http.impl.client.DefaultHttpClient] Authorization challenge
processed
DEBUG [org.apache.http.impl.client.DefaultHttpClient] Authentication scope:
NTLM any realm@tmgproxy.telenor.dk:8080
DEBUG [org.apache.http.client.protocol.RequestAddCookies] CookieSpec selected:
best-match
DEBUG [org.apache.http.impl.client.DefaultHttpClient] Attempt 2 to execute
request
DEBUG [org.apache.http.impl.conn.DefaultClientConnection] Sending request: GET
http://hc.apache.org:80/httpcomponents-client-ga/tutorial/html/authentication.html
HTTP/1.1
DEBUG [org.apache.http.headers] GET
http://hc.apache.org:80/httpcomponents-client-ga/tutorial/html/authentication.html
HTTP/1.1
DEBUG [org.apache.http.headers] Host: hc.apache.org:80
DEBUG [org.apache.http.headers] Proxy-Connection: Keep-Alive
DEBUG [org.apache.http.headers] User-Agent: Apache-HttpClient/4.1.3 (java
1.5)
DEBUG [org.apache.http.headers] Proxy-Authorization: NTLM
TlRMTVNTUAABNQIIIAwADAA8HAAcACBYAFAARgBFAFAAQwBDAEcARQBUAEgAVgBFAFQAUwBPAE4ARgBPAE4A
DEBUG [org.apache.http.impl.conn.DefaultClientConnection] Receiving response:
HTTP/1.1 407 Proxy Authentication Required ( Access is denied. )
DEBUG [org.apache.http.headers] HTTP/1.1 407 Proxy Authentication Required (
Access is denied. )
DEBUG [org.apache.http.headers]
SV: NTLM proxy authentication
Hi,
Just to follow up, I got NTLM proxy to work - atleast partly by using JCIFS as
described on: http://hc.apache.org/httpcomponents-client-ga/ntlm.html
However, I still have a number of use-cases, where my implementation fails.
From what I can gather from the logs, it has to do with missing proxy auth of
redirects. (See below.)
I there something I need to set or override to enable authentication on each
connection rather than request?
Or is it possible to prevent the client from closing the connection between the
two GET's? (Regardless of this problem, it seems wasteful. But I might be
mistaken.)
Best regards,
Thomas
[snip - initial GET resulting in 307 Temporary Redirect]
DEBUG [org.apache.http.impl.conn.DefaultClientConnection] Receiving response:
HTTP/1.1 307 Temporary Redirect
DEBUG [org.apache.http.headers] HTTP/1.1 307 Temporary Redirect
DEBUG [org.apache.http.headers] Accept-Ranges: bytes
DEBUG [org.apache.http.headers] Age: 0
DEBUG [org.apache.http.headers] Content-Type: application/xml
DEBUG [org.apache.http.headers] Date: Tue, 20 Mar 2012 14:51:56 GMT
DEBUG [org.apache.http.headers] Location:
https://partner.com/users/42/info?apiuserid=TNDK
DEBUG [org.apache.http.headers] Server: Jetty(8.0.0.M2)
DEBUG [org.apache.http.headers] Via: 1.1 varnish
DEBUG [org.apache.http.headers] X-Varnish: 1790574415
DEBUG [org.apache.http.headers] Content-Length: 0
DEBUG [org.apache.http.headers] Connection: keep-alive
DEBUG [org.apache.http.client.protocol.ResponseAuthCache] Caching 'basic' auth
scheme for https://partner.com
DEBUG [org.apache.http.impl.client.DefaultRedirectStrategy] Redirect requested
to location 'https://partner.com/id/users/42/info?apiuserid=TNDK'
DEBUG [org.apache.http.impl.client.DefaultHttpClient] Redirecting to
'https://partner.com/id/users/42/info?apiuserid=TNDK' via
HttpRoute[{tls}-http://tmgproxy.telenor.dk:8080-https://partner.com]
DEBUG [org.apache.http.impl.conn.DefaultClientConnection] Connection closed
DEBUG [org.apache.http.impl.conn.DefaultClientConnectionOperator] Connecting to
tmgproxy.telenor.dk:8080
DEBUG [org.apache.http.client.protocol.RequestAuthCache] Re-using cached 'ntlm'
auth scheme for http://tmgproxy.telenor.dk:8080
DEBUG [org.apache.http.impl.conn.DefaultClientConnection] Sending request:
CONNECT partner.com:443 HTTP/1.1
DEBUG [org.apache.http.headers] CONNECT partner.com:443 HTTP/1.1
DEBUG [org.apache.http.headers] Host: partner.com
DEBUG [org.apache.http.headers] Proxy-Connection: Keep-Alive
DEBUG [org.apache.http.headers] User-Agent: Apache-HttpClient/4.1.3 (java
1.5)
DEBUG [org.apache.http.impl.conn.DefaultClientConnection] Receiving response:
HTTP/1.1 407 Proxy Authentication Required ( Forefront TMG requires
authorization to fulfill the request. Access to the Web Proxy filter is denied.
)
DEBUG [org.apache.http.headers] HTTP/1.1 407 Proxy Authentication Required (
Forefront TMG requires authorization to fulfill the request. Access to the Web
Proxy filter is denied. )
DEBUG [org.apache.http.headers] Via: 1.1 IVABTMG02
DEBUG [org.apache.http.headers] Proxy-Authenticate: Negotiate
DEBUG [org.apache.http.headers] Proxy-Authenticate: Kerberos
DEBUG [org.apache.http.headers] Proxy-Authenticate: NTLM
DEBUG [org.apache.http.headers] Connection: close
DEBUG [org.apache.http.headers] Proxy-Connection: close
DEBUG [org.apache.http.headers] Pragma: no-cache
DEBUG [org.apache.http.headers] Cache-Control: no-cache
DEBUG [org.apache.http.headers] Content-Type: text/html
DEBUG [org.apache.http.headers] Content-Length: 2687
DEBUG [org.apache.http.impl.client.DefaultHttpClient] Proxy requested
authentication
DEBUG [org.apache.http.impl.client.DefaultHttpClient] Authorization challenge
processed
DEBUG [org.apache.http.impl.client.DefaultHttpClient] Authentication scope:
NTLM any realm@tmgproxy.telenor.dk:8080
DEBUG [org.apache.http.impl.client.DefaultHttpClient] Authentication failed
DEBUG [org.apache.http.impl.conn.DefaultClientConnection] Connection closed
DEBUG [org.apache.http.impl.client.DefaultHttpClient] CONNECT refused by proxy:
HTTP/1.1 407 Proxy Authentication Required ( Forefront TMG requires
authorization to fulfill the request. Access to the Web Proxy filter is denied.
)
DEBUG [org.apache.http.impl.conn.SingleClientConnManager] Releasing connection
org.apache.http.impl.conn.SingleClientConnManager$ConnAdapter@1f78040
-Oprindelig meddelelse-
Fra: Thomas Vestergaard [mailto:cget...@telenor.dk]
Sendt: 20. marts 2012 13:35
Til: httpclient-users@hc.apache.org
Emne: NTLM proxy authentication
Hello,
I am having a problem with getting HttpClient to send requests through a proxy
demanding NTLM authentication, which I understand should be possible.
My code for trying to accomplish this:
Credentials credentials;
try {
credentials = new NTCredentials(proxyUsername, proxyPassword,
InetAddress.getLocalHost().getHostName(), proxyDomain);
} catch (Exception e) {
throw new
SV: NTLM proxy authentication
Hi again,
Updating to version 4.2-beta1 solved the problem.
Best regards,
Thomas
-Oprindelig meddelelse-
Fra: Thomas Vestergaard [mailto:cget...@telenor.dk]
Sendt: 20. marts 2012 16:26
Til: HttpClient User Discussion
Emne: SV: NTLM proxy authentication
Hi,
Just to follow up, I got NTLM proxy to work - atleast partly by using JCIFS as
described on: http://hc.apache.org/httpcomponents-client-ga/ntlm.html
However, I still have a number of use-cases, where my implementation fails.
From what I can gather from the logs, it has to do with missing proxy auth of
redirects. (See below.)
I there something I need to set or override to enable authentication on each
connection rather than request?
Or is it possible to prevent the client from closing the connection between the
two GET's? (Regardless of this problem, it seems wasteful. But I might be
mistaken.)
Best regards,
Thomas
[snip - initial GET resulting in 307 Temporary Redirect]
DEBUG [org.apache.http.impl.conn.DefaultClientConnection] Receiving response:
HTTP/1.1 307 Temporary Redirect
DEBUG [org.apache.http.headers] HTTP/1.1 307 Temporary Redirect
DEBUG [org.apache.http.headers] Accept-Ranges: bytes
DEBUG [org.apache.http.headers] Age: 0
DEBUG [org.apache.http.headers] Content-Type: application/xml
DEBUG [org.apache.http.headers] Date: Tue, 20 Mar 2012 14:51:56 GMT
DEBUG [org.apache.http.headers] Location:
https://partner.com/users/42/info?apiuserid=TNDK
DEBUG [org.apache.http.headers] Server: Jetty(8.0.0.M2)
DEBUG [org.apache.http.headers] Via: 1.1 varnish
DEBUG [org.apache.http.headers] X-Varnish: 1790574415
DEBUG [org.apache.http.headers] Content-Length: 0
DEBUG [org.apache.http.headers] Connection: keep-alive
DEBUG [org.apache.http.client.protocol.ResponseAuthCache] Caching 'basic' auth
scheme for https://partner.com
DEBUG [org.apache.http.impl.client.DefaultRedirectStrategy] Redirect requested
to location 'https://partner.com/id/users/42/info?apiuserid=TNDK'
DEBUG [org.apache.http.impl.client.DefaultHttpClient] Redirecting to
'https://partner.com/id/users/42/info?apiuserid=TNDK' via
HttpRoute[{tls}-http://tmgproxy.telenor.dk:8080-https://partner.com]
DEBUG [org.apache.http.impl.conn.DefaultClientConnection] Connection closed
DEBUG [org.apache.http.impl.conn.DefaultClientConnectionOperator] Connecting to
tmgproxy.telenor.dk:8080
DEBUG [org.apache.http.client.protocol.RequestAuthCache] Re-using cached 'ntlm'
auth scheme for http://tmgproxy.telenor.dk:8080
DEBUG [org.apache.http.impl.conn.DefaultClientConnection] Sending request:
CONNECT partner.com:443 HTTP/1.1
DEBUG [org.apache.http.headers] CONNECT partner.com:443 HTTP/1.1
DEBUG [org.apache.http.headers] Host: partner.com
DEBUG [org.apache.http.headers] Proxy-Connection: Keep-Alive
DEBUG [org.apache.http.headers] User-Agent: Apache-HttpClient/4.1.3 (java
1.5)
DEBUG [org.apache.http.impl.conn.DefaultClientConnection] Receiving response:
HTTP/1.1 407 Proxy Authentication Required ( Forefront TMG requires
authorization to fulfill the request. Access to the Web Proxy filter is denied.
)
DEBUG [org.apache.http.headers] HTTP/1.1 407 Proxy Authentication Required (
Forefront TMG requires authorization to fulfill the request. Access to the Web
Proxy filter is denied. )
DEBUG [org.apache.http.headers] Via: 1.1 IVABTMG02
DEBUG [org.apache.http.headers] Proxy-Authenticate: Negotiate
DEBUG [org.apache.http.headers] Proxy-Authenticate: Kerberos
DEBUG [org.apache.http.headers] Proxy-Authenticate: NTLM
DEBUG [org.apache.http.headers] Connection: close
DEBUG [org.apache.http.headers] Proxy-Connection: close
DEBUG [org.apache.http.headers] Pragma: no-cache
DEBUG [org.apache.http.headers] Cache-Control: no-cache
DEBUG [org.apache.http.headers] Content-Type: text/html
DEBUG [org.apache.http.headers] Content-Length: 2687
DEBUG [org.apache.http.impl.client.DefaultHttpClient] Proxy requested
authentication
DEBUG [org.apache.http.impl.client.DefaultHttpClient] Authorization challenge
processed
DEBUG [org.apache.http.impl.client.DefaultHttpClient] Authentication scope:
NTLM any realm@tmgproxy.telenor.dk:8080
DEBUG [org.apache.http.impl.client.DefaultHttpClient] Authentication failed
DEBUG [org.apache.http.impl.conn.DefaultClientConnection] Connection closed
DEBUG [org.apache.http.impl.client.DefaultHttpClient] CONNECT refused by proxy:
HTTP/1.1 407 Proxy Authentication Required ( Forefront TMG requires
authorization to fulfill the request. Access to the Web Proxy filter is denied.
)
DEBUG [org.apache.http.impl.conn.SingleClientConnManager] Releasing connection
org.apache.http.impl.conn.SingleClientConnManager$ConnAdapter@1f78040
-Oprindelig meddelelse-
Fra: Thomas Vestergaard [mailto:cget...@telenor.dk]
Sendt: 20. marts 2012 13:35
Til: httpclient-users@hc.apache.org
Emne: NTLM proxy authentication
Hello,
I am having a problem with getting HttpClient to send requests through a proxy
demanding NTLM authentication, which I understand should
Re: SV: NTLM proxy authentication
On Tue, 2012-03-20 at 15:26 +, Thomas Vestergaard wrote:
Hi,
Just to follow up, I got NTLM proxy to work - atleast partly by using JCIFS
as described on: http://hc.apache.org/httpcomponents-client-ga/ntlm.html
Unfortunately the default NTLM implementation shipped with HttpClient is
not particularly great. As long as you do not mind using LGPL licensed
software JCIFS is the way to go.
Oleg
However, I still have a number of use-cases, where my implementation fails.
From what I can gather from the logs, it has to do with missing proxy auth of
redirects. (See below.)
I there something I need to set or override to enable authentication on each
connection rather than request?
Or is it possible to prevent the client from closing the connection between
the two GET's? (Regardless of this problem, it seems wasteful. But I might be
mistaken.)
Best regards,
Thomas
[snip - initial GET resulting in 307 Temporary Redirect]
DEBUG [org.apache.http.impl.conn.DefaultClientConnection] Receiving response:
HTTP/1.1 307 Temporary Redirect
DEBUG [org.apache.http.headers] HTTP/1.1 307 Temporary Redirect
DEBUG [org.apache.http.headers] Accept-Ranges: bytes
DEBUG [org.apache.http.headers] Age: 0
DEBUG [org.apache.http.headers] Content-Type: application/xml
DEBUG [org.apache.http.headers] Date: Tue, 20 Mar 2012 14:51:56 GMT
DEBUG [org.apache.http.headers] Location:
https://partner.com/users/42/info?apiuserid=TNDK
DEBUG [org.apache.http.headers] Server: Jetty(8.0.0.M2)
DEBUG [org.apache.http.headers] Via: 1.1 varnish
DEBUG [org.apache.http.headers] X-Varnish: 1790574415
DEBUG [org.apache.http.headers] Content-Length: 0
DEBUG [org.apache.http.headers] Connection: keep-alive
DEBUG [org.apache.http.client.protocol.ResponseAuthCache] Caching 'basic'
auth scheme for https://partner.com
DEBUG [org.apache.http.impl.client.DefaultRedirectStrategy] Redirect
requested to location 'https://partner.com/id/users/42/info?apiuserid=TNDK'
DEBUG [org.apache.http.impl.client.DefaultHttpClient] Redirecting to
'https://partner.com/id/users/42/info?apiuserid=TNDK' via
HttpRoute[{tls}-http://tmgproxy.telenor.dk:8080-https://partner.com]
DEBUG [org.apache.http.impl.conn.DefaultClientConnection] Connection closed
DEBUG [org.apache.http.impl.conn.DefaultClientConnectionOperator] Connecting
to tmgproxy.telenor.dk:8080
DEBUG [org.apache.http.client.protocol.RequestAuthCache] Re-using cached
'ntlm' auth scheme for http://tmgproxy.telenor.dk:8080
DEBUG [org.apache.http.impl.conn.DefaultClientConnection] Sending request:
CONNECT partner.com:443 HTTP/1.1
DEBUG [org.apache.http.headers] CONNECT partner.com:443 HTTP/1.1
DEBUG [org.apache.http.headers] Host: partner.com
DEBUG [org.apache.http.headers] Proxy-Connection: Keep-Alive
DEBUG [org.apache.http.headers] User-Agent: Apache-HttpClient/4.1.3 (java
1.5)
DEBUG [org.apache.http.impl.conn.DefaultClientConnection] Receiving response:
HTTP/1.1 407 Proxy Authentication Required ( Forefront TMG requires
authorization to fulfill the request. Access to the Web Proxy filter is
denied. )
DEBUG [org.apache.http.headers] HTTP/1.1 407 Proxy Authentication Required
( Forefront TMG requires authorization to fulfill the request. Access to the
Web Proxy filter is denied. )
DEBUG [org.apache.http.headers] Via: 1.1 IVABTMG02
DEBUG [org.apache.http.headers] Proxy-Authenticate: Negotiate
DEBUG [org.apache.http.headers] Proxy-Authenticate: Kerberos
DEBUG [org.apache.http.headers] Proxy-Authenticate: NTLM
DEBUG [org.apache.http.headers] Connection: close
DEBUG [org.apache.http.headers] Proxy-Connection: close
DEBUG [org.apache.http.headers] Pragma: no-cache
DEBUG [org.apache.http.headers] Cache-Control: no-cache
DEBUG [org.apache.http.headers] Content-Type: text/html
DEBUG [org.apache.http.headers] Content-Length: 2687
DEBUG [org.apache.http.impl.client.DefaultHttpClient] Proxy requested
authentication
DEBUG [org.apache.http.impl.client.DefaultHttpClient] Authorization challenge
processed
DEBUG [org.apache.http.impl.client.DefaultHttpClient] Authentication scope:
NTLM any realm@tmgproxy.telenor.dk:8080
DEBUG [org.apache.http.impl.client.DefaultHttpClient] Authentication failed
DEBUG [org.apache.http.impl.conn.DefaultClientConnection] Connection closed
DEBUG [org.apache.http.impl.client.DefaultHttpClient] CONNECT refused by
proxy: HTTP/1.1 407 Proxy Authentication Required ( Forefront TMG requires
authorization to fulfill the request. Access to the Web Proxy filter is
denied. )
DEBUG [org.apache.http.impl.conn.SingleClientConnManager] Releasing
connection
org.apache.http.impl.conn.SingleClientConnManager$ConnAdapter@1f78040
-Oprindelig meddelelse-
Fra: Thomas Vestergaard [mailto:cget...@telenor.dk]
Sendt: 20. marts 2012 13:35
Til: httpclient-users@hc.apache.org
Emne: NTLM proxy authentication
Hello,
I am having a problem with getting HttpClient to send
Re: NTLM Proxy Authentication ISA Server
Dear oleg, Sorry for my delay in response. I was away from town. I was mistaken that I am able to connect to the Internal server through IE. Even with IE it was not working. With bit of further googling, we found that it is the problem with the ISA server configuration, where the firewall rule is set to route to a non-standard ssl port for any internal addresses. Working with our network administrators for the same. Thank you for your reply. Regards, Hari olegk wrote: On Thu, 2009-03-26 at 12:28 -0700, pkbharigopal wrote: I am facing a strange problem in using HttpClient with ISA proxy server that supports NTLM. The program I wrote successfully authenticate to proxy using NTLM and retrieve pages if I connect to any external website (ex: www.yahoo.com) both using Http and Https (SSL). The same program through same proxy also works fine, if I connect to an internal host within our same corporate domain, if I use Http. However, it gives 502.2 Bad Gateway error if I connect to the same host using Https (SSL). Are you using a custom SSL socket factory by any chance? Post a complete wire log of the session Oleg I am able to successfully connect to that internal host using normal browser (IE) using both Http and Https (using same proxy). Any help on this is highly appreciated. The code I used is as follows: HttpClient client = new HttpClient(); HostConfiguration config = client.getHostConfiguration(); config.setProxy(proxyHost, proxyPort); NTCredentials credentials = new NTCredentials(userName, password, host, domain); HttpState state = client.getState(); state.setProxyCredentials(domain, proxyHost, credentials); GetMethod httpget = new GetMethod(https://hostname/;); httpget.setDoAuthentication(true); int status = client.executeMethod(httpget); System.out.println(httpget.getStatusLine().toString()); finally release connection.. Regards, hari - To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org -- View this message in context: http://www.nabble.com/NTLM-Proxy-Authentication-ISA-Server-tp22729238p22954363.html Sent from the HttpClient-User mailing list archive at Nabble.com. - To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
NTLM Proxy Authentication ISA Server
I am facing a strange problem in using HttpClient with ISA proxy server that supports NTLM. The program I wrote successfully authenticate to proxy using NTLM and retrieve pages if I connect to any external website (ex: www.yahoo.com) both using Http and Https (SSL). The same program through same proxy also works fine, if I connect to an internal host within our same corporate domain, if I use Http. However, it gives 502.2 Bad Gateway error if I connect to the same host using Https (SSL). I am able to successfully connect to that internal host using normal browser (IE) using both Http and Https (using same proxy). Any help on this is highly appreciated. The code I used is as follows: HttpClient client = new HttpClient(); HostConfiguration config = client.getHostConfiguration(); config.setProxy(proxyHost, proxyPort); NTCredentials credentials = new NTCredentials(userName, password, host, domain); HttpState state = client.getState(); state.setProxyCredentials(domain, proxyHost, credentials); GetMethod httpget = new GetMethod(https://hostname/;); httpget.setDoAuthentication(true); int status = client.executeMethod(httpget); System.out.println(httpget.getStatusLine().toString()); finally release connection.. Regards, hari -- View this message in context: http://www.nabble.com/NTLM-Proxy-Authentication-ISA-Server-tp22729238p22729238.html Sent from the HttpClient-User mailing list archive at Nabble.com. - To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
AW: NTLM-Proxy authentication and SSL-target
The version of Squid you are using appears broken. The proxy keeps one
sending 'Proxy-Connection: close' which is wrong given the fact that NTLM
requires a persistent connection in order to function.
Hi Oleg,
But how can it be explained, that a non-ssl target is handled correct? The
wire-log shows a Proxy-connection: closed too, but the authentication
works fine.
And if I open the ssl-target over a browser (the same proxy is used), it
worked fine, too.
Perhaps, do I have to set some more header fields manually to force the
correct behavior?
Many thanks!
I put in the wire-log of the non-ssl target.
executing request: GET / HTTP/1.1
via proxy: http://s-hqw2k3bd:3128
to target: http://www.verisign.com:80
[DEBUG] ClientParamsStack - 'http.protocol.max-redirects': null
[DEBUG] ClientParamsStack - 'http.route.forced-route': null
[DEBUG] ClientParamsStack - 'http.route.local-address': null
[DEBUG] ClientParamsStack - 'http.route.default-proxy':
http://s-hqw2k3bd:3128
[DEBUG] ClientParamsStack - 'http.conn-manager.timeout': null
[DEBUG] SingleClientConnManager - Get connection for route
HttpRoute[{}-http://s-hqw2k3bd:3128-http://www.verisign.com:80]
[DEBUG] ClientParamsStack - 'http.connection.stalecheck': null
[DEBUG] DefaultRequestDirector - Stale connection check
[DEBUG] DefaultRequestDirector - Stale connection detected
[DEBUG] DefaultClientConnection - Connection closed
[DEBUG] ClientParamsStack - 'http.connection.timeout': null
[DEBUG] ClientParamsStack - 'http.tcp.nodelay': null
[DEBUG] ClientParamsStack - 'http.socket.timeout': null
[DEBUG] ClientParamsStack - 'http.socket.linger': null
[DEBUG] ClientParamsStack - 'http.socket.buffer-size': null
[DEBUG] ClientParamsStack - 'http.protocol.element-charset': null
[DEBUG] ClientParamsStack - 'http.connection.max-line-length': null
[DEBUG] ClientParamsStack - 'http.protocol.element-charset': null
[DEBUG] ClientParamsStack - 'http.connection.max-header-count': null
[DEBUG] ClientParamsStack - 'http.connection.max-line-length': null
[DEBUG] ClientParamsStack - 'http.connection.max-status-line-garbage': null
[DEBUG] ClientParamsStack - 'http.virtual-host': null
[DEBUG] ClientParamsStack - 'http.protocol.version': HTTP/1.1
[DEBUG] ClientParamsStack - 'http.default-headers': null
[DEBUG] ClientParamsStack - 'http.protocol.version': HTTP/1.1
[DEBUG] ClientParamsStack - 'http.protocol.version': HTTP/1.1
[DEBUG] ClientParamsStack - 'http.protocol.version': HTTP/1.1
[DEBUG] ClientParamsStack - 'http.protocol.version': HTTP/1.1
[DEBUG] ClientParamsStack - 'http.useragent': Apache-HttpClient/4.0-beta1
(java 1.4)
[DEBUG] ClientParamsStack - 'http.protocol.version': HTTP/1.1
[DEBUG] ClientParamsStack - 'http.protocol.cookie-policy': null
[DEBUG] RequestAddCookies - CookieSpec selected: best-match
[DEBUG] ClientParamsStack - 'http.protocol.cookie-datepatterns': null
[DEBUG] ClientParamsStack - 'http.protocol.single-cookie-header': null
[DEBUG] ClientParamsStack - 'http.protocol.version': HTTP/1.1
[DEBUG] DefaultRequestDirector - Attempt 1 to execute request
[DEBUG] ClientParamsStack - 'http.protocol.version': HTTP/1.1
[DEBUG] wire - GET http://www.verisign.com:80/ HTTP/1.1[EOL]
[DEBUG] wire - Host: www.verisign.com:80[EOL]
[DEBUG] wire - Connection: Keep-Alive[EOL]
[DEBUG] wire - User-Agent: Apache-HttpClient/4.0-beta1 (java 1.4)[EOL]
[DEBUG] wire - [EOL]
[DEBUG] ClientParamsStack - 'http.protocol.version': HTTP/1.1
[DEBUG] headers - GET http://www.verisign.com:80/ HTTP/1.1
[DEBUG] headers - Host: www.verisign.com:80
[DEBUG] headers - Connection: Keep-Alive
[DEBUG] headers - User-Agent: Apache-HttpClient/4.0-beta1 (java 1.4)
[DEBUG] wire - HTTP/1.0 407 Proxy Authentication Required[EOL]
[DEBUG] wire - Server: squid/2.6.STABLE6-NT[EOL]
[DEBUG] wire - Date: Thu, 30 Oct 2008 07:21:21 GMT[EOL]
[DEBUG] wire - Content-Type: text/html[EOL]
[DEBUG] wire - Content-Length: 1359[EOL]
[DEBUG] wire - Expires: Thu, 30 Oct 2008 07:21:21 GMT[EOL]
[DEBUG] wire - X-Squid-Error: ERR_CACHE_ACCESS_DENIED 0[EOL]
[DEBUG] wire - Proxy-Authenticate: NTLM[EOL]
[DEBUG] wire - X-Cache: MISS from s-hqw2k3bd.pmbelz.de[EOL]
[DEBUG] wire - X-Cache-Lookup: NONE from s-hqw2k3bd.pmbelz.de:3128[EOL]
[DEBUG] wire - Via: 1.0 s-hqw2k3bd.pmbelz.de:3128
(squid/2.6.STABLE6-NT)[EOL]
[DEBUG] wire - Proxy-Connection: close[EOL]
[DEBUG] headers - HTTP/1.0 407 Proxy Authentication Required
[DEBUG] headers - Server: squid/2.6.STABLE6-NT
[DEBUG] headers - Date: Thu, 30 Oct 2008 07:21:21 GMT
[DEBUG] headers - Content-Type: text/html
[DEBUG] headers - Content-Length: 1359
[DEBUG] headers - Expires: Thu, 30 Oct 2008 07:21:21 GMT
[DEBUG] headers - X-Squid-Error: ERR_CACHE_ACCESS_DENIED 0
[DEBUG] headers - Proxy-Authenticate: NTLM
[DEBUG] headers - X-Cache: MISS from s-hqw2k3bd.pmbelz.de
[DEBUG] headers - X-Cache-Lookup: NONE from s-hqw2k3bd.pmbelz.de:3128
[DEBUG] headers - Via: 1.0 s-hqw2k3bd.pmbelz.de:3128
(squid/2.6.STABLE6-NT)
[DEBUG] headers - Proxy-Connection: close
[DEBUG]
Re: AW: NTLM-Proxy authentication and SSL-target
On Wed, 2008-11-05 at 16:17 +0100, Cech. Ulrich wrote:
The version of Squid you are using appears broken. The proxy keeps one
sending 'Proxy-Connection: close' which is wrong given the fact that NTLM
requires a persistent connection in order to function.
Hi Oleg,
But how can it be explained, that a non-ssl target is handled correct? The
wire-log shows a Proxy-connection: closed too, but the authentication
works fine.
And if I open the ssl-target over a browser (the same proxy is used), it
worked fine, too.
Perhaps, do I have to set some more header fields manually to force the
correct behavior?
Well, take a closer look at the wire log. The connection _is_ being
correctly reused between the initial challenge, message1, message2 and
message3 when SSL is not used. So, Squid is definitely the culprit.
You _may_ work the problem around by removing the offending 'Connection:
close' headers using a protocol interceptor or by employing a custom
connection reuse strategy. Use at your risk, though.
Oleg
Many thanks!
I put in the wire-log of the non-ssl target.
executing request: GET / HTTP/1.1
via proxy: http://s-hqw2k3bd:3128
to target: http://www.verisign.com:80
[DEBUG] ClientParamsStack - 'http.protocol.max-redirects': null
[DEBUG] ClientParamsStack - 'http.route.forced-route': null
[DEBUG] ClientParamsStack - 'http.route.local-address': null
[DEBUG] ClientParamsStack - 'http.route.default-proxy':
http://s-hqw2k3bd:3128
[DEBUG] ClientParamsStack - 'http.conn-manager.timeout': null
[DEBUG] SingleClientConnManager - Get connection for route
HttpRoute[{}-http://s-hqw2k3bd:3128-http://www.verisign.com:80]
[DEBUG] ClientParamsStack - 'http.connection.stalecheck': null
[DEBUG] DefaultRequestDirector - Stale connection check
[DEBUG] DefaultRequestDirector - Stale connection detected
[DEBUG] DefaultClientConnection - Connection closed
[DEBUG] ClientParamsStack - 'http.connection.timeout': null
[DEBUG] ClientParamsStack - 'http.tcp.nodelay': null
[DEBUG] ClientParamsStack - 'http.socket.timeout': null
[DEBUG] ClientParamsStack - 'http.socket.linger': null
[DEBUG] ClientParamsStack - 'http.socket.buffer-size': null
[DEBUG] ClientParamsStack - 'http.protocol.element-charset': null
[DEBUG] ClientParamsStack - 'http.connection.max-line-length': null
[DEBUG] ClientParamsStack - 'http.protocol.element-charset': null
[DEBUG] ClientParamsStack - 'http.connection.max-header-count': null
[DEBUG] ClientParamsStack - 'http.connection.max-line-length': null
[DEBUG] ClientParamsStack - 'http.connection.max-status-line-garbage': null
[DEBUG] ClientParamsStack - 'http.virtual-host': null
[DEBUG] ClientParamsStack - 'http.protocol.version': HTTP/1.1
[DEBUG] ClientParamsStack - 'http.default-headers': null
[DEBUG] ClientParamsStack - 'http.protocol.version': HTTP/1.1
[DEBUG] ClientParamsStack - 'http.protocol.version': HTTP/1.1
[DEBUG] ClientParamsStack - 'http.protocol.version': HTTP/1.1
[DEBUG] ClientParamsStack - 'http.protocol.version': HTTP/1.1
[DEBUG] ClientParamsStack - 'http.useragent': Apache-HttpClient/4.0-beta1
(java 1.4)
[DEBUG] ClientParamsStack - 'http.protocol.version': HTTP/1.1
[DEBUG] ClientParamsStack - 'http.protocol.cookie-policy': null
[DEBUG] RequestAddCookies - CookieSpec selected: best-match
[DEBUG] ClientParamsStack - 'http.protocol.cookie-datepatterns': null
[DEBUG] ClientParamsStack - 'http.protocol.single-cookie-header': null
[DEBUG] ClientParamsStack - 'http.protocol.version': HTTP/1.1
[DEBUG] DefaultRequestDirector - Attempt 1 to execute request
[DEBUG] ClientParamsStack - 'http.protocol.version': HTTP/1.1
[DEBUG] wire - GET http://www.verisign.com:80/ HTTP/1.1[EOL]
[DEBUG] wire - Host: www.verisign.com:80[EOL]
[DEBUG] wire - Connection: Keep-Alive[EOL]
[DEBUG] wire - User-Agent: Apache-HttpClient/4.0-beta1 (java 1.4)[EOL]
[DEBUG] wire - [EOL]
[DEBUG] ClientParamsStack - 'http.protocol.version': HTTP/1.1
[DEBUG] headers - GET http://www.verisign.com:80/ HTTP/1.1
[DEBUG] headers - Host: www.verisign.com:80
[DEBUG] headers - Connection: Keep-Alive
[DEBUG] headers - User-Agent: Apache-HttpClient/4.0-beta1 (java 1.4)
[DEBUG] wire - HTTP/1.0 407 Proxy Authentication Required[EOL]
[DEBUG] wire - Server: squid/2.6.STABLE6-NT[EOL]
[DEBUG] wire - Date: Thu, 30 Oct 2008 07:21:21 GMT[EOL]
[DEBUG] wire - Content-Type: text/html[EOL]
[DEBUG] wire - Content-Length: 1359[EOL]
[DEBUG] wire - Expires: Thu, 30 Oct 2008 07:21:21 GMT[EOL]
[DEBUG] wire - X-Squid-Error: ERR_CACHE_ACCESS_DENIED 0[EOL]
[DEBUG] wire - Proxy-Authenticate: NTLM[EOL]
[DEBUG] wire - X-Cache: MISS from s-hqw2k3bd.pmbelz.de[EOL]
[DEBUG] wire - X-Cache-Lookup: NONE from s-hqw2k3bd.pmbelz.de:3128[EOL]
[DEBUG] wire - Via: 1.0 s-hqw2k3bd.pmbelz.de:3128
(squid/2.6.STABLE6-NT)[EOL]
[DEBUG] wire - Proxy-Connection: close[EOL]
[DEBUG] headers - HTTP/1.0 407 Proxy Authentication Required
[DEBUG] headers - Server: squid/2.6.STABLE6-NT
[DEBUG]
AW: NTLM-Proxy authentication and SSL-target
-NT)
/ADDRESS
/BODY/HTML
-Ursprüngliche Nachricht-
Von: Oleg Kalnichevski [mailto:[EMAIL PROTECTED]
Gesendet: Dienstag, 28. Oktober 2008 21:39
An: HttpClient User Discussion
Betreff: Re: NTLM-Proxy authentication and SSL-target
On Mon, 2008-10-27 at 15:46 +0100, Cech. Ulrich wrote:
Hello,
I have a problem with SSL target over a proxy. I use the example of
the HttpClient-code (4.0 beta), without an SSL-target, everything work
fine.
But if I change the target to port 443 and https (s. commented line),
I receive the HTTP/1.0 407 Proxy Authentication Required from the
proxy (and nothing else as a hint).
NTLM is not the problem, because authentication works with an
un-SSL-ed target.
There is no certificate error (and the certificate is installed
correctly), and the site is displayed well in the normal browser (IE
and Firefox tested).
Has someone a hint, where the problem is?
Thanks in advance,
Ulrich
Ulrich
I assume you have followed the instructions of the NTLM guide:
http://hc.apache.org/httpcomponents-client/ntlm.html
If that is the case, could you please produce a context / wire log of the
session that exhibits the problem?
You need to pass the following settings to the JVM to activate the logs
-Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog
-Dorg.apache.commons.logging.simplelog.log.org.apache.http=DEBUG
Oleg
Here is the main-method from the example-class:
public static void main(String[] args) throws Exception {
DefaultHttpClient httpclient = new DefaultHttpClient();
httpclient.getAuthSchemes().register(NTLM, new
NTLMSchemeFactory());
httpclient.getCredentialsProvider().setCredentials(
new AuthScope(AuthScope.ANY),
new NTCredentials(user, pw, workstation, domain));
//HttpHost targetHost = new HttpHost(www.verisign.com, 443,
https);
HttpHost targetHost = new HttpHost(www.verisign.com, 80,
http);
HttpHost proxy = new HttpHost(s-hqw2k3bd, 3128);
httpclient.getParams().setParameter
(ConnRoutePNames.DEFAULT_PROXY, proxy);
HttpGet httpget = new HttpGet(/);
System.out.println(executing request: +
httpget.getRequestLine());
System.out.println(via proxy: + proxy);
System.out.println(to target: + targetHost);
HttpResponse response = httpclient.execute(targetHost, httpget);
HttpEntity entity = response.getEntity();
System.out.println();
System.out.println(response.getStatusLine());
if (entity != null) {
System.out.println(Response content length: +
entity.getContentLength());
}
if (entity != null) {
entity.consumeContent();
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: NTLM-Proxy authentication and SSL-target
On Wed, 2008-10-29 at 09:17 +0100, Cech. Ulrich wrote: Hi Oleg, Thanks for your reply. Correct, I use the NTLM-support like it is described in the documentation (with jcifs etc.). And that worked fine for no-SSL-targets. Thanks for your help, Ulrich Ulrich, The version of Squid you are using appears broken. The proxy keeps one sending 'Proxy-Connection: close' which is wrong given the fact that NTLM requires a persistent connection in order to function. See wire log below Oleg [DEBUG] headers - CONNECT www.verisign.com:443 http://www.verisign.com:443 HTTP/1.1 [DEBUG] headers - User-Agent: Apache-HttpClient/4.0-beta1 (java 1.4) [DEBUG] headers - HTTP/1.0 407 Proxy Authentication Required [DEBUG] headers - Server: squid/2.6.STABLE6-NT [DEBUG] headers - Date: Wed, 29 Oct 2008 07:36:24 GMT [DEBUG] headers - Content-Type: text/html [DEBUG] headers - Content-Length: 1347 [DEBUG] headers - Expires: Wed, 29 Oct 2008 07:36:24 GMT [DEBUG] headers - X-Squid-Error: ERR_CACHE_ACCESS_DENIED 0 [DEBUG] headers - Proxy-Authenticate: NTLM [DEBUG] headers - X-Cache: MISS from s-hqw2k3bd.pmbelz.de [DEBUG] headers - X-Cache-Lookup: NONE from s-hqw2k3bd.pmbelz.de:3128 [DEBUG] headers - Via: 1.0 s-hqw2k3bd.pmbelz.de:3128 (squid/2.6.STABLE6-NT) [DEBUG] headers - Proxy-Connection: close [DEBUG] headers - CONNECT www.verisign.com:443 http://www.verisign.com:443 HTTP/1.1 [DEBUG] headers - User-Agent: Apache-HttpClient/4.0-beta1 (java 1.4) [DEBUG] headers - Proxy-Authorization: NTLM TlRMTVNTUAABATIAAAYABgAgBwAHACYAAABQTUJFTFpQQy0xNjM0 [DEBUG] headers - HTTP/1.0 407 Proxy Authentication Required [DEBUG] headers - Server: squid/2.6.STABLE6-NT [DEBUG] headers - Date: Wed, 29 Oct 2008 07:36:24 GMT [DEBUG] headers - Content-Type: text/html [DEBUG] headers - Content-Length: 1347 [DEBUG] headers - Expires: Wed, 29 Oct 2008 07:36:24 GMT [DEBUG] headers - X-Squid-Error: ERR_CACHE_ACCESS_DENIED 0 [DEBUG] headers - Proxy-Authenticate: NTLM TlRMTVNTUAACADgBAgACJxWYyBecHP84BQLODg8= [DEBUG] headers - X-Cache: MISS from s-hqw2k3bd.pmbelz.de [DEBUG] headers - X-Cache-Lookup: NONE from s-hqw2k3bd.pmbelz.de:3128 [DEBUG] headers - Via: 1.0 s-hqw2k3bd.pmbelz.de:3128 (squid/2.6.STABLE6-NT) [DEBUG] headers - Proxy-Connection: close [DEBUG] headers - CONNECT www.verisign.com:443 http://www.verisign.com:443 HTTP/1.1 [DEBUG] headers - User-Agent: Apache-HttpClient/4.0-beta1 (java 1.4) [DEBUG] headers - Proxy-Authorization: NTLM TlRMTVNTUAADGAAYAEAYABgAWAwADABwCAAIAHwOAA4AhQIAAOOOenVD3rqAqXU7pJjbK5QyfrCD58Nj97AldWYk//1QtLyNjRSYH89g7e4f95Vx0lAATQBCAEUATABaAGMAZQBjAGgAUABDAC0AMQA2ADMANAA= [DEBUG] headers - HTTP/1.0 407 Proxy Authentication Required [DEBUG] headers - Server: squid/2.6.STABLE6-NT [DEBUG] headers - Date: Wed, 29 Oct 2008 07:36:24 GMT [DEBUG] headers - Content-Type: text/html [DEBUG] headers - Content-Length: 1347 [DEBUG] headers - Expires: Wed, 29 Oct 2008 07:36:24 GMT [DEBUG] headers - X-Squid-Error: ERR_CACHE_ACCESS_DENIED 0 [DEBUG] headers - Proxy-Authenticate: NTLM [DEBUG] headers - X-Cache: MISS from s-hqw2k3bd.pmbelz.de [DEBUG] headers - X-Cache-Lookup: NONE from s-hqw2k3bd.pmbelz.de:3128 [DEBUG] headers - Via: 1.0 s-hqw2k3bd.pmbelz.de:3128 (squid/2.6.STABLE6-NT) [DEBUG] headers - Proxy-Connection: close - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NTLM-Proxy authentication and SSL-target
On Mon, 2008-10-27 at 15:46 +0100, Cech. Ulrich wrote:
Hello,
I have a problem with SSL target over a proxy. I use the example of the
HttpClient-code (4.0 beta), without an SSL-target, everything work fine.
But if I change the target to port 443 and https (s. commented line), I
receive the HTTP/1.0 407 Proxy Authentication Required from the proxy (and
nothing else as a hint).
NTLM is not the problem, because authentication works with an un-SSL-ed
target.
There is no certificate error (and the certificate is installed correctly),
and the site is displayed well in the normal browser (IE and Firefox
tested).
Has someone a hint, where the problem is?
Thanks in advance,
Ulrich
Ulrich
I assume you have followed the instructions of the NTLM guide:
http://hc.apache.org/httpcomponents-client/ntlm.html
If that is the case, could you please produce a context / wire log of
the session that exhibits the problem?
You need to pass the following settings to the JVM to activate the logs
-Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog
-Dorg.apache.commons.logging.simplelog.log.org.apache.http=DEBUG
Oleg
Here is the main-method from the example-class:
public static void main(String[] args) throws Exception {
DefaultHttpClient httpclient = new DefaultHttpClient();
httpclient.getAuthSchemes().register(NTLM, new
NTLMSchemeFactory());
httpclient.getCredentialsProvider().setCredentials(
new AuthScope(AuthScope.ANY),
new NTCredentials(user, pw, workstation, domain));
//HttpHost targetHost = new HttpHost(www.verisign.com, 443,
https);
HttpHost targetHost = new HttpHost(www.verisign.com, 80, http);
HttpHost proxy = new HttpHost(s-hqw2k3bd, 3128);
httpclient.getParams().setParameter
(ConnRoutePNames.DEFAULT_PROXY, proxy);
HttpGet httpget = new HttpGet(/);
System.out.println(executing request: +
httpget.getRequestLine());
System.out.println(via proxy: + proxy);
System.out.println(to target: + targetHost);
HttpResponse response = httpclient.execute(targetHost, httpget);
HttpEntity entity = response.getEntity();
System.out.println();
System.out.println(response.getStatusLine());
if (entity != null) {
System.out.println(Response content length: +
entity.getContentLength());
}
if (entity != null) {
entity.consumeContent();
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
NTLM-Proxy authentication and SSL-target
Hello,
I have a problem with SSL target over a proxy. I use the example of the
HttpClient-code (4.0 beta), without an SSL-target, everything work fine.
But if I change the target to port 443 and https (s. commented line), I
receive the HTTP/1.0 407 Proxy Authentication Required from the proxy (and
nothing else as a hint).
NTLM is not the problem, because authentication works with an un-SSL-ed
target.
There is no certificate error (and the certificate is installed correctly),
and the site is displayed well in the normal browser (IE and Firefox
tested).
Has someone a hint, where the problem is?
Thanks in advance,
Ulrich
Here is the main-method from the example-class:
public static void main(String[] args) throws Exception {
DefaultHttpClient httpclient = new DefaultHttpClient();
httpclient.getAuthSchemes().register(NTLM, new
NTLMSchemeFactory());
httpclient.getCredentialsProvider().setCredentials(
new AuthScope(AuthScope.ANY),
new NTCredentials(user, pw, workstation, domain));
//HttpHost targetHost = new HttpHost(www.verisign.com, 443,
https);
HttpHost targetHost = new HttpHost(www.verisign.com, 80, http);
HttpHost proxy = new HttpHost(s-hqw2k3bd, 3128);
httpclient.getParams().setParameter
(ConnRoutePNames.DEFAULT_PROXY, proxy);
HttpGet httpget = new HttpGet(/);
System.out.println(executing request: +
httpget.getRequestLine());
System.out.println(via proxy: + proxy);
System.out.println(to target: + targetHost);
HttpResponse response = httpclient.execute(targetHost, httpget);
HttpEntity entity = response.getEntity();
System.out.println();
System.out.println(response.getStatusLine());
if (entity != null) {
System.out.println(Response content length: +
entity.getContentLength());
}
if (entity != null) {
entity.consumeContent();
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: ntlm proxy authentication question
I thought about that, yet in this situation neither the Type 1 nor the Type 2 message includes the Negotiate_NTLM2_Key flag. However, when firefox or IE talks to the same proxy, the type 1 message includes Negotiate_NTLM2_Key as does the type 2 message. If the proxy were required to use NTLM2, wouldn't it return that flag set in the type 2? The type 1 message has the following flags set: Negotiate_Domain_Supplied,Negotiate_Local_Call,Negotiate_NTLM,Negotiate_OEM,Request_Target And the type 2 messge has the following flags set: Negotiate_NTLM,Negotiate_OEM,Negotiate_Target_Info,Request_Target,Target_Type_Domain I see in the log I sent where it says Credential Charset not provided. using HTTP element charset. I'm not sure if that charset is the same as OEM [Ascii]. I could see how the server would reject the password hash if it is hashed with the wrong charset. I recognize that the httpclient 3.x NTLM support is sort of a boat anchor and that the true solution will be with httpclient 4.x if and when it supports NTLM Thanks JJ On 3/7/08, Oleg Kalnichevski [EMAIL PROTECTED] wrote: On Wed, 2008-03-05 at 14:03 -0800, John Jamison wrote: I was ohh so close - I am attempting to code a simple app that performs NTLM proxy authentication against a proxy server that supports NTLM and basic authentication. It took me some time to determine the correct value for the Domain field in the NTCredentials instance, but decoding the NTLM message 2 structure gave it to me (its the NT domain name). Now though it seems I still always get 407 responses. Here's the code: System.setProperty(org.apache.commons.logging.Log, org.apache.commons.logging.impl.SimpleLog); System.setProperty (org.apache.commons.logging.simplelog.showdatetime, true); System.setProperty (org.apache.commons.logging.simplelog.log.httpclient.wire.header, debug); System.setProperty (org.apache.commons.logging.simplelog.log.org.apache.commons.httpclient, debug); HttpClient httpclient = new HttpClient(); // set the proxy host and port httpclient.getHostConfiguration().setProxy(XXXPROXYHOSTXXX, 80); //tried this, triggers BASIC authentication automatically // httpclient.getParams().setAuthenticationPreemptive(true); // not sure if the following applies to proxy authentication List authPrefs = new ArrayList(1); authPrefs.add(AuthPolicy.NTLM); httpclient.getParams().setParameter (AuthPolicy.AUTH_SCHEME_PRIORITY, authPrefs); // // set the proxy credentials // httpclient.getState().setProxyCredentials( new AuthScope(AuthScope.ANY_HOST, 80, AuthScope.ANY_REALM), new NTCredentials(XXXUSERNAMEXXX, XXXPASSSWORDXXX, ,XXXDOMAINXXXcom) ); GetMethod get = new GetMethod(http://www.google.com/;); get.setFollowRedirects(true); int status = httpclient.executeMethod(get); System.out.println(status); ... Here's the scrubbed debug trace - Frankly I'm stumped as to why the credentials provided are not being accepted. John, Quite likely because the server has been configured to accept NTLMv2 authentication only, whereas HttpClient supports NTLMv1 only Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- John Jamison [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
