Hi Karl, Thanks Karl.
I have added the Sharepoint Active Directory Authority in my authorization group with this entry: Domain controller name: 10.10.10.102 user: [email protected] Authentication: SIMPLE Login name AD attribute : userPrincipalName and I have added the Sharepoint Native Authority in same authorization group with this entry: Server SharePoint version: SharePoint Services 5.0 (2013) Claims based authorization: Enabled Server protocol: http I have requested to http://localhost:8345/mcf-authority-service/[email protected] USERNOTFOUND:sharepoint++native AUTHORIZED:sharepoint+Active+directory TOKEN:Authority+Group:Ui%3A0%23.w%7Cmydomain.com%255cmyuser TOKEN:Authority+Group:Uc%3A0%2B.w%7Cs-1-5-32-545 TOKEN:Authority+Group:Uc%3A0%2B.w%7Cs-1-5-21-151231991-263585328-740192949-513 TOKEN:Authority+Group:Ui%3A0%2B.w%7Cs-1-5-21-151231991-263585328-740192949-1142 TOKEN:Authority+Group:Uc%3A0%21.s%7Cwindows TOKEN:Authority+Group:Uc%3A0%28.s%7Ctrue If I use myuser@mydomain instead of [email protected] as folow http://localhost:8345/mcf-authority-service/UserACLs?username=myuser@mydomain , the response: AUTHORIZED:sharepoint++native TOKEN:Authority+Group:Ui%3A0%23.w%7Cmydomain%5Cmyuser TOKEN:Authority+Group:Gtestsite+Members USERNOTFOUND:sharepoint+Active+directory I selected Authority Type as Sharepoint in Repository Connection in MFC and run the job. The files have been indexed. Then, I have searched from Solr using "[email protected]" , return 0 response. If I use "myuser@mydomain instead" of "[email protected]", return response as follow: The search response is seen as follow: .... "allow_token_document":["Authority+Group:Ui%3A0%23.w%7Cmydomain%5Cadministrator", "Authority+Group:GExcel+Services+Viewers", "Authority+Group:GRestricted+Readers", "Authority+Group:Gtestsite+Members", "Authority+Group:GHierarchy+Managers", "Authority+Group:GApprovers", "Authority+Group:Gtestsite+Visitors", "Authority+Group:Gtestsite+Owners", "Authority+Group:GDesigners"]}] .... That's perfectly OK. On the other hand, I selected Authority Type as Active Directory in Repository Connection and run the job. The files have been indexed. But I still haven't any ACL in my solr index. ... "allow_token_document":["Authority+Group:"], ... 1- Why should I use "myuser@mydomain" instead of "[email protected]" ? How to be fixed it ? 2- Why didn't I still see the ACL in my solr ? 2016-12-30 16:55 GMT+03:00 Karl Wright <[email protected]>: > Also, FWIW, I can see that the user logins are in fact native and are in > claims-based form, so your sharepoint is *definitely* configured to be > claims-based. > > Thanks, > Karl > > > On Fri, Dec 30, 2016 at 8:52 AM, Karl Wright <[email protected]> wrote: > >> Hi Cihad, >> >> I am almost certain your Sharepoint 2013 setup is using claims-based >> authorization, since that is the default for Sharepoint 2013 and the >> installer would have had to select something else to override that default. >> >> Claims-based auth works fine with ActiveDirectory but you must use >> different MCF authorities with claims-based auth than you would with >> non-claims-based auth. If your users are all in groups, and your documents >> are secured by groups, then your ACLs will describe those groups and NOT >> the SIDs. That's perfectly OK. You simply need to have BOTH the >> Sharepoint Active Directory Authority and the Sharepoint Native Authority >> in your authorization group and everything maps as it should. Of course, >> that authorization group must be the one referenced by your Sharepoint >> Repository Connection or the authorization won't work. >> >> Please try this and let me know if it works for you. >> >> Karl >> >> >> On Fri, Dec 30, 2016 at 8:25 AM, Cihad Guzel <[email protected]> wrote: >> >>> Hi Karl, >>> >>> I have changed the authority group as Native Sharepoint instead of >>> Active Directory and I could see the allow tokens in Solr index as follow: >>> >>> "allow_token_document":["Authority+Group:Ui%3A0%23.w%7Clagom >>> %5Cadministrator", >>> "Authority+Group:GExcel+Services+Viewers", >>> "Authority+Group:GRestricted+Readers", >>> "Authority+Group:Gtestsite+Members", >>> "Authority+Group:GHierarchy+Managers", >>> "Authority+Group:GApprovers", >>> "Authority+Group:Gtestsite+Visitors", >>> "Authority+Group:Gtestsite+Owners", >>> "Authority+Group:GDesigners"], >>> >>> >>> If I select the "Active Directory" setting, I don't see any tokens. >>> >>> "allow_token_document":["Authority+Group:"], >>> >>> I tried user profile synchronization from Active Directory. I followed >>> https://blogs.technet.microsoft.com/meacoex/2013/08/04/step- >>> by-step-active-directory-import-for-sharepoint-2013/ >>> I could see all Active Directory users in Sharepoint. Then, I request >>> GetUserInfo and GetGroupCollectionFromUser in Sharepoint API via soapUI but >>> the Sid field is empty for all user. You can see the response as follow: >>> >>> <GetUserInfo> >>> <User ID="17" Sid="" Name="testUser" LoginName="i:0#.w|lagom\testUser" >>> Email="[email protected]" Notes="" IsSiteAdmin="False" >>> IsDomainGroup="False" Flags="0"/> >>> </GetUserInfo> >>> >>> <GetUserCollectionFromGroup> >>> <Users> >>> <User ID="17" Sid="" Name="testUser" LoginName="i:0#.w|lagom\testUser" >>> Email="[email protected]" Notes="" IsSiteAdmin="False" >>> IsDomainGroup="False" Flags="0"/> >>> <User ID="18" Sid="" Name="testUser2" >>> LoginName="i:0#.w|lagom\testUser2" Email="" Notes="" >>> IsSiteAdmin="False" IsDomainGroup="False" Flags="0"/> >>> </Users> >>> </GetUserCollectionFromGroup> >>> >>> I created an issue on stackexchange. You can see from: >>> http://sharepoint.stackexchange.com/questions/203761/sid-hav >>> e-empty-values-after-sharepoint-userprofile-sync >>> I can see the "sid" value, If I request to sharepoint rest api as like: >>> <siteurl>/_api/sp.userprofiles.peoplemanager/getuserprofilepropertyfor(accountname=@v, >>> propertyname='SID')?@v='testdomain\testUser' >>> >>> The response: >>> <d:GetUserProfilePropertyFor xmlns:d="http://schemas.micros >>> oft.com/ado/2007/08/dataservices" xmlns:m="http://schemas.micros >>> oft.com/ado/2007/08/dataservices/metadata" xmlns:georss=" >>> http://www.georss.org/georss"; xmlns:gml="http://www.opengis.net/gml >>> ">S-1-5-21-151231991-263585328-740192949-1109</d:GetU >>> serProfilePropertyFor> >>> >>> Then I saw a manifoldcf issue : https://issues.apache.org/ji >>> ra/browse/CONNECTORS-754 . The issue was resolved. But I'm having the >>> same problem. >>> >>> >>> >>> >>> >>> >>> >>> 2016-12-28 14:41 GMT+03:00 Karl Wright <[email protected]>: >>> >>>> Hi Cihad, >>>> >>>> In your case, then, the connector is calling the "Users: >>>> GetUserCollectionFromGroup" SOAP method in the SharePoint API. This >>>> method is supposed to list the users that belong to the group, but I >>>> suspect that your SharePoint instance is not set up to work in that way, >>>> and that you should in fact set your MCF up as follows: >>>> >>>> - Do NOT select the "Active directory" setting. Use "claims-based" >>>> instead. >>>> - Use the appropriate SharePoint "native" authority. >>>> >>>> Read up on how to do that here: >>>> >>>> http://manifoldcf.apache.org/release/release-2.5/en_US/end-u >>>> ser-documentation.html#sharepointrepository >>>> >>>> Thanks, >>>> Karl >>>> >>>> >>>> On Wed, Dec 28, 2016 at 6:26 AM, Cihad Guzel <[email protected]> wrote: >>>> >>>>> Hi Karl, >>>>> >>>>> I selected "Active Directory". My SharePoint server run with Active >>>>> Directory. >>>>> >>>>> 2016-12-28 14:13 GMT+03:00 Karl Wright <[email protected]>: >>>>> >>>>>> Hi Cihad, >>>>>> >>>>>> The code for looking for document ACLs is as follows: >>>>>> >>>>>> >>>>>> >>>>>> Object node = nodeList.get( i ); >>>>>> String mask = doc.getValue( node, "Mask" ); >>>>>> long maskValue = new Long(mask).longValue(); >>>>>> if ((maskValue & 1L) == 1L) >>>>>> { >>>>>> // Permission to view >>>>>> String isUser = doc.getValue( node, "MemberIsUser" ); >>>>>> >>>>>> if ( isUser.compareToIgnoreCase("True") == 0 ) >>>>>> { >>>>>> // Use AD user or group >>>>>> String userLogin = doc.getValue( node, "UserLogin" ); >>>>>> String userSid = getSidForUser( userCall, userLogin, >>>>>> activeDirectoryAuthority ); >>>>>> sids.add( userSid ); >>>>>> } >>>>>> else >>>>>> { >>>>>> // Role >>>>>> List<String> roleSids; >>>>>> String roleName = doc.getValue( node, "RoleName" ); >>>>>> if ( roleName.length() == 0) >>>>>> { >>>>>> roleName = doc.getValue(node,"GroupName"); >>>>>> roleSids = getSidsForGroup(userCall, roleName, >>>>>> activeDirectoryAuthority); >>>>>> } >>>>>> else >>>>>> { >>>>>> roleSids = getSidsForRole(userCall, roleName, >>>>>> activeDirectoryAuthority); >>>>>> } >>>>>> >>>>>> for (String sid : roleSids) >>>>>> { >>>>>> sids.add( sid ); >>>>>> } >>>>>> } >>>>>> } >>>>>> >>>>>> <<<<<< >>>>>> >>>>>> So, in your example, getSidsForGroup() should be getting called. The >>>>>> code for that is as follows: >>>>>> >>>>>> >>>>>> >>>>>> private List<String> getSidsForGroup(com.microsoft. >>>>>> schemas.sharepoint.soap.directory.UserGroupSoap userCall, String >>>>>> groupName, >>>>>> boolean activeDirectoryAuthority) >>>>>> throws ManifoldCFException, java.net.MalformedURLException, >>>>>> javax.xml.rpc.ServiceException, java.rmi.RemoteException >>>>>> { >>>>>> List<String> rval = new ArrayList<String>(); >>>>>> >>>>>> com.microsoft.schemas.sharepoint.soap.directory.GetUserColle >>>>>> ctionFromGroupResponseGetUserCollectionFromGroupResult roleResp = >>>>>> userCall.getUserCollectionFromGroup(groupName); >>>>>> org.apache.axis.message.MessageElement[] roleList = >>>>>> roleResp.get_any(); >>>>>> >>>>>> if (roleList.length != 1) >>>>>> throw new ManifoldCFException("Bad response - expecting one >>>>>> outer 'GetUserCollectionFromGroup' node, saw >>>>>> "+Integer.toString(roleList.le >>>>>> ngth)); >>>>>> >>>>>> MessageElement roles = roleList[0]; >>>>>> if (!roles.getElementName().getLocalName().equals("GetUserColle >>>>>> ctionFromGroup")) >>>>>> throw new ManifoldCFException("Bad response - outer node should >>>>>> have been 'GetUserCollectionFromGroup' node"); >>>>>> >>>>>> Iterator rolesIter = roles.getChildElements(); >>>>>> >>>>>> if (!activeDirectoryAuthority) >>>>>> { >>>>>> // We need not only the group itself, but its user children >>>>>> that are Claims-based entities >>>>>> rval.add("G"+groupName); >>>>>> while (rolesIter.hasNext()) >>>>>> { >>>>>> MessageElement child = (MessageElement)rolesIter.next(); >>>>>> if (child.getElementName().getLocalName().equals("Users")) >>>>>> { >>>>>> Iterator usersIterator = child.getChildElements(); >>>>>> while (usersIterator.hasNext()) >>>>>> { >>>>>> MessageElement user = (MessageElement)usersIterator. >>>>>> next(); >>>>>> if (user.getElementName().getLocalName().equals("User")) >>>>>> { >>>>>> String isDomainGroup = user.getAttribute("IsDomainGro >>>>>> up"); >>>>>> if (isDomainGroup != null && >>>>>> isDomainGroup.equals("True")) >>>>>> { >>>>>> // Add a user token for the domain group >>>>>> rval.add("U"+user.getAttribute("LoginName")); >>>>>> } >>>>>> } >>>>>> } >>>>>> } >>>>>> } >>>>>> } >>>>>> else >>>>>> { >>>>>> while (rolesIter.hasNext()) >>>>>> { >>>>>> MessageElement child = (MessageElement)rolesIter.next(); >>>>>> if (child.getElementName().getLocalName().equals("Users")) >>>>>> { >>>>>> Iterator usersIterator = child.getChildElements(); >>>>>> while (usersIterator.hasNext()) >>>>>> { >>>>>> MessageElement user = (MessageElement)usersIterator. >>>>>> next(); >>>>>> if (user.getElementName().getLocalName().equals("User")) >>>>>> { >>>>>> rval.add(user.getAttribute("Sid")); >>>>>> } >>>>>> } >>>>>> } >>>>>> } >>>>>> } >>>>>> return rval; >>>>>> } >>>>>> >>>>>> <<<<<< >>>>>> >>>>>> So what happens there depends on what you've selected for the >>>>>> connection's "use Active Directory authority" selection. What have you >>>>>> chosen? >>>>>> >>>>>> Karl >>>>>> >>>>>> On Wed, Dec 28, 2016 at 5:35 AM, Cihad Guzel <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi Karl, >>>>>>> >>>>>>> 1- Yes, I selected Sharepoint 2013, >>>>>>> 2- Yes, I installed the plugin in my Sharepoint server. >>>>>>> >>>>>>> 2016-12-28 2:54 GMT+03:00 Karl Wright <[email protected]>: >>>>>>> >>>>>>>> Hi Cihad, >>>>>>>> >>>>>>>> Some questions: >>>>>>>> (1) Have you selected "SharePoint 2013" in your SharePoint >>>>>>>> connection? >>>>>>>> (2) Have you installed the ManifoldCF SharePoint 2013 plugin on >>>>>>>> your SharePoint server? >>>>>>>> >>>>>>>> You will need to do both of these in order for SharePoint 2013 ACLs >>>>>>>> to work right. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Karl >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Dec 27, 2016 at 3:01 PM, Cihad Guzel <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I am trying MFC with Sharepoint 2013. First, I install the >>>>>>>>> sharepoint plugin and then run my job. My files in sharepoint are >>>>>>>>> indexed >>>>>>>>> successfully to Solr. But I don't see the ACLs in solr index. You can >>>>>>>>> see >>>>>>>>> my sample solr data as follow: >>>>>>>>> >>>>>>>>> "filename":"Sample.doc", >>>>>>>>> "allow_token_document":["Authority+Group:"], "deny_token_document >>>>>>>>> ":["Authority+Group:DEAD_AUTHORITY"], "deny_token_parent":[ >>>>>>>>> "__nosecurity__"], "allow_token_share":["__nosecurity__"], " >>>>>>>>> allow_token_parent":["__nosecurity__"], "deny_token_share":[ >>>>>>>>> "__nosecurity__"], >>>>>>>>> >>>>>>>>> I run Sharepoint connector with debug mode. I follow Manifoldcf >>>>>>>>> log but I don't see any error in it. I can see "getDocumentACLs xml >>>>>>>>> response:" in the log as follow: >>>>>>>>> >>>>>>>>> <ns1:GetPermissionCollection ><ns1:Permissions> >>>>>>>>> ... >>>>>>>>> <ns1:Permission MemberID="3" Mask="-1" MemberIsUser="False" >>>>>>>>> MemberGlobal="True" GroupName="testsite Owners"/> >>>>>>>>> ... >>>>>>>>> </ns1:Permissions> >>>>>>>>> </ns1:GetPermissionCollection> >>>>>>>>> >>>>>>>>> How do I follow a way to solve the problem? >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Regards >>>>>>>>> Cihad Güzel >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Teşekkürler >>>>>>> Cihad Güzel >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Teşekkürler >>>>> Cihad Güzel >>>>> >>>> >>>> >>> >>> >>> -- >>> Teşekkürler >>> Cihad Güzel >>> >> >> > -- Teşekkürler Cihad Güzel
