[
https://issues.apache.org/jira/browse/CONNECTORS-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13507446#comment-13507446
]
Karl Wright commented on CONNECTORS-572:
----------------------------------------
Advice from Michael Allen:
"There is definitely nothing new in NTLM. Note that I don't think cURL even
does NTLMv2 and in general it's NTLM behavior is a joke so I wouldn't even
bother with that.
The standard procedure is to study and emulate exactly the oldest supported
version of the standard client which would be Windows XP (but also occasionally
try something new like Windows 7). Write a small VBScript program that makes an
HTTP call against IIS but run it from a workstation that isn't joined to the
domain so that it doesn't do Kerberos. Look at it with Wireshark and get all
your flags right and all that jazz. I suspect you'll find something off with
the HTTP handshake or your NTLM code."
Since I don't have lots of Windows machines around, I'm going to have to modify
the implementation based on the spec as described in the link in the previous
comment. The hope is that Microsoft's documentation is at least reasonably
accurate. The flag changes so far anticipated seem relatively contained, but I
will need to very carefully read the spec before I'm sure we've got everything
covered.
> SharePoint connector does not authenticate properly against some SharePoint
> instances
> -------------------------------------------------------------------------------------
>
> Key: CONNECTORS-572
> URL: https://issues.apache.org/jira/browse/CONNECTORS-572
> Project: ManifoldCF
> Issue Type: Bug
> Components: SharePoint connector
> Affects Versions: ManifoldCF 1.0, ManifoldCF 1.0.1
> Reporter: Karl Wright
> Assignee: Karl Wright
> Fix For: ManifoldCF 1.1
>
>
> The SharePoint connector does not always authenticate against the SharePoint
> instance. The problem may be a bug in commons-httpclient, and a
> corresponding problem in httpcomponents/httpclient, where the NTLM Type-2
> response user name is not the same as the NTLM Type-3 message user name. In
> particular, we've seen "administrator" be passed in in the Type 1 message,
> and "\administrator" come back in the Type 2 response, and if "administrator"
> is passed in again in the Type 3 message, authentication fails.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira