Dylan, If Fiddler isn't working for you, try TCPTrace ( http://www.pocketsoap.com/tcptrace/). It acts a man-in-the-middle for TCP traffic, so you don't run in to the proxy problems inherent with the Fiddler approach.
Joe. On Wed, Apr 28, 2010 at 8:31 AM, Dylan Tusler < [email protected]> wrote: > > you may have to ensure the service principal name is properly > associated with that account (SETSPN is the tool to do this). > > > > That's a bit opaque to me. > > The setspn tool is for server principal account isn't it? I don't see what > that has to do with service accounts. Our service accout is a domain > account, and the server permissions are full control to everyone (until we > sort this out.) > > We've been trying to capture some trace with fiddler, but no luck at all. > Despite being a web service call, the call doesn't route through the fiddler > proxy, it seems. > > Agh!, > > Dylan. > > > > > ------------------------------ > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Paul Glavich > *Sent:* Saturday, 24 April 2010 3:13 PM > *To:* 'ozDotNet' > *Subject:* RE: Web service call problem - The HTTP request is unauthorized > with client authentication scheme 'Negotiate' > > What security settings are you using? It looks like its trying to > authenticate using Windows Authentication and failing (specifically using > Kerberos). I would suspect the service account used to make the call to the > server is not properly setup to do so and you may have to ensure the service > principal name is properly associated with that account (SETSPN is the tool > to do this). > > > > - Glav > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Dylan Tusler > *Sent:* Thursday, 22 April 2010 4:54 PM > *To:* '[email protected]' > *Subject:* Web service call problem - The HTTP request is unauthorized > with client authentication scheme 'Negotiate' > > > > We're getting authentication issues with a web service call, and have spent > a couple of days struggling to get it to work. > > > > We have a C# class that invokes the service as part of a BizTalk process. > The code that makes the call runs under the context of a service account > and looks like this: > > try > { > TasksSoapClient client = new TasksSoapClient(bindingName, > endpointAddress); > string documentId = client.AddDoc(dclass, metaData, > mimeType, rName, folder, contents); > return documentId; > } > catch (Exception ex) > { > throw new Exception(String.Format("Error calling interface > at '{0}' with binding '{1}' for method '{2}' with Retrieval Name = '{3}': > {4}", > endpointAddress, > bindingName, "AddDocumentToFolder", retrievalName, ex.Message), ex); > } > > > > The error that we are getting is > > *Error calling FileNet interface at '[our web service address]' with > binding 'TasksSoap12' for method 'AddDocumentToFolder' with Retrieval Name > = 'rc10120.xml': The HTTP request is unauthorized with client authentication > scheme 'Negotiate'. The authentication header received from the server was > 'Negotiate,NTLM'.* > > > > The BizTalk class has a config file that specifies the binding for > TasksSoap12 like this (which was generated using svcutil.exe): > > <customBinding> > <binding name="TasksSoap12"> > <textMessageEncoding maxReadPoolSize="64" maxWritePoolSize="16" > messageVersion="Soap12" writeEncoding="utf-8"> > <readerQuotas maxDepth="32" maxStringContentLength="8192" > maxArrayLength="16384" > maxBytesPerRead="4096" maxNameTableCharCount="16384" /> > </textMessageEncoding> > <httpTransport manualAddressing="false" > maxBufferPoolSize="524288" > maxReceivedMessageSize="65536" allowCookies="false" > authenticationScheme="Negotiate" > bypassProxyOnLocal="false" > hostNameComparisonMode="StrongWildcard" > keepAliveEnabled="true" maxBufferSize="65536" > proxyAuthenticationScheme="Negotiate" > realm="" transferMode="Buffered" > unsafeConnectionNtlmAuthentication="false" > useDefaultWebProxy="true" /> > </binding> > </customBinding> > > Can anyone give me some pointers as to what we could try out here? > > > > Ideally we'd like to specify a login name and password for the web service > to execute under, or let it run under our service account. I've tried > messing with client.ClientCredentials.UserName.UserName and Password, but > the results are the same. I guess the first step is to get rid of the above > error message, but I guess I don't really understand the error message, and > Dr Google (who has been extensively consulted) hasn't been much help either. > > > > We are not in a position to change the IIS settings on the web service > side, but otherwise we can do quite a bit. > > Dylan Tusler > Acting Development & Integration Manager > Information and Communications Services Branch > Sunshine Coast Regional Council > ph: +61 (0)7 5441 8202 mon, thu, fri > ph: +61 (0)7 5420 8002 tue, wed > "Your Technology Solutions Partner" > > > > > ------------------------------------------------------------------------------------------------- > To find out more about the Sunshine Coast Council, visit your local council > office at Caloundra, Maroochydore, Nambour or Tewantin. Or, if you prefer, > visit us on line at www.sunshinecoast.qld.gov.au > > This email, together with any attachments, is intended for the named > recipient(s) only. Any form of review, disclosure, modification, > distribution and or publication of this email message is prohibited without > the express permission of the author. Please notify the sender immediately > if you have received this email by mistake and delete it from your system. > Unless otherwise stated, this email represents only the views of the sender > and not the views of the Sunshine Coast Regional Council. > maile 3_0_0 >
