Sharepoint/.NET Web Service Authentication

From what we are seeing it very much looks like the Authentication header isn't being processed at all.

ISS Responds with 401.2 with the specific error number meaning "No authentication was even supplied", then eventually logs timeout on the connection. WebMaker displays the 401 response.

(In case this is not clear, in normal situations IIS will respond 401.2 then expect the client to respond again using its authentication details and go through the whole sequence. We seem to get the 401.2, then webmaker never tries again. In some cases you can avoid this extra round trip by starting off by passing the credentials on the first try - is this what the "preemptive" attribute is for? - we have tried it either way and it doesn't change the final result.)

From the registery settings it appears it should be using NTLM version 1, however verifying this and monitoring requests will have to wait for next week, because unfortunately my colleague is off sick today and I don't have access to the simple web maker application we were using to test this.

Hi Hawk,

For info, you should be able to use Fiddler ok, but you do need to manually tell Tomcat to use it. You can do this by setting the proxy server settings as described in http://www.hyfinity.com/node/79

For Fiddler you would set the host to localhost, and the port to 8888 for the default settings.

The couple of times I have tried to use Wireshark I have found it harder to understand as it works at a lower level, where as Fiddler has the advantage of dealing with individual HTTP requests.

With regards to the specific error, that does seem strange. Are you able to send through (either on the forum or privately) any logs from Wireshark (or Fiddler :) ) for the successful and failing requests for us to look at in more detail?

Regards,
Gerard

Gerard

Having looked into the issues we have verified that we were negotiating to NTLM v2 and have managed to allow NTLM v1 now.

If you look on the web about configuring NTLM levels you will find the following article http://confluence.atlassian.com/display/SPCON/Determining+which+NTLM+version+is+used (which links the following long but good explanation http://technet.microsoft.com/en-us/magazine/2006.08.securitywatch.aspx) which are all about the LMCompatibilityLevel registry key. Assuming those keys are not activley stopping NTLM v2 (i.e.are not set to 3 on your client or 4 or 5 on your server) then that is _not_ what you need to be interested in.

What you actually care about is the local security policy. Reference http://support.microsoft.com/kb/823659, section 15. The settings:
+?+?-?Network Security: Minimum session security for NTLM SSP based (including secure RPC) servers
+?+?-?Network Security: Minimum session security for NTLM SSP based (including secure RPC) clients

have a "Require NLTM v2" setting. That is what is actually forcing you to comunicate using NTLM v2.

Obviously depending on the direction of traffic you may need to change one or both. Also, of course, you should be aware that these settings may be getting altered by a group policy on your environment.

I hope that helps the next person trying to do this.

Tom

Hi Tom,

I'm glad you managed to get it working.

Thanks for the detailed information. This will definitely be useful for others in the future.

Regards,
Gerard

Hi Hawk,

There are a few different options available to make sure this information is only present in one location.

Firstly you could change the file paths in your insert rules in all but one of the controllers to be relative paths. For example, in Controller1 you would link up the file as normal, but in Controller2 you would set the document location to be +?+?++../../Controller1/Controller/WSCredentials.xml+?+?+?.
In this way you only ever have to change the file under Controller1, and you can remove it from being linked to the other controllers. (To remove a resource use the Node Resource Details screen as detailed in the Translation FAQ. Otherwise it will still get deployed for each controller even though it won+?+?+?t ever be used.)
You could also use an absolute path in each controller, but this would mean that the file needed to be in exactly the same location on each environment.

The second option is to create a central controller to manage loading the credentials information. In each of you existing controllers you would then change the Insert actions to be Invoke Service actions that call this new controller.
You would then only have to load up the WSCredentials.xml file in this new Controller, and so it would only be in one location.
This approach would reduce the impact if you ever had to change where this credentials information is coming from in the future.

The third option is to store the HttpHeader fragment in a database rather than a flat file. In this case you would use SQLStatement actions to retrieve the fragment, rather than inserting a file.
The advantages of this approach are that it is a bit more secure as you are not storing the authentication details in a text file, and that you can preconfigure the databases for each environment, so there would be no additional steps needed to move a release from Dev through to Production.


I guess in an ideal world you would probably do a combination of 2 and 3 (ie use a central controller to get the fragment which in turn performs a SQL lookup), but this would be the most effort to implement, so I guess it depends on your requirements.

I hope this helps.

Regards,
Gerard