George, Thanks for that. Is there a guiude to cover how this can be done. Does it require changing axis code or is it a config change ? thanks, Brian
________________________________ From: George Stanchev [mailto:[email protected]] Sent: Fri 11/06/2010 17:55 To: [email protected] Subject: Re: NTLM Authentication failure with CommonsHTTPTransportSender IIIRC the default NTLM authentication with httpclient 3.x is NTLMv1 which Microsoft Servers rejects by default (unless you excplictly enable it by juggling registry settings). You need to enable NTLMv2 in axis2/httpclient, which is implemented in httpclient 4.x but you need to use jcifs in conjunction with the http client. May be someone here on the list can point with a guide how this is set up. George On Fri, Jun 11, 2010 at 1:52 AM, Brian Dillon <[email protected]> wrote: Hi, Just something else we have noticed which might be relevant. We have domains setup as; Top Level Domain: XXX Sub Domain: Development A user in the top level domain can call the web service and is authenticated through NTLM however a user (with the same permissions) on the sub domain devlopment.xxx.com <http://devlopment.xxx.com/> can't. Is there something different about user making a service invocation from a sub domain ? Both users are able to invoke the service if we use basic authentication (but obviously this is not secure enough as the password is sent in cleartext) Thanks, Brian From: Brian Dillon [mailto:[email protected]] Sent: 10 June 2010 17:59 To: [email protected] Subject: RE: NTLM Authentication failure with CommonsHTTPTransportSender Hi, Further on this. The on the wire request (taken from fiddler) has the following format No Proxy-Authorization Header is present. Authorization Header is present: NTLM 4E 54 4C 4D 53 53 50 00 03 00 00 00 18 00 18 00 NTLMSSP......... 61 00 00 00 00 00 00 00 79 00 00 00 0B 00 0B 00 a.......y....... 40 00 00 00 0E 00 0E 00 4B 00 00 00 08 00 08 00 @.......K....... 59 00 00 00 00 00 00 00 79 00 00 00 06 52 00 00 Y.......y....R.. 44 45 56 45 4C 4F 50 4D 45 4E 54 54 41 53 45 52 DEVELOPMENTTASER 56 49 43 45 53 55 53 45 52 49 45 44 45 56 31 35 VICESUSERIEM15 33 48 FB 57 4A 26 49 59 BD B2 2D 2B BE 6E 57 BF 3HûWJ&IY½²-+¾nW¿ 70 70 B6 EA DA F9 8B C8 D2 pp¶êÚù<ÈÒ -[NTLM Type3: Authentication]------------------------------ Provider: NTLMSSP Type: 3 OS Version: 68.69:17750 Flags: 0x5206 OEM strings supported in security buffer. Request server's authentication realm included in Type2 reply. NTLM authentication. Client workstation domain provided. Server can determine if the client eligible for local authentication. Server and client are same machine. Client may use local credentials rather than calculating challenge-response. lmresp_Offset: 97; lmresp_Length: 24; lmresp_Length2: 24 ntresp_Offset: 121; ntresp_Length: 0; ntresp_Length2: 0 Domain_Offset: 64; Domain_Length: 11; Domain_Length2: 11 User_Offset: 75; User_Length: 14; User_Length2: 14 Host_Offset: 89; Host_Length: 8; Host_Length2: 8 msg_len: 121 Domain: ?? User: ???? Host: ??? lm_resp: 48 FB 57 4A 26 49 59 BD B2 2D 2B BE 6E 57 BF 70 70 B6 EA DA F9 8B C8 D2 nt_resp: empty Thanks, Brian From: Brian Dillon [mailto:[email protected]] Sent: 10 June 2010 17:33 To: [email protected] Subject: NTLM Authentication failure with CommonsHTTPTransportSender Hi, I am using Axis2 1.4.1 I am currently trying to call a SharePoint service from Axis2 using NTLM authentication. My configuration is as follows; <transportSender name="http" class="org.apache.axis2.transport.http.CommonsHTTPTransportSender"> <parameter name="PROTOCOL">HTTP/1.1</parameter> <parameter name="Transfer-Encoding">chunked</parameter> </transportSender> I am invoking the service using the following; HttpTransportProperties.Authenticator auth = new HttpTransportProperties.Authenticator(); auth.setUsername(sharePointUser); auth.setPassword(sharePointPwd); String domain = getSharepointConfigProperty(AUTHENTICATION_DOMAIN); auth.setDomain(domain); List<String> authL = new ArrayList<String>(); authL.add(org.apache.axis2.transport.http.HttpTransportProperties.Authenticator.NTLM); auth.setAuthSchemes(authL); options.setProperty(HTTPConstants.AUTHENTICATE,auth); When I invoke the service I get the following error (seeing this in using fiddler to see the HTTP traffic) HTTP/1.1 401 Authorization Required Date: Thu, 10 Jun 2010 16:19:02 GMT Server: Apache/2.2.8 (Win32) DAV/2 SVN/1.5.5 mod_auth_sspi/1.0.4 WWW-Authenticate: NTLM TlRMTVNTUAACAAAADAAMADgAAAAFgomi/C9BoEfVN9gAAAAAAAAAAIIAggBEAAAABQLODgAAAA9GAEkATgBFAE8AUwACAAwARgBJAE4ARQBPAFMAAQAQAEkARQBEAEUAVgAwADAANAAEABQARgBJAE4ARQBPAFMALgBjAG8AbQADACYAaQBlAGQAZQB2ADAAMAA0AC4ARgBJAE4ARQBPAFMALgBjAG8AbQAFABQARgBJAE4ARQBPAFMALgBjAG8AbQAAAAAA Content-Length: 401 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/html; charset=iso-8859-1 Proxy-Support: Session-Based-Authentication <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>401 Authorization Required</title> </head><body> <h1>Authorization Required</h1> <p>This server could not verify that you are authorized to access the document requested. Either you supplied the wrong credentials (e.g., bad password), or your browser doesn't understand how to supply the credentials required.</p> </body></html> When I also found is that if I switch to use com.oaklandsw.http.axis2.OaklandHTTPTransportSender2 instead of the CommonsHTTPTransportSender that the request will succeed. Is this a know bug with CommonsHTTPTransportSender ? Is there a workaround or a known fix ? I don't want to go down the route of using the Oakland HTTP Sender as it is not an open source project. Any help is appreciated, Thanks, Brian Brian Dillon Technical Architecture FINEOS Corporation Pembroke House, 8-10 Lower Pembroke Street, Dublin2, Ireland. T +353-1-639-9700 F +353-1-639-9701 W www.FINEOS.com <https://connect.fineos.com/go/www.fineos.com> ENTERPRISE SOLUTIONS for INSURANCE, BANCASSURANCE AND SOCIAL INSURANCE __________________________________________________________ FINEOS Corporation is the global brand name of FINEOS Corporation Limited and its affiliated group companies worldwide. The information contained in this e-mail is confidential, may be privileged and is intended only for the use of the recipient named above. If you are not the intended recipient or a representative of the intended recipient, you have received this e-mail in error and must not copy, use or disclose the contents of this e-mail to anybody else. If you have received this e-mail in error, please notify the sender immediately by return e-mail and permanently delete the copy you received. This e-mail has been swept for computer viruses. However, you should carry out your own virus checks. Registered in Ireland, No. 205721. https://connect.fineos.com/go/www.fineos.com __________________________________________________________ __________________________________________________________ FINEOS Corporation is the global brand name of FINEOS Corporation Limited and its affiliated group companies worldwide. The information contained in this e-mail is confidential, may be privileged and is intended only for the use of the recipient named above. If you are not the intended recipient or a representative of the intended recipient, you have received this e-mail in error and must not copy, use or disclose the contents of this e-mail to anybody else. If you have received this e-mail in error, please notify the sender immediately by return e-mail and permanently delete the copy you received. This e-mail has been swept for computer viruses. However, you should carry out your own virus checks. Registered in Ireland, No. 205721. http://www.FINEOS.com __________________________________________________________
<<winmail.dat>>
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
