Mailing-List: contact user-help@manifoldcf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@manifoldcf.apache.org
Received-SPF: pass (nike.apache.org: domain of daddywri@gmail.com designates
 209.85.210.178 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CALUFAGBwa+4FbEyBWhStNRG__h-X6=3bXM4URybOtxswadTgsQ@mail.gmail.com>
References: 
 <CAMFr3O+VT4oze5FVc6MzHOS43AuyQsXv4KKUDBkqu=R7TfUfmA@mail.gmail.com>
	<CALUFAGDB-8SjrM-QD97U6UNeEkFS9WOXbxCNp6nKKBCwXmvjPQ@mail.gmail.com>
	<CAMFr3O+aYOwuhvxF6BoBTOB-3AR6sPdxY4yjyLpMpty=qhr+Gg@mail.gmail.com>
	<CALUFAGBwa+4FbEyBWhStNRG__h-X6=3bXM4URybOtxswadTgsQ@mail.gmail.com>
Date: Wed, 22 Aug 2012 20:50:28 -0400
Message-ID: 
 <CALUFAGCOu-T-ax8e43ssSjeGy+epQ0R4YJmV+NEH0UZF+r3hEg@mail.gmail.com>
Subject: Re: Sharepoint connector - authentication failure
From: Karl Wright <daddywri@gmail.com>
To: user@manifoldcf.apache.org
Content-Type: text/plain; charset=ISO-8859-1

So, the message "Credentials provider not available" is a last-resort
bit of logic inside httpclient.  By that time there has already been
an NTLM back-and-forth that failed.  The reason for the failure is not
clear from the wire log; the NTLM exchange takes place as it is
supposed to, but IIS at the end decides it's invalid and resets the
sequence with a final 401.

You may want to consult the appropriate Windows event logs to see why
the logon failed.  It is possible that the host name you are crawling
from is not recognized by AD and is thus forbidden from communicating
with IIS.  Or, it could just be that your server and/or AD controller
is configured to need a fully-qualified domain name in order to
proceed.

If none of this helps, the next step is to try to get header dumps
from the browser that successfully can access the SharePoint web
service URLs.  Firefox can do this using a plugin called Live HTTP
Headers, but Firefox does not understand NTLM so that won't help.
Maybe though there is something similar available for Chrome.  Having
a successful login sequence alongside an unsuccessful one may help
identify the critical difference that is blocking the logon.

On Wed, Aug 22, 2012 at 8:21 PM, Karl Wright <daddywri@gmail.com> wrote:
> Hi Mike,
>
> The exceptions having to do with ListsSoap we have seen before; they
> are warnings and do not affect anything.
>
> The fatal problem is the following:
>
> Credentials provider not available
>
> What do your connection credentials look like?  The name is obviously
> of the form <domain>\<user> because the UI insists on that, but it may
> be worth trying fully-qualified forms of the domain and not shorthand
> ones.  I'll look at the httpclient code in the meanwhile and see if I
> can understand why that message would come out and get back to you.
>
> Karl
>
> On Wed, Aug 22, 2012 at 7:39 PM, Michael Wilken <wilkenm@gmail.com> wrote:
>> Hi Karl,
>>
>> I turned on wire logging, and uploaded a the resulting log here:
>> http://pastebin.com/xnLxhSwE .  That's the output of adding a new
>> SharePoint 2003 Repository connection.  Things seem normal until the
>> 401 is returned for the GetListsCollection call (but I'm a SOAP &
>> Sharepoint neophyte).  Changing it to SP 2010 results in the same
>> errors.
>>
>> Using Chrome/FireFox/Safari, the following urls all work using the
>> credentials the connector is using:
>>
>> http://xxx.yyy.com/zzz/Pages/default.aspx
>> http://xxx.yyy.com/zzz/_vti_bin/Lists.asmx
>> http://xxx.yyy.com/zzz/_vti_bin/Lists.asmx?wsdl
>>
>> If I use soapUI and make the GetListCollection SOAP request using the
>> same credentials, I get a successful response, uploaded here:
>> http://pastebin.com/ZZXHXM5U
>>
>> Any chance you could take a look at the log and let me know if I'm
>> missing something obvious?
>>
>> -mike
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Aug 22, 2012 at 10:34 AM, Karl Wright <daddywri@gmail.com> wrote:
>>> Hi Mike,
>>>
>>> Which version of ManifoldCF are you using?  Did you select "SharePoint
>>> 2.0" from the pulldown?  You will need to do this if you do not have
>>> the SharePoint plugin installed.
>>>
>>> For the record, in order to be able to crawl SharePoint 2010, you MUST
>>> be using trunk (not ManifoldCF 0.6), and you MUST select "SharePoint
>>> 4.0 (2010)" from the pulldown.  That will also mean you need to build
>>> and deploy the SharePoint 2010 plug-in on the SharePoint server for
>>> anything to work at all with SharePoint 2010.  FWIW, all of this will
>>> be released in about a month when MCF 0.7 goes out the door.
>>>
>>> In the interim, you can check to see whether you have true connection
>>> problems by doing the following:
>>>
>>> - Select SharePoint 2.0 from the pulldown
>>> - Save the connection
>>> - If you still get the error, then we escalate to the next level of
>>> debugging, which will include some or all of the following:
>>>
>>> (1) See if you can get to the web services from IE.  For example, if
>>> the site's url is http://xxx.yyy.com, then try to get to
>>> http://xxx.yyy.com/_vti_bin/Lists.asmx.  If that fails, look into your
>>> IIS configuration.
>>> (2) Turn on "wire debugging", as described in the FAQ, and view your
>>> connection again; it may give additional error details that could be
>>> helpful.
>>>
>>> Karl
>>>
>>> On Wed, Aug 22, 2012 at 1:22 PM, Michael Wilken <wilkenm@gmail.com> wrote:
>>>> I'm running into authentication errors when trying to use ManifoldCF
>>>> trunk against a Sharepoint2010 site.
>>>>
>>>> After creating a repository connection, I get the following message in
>>>> 'Connection Status':
>>>>     Crawl user did not authenticate properly, or has insufficient
>>>> permissions to access http://tunedin.disney.com: (401)Unauthorized
>>>>
>>>> The SP site is using NTLM for authentication.  I've verified that the
>>>> login info is correct: I can access the SP site via a web browser
>>>> using the credentials, and can make SOAP calls with the credentials
>>>> using soapUI.
>>>>
>>>> I have not installed the MCPermission service, as we don't have to
>>>> worry about permissions at this time.  Looking at the code, I'd expect
>>>> to get a different error message if this was causing the problem.
>>>>
>>>> Any suggestions for further debugging to see what's going wrong?
>>>>
>>>> Thanks,
>>>> -mike