manifoldcf-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Wright <daddy...@gmail.com>
Subject Re: Which version of Solr have implements the Document Level Access Control
Date Tue, 03 May 2011 17:29:30 GMT
Even better - after reading up some more, I concluded that it is
impossible for a user to not have a SID.  Therefore it cannot be the
case that search() will return an empty list if there is a matching
user.

I've checked in the change, please try it.

Karl


On Tue, May 3, 2011 at 1:16 PM, Karl Wright <daddywri@gmail.com> wrote:
> I tried locating details of DSID-031006E0 on MSDN, to no avail.
> Microsoft apparently doesn't document this error.
> But I asked around, and there are two potential avenues forward.
>
> Avenue 1: There is a Windows tool called LDP, which should allow you
> to browse AD's LDAP.  What you would need to do is confirm that each
> user has a sAMAccountName attribute.  If they *don't*, it is possible
> that the domain was not set up in compatibility mode, which means
> we'll need to find a different attribute to query against.
>
> Avenue 2: Just change the string "sAMAccountName" in the
> ActiveDirectoryAuthority.java class to "uid", and try again.  The
> "uid" attribute should exist on all AD installations after Windows
> 2000.
>
> Thanks,
> Karl
>
>
> On Tue, May 3, 2011 at 12:52 PM, Karl Wright <daddywri@gmail.com> wrote:
>> I removed the object scope from the user lookup - it's worth another
>> try.  Care to synch up an run again?
>>
>> Karl
>>
>> On Tue, May 3, 2011 at 12:36 PM, Karl Wright <daddywri@gmail.com> wrote:
>>> As I feared, the new user-exists-check code is not correct in some
>>> way.  Apparently we can't retrieve the attribute I'm looking for by
>>> this kind of query.
>>>
>>> The following website seems to have some suggestions as to how to do
>>> better, with downloadable samples, but I'm not going to be able to
>>> look at it in any detail until this evening.
>>>
>>> http://www.techtalkz.com/windows-server-2003/424352-get-samaccountnames-all-users-active-directory-group.html
>>>
>>> Karl
>>>
>>> On Tue, May 3, 2011 at 12:12 PM, Kadri Atalay <atalay.kadri@gmail.com> wrote:
>>>> Karl,
>>>>
>>>> Here is the first round of tests with CONNECTORS-195t: Now we are getting
>>>> all responses as TEQA-DC:DEAD_AUTHORITY.. even with valid users.
>>>>
>>>> Please take a  look at the 2 bitmap files I have attached. (they have the
>>>> screen shots from debug screens)
>>>>
>>>> invalid user and invalid domain
>>>> C:\OPT>curl
>>>> "http://localhost:8345/mcf-authority-service/UserACLs?username=fakeuser@fakedomain"
>>>> USERNOTFOUND:TEQA-DC
>>>> TOKEN:TEQA-DC:DEAD_AUTHORITY
>>>>
>>>> invalid user and valid (full domain name)
>>>> C:\OPT>curl
>>>> "http://localhost:8345/mcf-authority-service/UserACLs?username=fakeuser@teqa.filetek.com"
>>>> USERNOTFOUND:TEQA-DC
>>>> TOKEN:TEQA-DC:DEAD_AUTHORITY
>>>>
>>>> valid user and valid domain  (please see bitmap file katalay_admin@teqa.bmp)
>>>> This name gets the similar error as the first fakeuser eventhough it's a
>>>> valid user.
>>>> C:\OPT>curl
>>>> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_admin@teqa"
>>>> USERNOTFOUND:TEQA-DC
>>>> TOKEN:TEQA-DC:DEAD_AUTHORITY
>>>>
>>>> valid user and valid domain (full domain name) (please see bitmap file
>>>> katalay_admin@teqa.filetek.com.bmp) This name gets a namenotfound exception
>>>> when full domain name is used.
>>>> C:\OPT>curl
>>>> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_admin@teqa.filetek.com"
>>>> USERNOTFOUND:TEQA-DC
>>>> TOKEN:TEQA-DC:DEAD_AUTHORITY
>>>>
>>>> valid user and valid domain (full domain name)
>>>> C:\OPT>curl
>>>> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay@teqa.filetek.com"
>>>> USERNOTFOUND:TEQA-DC
>>>> TOKEN:TEQA-DC:DEAD_AUTHORITY
>>>>
>>>> Thanks
>>>>
>>>> Kadri
>>>>
>>>> On Tue, May 3, 2011 at 3:55 AM, Karl Wright <daddywri@gmail.com> wrote:
>>>>>
>>>>> Because this looks like it might involve some experimentation, I
>>>>> decided to create a branch for working on the CONNECTORS-195 ticket.
>>>>> The branch has what I believe is the correct code checked into it.
>>>>> The branch svn root is:
>>>>>
>>>>> http://svn.apache.org/repos/asf/incubator/lcf/branches/CONNECTORS-195
>>>>>
>>>>> If you check this branch out and build it, I'd dearly love to know if
>>>>> it properly detects non-existent users on your system.  In theory it
>>>>> should.  If it is wrong, it might well decide that ALL users are
>>>>> invalid, so your feedback is essential before I consider committing
>>>>> this patch.
>>>>>
>>>>> Thanks,
>>>>> Karl
>>>>>
>>>>> On Mon, May 2, 2011 at 5:52 PM, Karl Wright <daddywri@gmail.com> wrote:
>>>>> > I opened a ticket, CONNECTORS-195, and added what I think is an
>>>>> > explicit check for existence of the user as a patch.  Can you apply
>>>>> > the patch and let me know if it seems to fix the problem?
>>>>> >
>>>>> > Thanks,
>>>>> > Karl
>>>>> >
>>>>> >
>>>>> > On Mon, May 2, 2011 at 3:51 PM, Kadri Atalay <atalay.kadri@gmail.com>
>>>>> > wrote:
>>>>> >> I see, thanks for the response.
>>>>> >> I'll look into it little deeper, before making a suggestion how to
>>>>> >> check for
>>>>> >> this internal exception.. If JDK 1.6 behavior is different than JDK 1.5
>>>>> >> for
>>>>> >> LDAP, this may not be the only problem we may encounter..
>>>>> >> Maybe any exception generated by JDK during this request should be
>>>>> >> evaluated.. We'll see.
>>>>> >> Thanks.
>>>>> >> Kadri
>>>>> >>
>>>>> >> On Mon, May 2, 2011 at 3:44 PM, Karl Wright <daddywri@gmail.com> wrote:
>>>>> >>>
>>>>> >>> "NameNotFound exception is never being reached because process is
>>>>> >>> throwing internal exception, and this is never checked."
>>>>> >>>
>>>>> >>> I see the logging trace; it looks like the ldap code is eating the
>>>>> >>> exception and returning a blank list.  This is explicitly NOT what is
>>>>> >>> supposed to happen, nor did it happen on JDK 1.5, I am certain.  You
>>>>> >>> might find that this behavior has changed between Java releases.
>>>>> >>>
>>>>> >>> "Also, what is the reason for adding everyone group for each response
>>>>> >>> ?"
>>>>> >>>
>>>>> >>> I added this in because the standard treatment of Active Directory
>>>>> >>> 2000 and 2003 was to exclude the public ACL.  Since all users have it,
>>>>> >>> if the user exists (which was the case if NameNotFound exception was
>>>>> >>> not being thrown), it was always safe to add it in.
>>>>> >>>
>>>>> >>>
>>>>> >>> If JDK xxx, which is eating the internal exception, gives back SOME
>>>>> >>> signal that the user does not exist, we can certainly check for that.
>>>>> >>> What signal do you recommend looking for, based on the trace?  Is
>>>>> >>> there any way to get at "errEx    PartialResultException  (id=7962)  "
>>>>> >>> from  NamingEnumeration answer?
>>>>> >>>
>>>>> >>> Karl
>>>>> >>>
>>>>> >>>
>>>>> >>>
>>>>> >>> On Mon, May 2, 2011 at 3:31 PM, Kadri Atalay <atalay.kadri@gmail.com>
>>>>> >>> wrote:
>>>>> >>> > Hi Karl,
>>>>> >>> >
>>>>> >>> > I noticed in the code that   NameNotFound exception is never being
>>>>> >>> > reached
>>>>> >>> > because process is throwing internal exception, and this is never
>>>>> >>> > checked.
>>>>> >>> > (see below)
>>>>> >>> > Also, what is the reason for adding everyone group for each response
>>>>> >>> > ?
>>>>> >>> >       theGroups.add("S-1-1-0");
>>>>> >>> >
>>>>> >>> > When there is no groups or SID's returned, following return code is
>>>>> >>> > still
>>>>> >>> > used..
>>>>> >>> >       return new
>>>>> >>> > AuthorizationResponse(tokens,AuthorizationResponse.RESPONSE_OK);
>>>>> >>> >
>>>>> >>> > Should I assume this code was tested against an Active Directory,
>>>>> >>> > and
>>>>> >>> > working, and or should I start checking from the beginning every
>>>>> >>> > parameter
>>>>> >>> > is entered. (see below)
>>>>> >>> > For example, in the following code, DIGEST-MD5 GSSAPI is used for
>>>>> >>> > security
>>>>> >>> > authentication, but user name and password is passed as a clear
>>>>> >>> > text..
>>>>> >>> > and
>>>>> >>> > not in the format they suggest in their documentation.
>>>>> >>> >
>>>>> >>> > Thanks
>>>>> >>> >
>>>>> >>> > Kadri
>>>>> >>> >
>>>>> >>> >
>>>>> >>> >
>>>>> >>> > http://download.oracle.com/javase/jndi/tutorial/ldap/security/gssapi.html
>>>>> >>> >
>>>>> >>> >
>>>>> >>> >     if (ctx == null)
>>>>> >>> >     {
>>>>> >>> >       // Calculate the ldap url first
>>>>> >>> >       String ldapURL = "ldap://" + domainControllerName + ":389";
>>>>> >>> >
>>>>> >>> >       Hashtable env = new Hashtable();
>>>>> >>> >
>>>>> >>> >
>>>>> >>> >
>>>>> >>> > env.put(Context.INITIAL_CONTEXT_FACTORY,"com.sun.jndi.ldap.LdapCtxFactory");
>>>>> >>> >       env.put(Context.SECURITY_AUTHENTICATION,"DIGEST-MD5 GSSAPI");
>>>>> >>> >       env.put(Context.SECURITY_PRINCIPAL,userName);
>>>>> >>> >       env.put(Context.SECURITY_CREDENTIALS,password);
>>>>> >>> >
>>>>> >>> >       //connect to my domain controller
>>>>> >>> >       env.put(Context.PROVIDER_URL,ldapURL);
>>>>> >>> >
>>>>> >>> >       //specify attributes to be returned in binary format
>>>>> >>> >       env.put("java.naming.ldap.attributes.binary","tokenGroups
>>>>> >>> > objectSid");
>>>>> >>> >
>>>>> >>> >
>>>>> >>> >
>>>>> >>> > fakeuser@teqa
>>>>> >>> >
>>>>> >>> >     //Search for objects using the filter
>>>>> >>> >       NamingEnumeration answer = ctx.search(searchBase,
>>>>> >>> > searchFilter,
>>>>> >>> > searchCtls);
>>>>> >>> >
>>>>> >>> > answer    LdapSearchEnumeration  (id=6635)
>>>>> >>> >     cleaned    false
>>>>> >>> >     cont    Continuation  (id=6674)
>>>>> >>> >     entries    Vector<E>  (id=6675)
>>>>> >>> >     enumClnt    LdapClient  (id=6676)
>>>>> >>> >         authenticateCalled    true
>>>>> >>> >         conn    Connection  (id=6906)
>>>>> >>> >         isLdapv3    true
>>>>> >>> >         pcb    null
>>>>> >>> >         pooled    false
>>>>> >>> >         referenceCount    1
>>>>> >>> >         unsolicited    Vector<E>  (id=6907)
>>>>> >>> >     errEx    PartialResultException  (id=6677)
>>>>> >>> >         cause    PartialResultException  (id=6677)
>>>>> >>> >         detailMessage    "[LDAP: error code 10 - 0000202B: RefErr:
>>>>> >>> > DSID-031006E0, data 0, 1 access points\n\tref 1: 'teqa'\n
>>>>> >>> >
>>>>> >>> >
>>>>> >>> >       ArrayList theGroups = new ArrayList();
>>>>> >>> >       // All users get certain well-known groups
>>>>> >>> >       theGroups.add("S-1-1-0");
>>>>> >>> >
>>>>> >>> >
>>>>> >>> > answer    LdapSearchEnumeration  (id=7940)
>>>>> >>> >     cleaned    false
>>>>> >>> >     cont    Continuation  (id=7959)
>>>>> >>> >     entries    Vector<E>  (id=7960)
>>>>> >>> >     enumClnt    LdapClient  (id=7961)
>>>>> >>> >     errEx    PartialResultException  (id=7962)
>>>>> >>> >         cause    PartialResultException  (id=7962)
>>>>> >>> >         detailMessage    "[LDAP: error code 10 - 0000202B: RefErr:
>>>>> >>> > DSID-031006E0, data 0, 1 access points\n\tref 1: 'teqa'\n
>>>>> >>> >
>>>>> >>> >       return new
>>>>> >>> > AuthorizationResponse(tokens,AuthorizationResponse.RESPONSE_OK);
>>>>> >>> >
>>>>> >>> >
>>>>> >>> > On Tue, Apr 26, 2011 at 12:54 PM, Karl Wright <daddywri@gmail.com>
>>>>> >>> > wrote:
>>>>> >>> >>
>>>>> >>> >> If a completely unknown user still comes back as existing, then
>>>>> >>> >> it's
>>>>> >>> >> time to look at how your domain controller is configured.
>>>>> >>> >> Specifically, what do you have it configured to trust?  What
>>>>> >>> >> version
>>>>> >>> >> of Windows is this?
>>>>> >>> >>
>>>>> >>> >> The way LDAP tells you a user does not exist in Java is by an
>>>>> >>> >> exception.  So this statement:
>>>>> >>> >>
>>>>> >>> >>      NamingEnumeration answer = ctx.search(searchBase,
>>>>> >>> >> searchFilter,
>>>>> >>> >> searchCtls);
>>>>> >>> >>
>>>>> >>> >> will throw the NameNotFoundException if the name doesn't exist,
>>>>> >>> >> which
>>>>> >>> >> the Active Directory connector then catches:
>>>>> >>> >>
>>>>> >>> >>    catch (NameNotFoundException e)
>>>>> >>> >>    {
>>>>> >>> >>      // This means that the user doesn't exist
>>>>> >>> >>      return userNotFoundResponse;
>>>>> >>> >>    }
>>>>> >>> >>
>>>>> >>> >> Clearly this is not working at all for your setup.  Maybe you can
>>>>> >>> >> look
>>>>> >>> >> at the DC's event logs, and see what kinds of decisions it is
>>>>> >>> >> making
>>>>> >>> >> here?  It's not making much sense to me at this point.
>>>>> >>> >>
>>>>> >>> >> Karl
>>>>> >>> >>
>>>>> >>> >> On Tue, Apr 26, 2011 at 12:45 PM, Kadri Atalay
>>>>> >>> >> <atalay.kadri@gmail.com>
>>>>> >>> >> wrote:
>>>>> >>> >> > Get the same result with user doesn't exist
>>>>> >>> >> > C:\OPT\security_example>curl
>>>>> >>> >> >
>>>>> >>> >> >
>>>>> >>> >> >
>>>>> >>> >> > "http://localhost:8345/mcf-authority-service/UserACLs?username=fakeuser@fakedomain"
>>>>> >>> >> > AUTHORIZED:TEQA-DC
>>>>> >>> >> > TOKEN:TEQA-DC:S-1-1-0
>>>>> >>> >> >
>>>>> >>> >> > BTW, is there a command to get all users available in Active
>>>>> >>> >> > Directory,
>>>>> >>> >> > from
>>>>> >>> >> > mcf-authority service, or other test commands to see if it's
>>>>> >>> >> > working
>>>>> >>> >> > correctly ?
>>>>> >>> >> >
>>>>> >>> >> > Also, I set the logging level to finest from Solr Admin for
>>>>> >>> >> > ManifoldCFSecurityFilter,but I don't see any logs created.. Is
>>>>> >>> >> > there
>>>>> >>> >> > any
>>>>> >>> >> > other settings need to be tweaked ?
>>>>> >>> >> >
>>>>> >>> >> > Thanks
>>>>> >>> >> >
>>>>> >>> >> > Kadri
>>>>> >>> >> >
>>>>> >>> >> > On Tue, Apr 26, 2011 at 12:38 PM, Karl Wright
>>>>> >>> >> > <daddywri@gmail.com>
>>>>> >>> >> > wrote:
>>>>> >>> >> >>
>>>>> >>> >> >> One other quick note.  You might want to try a user that doesn't
>>>>> >>> >> >> exist
>>>>> >>> >> >> and see what you get.  It should be a USERNOTFOUND response.
>>>>> >>> >> >>
>>>>> >>> >> >> If that's indeed what you get back, then this is a relatively
>>>>> >>> >> >> minor
>>>>> >>> >> >> issue with Active Directory.  Basically the S-1-1-0 SID is added
>>>>> >>> >> >> by
>>>>> >>> >> >> the active directory authority, so the DC is actually returning
>>>>> >>> >> >> an
>>>>> >>> >> >> empty list of SIDs for the user with an unknown domain.  It
>>>>> >>> >> >> *should*
>>>>> >>> >> >> tell us the user doesn't exist, I agree, but that's clearly a
>>>>> >>> >> >> problem
>>>>> >>> >> >> only Active Directory can solve; we can't make that decision in
>>>>> >>> >> >> the
>>>>> >>> >> >> active directory connector because the DC may be just one node
>>>>> >>> >> >> in a
>>>>> >>> >> >> hierarchy.  Perhaps there's a Microsoft knowledge-base article
>>>>> >>> >> >> that
>>>>> >>> >> >> would clarify things further.
>>>>> >>> >> >>
>>>>> >>> >> >> Please let me know what you find.
>>>>> >>> >> >> Karl
>>>>> >>> >> >>
>>>>> >>> >> >> On Tue, Apr 26, 2011 at 12:27 PM, Karl Wright
>>>>> >>> >> >> <daddywri@gmail.com>
>>>>> >>> >> >> wrote:
>>>>> >>> >> >> > The method code from the Active Directory authority that
>>>>> >>> >> >> > handles
>>>>> >>> >> >> > the
>>>>> >>> >> >> > LDAP query construction is below.  It looks perfectly
>>>>> >>> >> >> > reasonable
>>>>> >>> >> >> > to
>>>>> >>> >> >> > me:
>>>>> >>> >> >> >
>>>>> >>> >> >> >  /** Parse a user name into an ldap search base. */
>>>>> >>> >> >> >  protected static String parseUser(String userName)
>>>>> >>> >> >> >    throws ManifoldCFException
>>>>> >>> >> >> >  {
>>>>> >>> >> >> >    //String searchBase =
>>>>> >>> >> >> > "CN=Administrator,CN=Users,DC=qa-ad-76,DC=metacarta,DC=com";
>>>>> >>> >> >> >    int index = userName.indexOf("@");
>>>>> >>> >> >> >    if (index == -1)
>>>>> >>> >> >> >      throw new ManifoldCFException("Username is in unexpected
>>>>> >>> >> >> > form
>>>>> >>> >> >> > (no @): '"+userName+"'");
>>>>> >>> >> >> >    String userPart = userName.substring(0,index);
>>>>> >>> >> >> >    String domainPart = userName.substring(index+1);
>>>>> >>> >> >> >    // Start the search base assembly
>>>>> >>> >> >> >    StringBuffer sb = new StringBuffer();
>>>>> >>> >> >> >    sb.append("CN=").append(userPart).append(",CN=Users");
>>>>> >>> >> >> >    int j = 0;
>>>>> >>> >> >> >    while (true)
>>>>> >>> >> >> >    {
>>>>> >>> >> >> >      int k = domainPart.indexOf(".",j);
>>>>> >>> >> >> >      if (k == -1)
>>>>> >>> >> >> >      {
>>>>> >>> >> >> >        sb.append(",DC=").append(domainPart.substring(j));
>>>>> >>> >> >> >        break;
>>>>> >>> >> >> >      }
>>>>> >>> >> >> >      sb.append(",DC=").append(domainPart.substring(j,k));
>>>>> >>> >> >> >      j = k+1;
>>>>> >>> >> >> >    }
>>>>> >>> >> >> >    return sb.toString();
>>>>> >>> >> >> >  }
>>>>> >>> >> >> >
>>>>> >>> >> >> > So I have to conclude that your Active Directory domain
>>>>> >>> >> >> > controller
>>>>> >>> >> >> > is
>>>>> >>> >> >> > simply not caring what the DC= fields are, for some reason.
>>>>> >>> >> >> >  No
>>>>> >>> >> >> > idea
>>>>> >>> >> >> > why.
>>>>> >>> >> >> >
>>>>> >>> >> >> > If you want to confirm this picture, you might want to create
>>>>> >>> >> >> > a
>>>>> >>> >> >> > patch
>>>>> >>> >> >> > to add some Logging.authorityConnectors.debug statements at
>>>>> >>> >> >> > appropriate places so we can see the actual query it's sending
>>>>> >>> >> >> > to
>>>>> >>> >> >> > LDAP.  I'm happy to commit this debug output patch eventually
>>>>> >>> >> >> > if
>>>>> >>> >> >> > you
>>>>> >>> >> >> > also want to create a ticket.
>>>>> >>> >> >> >
>>>>> >>> >> >> > Thanks,
>>>>> >>> >> >> > Karl
>>>>> >>> >> >> >
>>>>> >>> >> >> > On Tue, Apr 26, 2011 at 12:17 PM, Kadri Atalay
>>>>> >>> >> >> > <atalay.kadri@gmail.com>
>>>>> >>> >> >> > wrote:
>>>>> >>> >> >> >> Yes, ManifoldCF is running with JCIFS connector, and using
>>>>> >>> >> >> >> Solr
>>>>> >>> >> >> >> 3.1
>>>>> >>> >> >> >>
>>>>> >>> >> >> >> response to first call:
>>>>> >>> >> >> >> C:\OPT\security_example>curl
>>>>> >>> >> >> >>
>>>>> >>> >> >> >>
>>>>> >>> >> >> >> "http://localhost:8345/mcf-authority-service/UserACLs?username=joe"
>>>>> >>> >> >> >> UNREACHABLEAUTHORITY:TEQA-DC
>>>>> >>> >> >> >> TOKEN:TEQA-DC:DEAD_AUTHORITY
>>>>> >>> >> >> >>
>>>>> >>> >> >> >> response to fake domain call:
>>>>> >>> >> >> >> C:\OPT\security_example>curl
>>>>> >>> >> >> >>
>>>>> >>> >> >> >>
>>>>> >>> >> >> >>
>>>>> >>> >> >> >>
>>>>> >>> >> >> >> "http://localhost:8345/mcf-authority-service/UserACLs?username=joe@fakedomain"
>>>>> >>> >> >> >> AUTHORIZED:TEQA-DC
>>>>> >>> >> >> >> TOKEN:TEQA-DC:S-1-1-0
>>>>> >>> >> >> >>
>>>>> >>> >> >> >> response to actual domain account call:
>>>>> >>> >> >> >> C:\OPT\security_example>curl
>>>>> >>> >> >> >>
>>>>> >>> >> >> >>
>>>>> >>> >> >> >>
>>>>> >>> >> >> >>
>>>>> >>> >> >> >> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_admin@teqa"
>>>>> >>> >> >> >> AUTHORIZED:TEQA-DC
>>>>> >>> >> >> >> TOKEN:TEQA-DC:S-1-1-0
>>>>> >>> >> >> >>
>>>>> >>> >> >> >> Looks like as long as there is a domain suffix, return is
>>>>> >>> >> >> >> positive..
>>>>> >>> >> >> >>
>>>>> >>> >> >> >> Thanks
>>>>> >>> >> >> >>
>>>>> >>> >> >> >> Kadri
>>>>> >>> >> >> >>
>>>>> >>> >> >> >>
>>>>> >>> >> >> >> On Tue, Apr 26, 2011 at 12:10 PM, Karl Wright
>>>>> >>> >> >> >> <daddywri@gmail.com>
>>>>> >>> >> >> >> wrote:
>>>>> >>> >> >> >>>
>>>>> >>> >> >> >>> So you are trying to extend the example in the book,
>>>>> >>> >> >> >>> correct, to
>>>>> >>> >> >> >>> run
>>>>> >>> >> >> >>> against active directory and the JCIFS connector?  And this
>>>>> >>> >> >> >>> is
>>>>> >>> >> >> >>> with
>>>>> >>> >> >> >>> Solr 3.1?
>>>>> >>> >> >> >>>
>>>>> >>> >> >> >>> The book was written for Solr 1.4.1, so it's entirely
>>>>> >>> >> >> >>> possible
>>>>> >>> >> >> >>> that
>>>>> >>> >> >> >>> something in Solr changed in relation to the way search
>>>>> >>> >> >> >>> components
>>>>> >>> >> >> >>> are
>>>>> >>> >> >> >>> used.  So I think we're going to need to do some debugging.
>>>>> >>> >> >> >>>
>>>>> >>> >> >> >>> (1) First, to confirm sanity, try using curl against the mcf
>>>>> >>> >> >> >>> authority
>>>>> >>> >> >> >>> service.  Try some combination of users to see how that
>>>>> >>> >> >> >>> works,
>>>>> >>> >> >> >>> e.g.:
>>>>> >>> >> >> >>>
>>>>> >>> >> >> >>> curl
>>>>> >>> >> >> >>>
>>>>> >>> >> >> >>>
>>>>> >>> >> >> >>> "http://localhost:8345/mcf-authority-service/UserACLs?username=joe"
>>>>> >>> >> >> >>>
>>>>> >>> >> >> >>> ...and
>>>>> >>> >> >> >>>
>>>>> >>> >> >> >>> curl
>>>>> >>> >> >> >>>
>>>>> >>> >> >> >>>
>>>>> >>> >> >> >>>
>>>>> >>> >> >> >>>
>>>>> >>> >> >> >>> "http://localhost:8345/mcf-authority-service/UserACLs?username=joe@fakedomain"
>>>>> >>> >> >> >>>
>>>>> >>> >> >> >>> ...and also the real domain name, whatever that is.  See if
>>>>> >>> >> >> >>> the
>>>>> >>> >> >> >>> access
>>>>> >>> >> >> >>> tokens that come back look correct.  If they don't then we
>>>>> >>> >> >> >>> know
>>>>> >>> >> >> >>> where
>>>>> >>> >> >> >>> there's an issue.
>>>>> >>> >> >> >>>
>>>>> >>> >> >> >>> If they *are* correct, let me know and we'll go to the next
>>>>> >>> >> >> >>> stage,
>>>>> >>> >> >> >>> which would be to make sure the authority service is
>>>>> >>> >> >> >>> actually
>>>>> >>> >> >> >>> getting
>>>>> >>> >> >> >>> called and the proper query is being built and run under
>>>>> >>> >> >> >>> Solr
>>>>> >>> >> >> >>> 3.1.
>>>>> >>> >> >> >>>
>>>>> >>> >> >> >>> Thanks,
>>>>> >>> >> >> >>> Karl
>>>>> >>> >> >> >>>
>>>>> >>> >> >> >>> On Tue, Apr 26, 2011 at 11:59 AM, Kadri Atalay
>>>>> >>> >> >> >>> <atalay.kadri@gmail.com>
>>>>> >>> >> >> >>> wrote:
>>>>> >>> >> >> >>> > Hi Karl,
>>>>> >>> >> >> >>> >
>>>>> >>> >> >> >>> > I followed the instructions, and for testing purposes set
>>>>> >>> >> >> >>> > "stored=true"
>>>>> >>> >> >> >>> > to
>>>>> >>> >> >> >>> > be able to see the ACL values stored in Solr.
>>>>> >>> >> >> >>> >
>>>>> >>> >> >> >>> > But, when I run the search in following format I get
>>>>> >>> >> >> >>> > peculiar
>>>>> >>> >> >> >>> > results..
>>>>> >>> >> >> >>> >
>>>>> >>> >> >> >>> >
>>>>> >>> >> >> >>> >
>>>>> >>> >> >> >>> >
>>>>> >>> >> >> >>> >
>>>>> >>> >> >> >>> > :http://10.1.200.155:8080/solr/select/?q=*%3A*&AuthenticatedUserName=username
>>>>> >>> >> >> >>> >
>>>>> >>> >> >> >>> > Any user name without a domain name  ie
>>>>> >>> >> >> >>> > AuthenticatedUserName=joe
>>>>> >>> >> >> >>> > does
>>>>> >>> >> >> >>> > not
>>>>> >>> >> >> >>> > return any results (which is correct)
>>>>> >>> >> >> >>> > But any user name with ANY domain name returns all the
>>>>> >>> >> >> >>> > indexes
>>>>> >>> >> >> >>> > ie
>>>>> >>> >> >> >>> > AuthenticatedUserName=joe@fakedomain   (which is not
>>>>> >>> >> >> >>> > correct)
>>>>> >>> >> >> >>> >
>>>>> >>> >> >> >>> > Any thoughts ?
>>>>> >>> >> >> >>> >
>>>>> >>> >> >> >>> > Thanks
>>>>> >>> >> >> >>> >
>>>>> >>> >> >> >>> > Kadri
>>>>> >>> >> >> >>> >
>>>>> >>> >> >> >>> > On Sun, Apr 24, 2011 at 7:08 PM, Karl Wright
>>>>> >>> >> >> >>> > <daddywri@gmail.com>
>>>>> >>> >> >> >>> > wrote:
>>>>> >>> >> >> >>> >>
>>>>> >>> >> >> >>> >> Solr 3.1 is being clever here; it's seeing arguments
>>>>> >>> >> >> >>> >> coming
>>>>> >>> >> >> >>> >> in
>>>>> >>> >> >> >>> >> that
>>>>> >>> >> >> >>> >> do
>>>>> >>> >> >> >>> >> not correspond to known schema fields, and presuming they
>>>>> >>> >> >> >>> >> are
>>>>> >>> >> >> >>> >> "automatic" fields.  So when the schema is unmodified,
>>>>> >>> >> >> >>> >> you
>>>>> >>> >> >> >>> >> see
>>>>> >>> >> >> >>> >> these
>>>>> >>> >> >> >>> >> fields that Solr creates for you, with the attr_ prefix.
>>>>> >>> >> >> >>> >>  They
>>>>> >>> >> >> >>> >> are
>>>>> >>> >> >> >>> >> created as being "stored", which is not good for access
>>>>> >>> >> >> >>> >> tokens
>>>>> >>> >> >> >>> >> since
>>>>> >>> >> >> >>> >> then you will see them in the response.  I don't know if
>>>>> >>> >> >> >>> >> they
>>>>> >>> >> >> >>> >> are
>>>>> >>> >> >> >>> >> indexed or not, but I imagine not, which is also not
>>>>> >>> >> >> >>> >> good.
>>>>> >>> >> >> >>> >>
>>>>> >>> >> >> >>> >> So following the instructions is still the right thing to
>>>>> >>> >> >> >>> >> do,
>>>>> >>> >> >> >>> >> I
>>>>> >>> >> >> >>> >> would
>>>>> >>> >> >> >>> >> say.
>>>>> >>> >> >> >>> >>
>>>>> >>> >> >> >>> >> Karl
>>>>> >>> >> >> >>> >>
>>>>> >>> >> >> >>> >> On Fri, Apr 22, 2011 at 3:24 PM, Kadri Atalay
>>>>> >>> >> >> >>> >> <atalay.kadri@gmail.com>
>>>>> >>> >> >> >>> >> wrote:
>>>>> >>> >> >> >>> >> > Hi Karl,
>>>>> >>> >> >> >>> >> >
>>>>> >>> >> >> >>> >> > There is one thing I noticed while following the
>>>>> >>> >> >> >>> >> > example in
>>>>> >>> >> >> >>> >> > chapter
>>>>> >>> >> >> >>> >> > 4.:
>>>>> >>> >> >> >>> >> > Prior to making any changes into the schema.xml, I was
>>>>> >>> >> >> >>> >> > able
>>>>> >>> >> >> >>> >> > to
>>>>> >>> >> >> >>> >> > see
>>>>> >>> >> >> >>> >> > the
>>>>> >>> >> >> >>> >> > following security information in query responses:
>>>>> >>> >> >> >>> >> > ie:
>>>>> >>> >> >> >>> >> >
>>>>> >>> >> >> >>> >> > <doc>
>>>>> >>> >> >> >>> >> > -
>>>>> >>> >> >> >>> >> > <arr name="attr_allow_token_document">
>>>>> >>> >> >> >>> >> > <str>TEQA-DC:S-1-3-0</str>
>>>>> >>> >> >> >>> >> > <str>TEQA-DC:S-1-5-13</str>
>>>>> >>> >> >> >>> >> > <str>TEQA-DC:S-1-5-18</str>
>>>>> >>> >> >> >>> >> > <str>TEQA-DC:S-1-5-32-544</str>
>>>>> >>> >> >> >>> >> > <str>TEQA-DC:S-1-5-32-545</str>
>>>>> >>> >> >> >>> >> > <str>TEQA-DC:S-1-5-32-547</str>
>>>>> >>> >> >> >>> >> > </arr>
>>>>> >>> >> >> >>> >> > -
>>>>> >>> >> >> >>> >> > <arr name="attr_allow_token_share">
>>>>> >>> >> >> >>> >> > <str>TEQA-DC:S-1-1-0</str>
>>>>> >>> >> >> >>> >> > <str>TEQA-DC:S-1-5-2</str>
>>>>> >>> >> >> >>> >> > -
>>>>> >>> >> >> >>> >> > <str>
>>>>> >>> >> >> >>> >> > TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1480
>>>>> >>> >> >> >>> >> > </str>
>>>>> >>> >> >> >>> >> > </arr>
>>>>> >>> >> >> >>> >> > -
>>>>> >>> >> >> >>> >> > <arr name="attr_content">
>>>>> >>> >> >> >>> >> > -
>>>>> >>> >> >> >>> >> > <str>
>>>>> >>> >> >> >>> >> >                              Autonomy ODBC Fetch
>>>>> >>> >> >> >>> >> > Technical
>>>>> >>> >> >> >>> >> > Brief
>>>>> >>> >> >> >>> >> > 0506
>>>>> >>> >> >> >>> >> > Technical Brief
>>>>> >>> >> >> >>> >> >
>>>>> >>> >> >> >>> >> >
>>>>> >>> >> >> >>> >> > But, after I modified the schema/xml, and added the
>>>>> >>> >> >> >>> >> > following
>>>>> >>> >> >> >>> >> > fields,
>>>>> >>> >> >> >>> >> >     <!-- Security fields -->
>>>>> >>> >> >> >>> >> >     <field name="allow_token_document" type="string"
>>>>> >>> >> >> >>> >> > indexed="true"
>>>>> >>> >> >> >>> >> > stored="false" multiValued="true"/>
>>>>> >>> >> >> >>> >> >     <field name="deny_token_document" type="string"
>>>>> >>> >> >> >>> >> > indexed="true"
>>>>> >>> >> >> >>> >> > stored="false" multiValued="true"/>
>>>>> >>> >> >> >>> >> >     <field name="allow_token_share" type="string"
>>>>> >>> >> >> >>> >> > indexed="true"
>>>>> >>> >> >> >>> >> > stored="false" multiValued="true"/>
>>>>> >>> >> >> >>> >> >     <field name="deny_token_share" type="string"
>>>>> >>> >> >> >>> >> > indexed="true"
>>>>> >>> >> >> >>> >> > stored="false" multiValued="true"/>
>>>>> >>> >> >> >>> >> >
>>>>> >>> >> >> >>> >> > I longer see neither the attr_allow_token_document   or
>>>>> >>> >> >> >>> >> > the
>>>>> >>> >> >> >>> >> > allow_token_document fields..
>>>>> >>> >> >> >>> >> >
>>>>> >>> >> >> >>> >> > Since same fields exist with attr_  prefix, should we
>>>>> >>> >> >> >>> >> > need
>>>>> >>> >> >> >>> >> > to
>>>>> >>> >> >> >>> >> > add
>>>>> >>> >> >> >>> >> > these
>>>>> >>> >> >> >>> >> > new
>>>>> >>> >> >> >>> >> > field names into the schema file, or can we simply
>>>>> >>> >> >> >>> >> > change
>>>>> >>> >> >> >>> >> > ManifoldSecurity
>>>>> >>> >> >> >>> >> > to use attr_ fields ?
>>>>> >>> >> >> >>> >> >
>>>>> >>> >> >> >>> >> > Also, when Solr is running under Tomcat, I have to
>>>>> >>> >> >> >>> >> > re-start
>>>>> >>> >> >> >>> >> > the
>>>>> >>> >> >> >>> >> > Solr
>>>>> >>> >> >> >>> >> > App, or
>>>>> >>> >> >> >>> >> > re-start Tomcat to see the newly added indexes..
>>>>> >>> >> >> >>> >> >
>>>>> >>> >> >> >>> >> > Any thoughts ?
>>>>> >>> >> >> >>> >> >
>>>>> >>> >> >> >>> >> > Thanks
>>>>> >>> >> >> >>> >> >
>>>>> >>> >> >> >>> >> > Kadri
>>>>> >>> >> >> >>> >> >
>>>>> >>> >> >> >>> >> > On Fri, Apr 22, 2011 at 12:53 PM, Karl Wright
>>>>> >>> >> >> >>> >> > <daddywri@gmail.com>
>>>>> >>> >> >> >>> >> > wrote:
>>>>> >>> >> >> >>> >> >>
>>>>> >>> >> >> >>> >> >> I don't believe Solr has yet officially released
>>>>> >>> >> >> >>> >> >> document
>>>>> >>> >> >> >>> >> >> access
>>>>> >>> >> >> >>> >> >> control, so you will need to use the patch for ticket
>>>>> >>> >> >> >>> >> >> 1895.
>>>>> >>> >> >> >>> >> >> Alternatively, the ManifoldCF in Action chapter 4
>>>>> >>> >> >> >>> >> >> example
>>>>> >>> >> >> >>> >> >> has
>>>>> >>> >> >> >>> >> >> an
>>>>> >>> >> >> >>> >> >> implementation based on this ticket.  You can get the
>>>>> >>> >> >> >>> >> >> code
>>>>> >>> >> >> >>> >> >> for
>>>>> >>> >> >> >>> >> >> it at
>>>>> >>> >> >> >>> >> >>
>>>>> >>> >> >> >>> >> >>
>>>>> >>> >> >> >>> >> >>
>>>>> >>> >> >> >>> >> >>
>>>>> >>> >> >> >>> >> >>
>>>>> >>> >> >> >>> >> >>
>>>>> >>> >> >> >>> >> >>
>>>>> >>> >> >> >>> >> >> https://manifoldcfinaction.googlecode.com/svn/trunk/edition_1/security_example.
>>>>> >>> >> >> >>> >> >>
>>>>> >>> >> >> >>> >> >> Thanks,
>>>>> >>> >> >> >>> >> >> Karl
>>>>> >>> >> >> >>> >> >>
>>>>> >>> >> >> >>> >> >>
>>>>> >>> >> >> >>> >> >> On Fri, Apr 22, 2011 at 11:45 AM, Kadri Atalay
>>>>> >>> >> >> >>> >> >> <atalay.kadri@gmail.com>
>>>>> >>> >> >> >>> >> >> wrote:
>>>>> >>> >> >> >>> >> >> > Hello,
>>>>> >>> >> >> >>> >> >> >
>>>>> >>> >> >> >>> >> >> > Does anyone know which version of Solr have
>>>>> >>> >> >> >>> >> >> > implements
>>>>> >>> >> >> >>> >> >> > the
>>>>> >>> >> >> >>> >> >> > Document
>>>>> >>> >> >> >>> >> >> > Level
>>>>> >>> >> >> >>> >> >> > Access Control, or has it implemented (partially or
>>>>> >>> >> >> >>> >> >> > fully)
>>>>> >>> >> >> >>> >> >> > ?
>>>>> >>> >> >> >>> >> >> > Particularly issue #s 1834, 1872, 1895
>>>>> >>> >> >> >>> >> >> >
>>>>> >>> >> >> >>> >> >> > Thanks
>>>>> >>> >> >> >>> >> >> >
>>>>> >>> >> >> >>> >> >> > Kadri
>>>>> >>> >> >> >>> >> >> >
>>>>> >>> >> >> >>> >> >
>>>>> >>> >> >> >>> >> >
>>>>> >>> >> >> >>> >
>>>>> >>> >> >> >>> >
>>>>> >>> >> >> >>
>>>>> >>> >> >> >>
>>>>> >>> >> >> >
>>>>> >>> >> >
>>>>> >>> >> >
>>>>> >>> >
>>>>> >>> >
>>>>> >>
>>>>> >>
>>>>> >
>>>>
>>>>
>>>
>>
>

Mime
View raw message