You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@manifoldcf.apache.org by Phillip Rhodes <mo...@gmail.com> on 2017/12/02 09:32:08 UTC
ManifoldCF + Alfresco + Solr security filtering problem
Hello all, I thought I had this all figured out, but I built a new
environment and it's not behaving as expected. Not sure if I changed
something I shouldn't have or if it was never really working, but
here's the situation:
1. I have an Alfresco server storing documents. There are 65 docs in
the built in "sample" space, which defaults to allowing access to
everyone.
2. With the MCF SearchComponent installed into Solr, if I pass the
AuthenticatedUserName parameter with any value, I get back all 65
documents as expected.
3. I added another space in Alfresco that only allows access for 4
specific users... testuser1, testuser2, testuser3, and testuser4. If I
log into Alfresco as any of those users I can view and/or upload
content to the space.
4. I put 7 documents in that space, and re-indexed with MCF.
5. Solr now shows a total of 72 documents for the core in question.
6. But, if I pass AuthenticatedUserName=testuser1 with my query, I
still only see the 65 docs from the other space.
7. If I temporarily turn off the MCF SearchComponent in Solr, I can
see the docs from the "locked down" space.
I set the various token fields to stored="true" so I can see what is
getting stored, and here's what I see for one sample document (one
that isn't being returned with the SearchComponent enabled, but which
should be).
"allow_token_document":["Alfresco:testuser1", "Alfresco:testuser2",
"Alfresco:testuser3", "Alfresco:testuser4"],
"deny_token_document":["__nosecurity__"],
"deny_token_parent":["__nosecurity__"],
"allow_token_share":["__nosecurity__"],
"allow_token_parent":["__nosecurity__"],
"deny_token_share":["__nosecurity__"],
Two things jump out to me:
1. I don't have entries for those users in allow_token_share and
allow_token_parent (and I'm not sure why not. This part seems to be a
black box from the perspective of configuring MCF to crawl Alfresco)
2. The "domain" part in the entries in allow_token_document is coming
up as "Alfresco". I tried adding AuthenticatedUserDomain=Alfresco to
my queries, but that didn't make any difference.
Can anybody see what is is that I'm missing here? Is there maybe
something I need to do either in MCF or in Alfresco to make sure those
allow_token_share and allow_token_parent entries get populated, or is
it something else?
Any thoughts / suggestions are greatly appreciated.
Phil
This message optimized for indexing by NSA PRISM
Re: ManifoldCF + Alfresco + Solr security filtering problem
Posted by Phillip Rhodes <mo...@gmail.com>.
Thaks Karl, here is the ticket:
https://issues.apache.org/jira/browse/CONNECTORS-1473
FWIW, I have verified a couple of additional points:
1. The alfresco users I've been testing with (testuser1 mainly) are
authenticated from OpenLDAP on the Alfresco side, so I tried creating
a new "local" user (testuser8) and trying the whole scenario over
again with that user. Same result. So if the problem is on the
Alfresco side, it doesn't appear to matter if you're using LDAP or the
built-in auth stuff.
2. If I test with user "admin" I also do *not* get back the
TOKEN:Alfresco:admin token from the authority service, which means
that admin also cannot see the documents in the "secured" folder, even
though that user is the owner of the folder (that is, at ingestion
time, no allow_token_document for admin was inserted into Solr even
though admin has access to the folder). Not sure if this is strictly
related to the other issue or not, but it seems counter-intuitive to
me at best.
Any insights you or the rest of the MCF community can share are very
much appreciated. For now I have what appears to be a semi-usable
workaround using the NULL connector thing mentioned in the other
thread, so this isn't necessarily time critical on my end. But it
would be nice to get it working properly.
Thanks,
Phil
This message optimized for indexing by NSA PRISM
On Sat, Dec 2, 2017 at 9:48 AM, Karl Wright <da...@gmail.com> wrote:
> I didn't write the Alfresco authority or repository connector, but any
> authority connection is supposed to return tokens that have something to do
> with the documents that are indexed with the corresponding repository
> connection.
>
> It is quite possible that the Alfresco authority is not returning the
> correct tokens -- that would explain your issue.
>
> Can you create a ticket for further research on this? The ticket should
> include:
> - which Alfresco repository connector you are using
> - which Alfresco authority connector you are using
> - a dump of what tokens get indexed for your sample documents
> - a dump of what tokens get returned by the authority service for each of
> the sample users you are using
>
> Once that's there I will try to engage an Alfresco user or two for more
> info.
>
> Thanks!
>
> Karl
>
>
> On Sat, Dec 2, 2017 at 5:15 AM, Phillip Rhodes <mo...@gmail.com>
> wrote:
>>
>> I think I'm starting to see what's going on. If I make a direct call
>> to the authority service like this:
>>
>>
>> http://manifoldcf.fogbeam.link:8345/mcf-authority-service/UserACLs?username=testuser1
>>
>> I get back:
>>
>> AUTHORIZED:Alfresco+Authority+Connection
>> TOKEN:Alfresco:GROUP_EVERYONE
>>
>> which explains why I can see the documents from the public folder,
>> because they all have an allow_token_document for
>> Alfresco:GROUP_EVERYONE.
>>
>> But what I would expect (perhaps incorrectly) is that when passing a
>> discrete username like that, I'd also get back something like:
>>
>> TOKEN:Alfresco:testuser1
>>
>> which would then presumably match the tokens I'm seeing in the
>> "secured" documents.
>>
>> So the question is, should I really be getting back a token like that
>> from the authority service? Or am I misunderstanding how this works?
>> And if I should be getting that back, any idea(s) what might explain
>> why I'm not getting them?
>>
>>
>> Thanks
>>
>>
>> Phil
>>
>> This message optimized for indexing by NSA PRISM
>>
>>
>> On Sat, Dec 2, 2017 at 5:09 AM, Phillip Rhodes
>> <mo...@gmail.com> wrote:
>> > FWIW, I only have one repository connection defined, and only one
>> > authority group.
>> >
>> >
>> > Phil
>> >
>> > This message optimized for indexing by NSA PRISM
>> >
>> >
>> > On Sat, Dec 2, 2017 at 4:55 AM, Karl Wright <da...@gmail.com> wrote:
>> >> Hi Phil,
>> >>
>> >> If you are using a different repository connection for the second
>> >> Alfresco
>> >> crawl, is it possible you may have misconfigured the connection to
>> >> refer to
>> >> the wrong authority group, or none at all? All connections that you
>> >> need to
>> >> be authorized together need to be part of the same group.
>> >>
>> >> Karl
>> >>
>> >>
>> >> On Sat, Dec 2, 2017 at 4:32 AM, Phillip Rhodes
>> >> <mo...@gmail.com>
>> >> wrote:
>> >>>
>> >>> Hello all, I thought I had this all figured out, but I built a new
>> >>> environment and it's not behaving as expected. Not sure if I changed
>> >>> something I shouldn't have or if it was never really working, but
>> >>> here's the situation:
>> >>>
>> >>> 1. I have an Alfresco server storing documents. There are 65 docs in
>> >>> the built in "sample" space, which defaults to allowing access to
>> >>> everyone.
>> >>> 2. With the MCF SearchComponent installed into Solr, if I pass the
>> >>> AuthenticatedUserName parameter with any value, I get back all 65
>> >>> documents as expected.
>> >>> 3. I added another space in Alfresco that only allows access for 4
>> >>> specific users... testuser1, testuser2, testuser3, and testuser4. If I
>> >>> log into Alfresco as any of those users I can view and/or upload
>> >>> content to the space.
>> >>> 4. I put 7 documents in that space, and re-indexed with MCF.
>> >>> 5. Solr now shows a total of 72 documents for the core in question.
>> >>> 6. But, if I pass AuthenticatedUserName=testuser1 with my query, I
>> >>> still only see the 65 docs from the other space.
>> >>> 7. If I temporarily turn off the MCF SearchComponent in Solr, I can
>> >>> see the docs from the "locked down" space.
>> >>>
>> >>> I set the various token fields to stored="true" so I can see what is
>> >>> getting stored, and here's what I see for one sample document (one
>> >>> that isn't being returned with the SearchComponent enabled, but which
>> >>> should be).
>> >>>
>> >>> "allow_token_document":["Alfresco:testuser1", "Alfresco:testuser2",
>> >>> "Alfresco:testuser3", "Alfresco:testuser4"],
>> >>> "deny_token_document":["__nosecurity__"],
>> >>> "deny_token_parent":["__nosecurity__"],
>> >>> "allow_token_share":["__nosecurity__"],
>> >>> "allow_token_parent":["__nosecurity__"],
>> >>> "deny_token_share":["__nosecurity__"],
>> >>>
>> >>> Two things jump out to me:
>> >>>
>> >>> 1. I don't have entries for those users in allow_token_share and
>> >>> allow_token_parent (and I'm not sure why not. This part seems to be a
>> >>> black box from the perspective of configuring MCF to crawl Alfresco)
>> >>>
>> >>> 2. The "domain" part in the entries in allow_token_document is coming
>> >>> up as "Alfresco". I tried adding AuthenticatedUserDomain=Alfresco to
>> >>> my queries, but that didn't make any difference.
>> >>>
>> >>> Can anybody see what is is that I'm missing here? Is there maybe
>> >>> something I need to do either in MCF or in Alfresco to make sure those
>> >>> allow_token_share and allow_token_parent entries get populated, or is
>> >>> it something else?
>> >>>
>> >>> Any thoughts / suggestions are greatly appreciated.
>> >>>
>> >>>
>> >>> Phil
>> >>>
>> >>>
>> >>>
>> >>> This message optimized for indexing by NSA PRISM
>> >>
>> >>
>
>
Re: ManifoldCF + Alfresco + Solr security filtering problem
Posted by Karl Wright <da...@gmail.com>.
I didn't write the Alfresco authority or repository connector, but any
authority connection is supposed to return tokens that have something to do
with the documents that are indexed with the corresponding repository
connection.
It is quite possible that the Alfresco authority is not returning the
correct tokens -- that would explain your issue.
Can you create a ticket for further research on this? The ticket should
include:
- which Alfresco repository connector you are using
- which Alfresco authority connector you are using
- a dump of what tokens get indexed for your sample documents
- a dump of what tokens get returned by the authority service for each of
the sample users you are using
Once that's there I will try to engage an Alfresco user or two for more
info.
Thanks!
Karl
On Sat, Dec 2, 2017 at 5:15 AM, Phillip Rhodes <mo...@gmail.com>
wrote:
> I think I'm starting to see what's going on. If I make a direct call
> to the authority service like this:
>
> http://manifoldcf.fogbeam.link:8345/mcf-authority-
> service/UserACLs?username=testuser1
>
> I get back:
>
> AUTHORIZED:Alfresco+Authority+Connection
> TOKEN:Alfresco:GROUP_EVERYONE
>
> which explains why I can see the documents from the public folder,
> because they all have an allow_token_document for
> Alfresco:GROUP_EVERYONE.
>
> But what I would expect (perhaps incorrectly) is that when passing a
> discrete username like that, I'd also get back something like:
>
> TOKEN:Alfresco:testuser1
>
> which would then presumably match the tokens I'm seeing in the
> "secured" documents.
>
> So the question is, should I really be getting back a token like that
> from the authority service? Or am I misunderstanding how this works?
> And if I should be getting that back, any idea(s) what might explain
> why I'm not getting them?
>
>
> Thanks
>
>
> Phil
>
> This message optimized for indexing by NSA PRISM
>
>
> On Sat, Dec 2, 2017 at 5:09 AM, Phillip Rhodes
> <mo...@gmail.com> wrote:
> > FWIW, I only have one repository connection defined, and only one
> > authority group.
> >
> >
> > Phil
> >
> > This message optimized for indexing by NSA PRISM
> >
> >
> > On Sat, Dec 2, 2017 at 4:55 AM, Karl Wright <da...@gmail.com> wrote:
> >> Hi Phil,
> >>
> >> If you are using a different repository connection for the second
> Alfresco
> >> crawl, is it possible you may have misconfigured the connection to
> refer to
> >> the wrong authority group, or none at all? All connections that you
> need to
> >> be authorized together need to be part of the same group.
> >>
> >> Karl
> >>
> >>
> >> On Sat, Dec 2, 2017 at 4:32 AM, Phillip Rhodes <
> motley.crue.fan@gmail.com>
> >> wrote:
> >>>
> >>> Hello all, I thought I had this all figured out, but I built a new
> >>> environment and it's not behaving as expected. Not sure if I changed
> >>> something I shouldn't have or if it was never really working, but
> >>> here's the situation:
> >>>
> >>> 1. I have an Alfresco server storing documents. There are 65 docs in
> >>> the built in "sample" space, which defaults to allowing access to
> >>> everyone.
> >>> 2. With the MCF SearchComponent installed into Solr, if I pass the
> >>> AuthenticatedUserName parameter with any value, I get back all 65
> >>> documents as expected.
> >>> 3. I added another space in Alfresco that only allows access for 4
> >>> specific users... testuser1, testuser2, testuser3, and testuser4. If I
> >>> log into Alfresco as any of those users I can view and/or upload
> >>> content to the space.
> >>> 4. I put 7 documents in that space, and re-indexed with MCF.
> >>> 5. Solr now shows a total of 72 documents for the core in question.
> >>> 6. But, if I pass AuthenticatedUserName=testuser1 with my query, I
> >>> still only see the 65 docs from the other space.
> >>> 7. If I temporarily turn off the MCF SearchComponent in Solr, I can
> >>> see the docs from the "locked down" space.
> >>>
> >>> I set the various token fields to stored="true" so I can see what is
> >>> getting stored, and here's what I see for one sample document (one
> >>> that isn't being returned with the SearchComponent enabled, but which
> >>> should be).
> >>>
> >>> "allow_token_document":["Alfresco:testuser1", "Alfresco:testuser2",
> >>> "Alfresco:testuser3", "Alfresco:testuser4"],
> >>> "deny_token_document":["__nosecurity__"],
> >>> "deny_token_parent":["__nosecurity__"],
> >>> "allow_token_share":["__nosecurity__"],
> >>> "allow_token_parent":["__nosecurity__"],
> >>> "deny_token_share":["__nosecurity__"],
> >>>
> >>> Two things jump out to me:
> >>>
> >>> 1. I don't have entries for those users in allow_token_share and
> >>> allow_token_parent (and I'm not sure why not. This part seems to be a
> >>> black box from the perspective of configuring MCF to crawl Alfresco)
> >>>
> >>> 2. The "domain" part in the entries in allow_token_document is coming
> >>> up as "Alfresco". I tried adding AuthenticatedUserDomain=Alfresco to
> >>> my queries, but that didn't make any difference.
> >>>
> >>> Can anybody see what is is that I'm missing here? Is there maybe
> >>> something I need to do either in MCF or in Alfresco to make sure those
> >>> allow_token_share and allow_token_parent entries get populated, or is
> >>> it something else?
> >>>
> >>> Any thoughts / suggestions are greatly appreciated.
> >>>
> >>>
> >>> Phil
> >>>
> >>>
> >>>
> >>> This message optimized for indexing by NSA PRISM
> >>
> >>
>
Re: ManifoldCF + Alfresco + Solr security filtering problem
Posted by Phillip Rhodes <mo...@gmail.com>.
I think I'm starting to see what's going on. If I make a direct call
to the authority service like this:
http://manifoldcf.fogbeam.link:8345/mcf-authority-service/UserACLs?username=testuser1
I get back:
AUTHORIZED:Alfresco+Authority+Connection
TOKEN:Alfresco:GROUP_EVERYONE
which explains why I can see the documents from the public folder,
because they all have an allow_token_document for
Alfresco:GROUP_EVERYONE.
But what I would expect (perhaps incorrectly) is that when passing a
discrete username like that, I'd also get back something like:
TOKEN:Alfresco:testuser1
which would then presumably match the tokens I'm seeing in the
"secured" documents.
So the question is, should I really be getting back a token like that
from the authority service? Or am I misunderstanding how this works?
And if I should be getting that back, any idea(s) what might explain
why I'm not getting them?
Thanks
Phil
This message optimized for indexing by NSA PRISM
On Sat, Dec 2, 2017 at 5:09 AM, Phillip Rhodes
<mo...@gmail.com> wrote:
> FWIW, I only have one repository connection defined, and only one
> authority group.
>
>
> Phil
>
> This message optimized for indexing by NSA PRISM
>
>
> On Sat, Dec 2, 2017 at 4:55 AM, Karl Wright <da...@gmail.com> wrote:
>> Hi Phil,
>>
>> If you are using a different repository connection for the second Alfresco
>> crawl, is it possible you may have misconfigured the connection to refer to
>> the wrong authority group, or none at all? All connections that you need to
>> be authorized together need to be part of the same group.
>>
>> Karl
>>
>>
>> On Sat, Dec 2, 2017 at 4:32 AM, Phillip Rhodes <mo...@gmail.com>
>> wrote:
>>>
>>> Hello all, I thought I had this all figured out, but I built a new
>>> environment and it's not behaving as expected. Not sure if I changed
>>> something I shouldn't have or if it was never really working, but
>>> here's the situation:
>>>
>>> 1. I have an Alfresco server storing documents. There are 65 docs in
>>> the built in "sample" space, which defaults to allowing access to
>>> everyone.
>>> 2. With the MCF SearchComponent installed into Solr, if I pass the
>>> AuthenticatedUserName parameter with any value, I get back all 65
>>> documents as expected.
>>> 3. I added another space in Alfresco that only allows access for 4
>>> specific users... testuser1, testuser2, testuser3, and testuser4. If I
>>> log into Alfresco as any of those users I can view and/or upload
>>> content to the space.
>>> 4. I put 7 documents in that space, and re-indexed with MCF.
>>> 5. Solr now shows a total of 72 documents for the core in question.
>>> 6. But, if I pass AuthenticatedUserName=testuser1 with my query, I
>>> still only see the 65 docs from the other space.
>>> 7. If I temporarily turn off the MCF SearchComponent in Solr, I can
>>> see the docs from the "locked down" space.
>>>
>>> I set the various token fields to stored="true" so I can see what is
>>> getting stored, and here's what I see for one sample document (one
>>> that isn't being returned with the SearchComponent enabled, but which
>>> should be).
>>>
>>> "allow_token_document":["Alfresco:testuser1", "Alfresco:testuser2",
>>> "Alfresco:testuser3", "Alfresco:testuser4"],
>>> "deny_token_document":["__nosecurity__"],
>>> "deny_token_parent":["__nosecurity__"],
>>> "allow_token_share":["__nosecurity__"],
>>> "allow_token_parent":["__nosecurity__"],
>>> "deny_token_share":["__nosecurity__"],
>>>
>>> Two things jump out to me:
>>>
>>> 1. I don't have entries for those users in allow_token_share and
>>> allow_token_parent (and I'm not sure why not. This part seems to be a
>>> black box from the perspective of configuring MCF to crawl Alfresco)
>>>
>>> 2. The "domain" part in the entries in allow_token_document is coming
>>> up as "Alfresco". I tried adding AuthenticatedUserDomain=Alfresco to
>>> my queries, but that didn't make any difference.
>>>
>>> Can anybody see what is is that I'm missing here? Is there maybe
>>> something I need to do either in MCF or in Alfresco to make sure those
>>> allow_token_share and allow_token_parent entries get populated, or is
>>> it something else?
>>>
>>> Any thoughts / suggestions are greatly appreciated.
>>>
>>>
>>> Phil
>>>
>>>
>>>
>>> This message optimized for indexing by NSA PRISM
>>
>>
Re: ManifoldCF + Alfresco + Solr security filtering problem
Posted by Phillip Rhodes <mo...@gmail.com>.
FWIW, I only have one repository connection defined, and only one
authority group.
Phil
This message optimized for indexing by NSA PRISM
On Sat, Dec 2, 2017 at 4:55 AM, Karl Wright <da...@gmail.com> wrote:
> Hi Phil,
>
> If you are using a different repository connection for the second Alfresco
> crawl, is it possible you may have misconfigured the connection to refer to
> the wrong authority group, or none at all? All connections that you need to
> be authorized together need to be part of the same group.
>
> Karl
>
>
> On Sat, Dec 2, 2017 at 4:32 AM, Phillip Rhodes <mo...@gmail.com>
> wrote:
>>
>> Hello all, I thought I had this all figured out, but I built a new
>> environment and it's not behaving as expected. Not sure if I changed
>> something I shouldn't have or if it was never really working, but
>> here's the situation:
>>
>> 1. I have an Alfresco server storing documents. There are 65 docs in
>> the built in "sample" space, which defaults to allowing access to
>> everyone.
>> 2. With the MCF SearchComponent installed into Solr, if I pass the
>> AuthenticatedUserName parameter with any value, I get back all 65
>> documents as expected.
>> 3. I added another space in Alfresco that only allows access for 4
>> specific users... testuser1, testuser2, testuser3, and testuser4. If I
>> log into Alfresco as any of those users I can view and/or upload
>> content to the space.
>> 4. I put 7 documents in that space, and re-indexed with MCF.
>> 5. Solr now shows a total of 72 documents for the core in question.
>> 6. But, if I pass AuthenticatedUserName=testuser1 with my query, I
>> still only see the 65 docs from the other space.
>> 7. If I temporarily turn off the MCF SearchComponent in Solr, I can
>> see the docs from the "locked down" space.
>>
>> I set the various token fields to stored="true" so I can see what is
>> getting stored, and here's what I see for one sample document (one
>> that isn't being returned with the SearchComponent enabled, but which
>> should be).
>>
>> "allow_token_document":["Alfresco:testuser1", "Alfresco:testuser2",
>> "Alfresco:testuser3", "Alfresco:testuser4"],
>> "deny_token_document":["__nosecurity__"],
>> "deny_token_parent":["__nosecurity__"],
>> "allow_token_share":["__nosecurity__"],
>> "allow_token_parent":["__nosecurity__"],
>> "deny_token_share":["__nosecurity__"],
>>
>> Two things jump out to me:
>>
>> 1. I don't have entries for those users in allow_token_share and
>> allow_token_parent (and I'm not sure why not. This part seems to be a
>> black box from the perspective of configuring MCF to crawl Alfresco)
>>
>> 2. The "domain" part in the entries in allow_token_document is coming
>> up as "Alfresco". I tried adding AuthenticatedUserDomain=Alfresco to
>> my queries, but that didn't make any difference.
>>
>> Can anybody see what is is that I'm missing here? Is there maybe
>> something I need to do either in MCF or in Alfresco to make sure those
>> allow_token_share and allow_token_parent entries get populated, or is
>> it something else?
>>
>> Any thoughts / suggestions are greatly appreciated.
>>
>>
>> Phil
>>
>>
>>
>> This message optimized for indexing by NSA PRISM
>
>
Re: ManifoldCF + Alfresco + Solr security filtering problem
Posted by Karl Wright <da...@gmail.com>.
Hi Phil,
If you are using a different repository connection for the second Alfresco
crawl, is it possible you may have misconfigured the connection to refer to
the wrong authority group, or none at all? All connections that you need
to be authorized together need to be part of the same group.
Karl
On Sat, Dec 2, 2017 at 4:32 AM, Phillip Rhodes <mo...@gmail.com>
wrote:
> Hello all, I thought I had this all figured out, but I built a new
> environment and it's not behaving as expected. Not sure if I changed
> something I shouldn't have or if it was never really working, but
> here's the situation:
>
> 1. I have an Alfresco server storing documents. There are 65 docs in
> the built in "sample" space, which defaults to allowing access to
> everyone.
> 2. With the MCF SearchComponent installed into Solr, if I pass the
> AuthenticatedUserName parameter with any value, I get back all 65
> documents as expected.
> 3. I added another space in Alfresco that only allows access for 4
> specific users... testuser1, testuser2, testuser3, and testuser4. If I
> log into Alfresco as any of those users I can view and/or upload
> content to the space.
> 4. I put 7 documents in that space, and re-indexed with MCF.
> 5. Solr now shows a total of 72 documents for the core in question.
> 6. But, if I pass AuthenticatedUserName=testuser1 with my query, I
> still only see the 65 docs from the other space.
> 7. If I temporarily turn off the MCF SearchComponent in Solr, I can
> see the docs from the "locked down" space.
>
> I set the various token fields to stored="true" so I can see what is
> getting stored, and here's what I see for one sample document (one
> that isn't being returned with the SearchComponent enabled, but which
> should be).
>
> "allow_token_document":["Alfresco:testuser1", "Alfresco:testuser2",
> "Alfresco:testuser3", "Alfresco:testuser4"],
> "deny_token_document":["__nosecurity__"],
> "deny_token_parent":["__nosecurity__"],
> "allow_token_share":["__nosecurity__"],
> "allow_token_parent":["__nosecurity__"],
> "deny_token_share":["__nosecurity__"],
>
> Two things jump out to me:
>
> 1. I don't have entries for those users in allow_token_share and
> allow_token_parent (and I'm not sure why not. This part seems to be a
> black box from the perspective of configuring MCF to crawl Alfresco)
>
> 2. The "domain" part in the entries in allow_token_document is coming
> up as "Alfresco". I tried adding AuthenticatedUserDomain=Alfresco to
> my queries, but that didn't make any difference.
>
> Can anybody see what is is that I'm missing here? Is there maybe
> something I need to do either in MCF or in Alfresco to make sure those
> allow_token_share and allow_token_parent entries get populated, or is
> it something else?
>
> Any thoughts / suggestions are greatly appreciated.
>
>
> Phil
>
>
>
> This message optimized for indexing by NSA PRISM
>