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 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 > > 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. http://www.FINEOS.com > > __________________________________________________________ > > >
