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 Wed, 04 May 2011 04:55:42 GMT
I went back over these emails.  It appears that at no time have you
actually received SIDs, either user or group, back from any Authority
Connector inquiry:

>>>>>>
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
<<<<<<

I could have sworn that you had seen SIDs other than S-1-1-0 back for
existing users on your setup, but I can find no evidence that was ever
the case.  Given that, it seems perfectly reasonable that the change
in CONNECTORS-195 would convert ALL of these responses to USERNOTFOUND
ones.

Other recent users of the AD controller had no difficulty getting SIDs
back, most notably Mr. Abe, who worked closely with me on getting the
AD connector working with caching.  The conclusion I have is that
either your domain controller configuration, or your connection
credentials/credential permissions, are incorrect.  (I'd look
carefully at the permissions of the account you are giving to the
connection, because on the face of it that sounds most likely).  But
the fix for non-existent users seems to be right nevertheless, so I
will go ahead and commit to trunk.

Thanks,
Karl


On Tue, May 3, 2011 at 7:38 PM, Karl Wright <daddywri@gmail.com> wrote:
> Ok, can you try the trunk code?  If that works, I'll be shocked.  I
> think something must have changed in your environment since you began
> this experiment.
>
> Karl
>
> On Tue, May 3, 2011 at 6:19 PM, Kadri Atalay <atalay.kadri@gmail.com> wrote:
>> Karl,
>>
>> This is result from lates 195 branch..
>> I'll run it in the debugger to see actual error messages later on.
>>
>> Is there anyone else can verify this code against their active directory ?
>>
>> Thanks
>>
>> Kadri
>>
>> C:\OPT>curl
>> "http://localhost:8345/mcf-authority-service/UserACLs?username=fakeuser@fakedomain"
>> USERNOTFOUND:TEQA-DC
>> TOKEN:TEQA-DC:DEAD_AUTHORITY
>>
>> C:\OPT>curl
>> "http://localhost:8345/mcf-authority-service/UserACLs?username=fakeuser@teqa.filetek.com"
>> USERNOTFOUND:TEQA-DC
>> TOKEN:TEQA-DC:DEAD_AUTHORITY
>>
>> C:\OPT>curl
>> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_admin@teqa"
>> USERNOTFOUND:TEQA-DC
>> TOKEN:TEQA-DC:DEAD_AUTHORITY
>>
>> C:\OPT>curl
>> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_admin@teqa.filetek.com"
>> USERNOTFOUND:TEQA-DC
>> TOKEN:TEQA-DC:DEAD_AUTHORITY
>>
>> C:\OPT>curl
>> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay@teqa.filetek.com"
>> USERNOTFOUND:TEQA-DC
>> TOKEN:TEQA-DC:DEAD_AUTHORITY
>>
>> On Tue, May 3, 2011 at 5:48 PM, Karl Wright <daddywri@gmail.com> wrote:
>>>
>>> Never seen that before.  Do you have more than one instance running?
>>> Only one instance can run at a time or the database is unhappy.
>>>
>>> If that still doesn't seem to be the problem, try "ant clean" and then
>>> "ant build" again.  It will clean out the existing database instance.
>>>
>>> Karl
>>>
>>> On Tue, May 3, 2011 at 5:34 PM, Kadri Atalay <atalay.kadri@gmail.com>
>>> wrote:
>>> > Hi Karl,
>>> >
>>> > You are right, somehow I still had the OLD 195 code..
>>> > Just got the latest, compiled, but this one doesn't start after the
>>> > message
>>> > "Configuration file successfully read"
>>> >
>>> > Any ideas ?
>>> >
>>> > Thanks
>>> >
>>> > Kadri
>>> >
>>> > On Tue, May 3, 2011 at 3:12 PM, Karl Wright <daddywri@gmail.com> wrote:
>>> >>
>>> >> The latest CONNECTORS-195 branch code doesn't use sAMAccountName.  It
>>> >> uses ObjectSid.  Your schema has ObjectSid.  The version of
>>> >> ActiveDirectoryAuthority in trunk looks up ObjectSid too.  Indeed, the
>>> >> only change is the addition of the following:
>>> >>
>>> >> if (theGroups.size() == 0)
>>> >>  return userNotFoundResponse;
>>> >>
>>> >> This CANNOT occur for an existing user, because all existing users
>>> >> must have at least one SID.  And, if existing users returned the
>>> >> proper SIDs before, this should not change anything.  So I cannot see
>>> >> how you could be getting the result you claim.
>>> >>
>>> >> Are you SURE you synched up the CONNECTORS-195 branch and built that?
>>> >> I have not checked this code into trunk yet.
>>> >>
>>> >> Karl
>>> >>
>>> >>
>>> >>
>>> >> On Tue, May 3, 2011 at 2:46 PM, Kadri Atalay <atalay.kadri@gmail.com>
>>> >> wrote:
>>> >> > Hi Carl,
>>> >> >
>>> >> > Got the latest one, built and tried but same result..
>>> >> > At the mean time took a look my user account with AD browser, and as
>>> >> > you
>>> >> > can
>>> >> > see (attached) it does have a sAMAccountName attribute.
>>> >> > BTW, do we have to use objectClass = user for the search filter ?
>>> >> > May
>>> >> > need
>>> >> > to check into this..
>>> >> >
>>> >> > Thanks
>>> >> >
>>> >> > Kadri
>>> >> >
>>> >> > 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