In our FAST ESP installation, we ran across this problem. FAST (Microsoft, these days) told us that claim-space authentication would not be added to the Sharepoint connector, as FAST ESP was getting near to the end of its life.
What we did was essentially to extract recognizable bits from the authentication tokens, look them up in AD and use the sids. In particular, tokens like i:0#.w|our-domain\some-user and c:0+.w|s-1-5-21-220523388-1085031214-725345543-169014 In the latter case, we would just use the SID directly (except for the encoding). We could have done a lookup to ensure that this was a valid/existing SID, but it would have no real effect on security filtering. This looks like the opposite of what you're proposing to do, but should have the same effect. On Tue, Oct 8, 2013 at 8:57 AM, Karl Wright (JIRA) <[email protected]> wrote: > > [ > https://issues.apache.org/jira/browse/CONNECTORS-754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13788980#comment-13788980] > > Karl Wright commented on CONNECTORS-754: > ---------------------------------------- > > This graphic is especially useful: > > > http://www.wictorwilen.se/Media/Default/Windows-Live-Writer/How-Claims-encoding-works-in-SharePoint-_14813/image_10.png > > So it appears that Microsoft replaces valid user and group names with > "claim space names", when Claim Space is enabled, and in the SID world it > is therefore necessary to lookup the group SID by taking the group name and > decoding it to obtain the SID. > > So one proposal to support Claim Space is as follows: > - The repository connector indexes the role names, group names, and user > names which seem to have the READ permission, as already determined by the > getACLs and getDocumentACLs methods in SPSProxyHelper. But it does not > attempt to map these to SIDs, and instead leaves them as claim space IDs > (which I presume is in the Name field). > - The authority connector converts the incoming user to a SharePoint user > (form: domain\user), then (a) looks up the group SIDs in Active Directory, > converting them to Claim Space identifiers natively, and (b) looks up the > SharePoint user claimspace ID, groups claimspace IDs, and role descriptions > claimspace IDs, using the usergroup.asmx web service. > > I don't know for sure whether this would work, and without a testbed > system there would be no way to confirm it. Otherwise it seems > straightforward and worth a try. > > > 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.5 > > > > Attachments: MCPermissionsService-Claims.zip > > > > > > 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 was sent by Atlassian JIRA > (v6.1#6144) >
