We're in the process of releasing a 2.0.2 version of the ES-1.5 plugin right now.
Karl On Mon, May 16, 2016 at 1:16 PM, Silvio Meier < [email protected]> wrote: > Hi Karl > > Thanks for the fast response. I was little bit confused about the domain > concept because the Elasticsearch plugin used the @ sign for separating MCF > auth domains from user names, which actually looked to me as if the MCF > domain was the same as the AD domain. > > I'm already using a version that I have patched myself. However, your > solution looks much better. Will it be part of an official release in future? > > Thanks > regards > Silvio > > > On 15.05.2016 19:06, Karl Wright wrote: > > Ah, it must be the ES-1.5 plugin you are using. That is not written by > me; it was a contribution. And it looks like the author of the plugin used > the "@" as a way of separating the user name and MCF authorization domain, > as follows: > > >>>>>> > String[] authenticatedUserNameAndDomain = buffer.split("@", 2); > <<<<<< > > Obviously this is completely at odds with the need to include the AD > domain in the user name. I will bet also that nobody has used this with an > actual MCF domain, so I'm just going to change the separator character from > "@" to ":" in MCFAuthorizer.java, as follows: > > >>>>>> > String[] authenticatedUserNameAndDomain = buffer.split(":", 2); > <<<<<< > > Once again, JIRA is down and I cannot create the proper ticket for this, > but I will do so as soon as it is back up. > > Thanks, > Karl > > > > On Sun, May 15, 2016 at 12:41 PM, Karl Wright <[email protected]> wrote: > >> Hi Silvio, >> >> The "domain" argument to the authority service does not represent an >> Active Directory domain. It represents an MCF authorization domain, which >> is described in the book and also in the other documentation. This cannot >> be used as an active directory domain. >> >> >>>>>> >> Unfortuanately, the elasticsearch plugin for Apache ManifoldCF >> authentication service does not allow one to hand over a username in the >> form of the user principal name, [email protected]. This is due to >> the fact that the @ sign is not allowed to be encoded in the user name. >> <<<<<< >> >> That's pretty surprising; the plugin has no character limits I am aware >> of for user names, and I wrote it. Perhaps you simply need to use proper >> URL encoding practices in forming the URL you are invoking ElasticSearch >> with? >> >> Karl >> >> >> On Sun, May 15, 2016 at 11:39 AM, Silvio Meier < >> <[email protected]>[email protected]> wrote: >> >>> Hi Apache ManifoldCF user list >>> >>> I’m experimenting with Apache ManifoldCF 2.3, Elasticsearch 1.74 and the >>> corresponding Elasticsearch plugin (v 2.0.1) which I use to index the >>> network Windows shares of our company. >>> I set up Apache Manifold using authorization services together with an >>> Active Directory. >>> >>> Using the Apache ManifoldCF authentication services with separated >>> domain name and user name does somehow not work for our active directory >>> configuration, so the when the following service call is made >>> <http://localhost:8081/mcf-authority-service/UserACLs?username=msi&domain=ourdomain.com> >>> http://localhost:8081/mcf-authority-service/UserACLs?username=msi&domain=ourdomain.com >>> , the authentication service does not return any ACL list. I tried to do >>> different combinations of domain names or netbios names together with user >>> names. Or just username without domain name. No success! >>> >>> However, the only thing that is working is when calling the >>> authorization service with >>> http://localhost:8081/mcf-authority-service/[email protected] >>> , i.e., using the user principal name as username. In this case the >>> service returns the correct set of ACLs. >>> >>> Unfortuanately, the elasticsearch plugin for Apache ManifoldCF >>> authentication service does not allow one to hand over a username in the >>> form of the user principal name, e.g. <[email protected]> >>> [email protected]. This is due to the fact that the @ sign is not >>> allowed to be encoded in the user name. My current work around (which >>> works) is to adapt the elasticsearch plugin to accept the @ sign in the >>> user name. However, this is not a nice solution. Is there a better >>> (built-in) solution, or did I just something miss regarding the >>> authencation service? >>> >>> Regards >>> Silvio >>> >>> >>> >>> >> >> >
