[
https://issues.apache.org/jira/browse/CONNECTORS-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13251493#comment-13251493
]
Karl Wright edited comment on CONNECTORS-460 at 4/11/12 12:06 PM:
--
Hi Colin,
The prefixes are not the issue. In ManifoldCF, there should be one authority
that is capable of dealing with all the interacting domains, just like
SharePoint understands all the domains by talking with just one domain
controller. An authority's job is to look up the SIDs for a given username,
and since your SharePoint instance can do this by talking with only one DC,
ManifoldCF's active directory authority connector ought to be able to do the
same thing.
The issue, then, is that the active directory authority connector doesn't know
how to deal with external, trusted domains. The authority must locate the
DC(s) for these domains within LDAP (I believe) and route requests to the
appropriate DC. Alternatively, if automatic discovery of the external DC is
too hard, we can modify the AD authority connector to simply allow the user to
describe multiple domain controllers.
Does this sound reasonable to you?
was (Author: kwri...@metacarta.com):
Hi Colin,
The prefixes are not the issue. In ManifoldCF, there should be one authority
that is capable of dealing with all the interacting domains, just like
SharePoint understands all the domains by talking with just one domain
controller. An authority's job is to look up the SIDs for a given username,
and since your SharePoint instance can do this by talking with only one DC,
ManifoldCF's active directory authority connector ought to be able to do the
same thing.
The issue, then, is that the active directory authority connector doesn't know
how to deal with external, trusted domains. The authority must located the
DC(s) for these domains within LDAP (I believe) and route requests to the
appropriate DC. Alternatively, if automatic discovery of the external DC is
too hard, we can modify the AD authority connector to simply allow the user to
describe multiple domain controllers.
Does this sound reasonable to you?
ManifoldCF authority service doesn't handle multi-domain environments
-
Key: CONNECTORS-460
URL: https://issues.apache.org/jira/browse/CONNECTORS-460
Project: ManifoldCF
Issue Type: Improvement
Components: Active Directory authority, Authority Service
Environment: Two Active Directory domains: {{internal.com}} and
{{external.com}}
I'm indexing a Sharepoint site, where that site has permissions set
from_both_domains
Reporter: Colin Anderson
Labels: active-directory, authorization, security
The ManifoldCF authority service doesn't handle multi-domain environments.
The authority service returns a list of SIDs for the specified user, from all
available ManifoldCF authorities, for example:
{{TOKEN:InternalAD:S-1-5-21-1234567890-1234567890-1234567890-1234}}
Note that the SID is prefixed with the name of the ManifoldCF authority.
Here is my setup:
Output connector: Solr
Authority connector1: Active Directory ({{internal.com}} domain), named
{{InternalAD}}
Authority connector2: Active Directory ({{external.com}} domain), named
{{ExternalAD}}
Repository connector: Sharepoint
If I set the Sharepoint repository connector to use the authority 'None
(Global Authority)', then {{allow_token_document}} will contain SIDs that are
_not_ prefixed with any authority name, for example:
{{S-1-5-21-1234567890-1234567890-1234567890-1234}}
It is therefore not possible to get any search results, because the authority
service tokens will not match the stored tokens (because they _are_ prefixed
with authority names).
If I set the Sharepoint repository connector to use one of the AD authorities
'InternalAD', then {{allow_token_document}} will contain SIDs that are
prefixed with 'InternalAD', for example:
{{TOKEN:InternalAD:S-1-5-21-1234567890-1234567890-1234567890-1234}}
However, the prefix is _always_ 'InternalAD', even if the user/group actually
belongs to the {{external.com}} domain. Therefore it is not possible for
users in the {{external.com}} domain to get any search results, because the
authority service tokens will not match the stored tokens.
In essence, there seems to be a mismatch between the tokens that the
authority service outputs, and those that repository connectors output.
Perhaps one solution would be to use the authority 'None (Global Authority)',
and modify the authority service to take an extra query parameter that
prevents it from prefixing SIDs with the authority name.
--
This message is automatically generated by JIRA.
If you think it was sent
