You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@manifoldcf.apache.org by "Karl Wright (JIRA)" <ji...@apache.org> on 2013/09/25 12:16:04 UTC
[jira] [Comment Edited] (CONNECTORS-754) SharePoint connector does
not work with claim space authentication properly
[ https://issues.apache.org/jira/browse/CONNECTORS-754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13777323#comment-13777323 ]
Karl Wright edited comment on CONNECTORS-754 at 9/25/13 10:14 AM:
------------------------------------------------------------------
Here's what apparently was needed.
"We found that enabling claims based authentication causes the SID not to be populated in the usergroup.asmx response. The SID does seem to be stored in Sharepoint, but as a binary rather than a string. After decompiling the usergroups.asmx webservice, we found that the webservice does not serve any binary values.
What we have done to get around this is
- Created a new operation in the MCPermissions.asmx webservice called GetUserSidPropertyByAccountName. The claims login name is always passed back in the XML response from usergroups.asmx, we are using the user profiles functionality to obtain the SID.
- In the java code, i have added a clause to the getSidsForGroup in the SPSProxyHelper.java class to call a new function getSidByLoginName, which gets the SID from MCPermissions if it is not present in the usergroups.asmx response.
- We have also found that some of the SID for groups are a part of the claims login name, so we have added another operation to the webservice called DecodeClaim to obtain the SID.
The solution above should also enable the MCPermissions.asmx to work with Sharepoint 2013 and clams based + Active Directory authentication, as Sharepoint 2013 has claims based enabled by default."
was (Author: kwright@metacarta.com):
Here's what apparently was needed.
"We found that enabling claims based authentication causes the SID not to be populated in the usergroup.asmx response. The SID does seem to be stored in Sharepoint, but as a binary rather than a string. After decompiling the usergroups.asmx webservice, we found that the webservice does not serve any binary values.
What we have done to get around this is
- Created a new operation in the MCPermissions.asmx webservice called GetUserSidPropertyByAccountName. The claims login name is always passed back in the XML response from usergroups.asmx, we are using the user profiles functionality to obtain the SID.
In the java code, i have added a clause to the getSidsForGroup in the SPSProxyHelper.java class to call a new function getSidByLoginName, which gets the SID from MCPermissions if it is not present in the usergroups.asmx response.
We have also found that some of the SID for groups are a part of the claims login name, so we have added another operation to the webservice called DecodeClaim to obtain the SID.
The solution above should also enable the MCPermissions.asmx to work with Sharepoint 2013 and clams based + Active Directory authentication, as Sharepoint 2013 has claims based enabled by default."
> SharePoint connector does not work with claim space authentication properly
> ---------------------------------------------------------------------------
>
> Key: CONNECTORS-754
> URL: https://issues.apache.org/jira/browse/CONNECTORS-754
> Project: ManifoldCF
> Issue Type: Bug
> Components: SharePoint 2010 MCPermissions extension, SharePoint connector
> Affects Versions: ManifoldCF 1.2
> Reporter: Karl Wright
> Assignee: Karl Wright
> Fix For: ManifoldCF 1.4
>
>
> When the SharePoint Connector is used against a SharePoint claimspace instance, it fails in the following ways:
> (1) The MCPermissions.asmx plugin is unable to write to the log. "EventLog.XXX" is not allowed, apparently, under this configuration option.
> (2) It is needing to write to the log, which indicates there is some hidden exception taking place that we aren't seeing.
> (3) When this fails, we're getting bad data returned from the list method, which causes ArrayIndexOutOfBoundsException's being thrown in the relative path manipulation code, due to the fact that the library/list name is not at the front of the relative path, e.g.:
> {code}
> FATAL 2013-07-17 19:24:57,927 (Worker thread '46') - Error tossed: String index out of range: 19
> java.lang.StringIndexOutOfBoundsException: String index out of range: 19
> at java.lang.String.substring(String.java:1955)
> at org.apache.manifoldcf.crawler.connectors.sharepoint.SharePointRepository$FileStream.addFile(SharePointRepository.java:1890)
> at org.apache.manifoldcf.crawler.connectors.sharepoint.SPSProxyHelper.getChildren(SPSProxyHelper.java:655)
> at org.apache.manifoldcf.crawler.connectors.sharepoint.SharePointRepository.processDocuments(SharePointRepository.java:1411)
> at org.apache.manifoldcf.crawler.connectors.BaseRepositoryConnector.processDocuments(BaseRepositoryConnector.java:423)
> at org.apache.manifoldcf.crawler.system.WorkerThread.run(WorkerThread.java:559)
> {code}
> (Regardless of the full resolution of the problem, we should definitely harden the connector against this kind of issue.)
--
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