You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@manifoldcf.apache.org by Kadri Atalay <at...@gmail.com> on 2011/05/02 21:31:43 UTC
Re: Which version of Solr have implements the Document Level Access Control
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 <da...@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 <at...@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 <da...@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 <da...@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 <da...@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
> >> >>> <at...@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 <da...@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
> >> >>> >> <at...@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
> >> >>> >> > <da...@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
> >> >>> >> >> <at...@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
> >> >>> >> >> >
> >> >>> >> >
> >> >>> >> >
> >> >>> >
> >> >>> >
> >> >>
> >> >>
> >> >
> >
> >
>
Re: Which version of Solr have implements the Document Level Access Control
Posted by Kadri Atalay <at...@gmail.com>.
Karl, it sounds good !
I'll let you know, with the results.
Thanks!
Kadri
On Tue, May 3, 2011 at 3:55 AM, Karl Wright <da...@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 <da...@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 <at...@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 <da...@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 <at...@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 <da...@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
> >>> >> >> > <at...@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
> >>> >> >> >> <da...@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
> >>> >> >> >>> <at...@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
> >>> >> >> >>> > <da...@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
> >>> >> >> >>> >> <at...@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
> >>> >> >> >>> >> > <da...@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
> >>> >> >> >>> >> >> <at...@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
> >>> >> >> >>> >> >> >
> >>> >> >> >>> >> >
> >>> >> >> >>> >> >
> >>> >> >> >>> >
> >>> >> >> >>> >
> >>> >> >> >>
> >>> >> >> >>
> >>> >> >> >
> >>> >> >
> >>> >> >
> >>> >
> >>> >
> >>
> >>
> >
>
Re: Which version of Solr have implements the Document Level Access Control
Posted by Karl Wright <da...@gmail.com>.
Hi again,
I did some research on S-1-1-0. Microsoft reserves this and by their
documentation you cannot change whether an individual user is
considered a member of this group or not. The only change they
mention to the behavior of this is that prior to Windows XP SP2,
anonymous users were considered to have S-1-1-0, while after Windows
XP SP2, they were not. It is possible that there is a global
configuration setting for S-1-1-0 group affinity for ALL users, but I
haven't found any solid indication of that, either.
Karl
On Wed, May 4, 2011 at 11:26 AM, Karl Wright <da...@gmail.com> wrote:
> Hi Kadri,
>
> Shinichiro Abe has been using the Active Directory authority connector
> actively and successfully recently. I've asked him to verify the
> change that I proposed for detecting the user-not-found condition more
> reliably. I am still waiting for his response.
>
> The code would not be adding the S-1-1-0 group if it was being
> returned by Active Directory, but in my tests (now more than a year
> ago) on Windows Server 2000 and Windows Server 2003, it never did get
> returned. And yet it was critically important, which is why I had no
> choice but to add it manually.
>
> Since it is a well-known group with a standard definition, there
> should be no concern that there would be a conflict. The only
> potential issue could be that not all users have S-1-1-0. I'd love to
> see any indication that this can ever be the case. If so, there must
> be a way to detect this detail through LDAP, which we'd have to learn
> somehow.
>
> Karl
>
>
Re: Which version of Solr have implements the Document Level Access Control
Posted by Karl Wright <da...@gmail.com>.
ok, if you try what I sent and it works, I will check it in.
Karl
On Thu, May 5, 2011 at 6:29 PM, Kadri Atalay <at...@gmail.com> wrote:
> I'm assuming that since this is a Domain logon name, we don't need to add
> any escaping sequence, otherwise OS would reject it during authentication.
>
> Yes, you are right, userSID is needed, if user is not any part of group but
> still have access to document.
>
> On Thu, May 5, 2011 at 6:23 PM, Karl Wright <da...@gmail.com> wrote:
>>
>> Thanks - we do need the user sid, so I will put that back.
>>
>> Also, I'd like to ask what you know about escaping the user name in
>> this expression:
>>
>> String searchFilter = "(&(objectClass=user)(sAMAccountName=" + userName +
>> "))";
>>
>> It seems to me that there is probably some escaping needed, but I
>> don't know what style. Do you think it is the same (C-style, with \
>> escape) as for the other case?
>>
>> Karl
>>
>> On Thu, May 5, 2011 at 6:20 PM, Kadri Atalay <at...@gmail.com>
>> wrote:
>> > Hi Karl,
>> >
>> > String returnedAtts[]={"tokenGroups"} is ONLY returning the
>> > memberGroups,
>> >
>> > C:\OPT>curl
>> >
>> > "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_admin@teqa.filetek.com"
>> > AUTHORIZED:TEQA-DC
>> > TOKEN:TEQA-DC:S-1-5-32-545
>> > TOKEN:TEQA-DC:S-1-5-32-544
>> > TOKEN:TEQA-DC:S-1-5-32-555
>> > TOKEN:TEQA-DC:S-1-5-21-
>> > 1212545812-2858578934-3563067286-1124
>> > TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-512
>> > TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
>> > TOKEN:TEQA-DC:S-1-1-0
>> >
>> > but,
>> >
>> > - String returnedAtts[] = {"tokenGroups","objectSid"}; is returning
>> > memberGroups AND SID for that user.
>> >
>> > C:\OPT>curl
>> >
>> > "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_admin@teqa.filetek.com"
>> > AUTHORIZED:TEQA-DC
>> > TOKEN:TEQA-DC:S-1-5-32-545
>> > TOKEN:TEQA-DC:S-1-5-32-544
>> > TOKEN:TEQA-DC:S-1-5-32-555
>> > TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1124
>> > TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-512
>> > TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
>> > TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1480
>> > TOKEN:TEQA-DC:S-1-1-0
>> >
>> > Since we are only interested in the member groups, tokenGroups is
>> > sufficient, but if you also need user SID then you might keep the
>> > objectSID
>> > as well.
>> >
>> > Thanks
>> >
>> > Kadri
>> >
>> >
>> > On Thu, May 5, 2011 at 6:01 PM, Karl Wright <da...@gmail.com> wrote:
>> >>
>> >> I am curious about the following change, which does not seem correct:
>> >>
>> >>
>> >> //Specify the attributes to return
>> >> - String returnedAtts[] = {"tokenGroups","objectSid"};
>> >> + String returnedAtts[]={"tokenGroups"};
>> >> searchCtls.setReturningAttributes(returnedAtts);
>> >>
>> >> Karl
>> >>
>> >>
>> >> On Thu, May 5, 2011 at 5:36 PM, Kadri Atalay <at...@gmail.com>
>> >> wrote:
>> >> > Karl,
>> >> >
>> >> > The ActiveDirectoryAuthority.java is attached.
>> >> >
>> >> > I'm not sure about clicking "Grant ASF License", or how to do that
>> >> > from
>> >> > Tortoise.
>> >> > But, you got my consent for granting the ASF license.
>> >> >
>> >> > Thanks
>> >> >
>> >> > Kadri
>> >> >
>> >> >
>> >> > On Thu, May 5, 2011 at 5:28 PM, Karl Wright <da...@gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> You may attach the whole ActiveDirectoryAuthority.java file to the
>> >> >> ticket if you prefer. But you must click the "Grant ASF License"
>> >> >> button.
>> >> >>
>> >> >> Karl
>> >> >>
>> >> >> On Thu, May 5, 2011 at 5:24 PM, Kadri Atalay
>> >> >> <at...@gmail.com>
>> >> >> wrote:
>> >> >> > Karl,
>> >> >> >
>> >> >> > I'm using the Tortoise SVN, and new to SVN..
>> >> >> > Do you know how to do this with Tortoise ?
>> >> >> > Otherwise, I can just send the source code directly to you.
>> >> >> > BTW, there are some changes in the ParseUser method also, you can
>> >> >> > see
>> >> >> > all
>> >> >> > when you run the diff.
>> >> >> >
>> >> >> > Thanks
>> >> >> >
>> >> >> > Kadri
>> >> >> >
>> >> >
>> >> >
>> >
>> >
>
>
Re: Which version of Solr have implements the Document Level Access Control
Posted by Kadri Atalay <at...@gmail.com>.
I'm assuming that since this is a Domain logon name, we don't need to add
any escaping sequence, otherwise OS would reject it during authentication.
Yes, you are right, userSID is needed, if user is not any part of group but
still have access to document.
On Thu, May 5, 2011 at 6:23 PM, Karl Wright <da...@gmail.com> wrote:
> Thanks - we do need the user sid, so I will put that back.
>
> Also, I'd like to ask what you know about escaping the user name in
> this expression:
>
> String searchFilter = "(&(objectClass=user)(sAMAccountName=" + userName +
> "))";
>
> It seems to me that there is probably some escaping needed, but I
> don't know what style. Do you think it is the same (C-style, with \
> escape) as for the other case?
>
> Karl
>
> On Thu, May 5, 2011 at 6:20 PM, Kadri Atalay <at...@gmail.com>
> wrote:
> > Hi Karl,
> >
> > String returnedAtts[]={"tokenGroups"} is ONLY returning the
> > memberGroups,
> >
> > C:\OPT>curl
> > "
> http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_admin@teqa.filetek.com
> "
> > AUTHORIZED:TEQA-DC
> > TOKEN:TEQA-DC:S-1-5-32-545
> > TOKEN:TEQA-DC:S-1-5-32-544
> > TOKEN:TEQA-DC:S-1-5-32-555
> > TOKEN:TEQA-DC:S-1-5-21-
> > 1212545812-2858578934-3563067286-1124
> > TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-512
> > TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
> > TOKEN:TEQA-DC:S-1-1-0
> >
> > but,
> >
> > - String returnedAtts[] = {"tokenGroups","objectSid"}; is returning
> > memberGroups AND SID for that user.
> >
> > C:\OPT>curl
> > "
> http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_admin@teqa.filetek.com
> "
> > AUTHORIZED:TEQA-DC
> > TOKEN:TEQA-DC:S-1-5-32-545
> > TOKEN:TEQA-DC:S-1-5-32-544
> > TOKEN:TEQA-DC:S-1-5-32-555
> > TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1124
> > TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-512
> > TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
> > TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1480
> > TOKEN:TEQA-DC:S-1-1-0
> >
> > Since we are only interested in the member groups, tokenGroups is
> > sufficient, but if you also need user SID then you might keep the
> objectSID
> > as well.
> >
> > Thanks
> >
> > Kadri
> >
> >
> > On Thu, May 5, 2011 at 6:01 PM, Karl Wright <da...@gmail.com> wrote:
> >>
> >> I am curious about the following change, which does not seem correct:
> >>
> >>
> >> //Specify the attributes to return
> >> - String returnedAtts[] = {"tokenGroups","objectSid"};
> >> + String returnedAtts[]={"tokenGroups"};
> >> searchCtls.setReturningAttributes(returnedAtts);
> >>
> >> Karl
> >>
> >>
> >> On Thu, May 5, 2011 at 5:36 PM, Kadri Atalay <at...@gmail.com>
> >> wrote:
> >> > Karl,
> >> >
> >> > The ActiveDirectoryAuthority.java is attached.
> >> >
> >> > I'm not sure about clicking "Grant ASF License", or how to do that
> from
> >> > Tortoise.
> >> > But, you got my consent for granting the ASF license.
> >> >
> >> > Thanks
> >> >
> >> > Kadri
> >> >
> >> >
> >> > On Thu, May 5, 2011 at 5:28 PM, Karl Wright <da...@gmail.com>
> wrote:
> >> >>
> >> >> You may attach the whole ActiveDirectoryAuthority.java file to the
> >> >> ticket if you prefer. But you must click the "Grant ASF License"
> >> >> button.
> >> >>
> >> >> Karl
> >> >>
> >> >> On Thu, May 5, 2011 at 5:24 PM, Kadri Atalay <atalay.kadri@gmail.com
> >
> >> >> wrote:
> >> >> > Karl,
> >> >> >
> >> >> > I'm using the Tortoise SVN, and new to SVN..
> >> >> > Do you know how to do this with Tortoise ?
> >> >> > Otherwise, I can just send the source code directly to you.
> >> >> > BTW, there are some changes in the ParseUser method also, you can
> see
> >> >> > all
> >> >> > when you run the diff.
> >> >> >
> >> >> > Thanks
> >> >> >
> >> >> > Kadri
> >> >> >
> >> >
> >> >
> >
> >
>
Re: Which version of Solr have implements the Document Level Access Control
Posted by Karl Wright <da...@gmail.com>.
Thanks - I'll have a look at this first chance I get.
Karl
On Fri, May 6, 2011 at 6:24 PM, Kadri Atalay <at...@gmail.com> wrote:
> Hi Karl,
>
> While looking over AD access and attributes, I found that
> "distinguishedName"
> attribute contains all the information we need for TokenGroups search, in
> the correct format ie:
> "CN=Administrator,CN=Users,DC=qa-ad-76,DC=metacarta,DC=com";
> and by using this attribute instead of CN, we don't need to build the
> searchbase ourselves.
>
> There are 2 advantages of using this attribute:
> 1- Even if the user is not part of users group (whatever the reason maybe)
> we still get the results back, because his information is included in the
> "distinguishedName" attribute.
> 2- We don't need to do treat any special characters like comma, etc.. (it's
> already formatted).
>
> I tested the code it works. Please see attached for the latest.
>
> Thanks
>
> Kadri
>
> Following is no longer needed:
> StringBuffer sb = new StringBuffer();
> sb.append("CN=").append(ldapEscape(userCN)).append(",CN=Users,");
> sb.append(domainsb);
>
>
>
>
>
> On Fri, May 6, 2011 at 11:03 AM, Kadri Atalay <at...@gmail.com>
> wrote:
>>
>> Hi Karl,
>>
>> Tested, and it's working.
>>
>> Thanks!
>>
>> Kadri
>>
>>
>> On Thu, May 5, 2011 at 7:29 PM, Karl Wright <da...@gmail.com> wrote:
>>>
>>> I think yours was working because it was returning "cn=null,
>>> cn=users", which was a result of the fact that cn was null and the
>>> expression was assembled using the "+" operator. When I separated the
>>> ldap escape out, it caused a null pointer exception to be thrown
>>> instead. It should be fixed now.
>>>
>>> Karl
>>>
>>>
>>> On Thu, May 5, 2011 at 7:19 PM, Kadri Atalay <at...@gmail.com>
>>> wrote:
>>> > Fyi. The file I sent you was returning usernotfound.
>>> >
>>> >
>>> > Sent from my iPhone
>>> >
>>> > On May 5, 2011, at 7:12 PM, Karl Wright <da...@gmail.com> wrote:
>>> >
>>> >> It must mean we're somehow throwing an exception in the case where the
>>> >> user is missing. I bet I know why - the CN lookup is failing instead.
>>> >> I'll see if I can change it.
>>> >>
>>> >> Karl
>>> >>
>>> >> On Thu, May 5, 2011 at 6:43 PM, Kadri Atalay <at...@gmail.com>
>>> >> wrote:
>>> >>> It works, only difference I see with previous one is: if a domain is
>>> >>> reachable, message usernotfound makes a better indicator, somehow we
>>> >>> lost
>>> >>> that.
>>> >>>
>>> >>>
>>> >>> C:\OPT>testauthority
>>> >>>
>>> >>> C:\OPT>curl
>>> >>>
>>> >>> "http://localhost:8345/mcf-authority-service/UserACLs?username=fakeuser"
>>> >>> UNREACHABLEAUTHORITY:TEQA-DC
>>> >>> TOKEN:TEQA-DC:DEAD_AUTHORITY
>>> >>>
>>> >>> C:\OPT>curl
>>> >>>
>>> >>> "http://localhost:8345/mcf-authority-service/UserACLs?username=fakeuser@fakedomain"
>>> >>> UNREACHABLEAUTHORITY:TEQA-DC
>>> >>> TOKEN:TEQA-DC:DEAD_AUTHORITY
>>> >>>
>>> >>> C:\OPT>curl
>>> >>>
>>> >>> "http://localhost:8345/mcf-authority-service/UserACLs?username=fakeuser@teqa.filetek.com"
>>> >>> UNREACHABLEAUTHORITY:TEQA-DC
>>> >>> TOKEN:TEQA-DC:DEAD_AUTHORITY
>>> >>>
>>> >>> Previous one
>>> >>> 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"
>>> >>> UNREACHABLEAUTHORITY:TEQA-DC
>>> >>> TOKEN:TEQA-DC:DEAD_AUTHORITY
>>> >>>
>>> >>> C:\OPT>curl
>>> >>>
>>> >>> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_admin@teqa.filetek.com"
>>> >>> AUTHORIZED:TEQA-DC
>>> >>> TOKEN:TEQA-DC:S-1-5-32-545
>>> >>> TOKEN:TEQA-DC:S-1-5-32-544
>>> >>> TOKEN:TEQA-DC:S-1-5-32-555
>>> >>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1124
>>> >>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-512
>>> >>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
>>> >>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1480
>>> >>> TOKEN:TEQA-DC:S-1-1-0
>>> >>>
>>> >>> C:\OPT>curl
>>> >>>
>>> >>> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay@teqa.filetek.com"
>>> >>> AUTHORIZED:TEQA-DC
>>> >>> TOKEN:TEQA-DC:S-1-5-32-545
>>> >>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
>>> >>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1473
>>> >>> TOKEN:TEQA-DC:S-1-1-0
>>> >>>
>>> >>> C:\OPT>curl
>>> >>>
>>> >>> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay@fakedomain"
>>> >>> UNREACHABLEAUTHORITY:TEQA-DC
>>> >>> TOKEN:TEQA-DC:DEAD_AUTHORITY
>>> >>>
>>> >>>
>>> >>> On Thu, May 5, 2011 at 6:29 PM, Karl Wright <da...@gmail.com>
>>> >>> wrote:
>>> >>>>
>>> >>>> I've cleaned things up slightly to restore the objectSid and also to
>>> >>>> fix an infinite loop ifyou have more than one comma in the escape
>>> >>>> expression. I've attached the file, can you see if it works?
>>> >>>>
>>> >>>> Thanks,
>>> >>>> Karl
>>> >>>>
>>> >>>>
>>> >>>> On Thu, May 5, 2011 at 6:23 PM, Karl Wright <da...@gmail.com>
>>> >>>> wrote:
>>> >>>>> Thanks - we do need the user sid, so I will put that back.
>>> >>>>>
>>> >>>>> Also, I'd like to ask what you know about escaping the user name in
>>> >>>>> this expression:
>>> >>>>>
>>> >>>>> String searchFilter = "(&(objectClass=user)(sAMAccountName=" +
>>> >>>>> userName
>>> >>>>> + "))";
>>> >>>>>
>>> >>>>> It seems to me that there is probably some escaping needed, but I
>>> >>>>> don't know what style. Do you think it is the same (C-style, with
>>> >>>>> \
>>> >>>>> escape) as for the other case?
>>> >>>>>
>>> >>>>> Karl
>>> >>>>>
>>> >>>>> On Thu, May 5, 2011 at 6:20 PM, Kadri Atalay
>>> >>>>> <at...@gmail.com>
>>> >>>>> wrote:
>>> >>>>>> Hi Karl,
>>> >>>>>>
>>> >>>>>> String returnedAtts[]={"tokenGroups"} is ONLY returning the
>>> >>>>>> memberGroups,
>>> >>>>>>
>>> >>>>>> C:\OPT>curl
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_admin@teqa.filetek.com"
>>> >>>>>> AUTHORIZED:TEQA-DC
>>> >>>>>> TOKEN:TEQA-DC:S-1-5-32-545
>>> >>>>>> TOKEN:TEQA-DC:S-1-5-32-544
>>> >>>>>> TOKEN:TEQA-DC:S-1-5-32-555
>>> >>>>>> TOKEN:TEQA-DC:S-1-5-21-
>>> >>>>>> 1212545812-2858578934-3563067286-1124
>>> >>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-512
>>> >>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
>>> >>>>>> TOKEN:TEQA-DC:S-1-1-0
>>> >>>>>>
>>> >>>>>> but,
>>> >>>>>>
>>> >>>>>> - String returnedAtts[] = {"tokenGroups","objectSid"}; is
>>> >>>>>> returning
>>> >>>>>> memberGroups AND SID for that user.
>>> >>>>>>
>>> >>>>>> C:\OPT>curl
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_admin@teqa.filetek.com"
>>> >>>>>> AUTHORIZED:TEQA-DC
>>> >>>>>> TOKEN:TEQA-DC:S-1-5-32-545
>>> >>>>>> TOKEN:TEQA-DC:S-1-5-32-544
>>> >>>>>> TOKEN:TEQA-DC:S-1-5-32-555
>>> >>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1124
>>> >>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-512
>>> >>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
>>> >>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1480
>>> >>>>>> TOKEN:TEQA-DC:S-1-1-0
>>> >>>>>>
>>> >>>>>> Since we are only interested in the member groups, tokenGroups is
>>> >>>>>> sufficient, but if you also need user SID then you might keep the
>>> >>>>>> objectSID
>>> >>>>>> as well.
>>> >>>>>>
>>> >>>>>> Thanks
>>> >>>>>>
>>> >>>>>> Kadri
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> On Thu, May 5, 2011 at 6:01 PM, Karl Wright <da...@gmail.com>
>>> >>>>>> wrote:
>>> >>>>>>>
>>> >>>>>>> I am curious about the following change, which does not seem
>>> >>>>>>> correct:
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>> //Specify the attributes to return
>>> >>>>>>> - String returnedAtts[] = {"tokenGroups","objectSid"};
>>> >>>>>>> + String returnedAtts[]={"tokenGroups"};
>>> >>>>>>> searchCtls.setReturningAttributes(returnedAtts);
>>> >>>>>>>
>>> >>>>>>> Karl
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>> On Thu, May 5, 2011 at 5:36 PM, Kadri Atalay
>>> >>>>>>> <at...@gmail.com>
>>> >>>>>>> wrote:
>>> >>>>>>>> Karl,
>>> >>>>>>>>
>>> >>>>>>>> The ActiveDirectoryAuthority.java is attached.
>>> >>>>>>>>
>>> >>>>>>>> I'm not sure about clicking "Grant ASF License", or how to do
>>> >>>>>>>> that
>>> >>>>>>>> from
>>> >>>>>>>> Tortoise.
>>> >>>>>>>> But, you got my consent for granting the ASF license.
>>> >>>>>>>>
>>> >>>>>>>> Thanks
>>> >>>>>>>>
>>> >>>>>>>> Kadri
>>> >>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>> On Thu, May 5, 2011 at 5:28 PM, Karl Wright <da...@gmail.com>
>>> >>>>>>>> wrote:
>>> >>>>>>>>>
>>> >>>>>>>>> You may attach the whole ActiveDirectoryAuthority.java file to
>>> >>>>>>>>> the
>>> >>>>>>>>> ticket if you prefer. But you must click the "Grant ASF
>>> >>>>>>>>> License"
>>> >>>>>>>>> button.
>>> >>>>>>>>>
>>> >>>>>>>>> Karl
>>> >>>>>>>>>
>>> >>>>>>>>> On Thu, May 5, 2011 at 5:24 PM, Kadri Atalay
>>> >>>>>>>>> <at...@gmail.com>
>>> >>>>>>>>> wrote:
>>> >>>>>>>>>> Karl,
>>> >>>>>>>>>>
>>> >>>>>>>>>> I'm using the Tortoise SVN, and new to SVN..
>>> >>>>>>>>>> Do you know how to do this with Tortoise ?
>>> >>>>>>>>>> Otherwise, I can just send the source code directly to you.
>>> >>>>>>>>>> BTW, there are some changes in the ParseUser method also, you
>>> >>>>>>>>>> can
>>> >>>>>>>>>> see
>>> >>>>>>>>>> all
>>> >>>>>>>>>> when you run the diff.
>>> >>>>>>>>>>
>>> >>>>>>>>>> Thanks
>>> >>>>>>>>>>
>>> >>>>>>>>>> Kadri
>>> >>>>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>
>>> >>>
>>> >>>
>>> >
>>
>
>
Re: Which version of Solr have implements the Document Level Access Control
Posted by Karl Wright <da...@gmail.com>.
Shinichiro submitted a patch based on simply selecting which field to
use, and that was committed earlier today.
But thanks anyway!
Karl
On Mon, May 9, 2011 at 4:47 PM, Kadri Atalay <at...@gmail.com> wrote:
> Hi Karl,
>
> sAMAccountName holds the logon name upto 20 chars, and userPrincipalName
> holds the logon name upto 256 (including domain name).
>
> I made changes to accomodate both cases: Please see attached file:
>
> We can resolve this issue by making 2 calls to getDistinguishedName method
> using different attributes.
> First call is with sAMAccountName (supports only up to 20 chars)
> If that fails, we can call again using userPrincipalName, up to 256 chars.
>
> Configuration may be used if we don't want to make 2 calls for performance
> reasons.
>
> //Get DistinguishedName (for this method we are using DomainPart as a
> searchBase ie: DC=qa-ad-76,DC=metacarta,DC=com")
> //First call is for logon-name limited to 20 chars used with
> sAMAccountName
> String userDN = getDistinguishedName(userPart, domainsb.toString(),
> "sAMAccountName" );
>
> //Second call is for logon-name NOT limited to 20 chars used with
> userPrincipalName
> if (userDN == null)
> userDN = getDistinguishedName(userName, domainsb.toString(),
> "userPrincipalName");
> return userDN;
>
> Following is the test results:
>
> Thanks
>
> Kadri
>
>
> C:\OPT>echo follOWING users are the same
>
> username 25 characters long
>
> C:\OPT>curl
> "http://localhost:8345/mcf-authority-service/UserACLs?username=1234567890123456789012345@teqa.filetek.com"
> AUTHORIZED:TEQA-DC
> TOKEN:TEQA-DC:S-1-5-32-545
> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-2627
> TOKEN:TEQA-DC:S-1-1-0
>
> username 20 characters long
>
> C:\OPT>curl
> "http://localhost:8345/mcf-authority-service/UserACLs?username=12345678901234567890@teqa.filetek.com"
> AUTHORIZED:TEQA-DC
> TOKEN:TEQA-DC:S-1-5-32-545
> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-2627
> TOKEN:TEQA-DC:S-1-1-0
>
> C:\OPT>
>
> On Sun, May 8, 2011 at 10:19 AM, Karl Wright <da...@gmail.com> wrote:
>>
>> This looked very good, so I committed it as-is. It does, however,
>> invalidate Shinichiro's earlier patch for CONNECTORS-197. Would you
>> know what the login id field would be if the active directory instance
>> does not have sAMAccountName? Is it uid?
>>
>> Karl
>>
>> On Fri, May 6, 2011 at 6:24 PM, Kadri Atalay <at...@gmail.com>
>> wrote:
>> > Hi Karl,
>> >
>> > While looking over AD access and attributes, I found that
>> > "distinguishedName"
>> > attribute contains all the information we need for TokenGroups search,
>> > in
>> > the correct format ie:
>> > "CN=Administrator,CN=Users,DC=qa-ad-76,DC=metacarta,DC=com";
>> > and by using this attribute instead of CN, we don't need to build the
>> > searchbase ourselves.
>> >
>> > There are 2 advantages of using this attribute:
>> > 1- Even if the user is not part of users group (whatever the reason
>> > maybe)
>> > we still get the results back, because his information is included in
>> > the
>> > "distinguishedName" attribute.
>> > 2- We don't need to do treat any special characters like comma, etc..
>> > (it's
>> > already formatted).
>> >
>> > I tested the code it works. Please see attached for the latest.
>> >
>> > Thanks
>> >
>> > Kadri
>> >
>> > Following is no longer needed:
>> > StringBuffer sb = new StringBuffer();
>> > sb.append("CN=").append(ldapEscape(userCN)).append(",CN=Users,");
>> > sb.append(domainsb);
>> >
>> >
>> >
>> >
>> >
>> > On Fri, May 6, 2011 at 11:03 AM, Kadri Atalay <at...@gmail.com>
>> > wrote:
>> >>
>> >> Hi Karl,
>> >>
>> >> Tested, and it's working.
>> >>
>> >> Thanks!
>> >>
>> >> Kadri
>> >>
>> >>
>> >> On Thu, May 5, 2011 at 7:29 PM, Karl Wright <da...@gmail.com> wrote:
>> >>>
>> >>> I think yours was working because it was returning "cn=null,
>> >>> cn=users", which was a result of the fact that cn was null and the
>> >>> expression was assembled using the "+" operator. When I separated the
>> >>> ldap escape out, it caused a null pointer exception to be thrown
>> >>> instead. It should be fixed now.
>> >>>
>> >>> Karl
>> >>>
>> >>>
>> >>> On Thu, May 5, 2011 at 7:19 PM, Kadri Atalay <at...@gmail.com>
>> >>> wrote:
>> >>> > Fyi. The file I sent you was returning usernotfound.
>> >>> >
>> >>> >
>> >>> > Sent from my iPhone
>> >>> >
>> >>> > On May 5, 2011, at 7:12 PM, Karl Wright <da...@gmail.com> wrote:
>> >>> >
>> >>> >> It must mean we're somehow throwing an exception in the case where
>> >>> >> the
>> >>> >> user is missing. I bet I know why - the CN lookup is failing
>> >>> >> instead.
>> >>> >> I'll see if I can change it.
>> >>> >>
>> >>> >> Karl
>> >>> >>
>> >>> >> On Thu, May 5, 2011 at 6:43 PM, Kadri Atalay
>> >>> >> <at...@gmail.com>
>> >>> >> wrote:
>> >>> >>> It works, only difference I see with previous one is: if a domain
>> >>> >>> is
>> >>> >>> reachable, message usernotfound makes a better indicator, somehow
>> >>> >>> we
>> >>> >>> lost
>> >>> >>> that.
>> >>> >>>
>> >>> >>>
>> >>> >>> C:\OPT>testauthority
>> >>> >>>
>> >>> >>> C:\OPT>curl
>> >>> >>>
>> >>> >>>
>> >>> >>> "http://localhost:8345/mcf-authority-service/UserACLs?username=fakeuser"
>> >>> >>> UNREACHABLEAUTHORITY:TEQA-DC
>> >>> >>> TOKEN:TEQA-DC:DEAD_AUTHORITY
>> >>> >>>
>> >>> >>> C:\OPT>curl
>> >>> >>>
>> >>> >>>
>> >>> >>> "http://localhost:8345/mcf-authority-service/UserACLs?username=fakeuser@fakedomain"
>> >>> >>> UNREACHABLEAUTHORITY:TEQA-DC
>> >>> >>> TOKEN:TEQA-DC:DEAD_AUTHORITY
>> >>> >>>
>> >>> >>> C:\OPT>curl
>> >>> >>>
>> >>> >>>
>> >>> >>> "http://localhost:8345/mcf-authority-service/UserACLs?username=fakeuser@teqa.filetek.com"
>> >>> >>> UNREACHABLEAUTHORITY:TEQA-DC
>> >>> >>> TOKEN:TEQA-DC:DEAD_AUTHORITY
>> >>> >>>
>> >>> >>> Previous one
>> >>> >>> 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"
>> >>> >>> UNREACHABLEAUTHORITY:TEQA-DC
>> >>> >>> TOKEN:TEQA-DC:DEAD_AUTHORITY
>> >>> >>>
>> >>> >>> C:\OPT>curl
>> >>> >>>
>> >>> >>>
>> >>> >>> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_admin@teqa.filetek.com"
>> >>> >>> AUTHORIZED:TEQA-DC
>> >>> >>> TOKEN:TEQA-DC:S-1-5-32-545
>> >>> >>> TOKEN:TEQA-DC:S-1-5-32-544
>> >>> >>> TOKEN:TEQA-DC:S-1-5-32-555
>> >>> >>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1124
>> >>> >>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-512
>> >>> >>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
>> >>> >>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1480
>> >>> >>> TOKEN:TEQA-DC:S-1-1-0
>> >>> >>>
>> >>> >>> C:\OPT>curl
>> >>> >>>
>> >>> >>>
>> >>> >>> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay@teqa.filetek.com"
>> >>> >>> AUTHORIZED:TEQA-DC
>> >>> >>> TOKEN:TEQA-DC:S-1-5-32-545
>> >>> >>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
>> >>> >>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1473
>> >>> >>> TOKEN:TEQA-DC:S-1-1-0
>> >>> >>>
>> >>> >>> C:\OPT>curl
>> >>> >>>
>> >>> >>>
>> >>> >>> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay@fakedomain"
>> >>> >>> UNREACHABLEAUTHORITY:TEQA-DC
>> >>> >>> TOKEN:TEQA-DC:DEAD_AUTHORITY
>> >>> >>>
>> >>> >>>
>> >>> >>> On Thu, May 5, 2011 at 6:29 PM, Karl Wright <da...@gmail.com>
>> >>> >>> wrote:
>> >>> >>>>
>> >>> >>>> I've cleaned things up slightly to restore the objectSid and also
>> >>> >>>> to
>> >>> >>>> fix an infinite loop ifyou have more than one comma in the escape
>> >>> >>>> expression. I've attached the file, can you see if it works?
>> >>> >>>>
>> >>> >>>> Thanks,
>> >>> >>>> Karl
>> >>> >>>>
>> >>> >>>>
>> >>> >>>> On Thu, May 5, 2011 at 6:23 PM, Karl Wright <da...@gmail.com>
>> >>> >>>> wrote:
>> >>> >>>>> Thanks - we do need the user sid, so I will put that back.
>> >>> >>>>>
>> >>> >>>>> Also, I'd like to ask what you know about escaping the user name
>> >>> >>>>> in
>> >>> >>>>> this expression:
>> >>> >>>>>
>> >>> >>>>> String searchFilter = "(&(objectClass=user)(sAMAccountName=" +
>> >>> >>>>> userName
>> >>> >>>>> + "))";
>> >>> >>>>>
>> >>> >>>>> It seems to me that there is probably some escaping needed, but
>> >>> >>>>> I
>> >>> >>>>> don't know what style. Do you think it is the same (C-style,
>> >>> >>>>> with
>> >>> >>>>> \
>> >>> >>>>> escape) as for the other case?
>> >>> >>>>>
>> >>> >>>>> Karl
>> >>> >>>>>
>> >>> >>>>> On Thu, May 5, 2011 at 6:20 PM, Kadri Atalay
>> >>> >>>>> <at...@gmail.com>
>> >>> >>>>> wrote:
>> >>> >>>>>> Hi Karl,
>> >>> >>>>>>
>> >>> >>>>>> String returnedAtts[]={"tokenGroups"} is ONLY returning the
>> >>> >>>>>> memberGroups,
>> >>> >>>>>>
>> >>> >>>>>> C:\OPT>curl
>> >>> >>>>>>
>> >>> >>>>>>
>> >>> >>>>>>
>> >>> >>>>>> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_admin@teqa.filetek.com"
>> >>> >>>>>> AUTHORIZED:TEQA-DC
>> >>> >>>>>> TOKEN:TEQA-DC:S-1-5-32-545
>> >>> >>>>>> TOKEN:TEQA-DC:S-1-5-32-544
>> >>> >>>>>> TOKEN:TEQA-DC:S-1-5-32-555
>> >>> >>>>>> TOKEN:TEQA-DC:S-1-5-21-
>> >>> >>>>>> 1212545812-2858578934-3563067286-1124
>> >>> >>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-512
>> >>> >>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
>> >>> >>>>>> TOKEN:TEQA-DC:S-1-1-0
>> >>> >>>>>>
>> >>> >>>>>> but,
>> >>> >>>>>>
>> >>> >>>>>> - String returnedAtts[] = {"tokenGroups","objectSid"}; is
>> >>> >>>>>> returning
>> >>> >>>>>> memberGroups AND SID for that user.
>> >>> >>>>>>
>> >>> >>>>>> C:\OPT>curl
>> >>> >>>>>>
>> >>> >>>>>>
>> >>> >>>>>>
>> >>> >>>>>> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_admin@teqa.filetek.com"
>> >>> >>>>>> AUTHORIZED:TEQA-DC
>> >>> >>>>>> TOKEN:TEQA-DC:S-1-5-32-545
>> >>> >>>>>> TOKEN:TEQA-DC:S-1-5-32-544
>> >>> >>>>>> TOKEN:TEQA-DC:S-1-5-32-555
>> >>> >>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1124
>> >>> >>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-512
>> >>> >>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
>> >>> >>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1480
>> >>> >>>>>> TOKEN:TEQA-DC:S-1-1-0
>> >>> >>>>>>
>> >>> >>>>>> Since we are only interested in the member groups, tokenGroups
>> >>> >>>>>> is
>> >>> >>>>>> sufficient, but if you also need user SID then you might keep
>> >>> >>>>>> the
>> >>> >>>>>> objectSID
>> >>> >>>>>> as well.
>> >>> >>>>>>
>> >>> >>>>>> Thanks
>> >>> >>>>>>
>> >>> >>>>>> Kadri
>> >>> >>>>>>
>> >>> >>>>>>
>> >>> >>>>>> On Thu, May 5, 2011 at 6:01 PM, Karl Wright
>> >>> >>>>>> <da...@gmail.com>
>> >>> >>>>>> wrote:
>> >>> >>>>>>>
>> >>> >>>>>>> I am curious about the following change, which does not seem
>> >>> >>>>>>> correct:
>> >>> >>>>>>>
>> >>> >>>>>>>
>> >>> >>>>>>> //Specify the attributes to return
>> >>> >>>>>>> - String returnedAtts[] = {"tokenGroups","objectSid"};
>> >>> >>>>>>> + String returnedAtts[]={"tokenGroups"};
>> >>> >>>>>>> searchCtls.setReturningAttributes(returnedAtts);
>> >>> >>>>>>>
>> >>> >>>>>>> Karl
>> >>> >>>>>>>
>> >>> >>>>>>>
>> >>> >>>>>>> On Thu, May 5, 2011 at 5:36 PM, Kadri Atalay
>> >>> >>>>>>> <at...@gmail.com>
>> >>> >>>>>>> wrote:
>> >>> >>>>>>>> Karl,
>> >>> >>>>>>>>
>> >>> >>>>>>>> The ActiveDirectoryAuthority.java is attached.
>> >>> >>>>>>>>
>> >>> >>>>>>>> I'm not sure about clicking "Grant ASF License", or how to do
>> >>> >>>>>>>> that
>> >>> >>>>>>>> from
>> >>> >>>>>>>> Tortoise.
>> >>> >>>>>>>> But, you got my consent for granting the ASF license.
>> >>> >>>>>>>>
>> >>> >>>>>>>> Thanks
>> >>> >>>>>>>>
>> >>> >>>>>>>> Kadri
>> >>> >>>>>>>>
>> >>> >>>>>>>>
>> >>> >>>>>>>> On Thu, May 5, 2011 at 5:28 PM, Karl Wright
>> >>> >>>>>>>> <da...@gmail.com>
>> >>> >>>>>>>> wrote:
>> >>> >>>>>>>>>
>> >>> >>>>>>>>> You may attach the whole ActiveDirectoryAuthority.java file
>> >>> >>>>>>>>> to
>> >>> >>>>>>>>> the
>> >>> >>>>>>>>> ticket if you prefer. But you must click the "Grant ASF
>> >>> >>>>>>>>> License"
>> >>> >>>>>>>>> button.
>> >>> >>>>>>>>>
>> >>> >>>>>>>>> Karl
>> >>> >>>>>>>>>
>> >>> >>>>>>>>> On Thu, May 5, 2011 at 5:24 PM, Kadri Atalay
>> >>> >>>>>>>>> <at...@gmail.com>
>> >>> >>>>>>>>> wrote:
>> >>> >>>>>>>>>> Karl,
>> >>> >>>>>>>>>>
>> >>> >>>>>>>>>> I'm using the Tortoise SVN, and new to SVN..
>> >>> >>>>>>>>>> Do you know how to do this with Tortoise ?
>> >>> >>>>>>>>>> Otherwise, I can just send the source code directly to you.
>> >>> >>>>>>>>>> BTW, there are some changes in the ParseUser method also,
>> >>> >>>>>>>>>> you
>> >>> >>>>>>>>>> can
>> >>> >>>>>>>>>> see
>> >>> >>>>>>>>>> all
>> >>> >>>>>>>>>> when you run the diff.
>> >>> >>>>>>>>>>
>> >>> >>>>>>>>>> Thanks
>> >>> >>>>>>>>>>
>> >>> >>>>>>>>>> Kadri
>> >>> >>>>>>>>>>
>> >>> >>>>>>>>
>> >>> >>>>>>>>
>> >>> >>>>>>
>> >>> >>>>>>
>> >>> >>>>>
>> >>> >>>
>> >>> >>>
>> >>> >
>> >>
>> >
>> >
>
>
Re: Which version of Solr have implements the Document Level Access Control
Posted by Kadri Atalay <at...@gmail.com>.
Hi Karl,
*sAMAccountName* holds the logon name upto 20 chars, and
*userPrincipalName*holds the logon name upto 256 (including domain
name).
I made changes to accomodate both cases: Please see attached file:
We can resolve this issue by making 2 calls to getDistinguishedName method
using different attributes.
First call is with sAMAccountName (supports only up to 20 chars)
If that fails, we can call again using userPrincipalName, up to 256 chars.
Configuration may be used if we don't want to make 2 calls for performance
reasons.
//Get DistinguishedName (for this method we are using DomainPart as a
searchBase ie: DC=qa-ad-76,DC=metacarta,DC=com")
//First call is for logon-name limited to 20 chars used with
sAMAccountName
String userDN = getDistinguishedName(userPart, domainsb.toString(),
"sAMAccountName" );
//Second call is for logon-name NOT limited to 20 chars used with
userPrincipalName
if (userDN == null)
userDN = getDistinguishedName(userName, domainsb.toString(),
"userPrincipalName");
return userDN;
Following is the test results:
Thanks
Kadri
C:\OPT>echo follOWING users are the same
username 25 characters long
C:\OPT>curl "
http://localhost:8345/mcf-authority-service/UserACLs?username=1234567890123456789012345@teqa.filetek.com
"
AUTHORIZED:TEQA-DC
TOKEN:TEQA-DC:S-1-5-32-545
TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-2627
TOKEN:TEQA-DC:S-1-1-0
username 20 characters long
C:\OPT>curl "
http://localhost:8345/mcf-authority-service/UserACLs?username=12345678901234567890@teqa.filetek.com
"
AUTHORIZED:TEQA-DC
TOKEN:TEQA-DC:S-1-5-32-545
TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-2627
TOKEN:TEQA-DC:S-1-1-0
C:\OPT>
On Sun, May 8, 2011 at 10:19 AM, Karl Wright <da...@gmail.com> wrote:
> This looked very good, so I committed it as-is. It does, however,
> invalidate Shinichiro's earlier patch for CONNECTORS-197. Would you
> know what the login id field would be if the active directory instance
> does not have sAMAccountName? Is it uid?
>
> Karl
>
> On Fri, May 6, 2011 at 6:24 PM, Kadri Atalay <at...@gmail.com>
> wrote:
> > Hi Karl,
> >
> > While looking over AD access and attributes, I found that
> > "distinguishedName"
> > attribute contains all the information we need for TokenGroups search, in
> > the correct format ie:
> > "CN=Administrator,CN=Users,DC=qa-ad-76,DC=metacarta,DC=com";
> > and by using this attribute instead of CN, we don't need to build the
> > searchbase ourselves.
> >
> > There are 2 advantages of using this attribute:
> > 1- Even if the user is not part of users group (whatever the reason
> maybe)
> > we still get the results back, because his information is included in the
> > "distinguishedName" attribute.
> > 2- We don't need to do treat any special characters like comma, etc..
> (it's
> > already formatted).
> >
> > I tested the code it works. Please see attached for the latest.
> >
> > Thanks
> >
> > Kadri
> >
> > Following is no longer needed:
> > StringBuffer sb = new StringBuffer();
> > sb.append("CN=").append(ldapEscape(userCN)).append(",CN=Users,");
> > sb.append(domainsb);
> >
> >
> >
> >
> >
> > On Fri, May 6, 2011 at 11:03 AM, Kadri Atalay <at...@gmail.com>
> > wrote:
> >>
> >> Hi Karl,
> >>
> >> Tested, and it's working.
> >>
> >> Thanks!
> >>
> >> Kadri
> >>
> >>
> >> On Thu, May 5, 2011 at 7:29 PM, Karl Wright <da...@gmail.com> wrote:
> >>>
> >>> I think yours was working because it was returning "cn=null,
> >>> cn=users", which was a result of the fact that cn was null and the
> >>> expression was assembled using the "+" operator. When I separated the
> >>> ldap escape out, it caused a null pointer exception to be thrown
> >>> instead. It should be fixed now.
> >>>
> >>> Karl
> >>>
> >>>
> >>> On Thu, May 5, 2011 at 7:19 PM, Kadri Atalay <at...@gmail.com>
> >>> wrote:
> >>> > Fyi. The file I sent you was returning usernotfound.
> >>> >
> >>> >
> >>> > Sent from my iPhone
> >>> >
> >>> > On May 5, 2011, at 7:12 PM, Karl Wright <da...@gmail.com> wrote:
> >>> >
> >>> >> It must mean we're somehow throwing an exception in the case where
> the
> >>> >> user is missing. I bet I know why - the CN lookup is failing
> instead.
> >>> >> I'll see if I can change it.
> >>> >>
> >>> >> Karl
> >>> >>
> >>> >> On Thu, May 5, 2011 at 6:43 PM, Kadri Atalay <
> atalay.kadri@gmail.com>
> >>> >> wrote:
> >>> >>> It works, only difference I see with previous one is: if a domain
> is
> >>> >>> reachable, message usernotfound makes a better indicator, somehow
> we
> >>> >>> lost
> >>> >>> that.
> >>> >>>
> >>> >>>
> >>> >>> C:\OPT>testauthority
> >>> >>>
> >>> >>> C:\OPT>curl
> >>> >>>
> >>> >>> "
> http://localhost:8345/mcf-authority-service/UserACLs?username=fakeuser"
> >>> >>> UNREACHABLEAUTHORITY:TEQA-DC
> >>> >>> TOKEN:TEQA-DC:DEAD_AUTHORITY
> >>> >>>
> >>> >>> C:\OPT>curl
> >>> >>>
> >>> >>> "
> http://localhost:8345/mcf-authority-service/UserACLs?username=fakeuser@fakedomain
> "
> >>> >>> UNREACHABLEAUTHORITY:TEQA-DC
> >>> >>> TOKEN:TEQA-DC:DEAD_AUTHORITY
> >>> >>>
> >>> >>> C:\OPT>curl
> >>> >>>
> >>> >>> "
> http://localhost:8345/mcf-authority-service/UserACLs?username=fakeuser@teqa.filetek.com
> "
> >>> >>> UNREACHABLEAUTHORITY:TEQA-DC
> >>> >>> TOKEN:TEQA-DC:DEAD_AUTHORITY
> >>> >>>
> >>> >>> Previous one
> >>> >>> 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
> "
> >>> >>> UNREACHABLEAUTHORITY:TEQA-DC
> >>> >>> TOKEN:TEQA-DC:DEAD_AUTHORITY
> >>> >>>
> >>> >>> C:\OPT>curl
> >>> >>>
> >>> >>> "
> http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_admin@teqa.filetek.com
> "
> >>> >>> AUTHORIZED:TEQA-DC
> >>> >>> TOKEN:TEQA-DC:S-1-5-32-545
> >>> >>> TOKEN:TEQA-DC:S-1-5-32-544
> >>> >>> TOKEN:TEQA-DC:S-1-5-32-555
> >>> >>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1124
> >>> >>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-512
> >>> >>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
> >>> >>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1480
> >>> >>> TOKEN:TEQA-DC:S-1-1-0
> >>> >>>
> >>> >>> C:\OPT>curl
> >>> >>>
> >>> >>> "
> http://localhost:8345/mcf-authority-service/UserACLs?username=katalay@teqa.filetek.com
> "
> >>> >>> AUTHORIZED:TEQA-DC
> >>> >>> TOKEN:TEQA-DC:S-1-5-32-545
> >>> >>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
> >>> >>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1473
> >>> >>> TOKEN:TEQA-DC:S-1-1-0
> >>> >>>
> >>> >>> C:\OPT>curl
> >>> >>>
> >>> >>> "
> http://localhost:8345/mcf-authority-service/UserACLs?username=katalay@fakedomain
> "
> >>> >>> UNREACHABLEAUTHORITY:TEQA-DC
> >>> >>> TOKEN:TEQA-DC:DEAD_AUTHORITY
> >>> >>>
> >>> >>>
> >>> >>> On Thu, May 5, 2011 at 6:29 PM, Karl Wright <da...@gmail.com>
> >>> >>> wrote:
> >>> >>>>
> >>> >>>> I've cleaned things up slightly to restore the objectSid and also
> to
> >>> >>>> fix an infinite loop ifyou have more than one comma in the escape
> >>> >>>> expression. I've attached the file, can you see if it works?
> >>> >>>>
> >>> >>>> Thanks,
> >>> >>>> Karl
> >>> >>>>
> >>> >>>>
> >>> >>>> On Thu, May 5, 2011 at 6:23 PM, Karl Wright <da...@gmail.com>
> >>> >>>> wrote:
> >>> >>>>> Thanks - we do need the user sid, so I will put that back.
> >>> >>>>>
> >>> >>>>> Also, I'd like to ask what you know about escaping the user name
> in
> >>> >>>>> this expression:
> >>> >>>>>
> >>> >>>>> String searchFilter = "(&(objectClass=user)(sAMAccountName=" +
> >>> >>>>> userName
> >>> >>>>> + "))";
> >>> >>>>>
> >>> >>>>> It seems to me that there is probably some escaping needed, but I
> >>> >>>>> don't know what style. Do you think it is the same (C-style,
> with
> >>> >>>>> \
> >>> >>>>> escape) as for the other case?
> >>> >>>>>
> >>> >>>>> Karl
> >>> >>>>>
> >>> >>>>> On Thu, May 5, 2011 at 6:20 PM, Kadri Atalay
> >>> >>>>> <at...@gmail.com>
> >>> >>>>> wrote:
> >>> >>>>>> Hi Karl,
> >>> >>>>>>
> >>> >>>>>> String returnedAtts[]={"tokenGroups"} is ONLY returning the
> >>> >>>>>> memberGroups,
> >>> >>>>>>
> >>> >>>>>> C:\OPT>curl
> >>> >>>>>>
> >>> >>>>>>
> >>> >>>>>> "
> http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_admin@teqa.filetek.com
> "
> >>> >>>>>> AUTHORIZED:TEQA-DC
> >>> >>>>>> TOKEN:TEQA-DC:S-1-5-32-545
> >>> >>>>>> TOKEN:TEQA-DC:S-1-5-32-544
> >>> >>>>>> TOKEN:TEQA-DC:S-1-5-32-555
> >>> >>>>>> TOKEN:TEQA-DC:S-1-5-21-
> >>> >>>>>> 1212545812-2858578934-3563067286-1124
> >>> >>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-512
> >>> >>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
> >>> >>>>>> TOKEN:TEQA-DC:S-1-1-0
> >>> >>>>>>
> >>> >>>>>> but,
> >>> >>>>>>
> >>> >>>>>> - String returnedAtts[] = {"tokenGroups","objectSid"}; is
> >>> >>>>>> returning
> >>> >>>>>> memberGroups AND SID for that user.
> >>> >>>>>>
> >>> >>>>>> C:\OPT>curl
> >>> >>>>>>
> >>> >>>>>>
> >>> >>>>>> "
> http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_admin@teqa.filetek.com
> "
> >>> >>>>>> AUTHORIZED:TEQA-DC
> >>> >>>>>> TOKEN:TEQA-DC:S-1-5-32-545
> >>> >>>>>> TOKEN:TEQA-DC:S-1-5-32-544
> >>> >>>>>> TOKEN:TEQA-DC:S-1-5-32-555
> >>> >>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1124
> >>> >>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-512
> >>> >>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
> >>> >>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1480
> >>> >>>>>> TOKEN:TEQA-DC:S-1-1-0
> >>> >>>>>>
> >>> >>>>>> Since we are only interested in the member groups, tokenGroups
> is
> >>> >>>>>> sufficient, but if you also need user SID then you might keep
> the
> >>> >>>>>> objectSID
> >>> >>>>>> as well.
> >>> >>>>>>
> >>> >>>>>> Thanks
> >>> >>>>>>
> >>> >>>>>> Kadri
> >>> >>>>>>
> >>> >>>>>>
> >>> >>>>>> On Thu, May 5, 2011 at 6:01 PM, Karl Wright <daddywri@gmail.com
> >
> >>> >>>>>> wrote:
> >>> >>>>>>>
> >>> >>>>>>> I am curious about the following change, which does not seem
> >>> >>>>>>> correct:
> >>> >>>>>>>
> >>> >>>>>>>
> >>> >>>>>>> //Specify the attributes to return
> >>> >>>>>>> - String returnedAtts[] = {"tokenGroups","objectSid"};
> >>> >>>>>>> + String returnedAtts[]={"tokenGroups"};
> >>> >>>>>>> searchCtls.setReturningAttributes(returnedAtts);
> >>> >>>>>>>
> >>> >>>>>>> Karl
> >>> >>>>>>>
> >>> >>>>>>>
> >>> >>>>>>> On Thu, May 5, 2011 at 5:36 PM, Kadri Atalay
> >>> >>>>>>> <at...@gmail.com>
> >>> >>>>>>> wrote:
> >>> >>>>>>>> Karl,
> >>> >>>>>>>>
> >>> >>>>>>>> The ActiveDirectoryAuthority.java is attached.
> >>> >>>>>>>>
> >>> >>>>>>>> I'm not sure about clicking "Grant ASF License", or how to do
> >>> >>>>>>>> that
> >>> >>>>>>>> from
> >>> >>>>>>>> Tortoise.
> >>> >>>>>>>> But, you got my consent for granting the ASF license.
> >>> >>>>>>>>
> >>> >>>>>>>> Thanks
> >>> >>>>>>>>
> >>> >>>>>>>> Kadri
> >>> >>>>>>>>
> >>> >>>>>>>>
> >>> >>>>>>>> On Thu, May 5, 2011 at 5:28 PM, Karl Wright <
> daddywri@gmail.com>
> >>> >>>>>>>> wrote:
> >>> >>>>>>>>>
> >>> >>>>>>>>> You may attach the whole ActiveDirectoryAuthority.java file
> to
> >>> >>>>>>>>> the
> >>> >>>>>>>>> ticket if you prefer. But you must click the "Grant ASF
> >>> >>>>>>>>> License"
> >>> >>>>>>>>> button.
> >>> >>>>>>>>>
> >>> >>>>>>>>> Karl
> >>> >>>>>>>>>
> >>> >>>>>>>>> On Thu, May 5, 2011 at 5:24 PM, Kadri Atalay
> >>> >>>>>>>>> <at...@gmail.com>
> >>> >>>>>>>>> wrote:
> >>> >>>>>>>>>> Karl,
> >>> >>>>>>>>>>
> >>> >>>>>>>>>> I'm using the Tortoise SVN, and new to SVN..
> >>> >>>>>>>>>> Do you know how to do this with Tortoise ?
> >>> >>>>>>>>>> Otherwise, I can just send the source code directly to you.
> >>> >>>>>>>>>> BTW, there are some changes in the ParseUser method also,
> you
> >>> >>>>>>>>>> can
> >>> >>>>>>>>>> see
> >>> >>>>>>>>>> all
> >>> >>>>>>>>>> when you run the diff.
> >>> >>>>>>>>>>
> >>> >>>>>>>>>> Thanks
> >>> >>>>>>>>>>
> >>> >>>>>>>>>> Kadri
> >>> >>>>>>>>>>
> >>> >>>>>>>>
> >>> >>>>>>>>
> >>> >>>>>>
> >>> >>>>>>
> >>> >>>>>
> >>> >>>
> >>> >>>
> >>> >
> >>
> >
> >
>
Re: Which version of Solr have implements the Document Level Access Control
Posted by Karl Wright <da...@gmail.com>.
This looked very good, so I committed it as-is. It does, however,
invalidate Shinichiro's earlier patch for CONNECTORS-197. Would you
know what the login id field would be if the active directory instance
does not have sAMAccountName? Is it uid?
Karl
On Fri, May 6, 2011 at 6:24 PM, Kadri Atalay <at...@gmail.com> wrote:
> Hi Karl,
>
> While looking over AD access and attributes, I found that
> "distinguishedName"
> attribute contains all the information we need for TokenGroups search, in
> the correct format ie:
> "CN=Administrator,CN=Users,DC=qa-ad-76,DC=metacarta,DC=com";
> and by using this attribute instead of CN, we don't need to build the
> searchbase ourselves.
>
> There are 2 advantages of using this attribute:
> 1- Even if the user is not part of users group (whatever the reason maybe)
> we still get the results back, because his information is included in the
> "distinguishedName" attribute.
> 2- We don't need to do treat any special characters like comma, etc.. (it's
> already formatted).
>
> I tested the code it works. Please see attached for the latest.
>
> Thanks
>
> Kadri
>
> Following is no longer needed:
> StringBuffer sb = new StringBuffer();
> sb.append("CN=").append(ldapEscape(userCN)).append(",CN=Users,");
> sb.append(domainsb);
>
>
>
>
>
> On Fri, May 6, 2011 at 11:03 AM, Kadri Atalay <at...@gmail.com>
> wrote:
>>
>> Hi Karl,
>>
>> Tested, and it's working.
>>
>> Thanks!
>>
>> Kadri
>>
>>
>> On Thu, May 5, 2011 at 7:29 PM, Karl Wright <da...@gmail.com> wrote:
>>>
>>> I think yours was working because it was returning "cn=null,
>>> cn=users", which was a result of the fact that cn was null and the
>>> expression was assembled using the "+" operator. When I separated the
>>> ldap escape out, it caused a null pointer exception to be thrown
>>> instead. It should be fixed now.
>>>
>>> Karl
>>>
>>>
>>> On Thu, May 5, 2011 at 7:19 PM, Kadri Atalay <at...@gmail.com>
>>> wrote:
>>> > Fyi. The file I sent you was returning usernotfound.
>>> >
>>> >
>>> > Sent from my iPhone
>>> >
>>> > On May 5, 2011, at 7:12 PM, Karl Wright <da...@gmail.com> wrote:
>>> >
>>> >> It must mean we're somehow throwing an exception in the case where the
>>> >> user is missing. I bet I know why - the CN lookup is failing instead.
>>> >> I'll see if I can change it.
>>> >>
>>> >> Karl
>>> >>
>>> >> On Thu, May 5, 2011 at 6:43 PM, Kadri Atalay <at...@gmail.com>
>>> >> wrote:
>>> >>> It works, only difference I see with previous one is: if a domain is
>>> >>> reachable, message usernotfound makes a better indicator, somehow we
>>> >>> lost
>>> >>> that.
>>> >>>
>>> >>>
>>> >>> C:\OPT>testauthority
>>> >>>
>>> >>> C:\OPT>curl
>>> >>>
>>> >>> "http://localhost:8345/mcf-authority-service/UserACLs?username=fakeuser"
>>> >>> UNREACHABLEAUTHORITY:TEQA-DC
>>> >>> TOKEN:TEQA-DC:DEAD_AUTHORITY
>>> >>>
>>> >>> C:\OPT>curl
>>> >>>
>>> >>> "http://localhost:8345/mcf-authority-service/UserACLs?username=fakeuser@fakedomain"
>>> >>> UNREACHABLEAUTHORITY:TEQA-DC
>>> >>> TOKEN:TEQA-DC:DEAD_AUTHORITY
>>> >>>
>>> >>> C:\OPT>curl
>>> >>>
>>> >>> "http://localhost:8345/mcf-authority-service/UserACLs?username=fakeuser@teqa.filetek.com"
>>> >>> UNREACHABLEAUTHORITY:TEQA-DC
>>> >>> TOKEN:TEQA-DC:DEAD_AUTHORITY
>>> >>>
>>> >>> Previous one
>>> >>> 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"
>>> >>> UNREACHABLEAUTHORITY:TEQA-DC
>>> >>> TOKEN:TEQA-DC:DEAD_AUTHORITY
>>> >>>
>>> >>> C:\OPT>curl
>>> >>>
>>> >>> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_admin@teqa.filetek.com"
>>> >>> AUTHORIZED:TEQA-DC
>>> >>> TOKEN:TEQA-DC:S-1-5-32-545
>>> >>> TOKEN:TEQA-DC:S-1-5-32-544
>>> >>> TOKEN:TEQA-DC:S-1-5-32-555
>>> >>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1124
>>> >>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-512
>>> >>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
>>> >>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1480
>>> >>> TOKEN:TEQA-DC:S-1-1-0
>>> >>>
>>> >>> C:\OPT>curl
>>> >>>
>>> >>> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay@teqa.filetek.com"
>>> >>> AUTHORIZED:TEQA-DC
>>> >>> TOKEN:TEQA-DC:S-1-5-32-545
>>> >>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
>>> >>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1473
>>> >>> TOKEN:TEQA-DC:S-1-1-0
>>> >>>
>>> >>> C:\OPT>curl
>>> >>>
>>> >>> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay@fakedomain"
>>> >>> UNREACHABLEAUTHORITY:TEQA-DC
>>> >>> TOKEN:TEQA-DC:DEAD_AUTHORITY
>>> >>>
>>> >>>
>>> >>> On Thu, May 5, 2011 at 6:29 PM, Karl Wright <da...@gmail.com>
>>> >>> wrote:
>>> >>>>
>>> >>>> I've cleaned things up slightly to restore the objectSid and also to
>>> >>>> fix an infinite loop ifyou have more than one comma in the escape
>>> >>>> expression. I've attached the file, can you see if it works?
>>> >>>>
>>> >>>> Thanks,
>>> >>>> Karl
>>> >>>>
>>> >>>>
>>> >>>> On Thu, May 5, 2011 at 6:23 PM, Karl Wright <da...@gmail.com>
>>> >>>> wrote:
>>> >>>>> Thanks - we do need the user sid, so I will put that back.
>>> >>>>>
>>> >>>>> Also, I'd like to ask what you know about escaping the user name in
>>> >>>>> this expression:
>>> >>>>>
>>> >>>>> String searchFilter = "(&(objectClass=user)(sAMAccountName=" +
>>> >>>>> userName
>>> >>>>> + "))";
>>> >>>>>
>>> >>>>> It seems to me that there is probably some escaping needed, but I
>>> >>>>> don't know what style. Do you think it is the same (C-style, with
>>> >>>>> \
>>> >>>>> escape) as for the other case?
>>> >>>>>
>>> >>>>> Karl
>>> >>>>>
>>> >>>>> On Thu, May 5, 2011 at 6:20 PM, Kadri Atalay
>>> >>>>> <at...@gmail.com>
>>> >>>>> wrote:
>>> >>>>>> Hi Karl,
>>> >>>>>>
>>> >>>>>> String returnedAtts[]={"tokenGroups"} is ONLY returning the
>>> >>>>>> memberGroups,
>>> >>>>>>
>>> >>>>>> C:\OPT>curl
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_admin@teqa.filetek.com"
>>> >>>>>> AUTHORIZED:TEQA-DC
>>> >>>>>> TOKEN:TEQA-DC:S-1-5-32-545
>>> >>>>>> TOKEN:TEQA-DC:S-1-5-32-544
>>> >>>>>> TOKEN:TEQA-DC:S-1-5-32-555
>>> >>>>>> TOKEN:TEQA-DC:S-1-5-21-
>>> >>>>>> 1212545812-2858578934-3563067286-1124
>>> >>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-512
>>> >>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
>>> >>>>>> TOKEN:TEQA-DC:S-1-1-0
>>> >>>>>>
>>> >>>>>> but,
>>> >>>>>>
>>> >>>>>> - String returnedAtts[] = {"tokenGroups","objectSid"}; is
>>> >>>>>> returning
>>> >>>>>> memberGroups AND SID for that user.
>>> >>>>>>
>>> >>>>>> C:\OPT>curl
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_admin@teqa.filetek.com"
>>> >>>>>> AUTHORIZED:TEQA-DC
>>> >>>>>> TOKEN:TEQA-DC:S-1-5-32-545
>>> >>>>>> TOKEN:TEQA-DC:S-1-5-32-544
>>> >>>>>> TOKEN:TEQA-DC:S-1-5-32-555
>>> >>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1124
>>> >>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-512
>>> >>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
>>> >>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1480
>>> >>>>>> TOKEN:TEQA-DC:S-1-1-0
>>> >>>>>>
>>> >>>>>> Since we are only interested in the member groups, tokenGroups is
>>> >>>>>> sufficient, but if you also need user SID then you might keep the
>>> >>>>>> objectSID
>>> >>>>>> as well.
>>> >>>>>>
>>> >>>>>> Thanks
>>> >>>>>>
>>> >>>>>> Kadri
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> On Thu, May 5, 2011 at 6:01 PM, Karl Wright <da...@gmail.com>
>>> >>>>>> wrote:
>>> >>>>>>>
>>> >>>>>>> I am curious about the following change, which does not seem
>>> >>>>>>> correct:
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>> //Specify the attributes to return
>>> >>>>>>> - String returnedAtts[] = {"tokenGroups","objectSid"};
>>> >>>>>>> + String returnedAtts[]={"tokenGroups"};
>>> >>>>>>> searchCtls.setReturningAttributes(returnedAtts);
>>> >>>>>>>
>>> >>>>>>> Karl
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>> On Thu, May 5, 2011 at 5:36 PM, Kadri Atalay
>>> >>>>>>> <at...@gmail.com>
>>> >>>>>>> wrote:
>>> >>>>>>>> Karl,
>>> >>>>>>>>
>>> >>>>>>>> The ActiveDirectoryAuthority.java is attached.
>>> >>>>>>>>
>>> >>>>>>>> I'm not sure about clicking "Grant ASF License", or how to do
>>> >>>>>>>> that
>>> >>>>>>>> from
>>> >>>>>>>> Tortoise.
>>> >>>>>>>> But, you got my consent for granting the ASF license.
>>> >>>>>>>>
>>> >>>>>>>> Thanks
>>> >>>>>>>>
>>> >>>>>>>> Kadri
>>> >>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>> On Thu, May 5, 2011 at 5:28 PM, Karl Wright <da...@gmail.com>
>>> >>>>>>>> wrote:
>>> >>>>>>>>>
>>> >>>>>>>>> You may attach the whole ActiveDirectoryAuthority.java file to
>>> >>>>>>>>> the
>>> >>>>>>>>> ticket if you prefer. But you must click the "Grant ASF
>>> >>>>>>>>> License"
>>> >>>>>>>>> button.
>>> >>>>>>>>>
>>> >>>>>>>>> Karl
>>> >>>>>>>>>
>>> >>>>>>>>> On Thu, May 5, 2011 at 5:24 PM, Kadri Atalay
>>> >>>>>>>>> <at...@gmail.com>
>>> >>>>>>>>> wrote:
>>> >>>>>>>>>> Karl,
>>> >>>>>>>>>>
>>> >>>>>>>>>> I'm using the Tortoise SVN, and new to SVN..
>>> >>>>>>>>>> Do you know how to do this with Tortoise ?
>>> >>>>>>>>>> Otherwise, I can just send the source code directly to you.
>>> >>>>>>>>>> BTW, there are some changes in the ParseUser method also, you
>>> >>>>>>>>>> can
>>> >>>>>>>>>> see
>>> >>>>>>>>>> all
>>> >>>>>>>>>> when you run the diff.
>>> >>>>>>>>>>
>>> >>>>>>>>>> Thanks
>>> >>>>>>>>>>
>>> >>>>>>>>>> Kadri
>>> >>>>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>
>>> >>>
>>> >>>
>>> >
>>
>
>
Re: Which version of Solr have implements the Document Level Access Control
Posted by Kadri Atalay <at...@gmail.com>.
Hi Karl,
While looking over AD access and attributes, I found that
"distinguishedName"
attribute contains all the information we need for TokenGroups search, in
the correct format ie:
"CN=Administrator,CN=Users,DC=qa-ad-76,DC=metacarta,DC=com";
and by using this attribute instead of CN, we don't need to build the
searchbase ourselves.
There are 2 advantages of using this attribute:
1- Even if the user is not part of users group (whatever the reason maybe)
we still get the results back, because his information is included in the
"distinguishedName" attribute.
2- We don't need to do treat any special characters like comma, etc.. (it's
already formatted).
I tested the code it works. Please see attached for the latest.
Thanks
Kadri
*Following is no longer needed:
StringBuffer sb = new StringBuffer();
sb.append("CN=").append(ldapEscape(userCN)).append(",CN=Users,");
sb.append(domainsb);*
On Fri, May 6, 2011 at 11:03 AM, Kadri Atalay <at...@gmail.com>wrote:
> Hi Karl,
>
> Tested, and it's working.
>
> Thanks!
>
> Kadri
>
>
> On Thu, May 5, 2011 at 7:29 PM, Karl Wright <da...@gmail.com> wrote:
>
>> I think yours was working because it was returning "cn=null,
>> cn=users", which was a result of the fact that cn was null and the
>> expression was assembled using the "+" operator. When I separated the
>> ldap escape out, it caused a null pointer exception to be thrown
>> instead. It should be fixed now.
>>
>> Karl
>>
>>
>> On Thu, May 5, 2011 at 7:19 PM, Kadri Atalay <at...@gmail.com>
>> wrote:
>> > Fyi. The file I sent you was returning usernotfound.
>> >
>> >
>> > Sent from my iPhone
>> >
>> > On May 5, 2011, at 7:12 PM, Karl Wright <da...@gmail.com> wrote:
>> >
>> >> It must mean we're somehow throwing an exception in the case where the
>> >> user is missing. I bet I know why - the CN lookup is failing instead.
>> >> I'll see if I can change it.
>> >>
>> >> Karl
>> >>
>> >> On Thu, May 5, 2011 at 6:43 PM, Kadri Atalay <at...@gmail.com>
>> wrote:
>> >>> It works, only difference I see with previous one is: if a domain is
>> >>> reachable, message usernotfound makes a better indicator, somehow we
>> lost
>> >>> that.
>> >>>
>> >>>
>> >>> C:\OPT>testauthority
>> >>>
>> >>> C:\OPT>curl
>> >>> "
>> http://localhost:8345/mcf-authority-service/UserACLs?username=fakeuser"
>> >>> UNREACHABLEAUTHORITY:TEQA-DC
>> >>> TOKEN:TEQA-DC:DEAD_AUTHORITY
>> >>>
>> >>> C:\OPT>curl
>> >>> "
>> http://localhost:8345/mcf-authority-service/UserACLs?username=fakeuser@fakedomain
>> "
>> >>> UNREACHABLEAUTHORITY:TEQA-DC
>> >>> TOKEN:TEQA-DC:DEAD_AUTHORITY
>> >>>
>> >>> C:\OPT>curl
>> >>> "
>> http://localhost:8345/mcf-authority-service/UserACLs?username=fakeuser@teqa.filetek.com
>> "
>> >>> UNREACHABLEAUTHORITY:TEQA-DC
>> >>> TOKEN:TEQA-DC:DEAD_AUTHORITY
>> >>>
>> >>> Previous one
>> >>> 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
>> "
>> >>> UNREACHABLEAUTHORITY:TEQA-DC
>> >>> TOKEN:TEQA-DC:DEAD_AUTHORITY
>> >>>
>> >>> C:\OPT>curl
>> >>> "
>> http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_admin@teqa.filetek.com
>> "
>> >>> AUTHORIZED:TEQA-DC
>> >>> TOKEN:TEQA-DC:S-1-5-32-545
>> >>> TOKEN:TEQA-DC:S-1-5-32-544
>> >>> TOKEN:TEQA-DC:S-1-5-32-555
>> >>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1124
>> >>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-512
>> >>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
>> >>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1480
>> >>> TOKEN:TEQA-DC:S-1-1-0
>> >>>
>> >>> C:\OPT>curl
>> >>> "
>> http://localhost:8345/mcf-authority-service/UserACLs?username=katalay@teqa.filetek.com
>> "
>> >>> AUTHORIZED:TEQA-DC
>> >>> TOKEN:TEQA-DC:S-1-5-32-545
>> >>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
>> >>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1473
>> >>> TOKEN:TEQA-DC:S-1-1-0
>> >>>
>> >>> C:\OPT>curl
>> >>> "
>> http://localhost:8345/mcf-authority-service/UserACLs?username=katalay@fakedomain
>> "
>> >>> UNREACHABLEAUTHORITY:TEQA-DC
>> >>> TOKEN:TEQA-DC:DEAD_AUTHORITY
>> >>>
>> >>>
>> >>> On Thu, May 5, 2011 at 6:29 PM, Karl Wright <da...@gmail.com>
>> wrote:
>> >>>>
>> >>>> I've cleaned things up slightly to restore the objectSid and also to
>> >>>> fix an infinite loop ifyou have more than one comma in the escape
>> >>>> expression. I've attached the file, can you see if it works?
>> >>>>
>> >>>> Thanks,
>> >>>> Karl
>> >>>>
>> >>>>
>> >>>> On Thu, May 5, 2011 at 6:23 PM, Karl Wright <da...@gmail.com>
>> wrote:
>> >>>>> Thanks - we do need the user sid, so I will put that back.
>> >>>>>
>> >>>>> Also, I'd like to ask what you know about escaping the user name in
>> >>>>> this expression:
>> >>>>>
>> >>>>> String searchFilter = "(&(objectClass=user)(sAMAccountName=" +
>> userName
>> >>>>> + "))";
>> >>>>>
>> >>>>> It seems to me that there is probably some escaping needed, but I
>> >>>>> don't know what style. Do you think it is the same (C-style, with \
>> >>>>> escape) as for the other case?
>> >>>>>
>> >>>>> Karl
>> >>>>>
>> >>>>> On Thu, May 5, 2011 at 6:20 PM, Kadri Atalay <
>> atalay.kadri@gmail.com>
>> >>>>> wrote:
>> >>>>>> Hi Karl,
>> >>>>>>
>> >>>>>> String returnedAtts[]={"tokenGroups"} is ONLY returning the
>> >>>>>> memberGroups,
>> >>>>>>
>> >>>>>> C:\OPT>curl
>> >>>>>>
>> >>>>>> "
>> http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_admin@teqa.filetek.com
>> "
>> >>>>>> AUTHORIZED:TEQA-DC
>> >>>>>> TOKEN:TEQA-DC:S-1-5-32-545
>> >>>>>> TOKEN:TEQA-DC:S-1-5-32-544
>> >>>>>> TOKEN:TEQA-DC:S-1-5-32-555
>> >>>>>> TOKEN:TEQA-DC:S-1-5-21-
>> >>>>>> 1212545812-2858578934-3563067286-1124
>> >>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-512
>> >>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
>> >>>>>> TOKEN:TEQA-DC:S-1-1-0
>> >>>>>>
>> >>>>>> but,
>> >>>>>>
>> >>>>>> - String returnedAtts[] = {"tokenGroups","objectSid"}; is
>> returning
>> >>>>>> memberGroups AND SID for that user.
>> >>>>>>
>> >>>>>> C:\OPT>curl
>> >>>>>>
>> >>>>>> "
>> http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_admin@teqa.filetek.com
>> "
>> >>>>>> AUTHORIZED:TEQA-DC
>> >>>>>> TOKEN:TEQA-DC:S-1-5-32-545
>> >>>>>> TOKEN:TEQA-DC:S-1-5-32-544
>> >>>>>> TOKEN:TEQA-DC:S-1-5-32-555
>> >>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1124
>> >>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-512
>> >>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
>> >>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1480
>> >>>>>> TOKEN:TEQA-DC:S-1-1-0
>> >>>>>>
>> >>>>>> Since we are only interested in the member groups, tokenGroups is
>> >>>>>> sufficient, but if you also need user SID then you might keep the
>> >>>>>> objectSID
>> >>>>>> as well.
>> >>>>>>
>> >>>>>> Thanks
>> >>>>>>
>> >>>>>> Kadri
>> >>>>>>
>> >>>>>>
>> >>>>>> On Thu, May 5, 2011 at 6:01 PM, Karl Wright <da...@gmail.com>
>> wrote:
>> >>>>>>>
>> >>>>>>> I am curious about the following change, which does not seem
>> correct:
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> //Specify the attributes to return
>> >>>>>>> - String returnedAtts[] = {"tokenGroups","objectSid"};
>> >>>>>>> + String returnedAtts[]={"tokenGroups"};
>> >>>>>>> searchCtls.setReturningAttributes(returnedAtts);
>> >>>>>>>
>> >>>>>>> Karl
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> On Thu, May 5, 2011 at 5:36 PM, Kadri Atalay <
>> atalay.kadri@gmail.com>
>> >>>>>>> wrote:
>> >>>>>>>> Karl,
>> >>>>>>>>
>> >>>>>>>> The ActiveDirectoryAuthority.java is attached.
>> >>>>>>>>
>> >>>>>>>> I'm not sure about clicking "Grant ASF License", or how to do
>> that
>> >>>>>>>> from
>> >>>>>>>> Tortoise.
>> >>>>>>>> But, you got my consent for granting the ASF license.
>> >>>>>>>>
>> >>>>>>>> Thanks
>> >>>>>>>>
>> >>>>>>>> Kadri
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> On Thu, May 5, 2011 at 5:28 PM, Karl Wright <da...@gmail.com>
>> >>>>>>>> wrote:
>> >>>>>>>>>
>> >>>>>>>>> You may attach the whole ActiveDirectoryAuthority.java file to
>> the
>> >>>>>>>>> ticket if you prefer. But you must click the "Grant ASF
>> License"
>> >>>>>>>>> button.
>> >>>>>>>>>
>> >>>>>>>>> Karl
>> >>>>>>>>>
>> >>>>>>>>> On Thu, May 5, 2011 at 5:24 PM, Kadri Atalay
>> >>>>>>>>> <at...@gmail.com>
>> >>>>>>>>> wrote:
>> >>>>>>>>>> Karl,
>> >>>>>>>>>>
>> >>>>>>>>>> I'm using the Tortoise SVN, and new to SVN..
>> >>>>>>>>>> Do you know how to do this with Tortoise ?
>> >>>>>>>>>> Otherwise, I can just send the source code directly to you.
>> >>>>>>>>>> BTW, there are some changes in the ParseUser method also, you
>> can
>> >>>>>>>>>> see
>> >>>>>>>>>> all
>> >>>>>>>>>> when you run the diff.
>> >>>>>>>>>>
>> >>>>>>>>>> Thanks
>> >>>>>>>>>>
>> >>>>>>>>>> Kadri
>> >>>>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>
>> >>>
>> >
>>
>
>
Re: Which version of Solr have implements the Document Level Access Control
Posted by Kadri Atalay <at...@gmail.com>.
Hi Karl,
Tested, and it's working.
Thanks!
Kadri
On Thu, May 5, 2011 at 7:29 PM, Karl Wright <da...@gmail.com> wrote:
> I think yours was working because it was returning "cn=null,
> cn=users", which was a result of the fact that cn was null and the
> expression was assembled using the "+" operator. When I separated the
> ldap escape out, it caused a null pointer exception to be thrown
> instead. It should be fixed now.
>
> Karl
>
>
> On Thu, May 5, 2011 at 7:19 PM, Kadri Atalay <at...@gmail.com>
> wrote:
> > Fyi. The file I sent you was returning usernotfound.
> >
> >
> > Sent from my iPhone
> >
> > On May 5, 2011, at 7:12 PM, Karl Wright <da...@gmail.com> wrote:
> >
> >> It must mean we're somehow throwing an exception in the case where the
> >> user is missing. I bet I know why - the CN lookup is failing instead.
> >> I'll see if I can change it.
> >>
> >> Karl
> >>
> >> On Thu, May 5, 2011 at 6:43 PM, Kadri Atalay <at...@gmail.com>
> wrote:
> >>> It works, only difference I see with previous one is: if a domain is
> >>> reachable, message usernotfound makes a better indicator, somehow we
> lost
> >>> that.
> >>>
> >>>
> >>> C:\OPT>testauthority
> >>>
> >>> C:\OPT>curl
> >>> "
> http://localhost:8345/mcf-authority-service/UserACLs?username=fakeuser"
> >>> UNREACHABLEAUTHORITY:TEQA-DC
> >>> TOKEN:TEQA-DC:DEAD_AUTHORITY
> >>>
> >>> C:\OPT>curl
> >>> "
> http://localhost:8345/mcf-authority-service/UserACLs?username=fakeuser@fakedomain
> "
> >>> UNREACHABLEAUTHORITY:TEQA-DC
> >>> TOKEN:TEQA-DC:DEAD_AUTHORITY
> >>>
> >>> C:\OPT>curl
> >>> "
> http://localhost:8345/mcf-authority-service/UserACLs?username=fakeuser@teqa.filetek.com
> "
> >>> UNREACHABLEAUTHORITY:TEQA-DC
> >>> TOKEN:TEQA-DC:DEAD_AUTHORITY
> >>>
> >>> Previous one
> >>> 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
> "
> >>> UNREACHABLEAUTHORITY:TEQA-DC
> >>> TOKEN:TEQA-DC:DEAD_AUTHORITY
> >>>
> >>> C:\OPT>curl
> >>> "
> http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_admin@teqa.filetek.com
> "
> >>> AUTHORIZED:TEQA-DC
> >>> TOKEN:TEQA-DC:S-1-5-32-545
> >>> TOKEN:TEQA-DC:S-1-5-32-544
> >>> TOKEN:TEQA-DC:S-1-5-32-555
> >>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1124
> >>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-512
> >>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
> >>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1480
> >>> TOKEN:TEQA-DC:S-1-1-0
> >>>
> >>> C:\OPT>curl
> >>> "
> http://localhost:8345/mcf-authority-service/UserACLs?username=katalay@teqa.filetek.com
> "
> >>> AUTHORIZED:TEQA-DC
> >>> TOKEN:TEQA-DC:S-1-5-32-545
> >>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
> >>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1473
> >>> TOKEN:TEQA-DC:S-1-1-0
> >>>
> >>> C:\OPT>curl
> >>> "
> http://localhost:8345/mcf-authority-service/UserACLs?username=katalay@fakedomain
> "
> >>> UNREACHABLEAUTHORITY:TEQA-DC
> >>> TOKEN:TEQA-DC:DEAD_AUTHORITY
> >>>
> >>>
> >>> On Thu, May 5, 2011 at 6:29 PM, Karl Wright <da...@gmail.com>
> wrote:
> >>>>
> >>>> I've cleaned things up slightly to restore the objectSid and also to
> >>>> fix an infinite loop ifyou have more than one comma in the escape
> >>>> expression. I've attached the file, can you see if it works?
> >>>>
> >>>> Thanks,
> >>>> Karl
> >>>>
> >>>>
> >>>> On Thu, May 5, 2011 at 6:23 PM, Karl Wright <da...@gmail.com>
> wrote:
> >>>>> Thanks - we do need the user sid, so I will put that back.
> >>>>>
> >>>>> Also, I'd like to ask what you know about escaping the user name in
> >>>>> this expression:
> >>>>>
> >>>>> String searchFilter = "(&(objectClass=user)(sAMAccountName=" +
> userName
> >>>>> + "))";
> >>>>>
> >>>>> It seems to me that there is probably some escaping needed, but I
> >>>>> don't know what style. Do you think it is the same (C-style, with \
> >>>>> escape) as for the other case?
> >>>>>
> >>>>> Karl
> >>>>>
> >>>>> On Thu, May 5, 2011 at 6:20 PM, Kadri Atalay <atalay.kadri@gmail.com
> >
> >>>>> wrote:
> >>>>>> Hi Karl,
> >>>>>>
> >>>>>> String returnedAtts[]={"tokenGroups"} is ONLY returning the
> >>>>>> memberGroups,
> >>>>>>
> >>>>>> C:\OPT>curl
> >>>>>>
> >>>>>> "
> http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_admin@teqa.filetek.com
> "
> >>>>>> AUTHORIZED:TEQA-DC
> >>>>>> TOKEN:TEQA-DC:S-1-5-32-545
> >>>>>> TOKEN:TEQA-DC:S-1-5-32-544
> >>>>>> TOKEN:TEQA-DC:S-1-5-32-555
> >>>>>> TOKEN:TEQA-DC:S-1-5-21-
> >>>>>> 1212545812-2858578934-3563067286-1124
> >>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-512
> >>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
> >>>>>> TOKEN:TEQA-DC:S-1-1-0
> >>>>>>
> >>>>>> but,
> >>>>>>
> >>>>>> - String returnedAtts[] = {"tokenGroups","objectSid"}; is
> returning
> >>>>>> memberGroups AND SID for that user.
> >>>>>>
> >>>>>> C:\OPT>curl
> >>>>>>
> >>>>>> "
> http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_admin@teqa.filetek.com
> "
> >>>>>> AUTHORIZED:TEQA-DC
> >>>>>> TOKEN:TEQA-DC:S-1-5-32-545
> >>>>>> TOKEN:TEQA-DC:S-1-5-32-544
> >>>>>> TOKEN:TEQA-DC:S-1-5-32-555
> >>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1124
> >>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-512
> >>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
> >>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1480
> >>>>>> TOKEN:TEQA-DC:S-1-1-0
> >>>>>>
> >>>>>> Since we are only interested in the member groups, tokenGroups is
> >>>>>> sufficient, but if you also need user SID then you might keep the
> >>>>>> objectSID
> >>>>>> as well.
> >>>>>>
> >>>>>> Thanks
> >>>>>>
> >>>>>> Kadri
> >>>>>>
> >>>>>>
> >>>>>> On Thu, May 5, 2011 at 6:01 PM, Karl Wright <da...@gmail.com>
> wrote:
> >>>>>>>
> >>>>>>> I am curious about the following change, which does not seem
> correct:
> >>>>>>>
> >>>>>>>
> >>>>>>> //Specify the attributes to return
> >>>>>>> - String returnedAtts[] = {"tokenGroups","objectSid"};
> >>>>>>> + String returnedAtts[]={"tokenGroups"};
> >>>>>>> searchCtls.setReturningAttributes(returnedAtts);
> >>>>>>>
> >>>>>>> Karl
> >>>>>>>
> >>>>>>>
> >>>>>>> On Thu, May 5, 2011 at 5:36 PM, Kadri Atalay <
> atalay.kadri@gmail.com>
> >>>>>>> wrote:
> >>>>>>>> Karl,
> >>>>>>>>
> >>>>>>>> The ActiveDirectoryAuthority.java is attached.
> >>>>>>>>
> >>>>>>>> I'm not sure about clicking "Grant ASF License", or how to do that
> >>>>>>>> from
> >>>>>>>> Tortoise.
> >>>>>>>> But, you got my consent for granting the ASF license.
> >>>>>>>>
> >>>>>>>> Thanks
> >>>>>>>>
> >>>>>>>> Kadri
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Thu, May 5, 2011 at 5:28 PM, Karl Wright <da...@gmail.com>
> >>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>> You may attach the whole ActiveDirectoryAuthority.java file to
> the
> >>>>>>>>> ticket if you prefer. But you must click the "Grant ASF License"
> >>>>>>>>> button.
> >>>>>>>>>
> >>>>>>>>> Karl
> >>>>>>>>>
> >>>>>>>>> On Thu, May 5, 2011 at 5:24 PM, Kadri Atalay
> >>>>>>>>> <at...@gmail.com>
> >>>>>>>>> wrote:
> >>>>>>>>>> Karl,
> >>>>>>>>>>
> >>>>>>>>>> I'm using the Tortoise SVN, and new to SVN..
> >>>>>>>>>> Do you know how to do this with Tortoise ?
> >>>>>>>>>> Otherwise, I can just send the source code directly to you.
> >>>>>>>>>> BTW, there are some changes in the ParseUser method also, you
> can
> >>>>>>>>>> see
> >>>>>>>>>> all
> >>>>>>>>>> when you run the diff.
> >>>>>>>>>>
> >>>>>>>>>> Thanks
> >>>>>>>>>>
> >>>>>>>>>> Kadri
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>
> >>>
> >
>
Re: Which version of Solr have implements the Document Level Access Control
Posted by Karl Wright <da...@gmail.com>.
I agree we probably want a compatibility switch in the configuration
switch. I'll create a ticket for that tomorrow morning, unless you
would like to do it first. ;-)
Karl
On Fri, May 6, 2011 at 1:44 AM, Shinichiro Abe
<sh...@gmail.com> wrote:
> Hi.
>
> I ran test in my environment. It works well.
> I confirmed that it was improved about the S-1-1-0 problem, incorrect responses, and implements by samAccountName.
> The test results are in attachments.
>
> One question:
> Size of samAccountName is specified as less than 20 characters.
> Size of Login Name is specified as over 20 characters(256).
> if a user does not support old version of OS and support only new version, it is hard for ManifoldCF to restrict 20 characters of Login name, I think. Is it rare? Is it okay that MCF always refers to samAccountName? It seems that we should add the compatible option.
>
> Thank you
> Shinichiro Abe
>
>
>
>
> On 2011/05/06, at 8:29, Karl Wright wrote:
>
>> I think yours was working because it was returning "cn=null,
>> cn=users", which was a result of the fact that cn was null and the
>> expression was assembled using the "+" operator. When I separated the
>> ldap escape out, it caused a null pointer exception to be thrown
>> instead. It should be fixed now.
>>
>> Karl
>>
>>
>> On Thu, May 5, 2011 at 7:19 PM, Kadri Atalay <at...@gmail.com> wrote:
>>> Fyi. The file I sent you was returning usernotfound.
>>>
>>>
>>> Sent from my iPhone
>>>
>>> On May 5, 2011, at 7:12 PM, Karl Wright <da...@gmail.com> wrote:
>>>
>>>> It must mean we're somehow throwing an exception in the case where the
>>>> user is missing. I bet I know why - the CN lookup is failing instead.
>>>> I'll see if I can change it.
>>>>
>>>> Karl
>>>>
>>>> On Thu, May 5, 2011 at 6:43 PM, Kadri Atalay <at...@gmail.com> wrote:
>>>>> It works, only difference I see with previous one is: if a domain is
>>>>> reachable, message usernotfound makes a better indicator, somehow we lost
>>>>> that.
>>>>>
>>>>>
>>>>> C:\OPT>testauthority
>>>>>
>>>>> C:\OPT>curl
>>>>> "http://localhost:8345/mcf-authority-service/UserACLs?username=fakeuser"
>>>>> UNREACHABLEAUTHORITY:TEQA-DC
>>>>> TOKEN:TEQA-DC:DEAD_AUTHORITY
>>>>>
>>>>> C:\OPT>curl
>>>>> "http://localhost:8345/mcf-authority-service/UserACLs?username=fakeuser@fakedomain"
>>>>> UNREACHABLEAUTHORITY:TEQA-DC
>>>>> TOKEN:TEQA-DC:DEAD_AUTHORITY
>>>>>
>>>>> C:\OPT>curl
>>>>> "http://localhost:8345/mcf-authority-service/UserACLs?username=fakeuser@teqa.filetek.com"
>>>>> UNREACHABLEAUTHORITY:TEQA-DC
>>>>> TOKEN:TEQA-DC:DEAD_AUTHORITY
>>>>>
>>>>> Previous one
>>>>> 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"
>>>>> UNREACHABLEAUTHORITY:TEQA-DC
>>>>> TOKEN:TEQA-DC:DEAD_AUTHORITY
>>>>>
>>>>> C:\OPT>curl
>>>>> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_admin@teqa.filetek.com"
>>>>> AUTHORIZED:TEQA-DC
>>>>> TOKEN:TEQA-DC:S-1-5-32-545
>>>>> TOKEN:TEQA-DC:S-1-5-32-544
>>>>> TOKEN:TEQA-DC:S-1-5-32-555
>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1124
>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-512
>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1480
>>>>> TOKEN:TEQA-DC:S-1-1-0
>>>>>
>>>>> C:\OPT>curl
>>>>> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay@teqa.filetek.com"
>>>>> AUTHORIZED:TEQA-DC
>>>>> TOKEN:TEQA-DC:S-1-5-32-545
>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1473
>>>>> TOKEN:TEQA-DC:S-1-1-0
>>>>>
>>>>> C:\OPT>curl
>>>>> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay@fakedomain"
>>>>> UNREACHABLEAUTHORITY:TEQA-DC
>>>>> TOKEN:TEQA-DC:DEAD_AUTHORITY
>>>>>
>>>>>
>>>>> On Thu, May 5, 2011 at 6:29 PM, Karl Wright <da...@gmail.com> wrote:
>>>>>>
>>>>>> I've cleaned things up slightly to restore the objectSid and also to
>>>>>> fix an infinite loop ifyou have more than one comma in the escape
>>>>>> expression. I've attached the file, can you see if it works?
>>>>>>
>>>>>> Thanks,
>>>>>> Karl
>>>>>>
>>>>>>
>>>>>> On Thu, May 5, 2011 at 6:23 PM, Karl Wright <da...@gmail.com> wrote:
>>>>>>> Thanks - we do need the user sid, so I will put that back.
>>>>>>>
>>>>>>> Also, I'd like to ask what you know about escaping the user name in
>>>>>>> this expression:
>>>>>>>
>>>>>>> String searchFilter = "(&(objectClass=user)(sAMAccountName=" + userName
>>>>>>> + "))";
>>>>>>>
>>>>>>> It seems to me that there is probably some escaping needed, but I
>>>>>>> don't know what style. Do you think it is the same (C-style, with \
>>>>>>> escape) as for the other case?
>>>>>>>
>>>>>>> Karl
>>>>>>>
>>>>>>> On Thu, May 5, 2011 at 6:20 PM, Kadri Atalay <at...@gmail.com>
>>>>>>> wrote:
>>>>>>>> Hi Karl,
>>>>>>>>
>>>>>>>> String returnedAtts[]={"tokenGroups"} is ONLY returning the
>>>>>>>> memberGroups,
>>>>>>>>
>>>>>>>> C:\OPT>curl
>>>>>>>>
>>>>>>>> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_admin@teqa.filetek.com"
>>>>>>>> AUTHORIZED:TEQA-DC
>>>>>>>> TOKEN:TEQA-DC:S-1-5-32-545
>>>>>>>> TOKEN:TEQA-DC:S-1-5-32-544
>>>>>>>> TOKEN:TEQA-DC:S-1-5-32-555
>>>>>>>> TOKEN:TEQA-DC:S-1-5-21-
>>>>>>>> 1212545812-2858578934-3563067286-1124
>>>>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-512
>>>>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
>>>>>>>> TOKEN:TEQA-DC:S-1-1-0
>>>>>>>>
>>>>>>>> but,
>>>>>>>>
>>>>>>>> - String returnedAtts[] = {"tokenGroups","objectSid"}; is returning
>>>>>>>> memberGroups AND SID for that user.
>>>>>>>>
>>>>>>>> C:\OPT>curl
>>>>>>>>
>>>>>>>> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_admin@teqa.filetek.com"
>>>>>>>> AUTHORIZED:TEQA-DC
>>>>>>>> TOKEN:TEQA-DC:S-1-5-32-545
>>>>>>>> TOKEN:TEQA-DC:S-1-5-32-544
>>>>>>>> TOKEN:TEQA-DC:S-1-5-32-555
>>>>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1124
>>>>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-512
>>>>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
>>>>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1480
>>>>>>>> TOKEN:TEQA-DC:S-1-1-0
>>>>>>>>
>>>>>>>> Since we are only interested in the member groups, tokenGroups is
>>>>>>>> sufficient, but if you also need user SID then you might keep the
>>>>>>>> objectSID
>>>>>>>> as well.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>> Kadri
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, May 5, 2011 at 6:01 PM, Karl Wright <da...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> I am curious about the following change, which does not seem correct:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> //Specify the attributes to return
>>>>>>>>> - String returnedAtts[] = {"tokenGroups","objectSid"};
>>>>>>>>> + String returnedAtts[]={"tokenGroups"};
>>>>>>>>> searchCtls.setReturningAttributes(returnedAtts);
>>>>>>>>>
>>>>>>>>> Karl
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, May 5, 2011 at 5:36 PM, Kadri Atalay <at...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>> Karl,
>>>>>>>>>>
>>>>>>>>>> The ActiveDirectoryAuthority.java is attached.
>>>>>>>>>>
>>>>>>>>>> I'm not sure about clicking "Grant ASF License", or how to do that
>>>>>>>>>> from
>>>>>>>>>> Tortoise.
>>>>>>>>>> But, you got my consent for granting the ASF license.
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>>
>>>>>>>>>> Kadri
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, May 5, 2011 at 5:28 PM, Karl Wright <da...@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> You may attach the whole ActiveDirectoryAuthority.java file to the
>>>>>>>>>>> ticket if you prefer. But you must click the "Grant ASF License"
>>>>>>>>>>> button.
>>>>>>>>>>>
>>>>>>>>>>> Karl
>>>>>>>>>>>
>>>>>>>>>>> On Thu, May 5, 2011 at 5:24 PM, Kadri Atalay
>>>>>>>>>>> <at...@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>> Karl,
>>>>>>>>>>>>
>>>>>>>>>>>> I'm using the Tortoise SVN, and new to SVN..
>>>>>>>>>>>> Do you know how to do this with Tortoise ?
>>>>>>>>>>>> Otherwise, I can just send the source code directly to you.
>>>>>>>>>>>> BTW, there are some changes in the ParseUser method also, you can
>>>>>>>>>>>> see
>>>>>>>>>>>> all
>>>>>>>>>>>> when you run the diff.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>>
>>>>>>>>>>>> Kadri
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>
>
>
Re: Which version of Solr have implements the Document Level Access Control
Posted by Shinichiro Abe <sh...@gmail.com>.
Hi.
I ran test in my environment. It works well.
I confirmed that it was improved about the S-1-1-0 problem, incorrect responses, and implements by samAccountName.
The test results are in attachments.
One question:
Size of samAccountName is specified as less than 20 characters.
Size of Login Name is specified as over 20 characters(256).
if a user does not support old version of OS and support only new version, it is hard for ManifoldCF to restrict 20 characters of Login name, I think. Is it rare? Is it okay that MCF always refers to samAccountName? It seems that we should add the compatible option.
Thank you
Shinichiro Abe
Re: Which version of Solr have implements the Document Level Access Control
Posted by Karl Wright <da...@gmail.com>.
I think yours was working because it was returning "cn=null,
cn=users", which was a result of the fact that cn was null and the
expression was assembled using the "+" operator. When I separated the
ldap escape out, it caused a null pointer exception to be thrown
instead. It should be fixed now.
Karl
On Thu, May 5, 2011 at 7:19 PM, Kadri Atalay <at...@gmail.com> wrote:
> Fyi. The file I sent you was returning usernotfound.
>
>
> Sent from my iPhone
>
> On May 5, 2011, at 7:12 PM, Karl Wright <da...@gmail.com> wrote:
>
>> It must mean we're somehow throwing an exception in the case where the
>> user is missing. I bet I know why - the CN lookup is failing instead.
>> I'll see if I can change it.
>>
>> Karl
>>
>> On Thu, May 5, 2011 at 6:43 PM, Kadri Atalay <at...@gmail.com> wrote:
>>> It works, only difference I see with previous one is: if a domain is
>>> reachable, message usernotfound makes a better indicator, somehow we lost
>>> that.
>>>
>>>
>>> C:\OPT>testauthority
>>>
>>> C:\OPT>curl
>>> "http://localhost:8345/mcf-authority-service/UserACLs?username=fakeuser"
>>> UNREACHABLEAUTHORITY:TEQA-DC
>>> TOKEN:TEQA-DC:DEAD_AUTHORITY
>>>
>>> C:\OPT>curl
>>> "http://localhost:8345/mcf-authority-service/UserACLs?username=fakeuser@fakedomain"
>>> UNREACHABLEAUTHORITY:TEQA-DC
>>> TOKEN:TEQA-DC:DEAD_AUTHORITY
>>>
>>> C:\OPT>curl
>>> "http://localhost:8345/mcf-authority-service/UserACLs?username=fakeuser@teqa.filetek.com"
>>> UNREACHABLEAUTHORITY:TEQA-DC
>>> TOKEN:TEQA-DC:DEAD_AUTHORITY
>>>
>>> Previous one
>>> 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"
>>> UNREACHABLEAUTHORITY:TEQA-DC
>>> TOKEN:TEQA-DC:DEAD_AUTHORITY
>>>
>>> C:\OPT>curl
>>> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_admin@teqa.filetek.com"
>>> AUTHORIZED:TEQA-DC
>>> TOKEN:TEQA-DC:S-1-5-32-545
>>> TOKEN:TEQA-DC:S-1-5-32-544
>>> TOKEN:TEQA-DC:S-1-5-32-555
>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1124
>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-512
>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1480
>>> TOKEN:TEQA-DC:S-1-1-0
>>>
>>> C:\OPT>curl
>>> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay@teqa.filetek.com"
>>> AUTHORIZED:TEQA-DC
>>> TOKEN:TEQA-DC:S-1-5-32-545
>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1473
>>> TOKEN:TEQA-DC:S-1-1-0
>>>
>>> C:\OPT>curl
>>> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay@fakedomain"
>>> UNREACHABLEAUTHORITY:TEQA-DC
>>> TOKEN:TEQA-DC:DEAD_AUTHORITY
>>>
>>>
>>> On Thu, May 5, 2011 at 6:29 PM, Karl Wright <da...@gmail.com> wrote:
>>>>
>>>> I've cleaned things up slightly to restore the objectSid and also to
>>>> fix an infinite loop ifyou have more than one comma in the escape
>>>> expression. I've attached the file, can you see if it works?
>>>>
>>>> Thanks,
>>>> Karl
>>>>
>>>>
>>>> On Thu, May 5, 2011 at 6:23 PM, Karl Wright <da...@gmail.com> wrote:
>>>>> Thanks - we do need the user sid, so I will put that back.
>>>>>
>>>>> Also, I'd like to ask what you know about escaping the user name in
>>>>> this expression:
>>>>>
>>>>> String searchFilter = "(&(objectClass=user)(sAMAccountName=" + userName
>>>>> + "))";
>>>>>
>>>>> It seems to me that there is probably some escaping needed, but I
>>>>> don't know what style. Do you think it is the same (C-style, with \
>>>>> escape) as for the other case?
>>>>>
>>>>> Karl
>>>>>
>>>>> On Thu, May 5, 2011 at 6:20 PM, Kadri Atalay <at...@gmail.com>
>>>>> wrote:
>>>>>> Hi Karl,
>>>>>>
>>>>>> String returnedAtts[]={"tokenGroups"} is ONLY returning the
>>>>>> memberGroups,
>>>>>>
>>>>>> C:\OPT>curl
>>>>>>
>>>>>> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_admin@teqa.filetek.com"
>>>>>> AUTHORIZED:TEQA-DC
>>>>>> TOKEN:TEQA-DC:S-1-5-32-545
>>>>>> TOKEN:TEQA-DC:S-1-5-32-544
>>>>>> TOKEN:TEQA-DC:S-1-5-32-555
>>>>>> TOKEN:TEQA-DC:S-1-5-21-
>>>>>> 1212545812-2858578934-3563067286-1124
>>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-512
>>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
>>>>>> TOKEN:TEQA-DC:S-1-1-0
>>>>>>
>>>>>> but,
>>>>>>
>>>>>> - String returnedAtts[] = {"tokenGroups","objectSid"}; is returning
>>>>>> memberGroups AND SID for that user.
>>>>>>
>>>>>> C:\OPT>curl
>>>>>>
>>>>>> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_admin@teqa.filetek.com"
>>>>>> AUTHORIZED:TEQA-DC
>>>>>> TOKEN:TEQA-DC:S-1-5-32-545
>>>>>> TOKEN:TEQA-DC:S-1-5-32-544
>>>>>> TOKEN:TEQA-DC:S-1-5-32-555
>>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1124
>>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-512
>>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
>>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1480
>>>>>> TOKEN:TEQA-DC:S-1-1-0
>>>>>>
>>>>>> Since we are only interested in the member groups, tokenGroups is
>>>>>> sufficient, but if you also need user SID then you might keep the
>>>>>> objectSID
>>>>>> as well.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Kadri
>>>>>>
>>>>>>
>>>>>> On Thu, May 5, 2011 at 6:01 PM, Karl Wright <da...@gmail.com> wrote:
>>>>>>>
>>>>>>> I am curious about the following change, which does not seem correct:
>>>>>>>
>>>>>>>
>>>>>>> //Specify the attributes to return
>>>>>>> - String returnedAtts[] = {"tokenGroups","objectSid"};
>>>>>>> + String returnedAtts[]={"tokenGroups"};
>>>>>>> searchCtls.setReturningAttributes(returnedAtts);
>>>>>>>
>>>>>>> Karl
>>>>>>>
>>>>>>>
>>>>>>> On Thu, May 5, 2011 at 5:36 PM, Kadri Atalay <at...@gmail.com>
>>>>>>> wrote:
>>>>>>>> Karl,
>>>>>>>>
>>>>>>>> The ActiveDirectoryAuthority.java is attached.
>>>>>>>>
>>>>>>>> I'm not sure about clicking "Grant ASF License", or how to do that
>>>>>>>> from
>>>>>>>> Tortoise.
>>>>>>>> But, you got my consent for granting the ASF license.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>> Kadri
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, May 5, 2011 at 5:28 PM, Karl Wright <da...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> You may attach the whole ActiveDirectoryAuthority.java file to the
>>>>>>>>> ticket if you prefer. But you must click the "Grant ASF License"
>>>>>>>>> button.
>>>>>>>>>
>>>>>>>>> Karl
>>>>>>>>>
>>>>>>>>> On Thu, May 5, 2011 at 5:24 PM, Kadri Atalay
>>>>>>>>> <at...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>> Karl,
>>>>>>>>>>
>>>>>>>>>> I'm using the Tortoise SVN, and new to SVN..
>>>>>>>>>> Do you know how to do this with Tortoise ?
>>>>>>>>>> Otherwise, I can just send the source code directly to you.
>>>>>>>>>> BTW, there are some changes in the ParseUser method also, you can
>>>>>>>>>> see
>>>>>>>>>> all
>>>>>>>>>> when you run the diff.
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>>
>>>>>>>>>> Kadri
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>>>
>
Re: Which version of Solr have implements the Document Level Access Control
Posted by Kadri Atalay <at...@gmail.com>.
Fyi. The file I sent you was returning usernotfound.
Sent from my iPhone
On May 5, 2011, at 7:12 PM, Karl Wright <da...@gmail.com> wrote:
> It must mean we're somehow throwing an exception in the case where the
> user is missing. I bet I know why - the CN lookup is failing instead.
> I'll see if I can change it.
>
> Karl
>
> On Thu, May 5, 2011 at 6:43 PM, Kadri Atalay <at...@gmail.com> wrote:
>> It works, only difference I see with previous one is: if a domain is
>> reachable, message usernotfound makes a better indicator, somehow we lost
>> that.
>>
>>
>> C:\OPT>testauthority
>>
>> C:\OPT>curl
>> "http://localhost:8345/mcf-authority-service/UserACLs?username=fakeuser"
>> UNREACHABLEAUTHORITY:TEQA-DC
>> TOKEN:TEQA-DC:DEAD_AUTHORITY
>>
>> C:\OPT>curl
>> "http://localhost:8345/mcf-authority-service/UserACLs?username=fakeuser@fakedomain"
>> UNREACHABLEAUTHORITY:TEQA-DC
>> TOKEN:TEQA-DC:DEAD_AUTHORITY
>>
>> C:\OPT>curl
>> "http://localhost:8345/mcf-authority-service/UserACLs?username=fakeuser@teqa.filetek.com"
>> UNREACHABLEAUTHORITY:TEQA-DC
>> TOKEN:TEQA-DC:DEAD_AUTHORITY
>>
>> Previous one
>> 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"
>> UNREACHABLEAUTHORITY:TEQA-DC
>> TOKEN:TEQA-DC:DEAD_AUTHORITY
>>
>> C:\OPT>curl
>> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_admin@teqa.filetek.com"
>> AUTHORIZED:TEQA-DC
>> TOKEN:TEQA-DC:S-1-5-32-545
>> TOKEN:TEQA-DC:S-1-5-32-544
>> TOKEN:TEQA-DC:S-1-5-32-555
>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1124
>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-512
>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1480
>> TOKEN:TEQA-DC:S-1-1-0
>>
>> C:\OPT>curl
>> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay@teqa.filetek.com"
>> AUTHORIZED:TEQA-DC
>> TOKEN:TEQA-DC:S-1-5-32-545
>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1473
>> TOKEN:TEQA-DC:S-1-1-0
>>
>> C:\OPT>curl
>> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay@fakedomain"
>> UNREACHABLEAUTHORITY:TEQA-DC
>> TOKEN:TEQA-DC:DEAD_AUTHORITY
>>
>>
>> On Thu, May 5, 2011 at 6:29 PM, Karl Wright <da...@gmail.com> wrote:
>>>
>>> I've cleaned things up slightly to restore the objectSid and also to
>>> fix an infinite loop ifyou have more than one comma in the escape
>>> expression. I've attached the file, can you see if it works?
>>>
>>> Thanks,
>>> Karl
>>>
>>>
>>> On Thu, May 5, 2011 at 6:23 PM, Karl Wright <da...@gmail.com> wrote:
>>>> Thanks - we do need the user sid, so I will put that back.
>>>>
>>>> Also, I'd like to ask what you know about escaping the user name in
>>>> this expression:
>>>>
>>>> String searchFilter = "(&(objectClass=user)(sAMAccountName=" + userName
>>>> + "))";
>>>>
>>>> It seems to me that there is probably some escaping needed, but I
>>>> don't know what style. Do you think it is the same (C-style, with \
>>>> escape) as for the other case?
>>>>
>>>> Karl
>>>>
>>>> On Thu, May 5, 2011 at 6:20 PM, Kadri Atalay <at...@gmail.com>
>>>> wrote:
>>>>> Hi Karl,
>>>>>
>>>>> String returnedAtts[]={"tokenGroups"} is ONLY returning the
>>>>> memberGroups,
>>>>>
>>>>> C:\OPT>curl
>>>>>
>>>>> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_admin@teqa.filetek.com"
>>>>> AUTHORIZED:TEQA-DC
>>>>> TOKEN:TEQA-DC:S-1-5-32-545
>>>>> TOKEN:TEQA-DC:S-1-5-32-544
>>>>> TOKEN:TEQA-DC:S-1-5-32-555
>>>>> TOKEN:TEQA-DC:S-1-5-21-
>>>>> 1212545812-2858578934-3563067286-1124
>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-512
>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
>>>>> TOKEN:TEQA-DC:S-1-1-0
>>>>>
>>>>> but,
>>>>>
>>>>> - String returnedAtts[] = {"tokenGroups","objectSid"}; is returning
>>>>> memberGroups AND SID for that user.
>>>>>
>>>>> C:\OPT>curl
>>>>>
>>>>> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_admin@teqa.filetek.com"
>>>>> AUTHORIZED:TEQA-DC
>>>>> TOKEN:TEQA-DC:S-1-5-32-545
>>>>> TOKEN:TEQA-DC:S-1-5-32-544
>>>>> TOKEN:TEQA-DC:S-1-5-32-555
>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1124
>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-512
>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1480
>>>>> TOKEN:TEQA-DC:S-1-1-0
>>>>>
>>>>> Since we are only interested in the member groups, tokenGroups is
>>>>> sufficient, but if you also need user SID then you might keep the
>>>>> objectSID
>>>>> as well.
>>>>>
>>>>> Thanks
>>>>>
>>>>> Kadri
>>>>>
>>>>>
>>>>> On Thu, May 5, 2011 at 6:01 PM, Karl Wright <da...@gmail.com> wrote:
>>>>>>
>>>>>> I am curious about the following change, which does not seem correct:
>>>>>>
>>>>>>
>>>>>> //Specify the attributes to return
>>>>>> - String returnedAtts[] = {"tokenGroups","objectSid"};
>>>>>> + String returnedAtts[]={"tokenGroups"};
>>>>>> searchCtls.setReturningAttributes(returnedAtts);
>>>>>>
>>>>>> Karl
>>>>>>
>>>>>>
>>>>>> On Thu, May 5, 2011 at 5:36 PM, Kadri Atalay <at...@gmail.com>
>>>>>> wrote:
>>>>>>> Karl,
>>>>>>>
>>>>>>> The ActiveDirectoryAuthority.java is attached.
>>>>>>>
>>>>>>> I'm not sure about clicking "Grant ASF License", or how to do that
>>>>>>> from
>>>>>>> Tortoise.
>>>>>>> But, you got my consent for granting the ASF license.
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> Kadri
>>>>>>>
>>>>>>>
>>>>>>> On Thu, May 5, 2011 at 5:28 PM, Karl Wright <da...@gmail.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> You may attach the whole ActiveDirectoryAuthority.java file to the
>>>>>>>> ticket if you prefer. But you must click the "Grant ASF License"
>>>>>>>> button.
>>>>>>>>
>>>>>>>> Karl
>>>>>>>>
>>>>>>>> On Thu, May 5, 2011 at 5:24 PM, Kadri Atalay
>>>>>>>> <at...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>> Karl,
>>>>>>>>>
>>>>>>>>> I'm using the Tortoise SVN, and new to SVN..
>>>>>>>>> Do you know how to do this with Tortoise ?
>>>>>>>>> Otherwise, I can just send the source code directly to you.
>>>>>>>>> BTW, there are some changes in the ParseUser method also, you can
>>>>>>>>> see
>>>>>>>>> all
>>>>>>>>> when you run the diff.
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>>
>>>>>>>>> Kadri
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>
>>
Re: Which version of Solr have implements the Document Level Access Control
Posted by Kadri Atalay <at...@gmail.com>.
Out of office now. Will try tomorrow .
Thx
Sent from my iPhone
On May 5, 2011, at 7:17 PM, Karl Wright <da...@gmail.com> wrote:
> Try this.
> Karl
>
>
> On Thu, May 5, 2011 at 7:12 PM, Karl Wright <da...@gmail.com> wrote:
>> It must mean we're somehow throwing an exception in the case where the
>> user is missing. I bet I know why - the CN lookup is failing instead.
>> I'll see if I can change it.
>>
>> Karl
>>
>> On Thu, May 5, 2011 at 6:43 PM, Kadri Atalay <at...@gmail.com> wrote:
>>> It works, only difference I see with previous one is: if a domain is
>>> reachable, message usernotfound makes a better indicator, somehow we lost
>>> that.
>>>
>>>
>>> C:\OPT>testauthority
>>>
>>> C:\OPT>curl
>>> "http://localhost:8345/mcf-authority-service/UserACLs?username=fakeuser"
>>> UNREACHABLEAUTHORITY:TEQA-DC
>>> TOKEN:TEQA-DC:DEAD_AUTHORITY
>>>
>>> C:\OPT>curl
>>> "http://localhost:8345/mcf-authority-service/UserACLs?username=fakeuser@fakedomain"
>>> UNREACHABLEAUTHORITY:TEQA-DC
>>> TOKEN:TEQA-DC:DEAD_AUTHORITY
>>>
>>> C:\OPT>curl
>>> "http://localhost:8345/mcf-authority-service/UserACLs?username=fakeuser@teqa.filetek.com"
>>> UNREACHABLEAUTHORITY:TEQA-DC
>>> TOKEN:TEQA-DC:DEAD_AUTHORITY
>>>
>>> Previous one
>>> 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"
>>> UNREACHABLEAUTHORITY:TEQA-DC
>>> TOKEN:TEQA-DC:DEAD_AUTHORITY
>>>
>>> C:\OPT>curl
>>> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_admin@teqa.filetek.com"
>>> AUTHORIZED:TEQA-DC
>>> TOKEN:TEQA-DC:S-1-5-32-545
>>> TOKEN:TEQA-DC:S-1-5-32-544
>>> TOKEN:TEQA-DC:S-1-5-32-555
>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1124
>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-512
>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1480
>>> TOKEN:TEQA-DC:S-1-1-0
>>>
>>> C:\OPT>curl
>>> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay@teqa.filetek.com"
>>> AUTHORIZED:TEQA-DC
>>> TOKEN:TEQA-DC:S-1-5-32-545
>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1473
>>> TOKEN:TEQA-DC:S-1-1-0
>>>
>>> C:\OPT>curl
>>> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay@fakedomain"
>>> UNREACHABLEAUTHORITY:TEQA-DC
>>> TOKEN:TEQA-DC:DEAD_AUTHORITY
>>>
>>>
>>> On Thu, May 5, 2011 at 6:29 PM, Karl Wright <da...@gmail.com> wrote:
>>>>
>>>> I've cleaned things up slightly to restore the objectSid and also to
>>>> fix an infinite loop ifyou have more than one comma in the escape
>>>> expression. I've attached the file, can you see if it works?
>>>>
>>>> Thanks,
>>>> Karl
>>>>
>>>>
>>>> On Thu, May 5, 2011 at 6:23 PM, Karl Wright <da...@gmail.com> wrote:
>>>>> Thanks - we do need the user sid, so I will put that back.
>>>>>
>>>>> Also, I'd like to ask what you know about escaping the user name in
>>>>> this expression:
>>>>>
>>>>> String searchFilter = "(&(objectClass=user)(sAMAccountName=" + userName
>>>>> + "))";
>>>>>
>>>>> It seems to me that there is probably some escaping needed, but I
>>>>> don't know what style. Do you think it is the same (C-style, with \
>>>>> escape) as for the other case?
>>>>>
>>>>> Karl
>>>>>
>>>>> On Thu, May 5, 2011 at 6:20 PM, Kadri Atalay <at...@gmail.com>
>>>>> wrote:
>>>>>> Hi Karl,
>>>>>>
>>>>>> String returnedAtts[]={"tokenGroups"} is ONLY returning the
>>>>>> memberGroups,
>>>>>>
>>>>>> C:\OPT>curl
>>>>>>
>>>>>> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_admin@teqa.filetek.com"
>>>>>> AUTHORIZED:TEQA-DC
>>>>>> TOKEN:TEQA-DC:S-1-5-32-545
>>>>>> TOKEN:TEQA-DC:S-1-5-32-544
>>>>>> TOKEN:TEQA-DC:S-1-5-32-555
>>>>>> TOKEN:TEQA-DC:S-1-5-21-
>>>>>> 1212545812-2858578934-3563067286-1124
>>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-512
>>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
>>>>>> TOKEN:TEQA-DC:S-1-1-0
>>>>>>
>>>>>> but,
>>>>>>
>>>>>> - String returnedAtts[] = {"tokenGroups","objectSid"}; is returning
>>>>>> memberGroups AND SID for that user.
>>>>>>
>>>>>> C:\OPT>curl
>>>>>>
>>>>>> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_admin@teqa.filetek.com"
>>>>>> AUTHORIZED:TEQA-DC
>>>>>> TOKEN:TEQA-DC:S-1-5-32-545
>>>>>> TOKEN:TEQA-DC:S-1-5-32-544
>>>>>> TOKEN:TEQA-DC:S-1-5-32-555
>>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1124
>>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-512
>>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
>>>>>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1480
>>>>>> TOKEN:TEQA-DC:S-1-1-0
>>>>>>
>>>>>> Since we are only interested in the member groups, tokenGroups is
>>>>>> sufficient, but if you also need user SID then you might keep the
>>>>>> objectSID
>>>>>> as well.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Kadri
>>>>>>
>>>>>>
>>>>>> On Thu, May 5, 2011 at 6:01 PM, Karl Wright <da...@gmail.com> wrote:
>>>>>>>
>>>>>>> I am curious about the following change, which does not seem correct:
>>>>>>>
>>>>>>>
>>>>>>> //Specify the attributes to return
>>>>>>> - String returnedAtts[] = {"tokenGroups","objectSid"};
>>>>>>> + String returnedAtts[]={"tokenGroups"};
>>>>>>> searchCtls.setReturningAttributes(returnedAtts);
>>>>>>>
>>>>>>> Karl
>>>>>>>
>>>>>>>
>>>>>>> On Thu, May 5, 2011 at 5:36 PM, Kadri Atalay <at...@gmail.com>
>>>>>>> wrote:
>>>>>>>> Karl,
>>>>>>>>
>>>>>>>> The ActiveDirectoryAuthority.java is attached.
>>>>>>>>
>>>>>>>> I'm not sure about clicking "Grant ASF License", or how to do that
>>>>>>>> from
>>>>>>>> Tortoise.
>>>>>>>> But, you got my consent for granting the ASF license.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>> Kadri
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, May 5, 2011 at 5:28 PM, Karl Wright <da...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> You may attach the whole ActiveDirectoryAuthority.java file to the
>>>>>>>>> ticket if you prefer. But you must click the "Grant ASF License"
>>>>>>>>> button.
>>>>>>>>>
>>>>>>>>> Karl
>>>>>>>>>
>>>>>>>>> On Thu, May 5, 2011 at 5:24 PM, Kadri Atalay
>>>>>>>>> <at...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>> Karl,
>>>>>>>>>>
>>>>>>>>>> I'm using the Tortoise SVN, and new to SVN..
>>>>>>>>>> Do you know how to do this with Tortoise ?
>>>>>>>>>> Otherwise, I can just send the source code directly to you.
>>>>>>>>>> BTW, there are some changes in the ParseUser method also, you can
>>>>>>>>>> see
>>>>>>>>>> all
>>>>>>>>>> when you run the diff.
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>>
>>>>>>>>>> Kadri
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>>>
>>
> <ActiveDirectoryAuthority.java>
Re: Which version of Solr have implements the Document Level Access Control
Posted by Karl Wright <da...@gmail.com>.
Try this.
Karl
On Thu, May 5, 2011 at 7:12 PM, Karl Wright <da...@gmail.com> wrote:
> It must mean we're somehow throwing an exception in the case where the
> user is missing. I bet I know why - the CN lookup is failing instead.
> I'll see if I can change it.
>
> Karl
>
> On Thu, May 5, 2011 at 6:43 PM, Kadri Atalay <at...@gmail.com> wrote:
>> It works, only difference I see with previous one is: if a domain is
>> reachable, message usernotfound makes a better indicator, somehow we lost
>> that.
>>
>>
>> C:\OPT>testauthority
>>
>> C:\OPT>curl
>> "http://localhost:8345/mcf-authority-service/UserACLs?username=fakeuser"
>> UNREACHABLEAUTHORITY:TEQA-DC
>> TOKEN:TEQA-DC:DEAD_AUTHORITY
>>
>> C:\OPT>curl
>> "http://localhost:8345/mcf-authority-service/UserACLs?username=fakeuser@fakedomain"
>> UNREACHABLEAUTHORITY:TEQA-DC
>> TOKEN:TEQA-DC:DEAD_AUTHORITY
>>
>> C:\OPT>curl
>> "http://localhost:8345/mcf-authority-service/UserACLs?username=fakeuser@teqa.filetek.com"
>> UNREACHABLEAUTHORITY:TEQA-DC
>> TOKEN:TEQA-DC:DEAD_AUTHORITY
>>
>> Previous one
>> 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"
>> UNREACHABLEAUTHORITY:TEQA-DC
>> TOKEN:TEQA-DC:DEAD_AUTHORITY
>>
>> C:\OPT>curl
>> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_admin@teqa.filetek.com"
>> AUTHORIZED:TEQA-DC
>> TOKEN:TEQA-DC:S-1-5-32-545
>> TOKEN:TEQA-DC:S-1-5-32-544
>> TOKEN:TEQA-DC:S-1-5-32-555
>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1124
>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-512
>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1480
>> TOKEN:TEQA-DC:S-1-1-0
>>
>> C:\OPT>curl
>> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay@teqa.filetek.com"
>> AUTHORIZED:TEQA-DC
>> TOKEN:TEQA-DC:S-1-5-32-545
>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1473
>> TOKEN:TEQA-DC:S-1-1-0
>>
>> C:\OPT>curl
>> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay@fakedomain"
>> UNREACHABLEAUTHORITY:TEQA-DC
>> TOKEN:TEQA-DC:DEAD_AUTHORITY
>>
>>
>> On Thu, May 5, 2011 at 6:29 PM, Karl Wright <da...@gmail.com> wrote:
>>>
>>> I've cleaned things up slightly to restore the objectSid and also to
>>> fix an infinite loop ifyou have more than one comma in the escape
>>> expression. I've attached the file, can you see if it works?
>>>
>>> Thanks,
>>> Karl
>>>
>>>
>>> On Thu, May 5, 2011 at 6:23 PM, Karl Wright <da...@gmail.com> wrote:
>>> > Thanks - we do need the user sid, so I will put that back.
>>> >
>>> > Also, I'd like to ask what you know about escaping the user name in
>>> > this expression:
>>> >
>>> > String searchFilter = "(&(objectClass=user)(sAMAccountName=" + userName
>>> > + "))";
>>> >
>>> > It seems to me that there is probably some escaping needed, but I
>>> > don't know what style. Do you think it is the same (C-style, with \
>>> > escape) as for the other case?
>>> >
>>> > Karl
>>> >
>>> > On Thu, May 5, 2011 at 6:20 PM, Kadri Atalay <at...@gmail.com>
>>> > wrote:
>>> >> Hi Karl,
>>> >>
>>> >> String returnedAtts[]={"tokenGroups"} is ONLY returning the
>>> >> memberGroups,
>>> >>
>>> >> C:\OPT>curl
>>> >>
>>> >> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_admin@teqa.filetek.com"
>>> >> AUTHORIZED:TEQA-DC
>>> >> TOKEN:TEQA-DC:S-1-5-32-545
>>> >> TOKEN:TEQA-DC:S-1-5-32-544
>>> >> TOKEN:TEQA-DC:S-1-5-32-555
>>> >> TOKEN:TEQA-DC:S-1-5-21-
>>> >> 1212545812-2858578934-3563067286-1124
>>> >> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-512
>>> >> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
>>> >> TOKEN:TEQA-DC:S-1-1-0
>>> >>
>>> >> but,
>>> >>
>>> >> - String returnedAtts[] = {"tokenGroups","objectSid"}; is returning
>>> >> memberGroups AND SID for that user.
>>> >>
>>> >> C:\OPT>curl
>>> >>
>>> >> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_admin@teqa.filetek.com"
>>> >> AUTHORIZED:TEQA-DC
>>> >> TOKEN:TEQA-DC:S-1-5-32-545
>>> >> TOKEN:TEQA-DC:S-1-5-32-544
>>> >> TOKEN:TEQA-DC:S-1-5-32-555
>>> >> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1124
>>> >> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-512
>>> >> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
>>> >> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1480
>>> >> TOKEN:TEQA-DC:S-1-1-0
>>> >>
>>> >> Since we are only interested in the member groups, tokenGroups is
>>> >> sufficient, but if you also need user SID then you might keep the
>>> >> objectSID
>>> >> as well.
>>> >>
>>> >> Thanks
>>> >>
>>> >> Kadri
>>> >>
>>> >>
>>> >> On Thu, May 5, 2011 at 6:01 PM, Karl Wright <da...@gmail.com> wrote:
>>> >>>
>>> >>> I am curious about the following change, which does not seem correct:
>>> >>>
>>> >>>
>>> >>> //Specify the attributes to return
>>> >>> - String returnedAtts[] = {"tokenGroups","objectSid"};
>>> >>> + String returnedAtts[]={"tokenGroups"};
>>> >>> searchCtls.setReturningAttributes(returnedAtts);
>>> >>>
>>> >>> Karl
>>> >>>
>>> >>>
>>> >>> On Thu, May 5, 2011 at 5:36 PM, Kadri Atalay <at...@gmail.com>
>>> >>> wrote:
>>> >>> > Karl,
>>> >>> >
>>> >>> > The ActiveDirectoryAuthority.java is attached.
>>> >>> >
>>> >>> > I'm not sure about clicking "Grant ASF License", or how to do that
>>> >>> > from
>>> >>> > Tortoise.
>>> >>> > But, you got my consent for granting the ASF license.
>>> >>> >
>>> >>> > Thanks
>>> >>> >
>>> >>> > Kadri
>>> >>> >
>>> >>> >
>>> >>> > On Thu, May 5, 2011 at 5:28 PM, Karl Wright <da...@gmail.com>
>>> >>> > wrote:
>>> >>> >>
>>> >>> >> You may attach the whole ActiveDirectoryAuthority.java file to the
>>> >>> >> ticket if you prefer. But you must click the "Grant ASF License"
>>> >>> >> button.
>>> >>> >>
>>> >>> >> Karl
>>> >>> >>
>>> >>> >> On Thu, May 5, 2011 at 5:24 PM, Kadri Atalay
>>> >>> >> <at...@gmail.com>
>>> >>> >> wrote:
>>> >>> >> > Karl,
>>> >>> >> >
>>> >>> >> > I'm using the Tortoise SVN, and new to SVN..
>>> >>> >> > Do you know how to do this with Tortoise ?
>>> >>> >> > Otherwise, I can just send the source code directly to you.
>>> >>> >> > BTW, there are some changes in the ParseUser method also, you can
>>> >>> >> > see
>>> >>> >> > all
>>> >>> >> > when you run the diff.
>>> >>> >> >
>>> >>> >> > Thanks
>>> >>> >> >
>>> >>> >> > Kadri
>>> >>> >> >
>>> >>> >
>>> >>> >
>>> >>
>>> >>
>>> >
>>
>>
>
Re: Which version of Solr have implements the Document Level Access Control
Posted by Karl Wright <da...@gmail.com>.
It must mean we're somehow throwing an exception in the case where the
user is missing. I bet I know why - the CN lookup is failing instead.
I'll see if I can change it.
Karl
On Thu, May 5, 2011 at 6:43 PM, Kadri Atalay <at...@gmail.com> wrote:
> It works, only difference I see with previous one is: if a domain is
> reachable, message usernotfound makes a better indicator, somehow we lost
> that.
>
>
> C:\OPT>testauthority
>
> C:\OPT>curl
> "http://localhost:8345/mcf-authority-service/UserACLs?username=fakeuser"
> UNREACHABLEAUTHORITY:TEQA-DC
> TOKEN:TEQA-DC:DEAD_AUTHORITY
>
> C:\OPT>curl
> "http://localhost:8345/mcf-authority-service/UserACLs?username=fakeuser@fakedomain"
> UNREACHABLEAUTHORITY:TEQA-DC
> TOKEN:TEQA-DC:DEAD_AUTHORITY
>
> C:\OPT>curl
> "http://localhost:8345/mcf-authority-service/UserACLs?username=fakeuser@teqa.filetek.com"
> UNREACHABLEAUTHORITY:TEQA-DC
> TOKEN:TEQA-DC:DEAD_AUTHORITY
>
> Previous one
> 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"
> UNREACHABLEAUTHORITY:TEQA-DC
> TOKEN:TEQA-DC:DEAD_AUTHORITY
>
> C:\OPT>curl
> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_admin@teqa.filetek.com"
> AUTHORIZED:TEQA-DC
> TOKEN:TEQA-DC:S-1-5-32-545
> TOKEN:TEQA-DC:S-1-5-32-544
> TOKEN:TEQA-DC:S-1-5-32-555
> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1124
> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-512
> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1480
> TOKEN:TEQA-DC:S-1-1-0
>
> C:\OPT>curl
> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay@teqa.filetek.com"
> AUTHORIZED:TEQA-DC
> TOKEN:TEQA-DC:S-1-5-32-545
> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1473
> TOKEN:TEQA-DC:S-1-1-0
>
> C:\OPT>curl
> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay@fakedomain"
> UNREACHABLEAUTHORITY:TEQA-DC
> TOKEN:TEQA-DC:DEAD_AUTHORITY
>
>
> On Thu, May 5, 2011 at 6:29 PM, Karl Wright <da...@gmail.com> wrote:
>>
>> I've cleaned things up slightly to restore the objectSid and also to
>> fix an infinite loop ifyou have more than one comma in the escape
>> expression. I've attached the file, can you see if it works?
>>
>> Thanks,
>> Karl
>>
>>
>> On Thu, May 5, 2011 at 6:23 PM, Karl Wright <da...@gmail.com> wrote:
>> > Thanks - we do need the user sid, so I will put that back.
>> >
>> > Also, I'd like to ask what you know about escaping the user name in
>> > this expression:
>> >
>> > String searchFilter = "(&(objectClass=user)(sAMAccountName=" + userName
>> > + "))";
>> >
>> > It seems to me that there is probably some escaping needed, but I
>> > don't know what style. Do you think it is the same (C-style, with \
>> > escape) as for the other case?
>> >
>> > Karl
>> >
>> > On Thu, May 5, 2011 at 6:20 PM, Kadri Atalay <at...@gmail.com>
>> > wrote:
>> >> Hi Karl,
>> >>
>> >> String returnedAtts[]={"tokenGroups"} is ONLY returning the
>> >> memberGroups,
>> >>
>> >> C:\OPT>curl
>> >>
>> >> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_admin@teqa.filetek.com"
>> >> AUTHORIZED:TEQA-DC
>> >> TOKEN:TEQA-DC:S-1-5-32-545
>> >> TOKEN:TEQA-DC:S-1-5-32-544
>> >> TOKEN:TEQA-DC:S-1-5-32-555
>> >> TOKEN:TEQA-DC:S-1-5-21-
>> >> 1212545812-2858578934-3563067286-1124
>> >> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-512
>> >> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
>> >> TOKEN:TEQA-DC:S-1-1-0
>> >>
>> >> but,
>> >>
>> >> - String returnedAtts[] = {"tokenGroups","objectSid"}; is returning
>> >> memberGroups AND SID for that user.
>> >>
>> >> C:\OPT>curl
>> >>
>> >> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_admin@teqa.filetek.com"
>> >> AUTHORIZED:TEQA-DC
>> >> TOKEN:TEQA-DC:S-1-5-32-545
>> >> TOKEN:TEQA-DC:S-1-5-32-544
>> >> TOKEN:TEQA-DC:S-1-5-32-555
>> >> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1124
>> >> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-512
>> >> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
>> >> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1480
>> >> TOKEN:TEQA-DC:S-1-1-0
>> >>
>> >> Since we are only interested in the member groups, tokenGroups is
>> >> sufficient, but if you also need user SID then you might keep the
>> >> objectSID
>> >> as well.
>> >>
>> >> Thanks
>> >>
>> >> Kadri
>> >>
>> >>
>> >> On Thu, May 5, 2011 at 6:01 PM, Karl Wright <da...@gmail.com> wrote:
>> >>>
>> >>> I am curious about the following change, which does not seem correct:
>> >>>
>> >>>
>> >>> //Specify the attributes to return
>> >>> - String returnedAtts[] = {"tokenGroups","objectSid"};
>> >>> + String returnedAtts[]={"tokenGroups"};
>> >>> searchCtls.setReturningAttributes(returnedAtts);
>> >>>
>> >>> Karl
>> >>>
>> >>>
>> >>> On Thu, May 5, 2011 at 5:36 PM, Kadri Atalay <at...@gmail.com>
>> >>> wrote:
>> >>> > Karl,
>> >>> >
>> >>> > The ActiveDirectoryAuthority.java is attached.
>> >>> >
>> >>> > I'm not sure about clicking "Grant ASF License", or how to do that
>> >>> > from
>> >>> > Tortoise.
>> >>> > But, you got my consent for granting the ASF license.
>> >>> >
>> >>> > Thanks
>> >>> >
>> >>> > Kadri
>> >>> >
>> >>> >
>> >>> > On Thu, May 5, 2011 at 5:28 PM, Karl Wright <da...@gmail.com>
>> >>> > wrote:
>> >>> >>
>> >>> >> You may attach the whole ActiveDirectoryAuthority.java file to the
>> >>> >> ticket if you prefer. But you must click the "Grant ASF License"
>> >>> >> button.
>> >>> >>
>> >>> >> Karl
>> >>> >>
>> >>> >> On Thu, May 5, 2011 at 5:24 PM, Kadri Atalay
>> >>> >> <at...@gmail.com>
>> >>> >> wrote:
>> >>> >> > Karl,
>> >>> >> >
>> >>> >> > I'm using the Tortoise SVN, and new to SVN..
>> >>> >> > Do you know how to do this with Tortoise ?
>> >>> >> > Otherwise, I can just send the source code directly to you.
>> >>> >> > BTW, there are some changes in the ParseUser method also, you can
>> >>> >> > see
>> >>> >> > all
>> >>> >> > when you run the diff.
>> >>> >> >
>> >>> >> > Thanks
>> >>> >> >
>> >>> >> > Kadri
>> >>> >> >
>> >>> >
>> >>> >
>> >>
>> >>
>> >
>
>
Re: Which version of Solr have implements the Document Level Access Control
Posted by Kadri Atalay <at...@gmail.com>.
It works, only difference I see with previous one is: if a domain is
reachable, message usernotfound makes a better indicator, somehow we lost
that.
C:\OPT>testauthority
C:\OPT>curl "
http://localhost:8345/mcf-authority-service/UserACLs?username=fakeuser"
UNREACHABLEAUTHORITY:TEQA-DC
TOKEN:TEQA-DC:DEAD_AUTHORITY
C:\OPT>curl "
http://localhost:8345/mcf-authority-service/UserACLs?username=fakeuser@fakedomain
"
UNREACHABLEAUTHORITY:TEQA-DC
TOKEN:TEQA-DC:DEAD_AUTHORITY
C:\OPT>curl "
http://localhost:8345/mcf-authority-service/UserACLs?username=fakeuser@teqa.filetek.com
"
UNREACHABLEAUTHORITY:TEQA-DC
TOKEN:TEQA-DC:DEAD_AUTHORITY
Previous one
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
"
UNREACHABLEAUTHORITY:TEQA-DC
TOKEN:TEQA-DC:DEAD_AUTHORITY
C:\OPT>curl "
http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_admin@teqa.filetek.com
"
AUTHORIZED:TEQA-DC
TOKEN:TEQA-DC:S-1-5-32-545
TOKEN:TEQA-DC:S-1-5-32-544
TOKEN:TEQA-DC:S-1-5-32-555
TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1124
TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-512
TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1480
TOKEN:TEQA-DC:S-1-1-0
C:\OPT>curl "
http://localhost:8345/mcf-authority-service/UserACLs?username=katalay@teqa.filetek.com
"
AUTHORIZED:TEQA-DC
TOKEN:TEQA-DC:S-1-5-32-545
TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1473
TOKEN:TEQA-DC:S-1-1-0
C:\OPT>curl "
http://localhost:8345/mcf-authority-service/UserACLs?username=katalay@fakedomain
"
UNREACHABLEAUTHORITY:TEQA-DC
TOKEN:TEQA-DC:DEAD_AUTHORITY
On Thu, May 5, 2011 at 6:29 PM, Karl Wright <da...@gmail.com> wrote:
> I've cleaned things up slightly to restore the objectSid and also to
> fix an infinite loop ifyou have more than one comma in the escape
> expression. I've attached the file, can you see if it works?
>
> Thanks,
> Karl
>
>
> On Thu, May 5, 2011 at 6:23 PM, Karl Wright <da...@gmail.com> wrote:
> > Thanks - we do need the user sid, so I will put that back.
> >
> > Also, I'd like to ask what you know about escaping the user name in
> > this expression:
> >
> > String searchFilter = "(&(objectClass=user)(sAMAccountName=" + userName +
> "))";
> >
> > It seems to me that there is probably some escaping needed, but I
> > don't know what style. Do you think it is the same (C-style, with \
> > escape) as for the other case?
> >
> > Karl
> >
> > On Thu, May 5, 2011 at 6:20 PM, Kadri Atalay <at...@gmail.com>
> wrote:
> >> Hi Karl,
> >>
> >> String returnedAtts[]={"tokenGroups"} is ONLY returning the
> >> memberGroups,
> >>
> >> C:\OPT>curl
> >> "
> http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_admin@teqa.filetek.com
> "
> >> AUTHORIZED:TEQA-DC
> >> TOKEN:TEQA-DC:S-1-5-32-545
> >> TOKEN:TEQA-DC:S-1-5-32-544
> >> TOKEN:TEQA-DC:S-1-5-32-555
> >> TOKEN:TEQA-DC:S-1-5-21-
> >> 1212545812-2858578934-3563067286-1124
> >> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-512
> >> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
> >> TOKEN:TEQA-DC:S-1-1-0
> >>
> >> but,
> >>
> >> - String returnedAtts[] = {"tokenGroups","objectSid"}; is returning
> >> memberGroups AND SID for that user.
> >>
> >> C:\OPT>curl
> >> "
> http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_admin@teqa.filetek.com
> "
> >> AUTHORIZED:TEQA-DC
> >> TOKEN:TEQA-DC:S-1-5-32-545
> >> TOKEN:TEQA-DC:S-1-5-32-544
> >> TOKEN:TEQA-DC:S-1-5-32-555
> >> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1124
> >> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-512
> >> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
> >> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1480
> >> TOKEN:TEQA-DC:S-1-1-0
> >>
> >> Since we are only interested in the member groups, tokenGroups is
> >> sufficient, but if you also need user SID then you might keep the
> objectSID
> >> as well.
> >>
> >> Thanks
> >>
> >> Kadri
> >>
> >>
> >> On Thu, May 5, 2011 at 6:01 PM, Karl Wright <da...@gmail.com> wrote:
> >>>
> >>> I am curious about the following change, which does not seem correct:
> >>>
> >>>
> >>> //Specify the attributes to return
> >>> - String returnedAtts[] = {"tokenGroups","objectSid"};
> >>> + String returnedAtts[]={"tokenGroups"};
> >>> searchCtls.setReturningAttributes(returnedAtts);
> >>>
> >>> Karl
> >>>
> >>>
> >>> On Thu, May 5, 2011 at 5:36 PM, Kadri Atalay <at...@gmail.com>
> >>> wrote:
> >>> > Karl,
> >>> >
> >>> > The ActiveDirectoryAuthority.java is attached.
> >>> >
> >>> > I'm not sure about clicking "Grant ASF License", or how to do that
> from
> >>> > Tortoise.
> >>> > But, you got my consent for granting the ASF license.
> >>> >
> >>> > Thanks
> >>> >
> >>> > Kadri
> >>> >
> >>> >
> >>> > On Thu, May 5, 2011 at 5:28 PM, Karl Wright <da...@gmail.com>
> wrote:
> >>> >>
> >>> >> You may attach the whole ActiveDirectoryAuthority.java file to the
> >>> >> ticket if you prefer. But you must click the "Grant ASF License"
> >>> >> button.
> >>> >>
> >>> >> Karl
> >>> >>
> >>> >> On Thu, May 5, 2011 at 5:24 PM, Kadri Atalay <
> atalay.kadri@gmail.com>
> >>> >> wrote:
> >>> >> > Karl,
> >>> >> >
> >>> >> > I'm using the Tortoise SVN, and new to SVN..
> >>> >> > Do you know how to do this with Tortoise ?
> >>> >> > Otherwise, I can just send the source code directly to you.
> >>> >> > BTW, there are some changes in the ParseUser method also, you can
> see
> >>> >> > all
> >>> >> > when you run the diff.
> >>> >> >
> >>> >> > Thanks
> >>> >> >
> >>> >> > Kadri
> >>> >> >
> >>> >
> >>> >
> >>
> >>
> >
>
Re: Which version of Solr have implements the Document Level Access Control
Posted by Karl Wright <da...@gmail.com>.
I've cleaned things up slightly to restore the objectSid and also to
fix an infinite loop ifyou have more than one comma in the escape
expression. I've attached the file, can you see if it works?
Thanks,
Karl
On Thu, May 5, 2011 at 6:23 PM, Karl Wright <da...@gmail.com> wrote:
> Thanks - we do need the user sid, so I will put that back.
>
> Also, I'd like to ask what you know about escaping the user name in
> this expression:
>
> String searchFilter = "(&(objectClass=user)(sAMAccountName=" + userName + "))";
>
> It seems to me that there is probably some escaping needed, but I
> don't know what style. Do you think it is the same (C-style, with \
> escape) as for the other case?
>
> Karl
>
> On Thu, May 5, 2011 at 6:20 PM, Kadri Atalay <at...@gmail.com> wrote:
>> Hi Karl,
>>
>> String returnedAtts[]={"tokenGroups"} is ONLY returning the
>> memberGroups,
>>
>> C:\OPT>curl
>> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_admin@teqa.filetek.com"
>> AUTHORIZED:TEQA-DC
>> TOKEN:TEQA-DC:S-1-5-32-545
>> TOKEN:TEQA-DC:S-1-5-32-544
>> TOKEN:TEQA-DC:S-1-5-32-555
>> TOKEN:TEQA-DC:S-1-5-21-
>> 1212545812-2858578934-3563067286-1124
>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-512
>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
>> TOKEN:TEQA-DC:S-1-1-0
>>
>> but,
>>
>> - String returnedAtts[] = {"tokenGroups","objectSid"}; is returning
>> memberGroups AND SID for that user.
>>
>> C:\OPT>curl
>> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_admin@teqa.filetek.com"
>> AUTHORIZED:TEQA-DC
>> TOKEN:TEQA-DC:S-1-5-32-545
>> TOKEN:TEQA-DC:S-1-5-32-544
>> TOKEN:TEQA-DC:S-1-5-32-555
>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1124
>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-512
>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
>> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1480
>> TOKEN:TEQA-DC:S-1-1-0
>>
>> Since we are only interested in the member groups, tokenGroups is
>> sufficient, but if you also need user SID then you might keep the objectSID
>> as well.
>>
>> Thanks
>>
>> Kadri
>>
>>
>> On Thu, May 5, 2011 at 6:01 PM, Karl Wright <da...@gmail.com> wrote:
>>>
>>> I am curious about the following change, which does not seem correct:
>>>
>>>
>>> //Specify the attributes to return
>>> - String returnedAtts[] = {"tokenGroups","objectSid"};
>>> + String returnedAtts[]={"tokenGroups"};
>>> searchCtls.setReturningAttributes(returnedAtts);
>>>
>>> Karl
>>>
>>>
>>> On Thu, May 5, 2011 at 5:36 PM, Kadri Atalay <at...@gmail.com>
>>> wrote:
>>> > Karl,
>>> >
>>> > The ActiveDirectoryAuthority.java is attached.
>>> >
>>> > I'm not sure about clicking "Grant ASF License", or how to do that from
>>> > Tortoise.
>>> > But, you got my consent for granting the ASF license.
>>> >
>>> > Thanks
>>> >
>>> > Kadri
>>> >
>>> >
>>> > On Thu, May 5, 2011 at 5:28 PM, Karl Wright <da...@gmail.com> wrote:
>>> >>
>>> >> You may attach the whole ActiveDirectoryAuthority.java file to the
>>> >> ticket if you prefer. But you must click the "Grant ASF License"
>>> >> button.
>>> >>
>>> >> Karl
>>> >>
>>> >> On Thu, May 5, 2011 at 5:24 PM, Kadri Atalay <at...@gmail.com>
>>> >> wrote:
>>> >> > Karl,
>>> >> >
>>> >> > I'm using the Tortoise SVN, and new to SVN..
>>> >> > Do you know how to do this with Tortoise ?
>>> >> > Otherwise, I can just send the source code directly to you.
>>> >> > BTW, there are some changes in the ParseUser method also, you can see
>>> >> > all
>>> >> > when you run the diff.
>>> >> >
>>> >> > Thanks
>>> >> >
>>> >> > Kadri
>>> >> >
>>> >
>>> >
>>
>>
>
Re: Which version of Solr have implements the Document Level Access Control
Posted by Karl Wright <da...@gmail.com>.
Thanks - we do need the user sid, so I will put that back.
Also, I'd like to ask what you know about escaping the user name in
this expression:
String searchFilter = "(&(objectClass=user)(sAMAccountName=" + userName + "))";
It seems to me that there is probably some escaping needed, but I
don't know what style. Do you think it is the same (C-style, with \
escape) as for the other case?
Karl
On Thu, May 5, 2011 at 6:20 PM, Kadri Atalay <at...@gmail.com> wrote:
> Hi Karl,
>
> String returnedAtts[]={"tokenGroups"} is ONLY returning the
> memberGroups,
>
> C:\OPT>curl
> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_admin@teqa.filetek.com"
> AUTHORIZED:TEQA-DC
> TOKEN:TEQA-DC:S-1-5-32-545
> TOKEN:TEQA-DC:S-1-5-32-544
> TOKEN:TEQA-DC:S-1-5-32-555
> TOKEN:TEQA-DC:S-1-5-21-
> 1212545812-2858578934-3563067286-1124
> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-512
> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
> TOKEN:TEQA-DC:S-1-1-0
>
> but,
>
> - String returnedAtts[] = {"tokenGroups","objectSid"}; is returning
> memberGroups AND SID for that user.
>
> C:\OPT>curl
> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_admin@teqa.filetek.com"
> AUTHORIZED:TEQA-DC
> TOKEN:TEQA-DC:S-1-5-32-545
> TOKEN:TEQA-DC:S-1-5-32-544
> TOKEN:TEQA-DC:S-1-5-32-555
> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1124
> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-512
> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1480
> TOKEN:TEQA-DC:S-1-1-0
>
> Since we are only interested in the member groups, tokenGroups is
> sufficient, but if you also need user SID then you might keep the objectSID
> as well.
>
> Thanks
>
> Kadri
>
>
> On Thu, May 5, 2011 at 6:01 PM, Karl Wright <da...@gmail.com> wrote:
>>
>> I am curious about the following change, which does not seem correct:
>>
>>
>> //Specify the attributes to return
>> - String returnedAtts[] = {"tokenGroups","objectSid"};
>> + String returnedAtts[]={"tokenGroups"};
>> searchCtls.setReturningAttributes(returnedAtts);
>>
>> Karl
>>
>>
>> On Thu, May 5, 2011 at 5:36 PM, Kadri Atalay <at...@gmail.com>
>> wrote:
>> > Karl,
>> >
>> > The ActiveDirectoryAuthority.java is attached.
>> >
>> > I'm not sure about clicking "Grant ASF License", or how to do that from
>> > Tortoise.
>> > But, you got my consent for granting the ASF license.
>> >
>> > Thanks
>> >
>> > Kadri
>> >
>> >
>> > On Thu, May 5, 2011 at 5:28 PM, Karl Wright <da...@gmail.com> wrote:
>> >>
>> >> You may attach the whole ActiveDirectoryAuthority.java file to the
>> >> ticket if you prefer. But you must click the "Grant ASF License"
>> >> button.
>> >>
>> >> Karl
>> >>
>> >> On Thu, May 5, 2011 at 5:24 PM, Kadri Atalay <at...@gmail.com>
>> >> wrote:
>> >> > Karl,
>> >> >
>> >> > I'm using the Tortoise SVN, and new to SVN..
>> >> > Do you know how to do this with Tortoise ?
>> >> > Otherwise, I can just send the source code directly to you.
>> >> > BTW, there are some changes in the ParseUser method also, you can see
>> >> > all
>> >> > when you run the diff.
>> >> >
>> >> > Thanks
>> >> >
>> >> > Kadri
>> >> >
>> >
>> >
>
>
Re: Which version of Solr have implements the Document Level Access Control
Posted by Kadri Atalay <at...@gmail.com>.
Hi Karl,
String returnedAtts[]={"tokenGroups"} is ONLY returning the
memberGroups,
C:\OPT>curl "
http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_admin@teqa.filetek.com
"
AUTHORIZED:TEQA-DC
TOKEN:TEQA-DC:S-1-5-32-545
TOKEN:TEQA-DC:S-1-5-32-544
TOKEN:TEQA-DC:S-1-5-32-555
TOKEN:TEQA-DC:S-1-5-21-
1212545812-2858578934-3563067286-1124
TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-512
TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
TOKEN:TEQA-DC:S-1-1-0
but,
- String returnedAtts[] = {"tokenGroups","objectSid"}; is returning
memberGroups AND *SID for that user*.
> C:\OPT>curl "
http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_admin@teqa.filetek.com
"
AUTHORIZED:TEQA-DC
TOKEN:TEQA-DC:S-1-5-32-545
TOKEN:TEQA-DC:S-1-5-32-544
TOKEN:TEQA-DC:S-1-5-32-555
TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1124
TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-512
TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
*TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1480*
TOKEN:TEQA-DC:S-1-1-0
Since we are only interested in the member groups, tokenGroups is
sufficient, but if you also need user SID then you might keep the objectSID
as well.
Thanks
Kadri
On Thu, May 5, 2011 at 6:01 PM, Karl Wright <da...@gmail.com> wrote:
> I am curious about the following change, which does not seem correct:
>
>
> //Specify the attributes to return
> - String returnedAtts[] = {"tokenGroups","objectSid"};
> + String returnedAtts[]={"tokenGroups"};
> searchCtls.setReturningAttributes(returnedAtts);
>
> Karl
>
>
> On Thu, May 5, 2011 at 5:36 PM, Kadri Atalay <at...@gmail.com>
> wrote:
> > Karl,
> >
> > The ActiveDirectoryAuthority.java is attached.
> >
> > I'm not sure about clicking "Grant ASF License", or how to do that from
> > Tortoise.
> > But, you got my consent for granting the ASF license.
> >
> > Thanks
> >
> > Kadri
> >
> >
> > On Thu, May 5, 2011 at 5:28 PM, Karl Wright <da...@gmail.com> wrote:
> >>
> >> You may attach the whole ActiveDirectoryAuthority.java file to the
> >> ticket if you prefer. But you must click the "Grant ASF License"
> >> button.
> >>
> >> Karl
> >>
> >> On Thu, May 5, 2011 at 5:24 PM, Kadri Atalay <at...@gmail.com>
> >> wrote:
> >> > Karl,
> >> >
> >> > I'm using the Tortoise SVN, and new to SVN..
> >> > Do you know how to do this with Tortoise ?
> >> > Otherwise, I can just send the source code directly to you.
> >> > BTW, there are some changes in the ParseUser method also, you can see
> >> > all
> >> > when you run the diff.
> >> >
> >> > Thanks
> >> >
> >> > Kadri
> >> >
> >
> >
>
Re: Which version of Solr have implements the Document Level Access Control
Posted by Karl Wright <da...@gmail.com>.
I am curious about the following change, which does not seem correct:
//Specify the attributes to return
- String returnedAtts[] = {"tokenGroups","objectSid"};
+ String returnedAtts[]={"tokenGroups"};
searchCtls.setReturningAttributes(returnedAtts);
Karl
On Thu, May 5, 2011 at 5:36 PM, Kadri Atalay <at...@gmail.com> wrote:
> Karl,
>
> The ActiveDirectoryAuthority.java is attached.
>
> I'm not sure about clicking "Grant ASF License", or how to do that from
> Tortoise.
> But, you got my consent for granting the ASF license.
>
> Thanks
>
> Kadri
>
>
> On Thu, May 5, 2011 at 5:28 PM, Karl Wright <da...@gmail.com> wrote:
>>
>> You may attach the whole ActiveDirectoryAuthority.java file to the
>> ticket if you prefer. But you must click the "Grant ASF License"
>> button.
>>
>> Karl
>>
>> On Thu, May 5, 2011 at 5:24 PM, Kadri Atalay <at...@gmail.com>
>> wrote:
>> > Karl,
>> >
>> > I'm using the Tortoise SVN, and new to SVN..
>> > Do you know how to do this with Tortoise ?
>> > Otherwise, I can just send the source code directly to you.
>> > BTW, there are some changes in the ParseUser method also, you can see
>> > all
>> > when you run the diff.
>> >
>> > Thanks
>> >
>> > Kadri
>> >
>
>
Re: Which version of Solr have implements the Document Level Access Control
Posted by Kadri Atalay <at...@gmail.com>.
Karl,
The ActiveDirectoryAuthority.java is attached.
I'm not sure about clicking "Grant ASF License", or how to do that from
Tortoise.
But, you got my consent for granting the ASF license.
Thanks
Kadri
On Thu, May 5, 2011 at 5:28 PM, Karl Wright <da...@gmail.com> wrote:
> You may attach the whole ActiveDirectoryAuthority.java file to the
> ticket if you prefer. But you must click the "Grant ASF License"
> button.
>
> Karl
>
> On Thu, May 5, 2011 at 5:24 PM, Kadri Atalay <at...@gmail.com>
> wrote:
> > Karl,
> >
> > I'm using the Tortoise SVN, and new to SVN..
> > Do you know how to do this with Tortoise ?
> > Otherwise, I can just send the source code directly to you.
> > BTW, there are some changes in the ParseUser method also, you can see all
> > when you run the diff.
> >
> > Thanks
> >
> > Kadri
> >
>
Re: Which version of Solr have implements the Document Level Access Control
Posted by Karl Wright <da...@gmail.com>.
You may attach the whole ActiveDirectoryAuthority.java file to the
ticket if you prefer. But you must click the "Grant ASF License"
button.
Karl
On Thu, May 5, 2011 at 5:24 PM, Kadri Atalay <at...@gmail.com> wrote:
> Karl,
>
> I'm using the Tortoise SVN, and new to SVN..
> Do you know how to do this with Tortoise ?
> Otherwise, I can just send the source code directly to you.
> BTW, there are some changes in the ParseUser method also, you can see all
> when you run the diff.
>
> Thanks
>
> Kadri
>
Re: Which version of Solr have implements the Document Level Access Control
Posted by Kadri Atalay <at...@gmail.com>.
Karl,
I'm using the Tortoise SVN, and new to SVN..
Do you know how to do this with Tortoise ?
Otherwise, I can just send the source code directly to you.
BTW, there are some changes in the ParseUser method also, you can see all
when you run the diff.
Thanks
Kadri
On Thu, May 5, 2011 at 5:16 PM, Karl Wright <da...@gmail.com> wrote:
> That's great news!
>
> You cannot commit directly even into a branch unless you are a
> committer. But if you could do the following:
>
> svn diff >CONNECTORS-195.patch
>
> and attach that file to CONNECTORS-195 ticket, I'd be happy to include
> the code. Please remember to click the "Grant license to ASF" button
> when you are attaching, or we can't use your contribution.
>
> Thanks for all the hard work!
> Karl
>
>
> On Thu, May 5, 2011 at 5:08 PM, Kadri Atalay <at...@gmail.com>
> wrote:
> > Hi Karl,
> >
> > I have got GOOD news. Finally I get it to work:
> >
> > The reason my tests were not working was that my domain logon name
> > "katalay_admin" is different than the cn attribute "Atalay, Kadri
> (Admin)"
> > which is also used in display name.
> > Which I believe is true for most users. The existing code would ONLY
> work
> > where logon name is as same as the cn attribute in Active Directory.
> > As it's indicated in the method parseUser():
> >
> > //String searchBase =
> > "CN=Administrator,CN=Users,DC=qa-ad-76,DC=metacarta,DC=com";
> > First parameter is full name not the logon name (unless they are the
> same).
> > This searchBase is used when scope is set to =====
> > searchCtls.setSearchScope(SearchControls.OBJECT_SCOPE);
> >
> > So, to retrieve the cn attribute (full name), I have added a new method
> > called String getCnAttribute(String userName, String searchBase)
> > which is called from parseUser, and first CN= parameter is correctly
> > populated filter & scope is changed.
> > String searchFilter = "(&(objectClass=user)(sAMAccountName=" +
> userName
> > + "))";
> > searchCtls.setSearchScope(SearchControls.SUBTREE_SCOPE);
> >
> > I have also added a method to clean this retrieved cn attribute because
> it
> > contains cn:, and it may contains commas which are trouble during the
> query.
> >
> > Following are the test results, as expected:
> >
> > If you like, I can check in the changes for CONNECTORS-195 branch.
> >
> > Thanks
> >
> > Kadri
> >
> >
> > C:\OPT>testauthority
> >
> > C:\OPT>curl
> > "http://localhost:8345/mcf-authority-service/UserACLs?username=fakeuser"
> > UNREACHABLEAUTHORITY:TEQA-DC
> > TOKEN:TEQA-DC:DEAD_AUTHORITY
> >
> > 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
> "
> > AUTHORIZED:TEQA-DC
> > TOKEN:TEQA-DC:S-1-5-32-545
> > TOKEN:TEQA-DC:S-1-5-32-544
> > TOKEN:TEQA-DC:S-1-5-32-555
> > TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1124
> > TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-512
> > TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
> > TOKEN:TEQA-DC:S-1-1-0
> >
> > C:\OPT>curl
> > "
> http://localhost:8345/mcf-authority-service/UserACLs?username=katalay@teqa.filetek.com
> "
> > AUTHORIZED:TEQA-DC
> > TOKEN:TEQA-DC:S-1-5-32-545
> > TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
> > TOKEN:TEQA-DC:S-1-1-0
> >
> > C:\OPT>curl
> > "
> http://localhost:8345/mcf-authority-service/UserACLs?username=katalay@fakedomain
> "
> > USERNOTFOUND:TEQA-DC
> > TOKEN:TEQA-DC:DEAD_AUTHORITY
> >
> > On Wed, May 4, 2011 at 11:26 AM, Karl Wright <da...@gmail.com> wrote:
> >>
> >> Hi Kadri,
> >>
> >> Shinichiro Abe has been using the Active Directory authority connector
> >> actively and successfully recently. I've asked him to verify the
> >> change that I proposed for detecting the user-not-found condition more
> >> reliably. I am still waiting for his response.
> >>
> >> The code would not be adding the S-1-1-0 group if it was being
> >> returned by Active Directory, but in my tests (now more than a year
> >> ago) on Windows Server 2000 and Windows Server 2003, it never did get
> >> returned. And yet it was critically important, which is why I had no
> >> choice but to add it manually.
> >>
> >> Since it is a well-known group with a standard definition, there
> >> should be no concern that there would be a conflict. The only
> >> potential issue could be that not all users have S-1-1-0. I'd love to
> >> see any indication that this can ever be the case. If so, there must
> >> be a way to detect this detail through LDAP, which we'd have to learn
> >> somehow.
> >>
> >> Karl
> >>
> >>
> >> On Wed, May 4, 2011 at 11:05 AM, Kadri Atalay <at...@gmail.com>
> >> wrote:
> >> > Hi Karl,
> >> >
> >> > You might be remembering the SID's indexed with documents. During
> >> > document
> >> > indexing correct SID's are stored in the SOlr.
> >> > But, while making a request per user, never received a different SID
> >> > other
> >> > than the everyone group (S-1-1-0) which is artificially inserted
> within
> >> > the
> >> > manifold code.
> >> > I believe adding this everyone group (S-1-1-0) is wrong, because the
> >> > code is
> >> > adding something it may not be there. (Not every organization have an
> >> > everyone group, or not every user is part of everyone group)
> >> > Code should only return the groups truly exist in the active
> directory..
> >> > (Well that's my humble opinion, and we'll use it for my company like
> >> > that.)
> >> >
> >> > I would be curious to see actual test results from different active
> >> > directories, and at the mean time will try to create some here.
> >> >
> >> > Thanks for your help !
> >> >
> >> > Kadri
> >> >
> >> >
> >> > On Wed, May 4, 2011 at 12:55 AM, Karl Wright <da...@gmail.com>
> wrote:
> >> >>
> >> >> 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 <da...@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 <da...@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
> >> >> >>> <at...@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
> >> >> >>> >> <at...@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
> >> >> >>> >> > <da...@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
> >> >> >>> >> >> <da...@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
> >> >> >>> >> >> > <da...@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
> >> >> >>> >> >> >> <at...@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
> >> >> >>> >> >> >>> <da...@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
> >> >> >>> >> >> >>>> <da...@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
> >> >> >>> >> >> >>>> > <at...@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
> >> >> >>> >> >> >>>> >> <da...@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
> >> >> >>> >> >> >>>> >>> <at...@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
> >> >> >>> >> >> >>>> >>> > <da...@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
> >> >> >>> >> >> >>>> >>> >> <at...@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
> >> >> >>> >> >> >>>> >>> >> > <da...@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
> >> >> >>> >> >> >>>> >>> >> >> <da...@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
> >> >> >>> >> >> >>>> >>> >> >> > <at...@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
> >> >> >>> >> >> >>>> >>> >> >> >> <da...@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
> >> >> >>> >> >> >>>> >>> >> >> >>> <at...@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
> >> >> >>> >> >> >>>> >>> >> >> >>> > <da...@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
> >> >> >>> >> >> >>>> >>> >> >> >>> >> <at...@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
> >> >> >>> >> >> >>>> >>> >> >> >>> >> > <da...@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
> >> >> >>> >> >> >>>> >>> >> >> >>> >> >> <at...@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
> >> >> >>> >> >> >>>> >>> >> >> >>> >> >> >
> >> >> >>> >> >> >>>> >>> >> >> >>> >> >
> >> >> >>> >> >> >>>> >>> >> >> >>> >> >
> >> >> >>> >> >> >>>> >>> >> >> >>> >
> >> >> >>> >> >> >>>> >>> >> >> >>> >
> >> >> >>> >> >> >>>> >>> >> >> >>
> >> >> >>> >> >> >>>> >>> >> >> >>
> >> >> >>> >> >> >>>> >>> >> >> >
> >> >> >>> >> >> >>>> >>> >> >
> >> >> >>> >> >> >>>> >>> >> >
> >> >> >>> >> >> >>>> >>> >
> >> >> >>> >> >> >>>> >>> >
> >> >> >>> >> >> >>>> >>
> >> >> >>> >> >> >>>> >>
> >> >> >>> >> >> >>>> >
> >> >> >>> >> >> >>>
> >> >> >>> >> >> >>>
> >> >> >>> >> >> >>
> >> >> >>> >> >> >
> >> >> >>> >> >
> >> >> >>> >> >
> >> >> >>> >
> >> >> >>> >
> >> >> >>
> >> >> >>
> >> >> >
> >> >
> >> >
> >
> >
>
Re: Which version of Solr have implements the Document Level Access Control
Posted by Karl Wright <da...@gmail.com>.
That's great news!
You cannot commit directly even into a branch unless you are a
committer. But if you could do the following:
svn diff >CONNECTORS-195.patch
and attach that file to CONNECTORS-195 ticket, I'd be happy to include
the code. Please remember to click the "Grant license to ASF" button
when you are attaching, or we can't use your contribution.
Thanks for all the hard work!
Karl
On Thu, May 5, 2011 at 5:08 PM, Kadri Atalay <at...@gmail.com> wrote:
> Hi Karl,
>
> I have got GOOD news. Finally I get it to work:
>
> The reason my tests were not working was that my domain logon name
> "katalay_admin" is different than the cn attribute "Atalay, Kadri (Admin)"
> which is also used in display name.
> Which I believe is true for most users. The existing code would ONLY work
> where logon name is as same as the cn attribute in Active Directory.
> As it's indicated in the method parseUser():
>
> //String searchBase =
> "CN=Administrator,CN=Users,DC=qa-ad-76,DC=metacarta,DC=com";
> First parameter is full name not the logon name (unless they are the same).
> This searchBase is used when scope is set to =====
> searchCtls.setSearchScope(SearchControls.OBJECT_SCOPE);
>
> So, to retrieve the cn attribute (full name), I have added a new method
> called String getCnAttribute(String userName, String searchBase)
> which is called from parseUser, and first CN= parameter is correctly
> populated filter & scope is changed.
> String searchFilter = "(&(objectClass=user)(sAMAccountName=" + userName
> + "))";
> searchCtls.setSearchScope(SearchControls.SUBTREE_SCOPE);
>
> I have also added a method to clean this retrieved cn attribute because it
> contains cn:, and it may contains commas which are trouble during the query.
>
> Following are the test results, as expected:
>
> If you like, I can check in the changes for CONNECTORS-195 branch.
>
> Thanks
>
> Kadri
>
>
> C:\OPT>testauthority
>
> C:\OPT>curl
> "http://localhost:8345/mcf-authority-service/UserACLs?username=fakeuser"
> UNREACHABLEAUTHORITY:TEQA-DC
> TOKEN:TEQA-DC:DEAD_AUTHORITY
>
> 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"
> AUTHORIZED:TEQA-DC
> TOKEN:TEQA-DC:S-1-5-32-545
> TOKEN:TEQA-DC:S-1-5-32-544
> TOKEN:TEQA-DC:S-1-5-32-555
> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1124
> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-512
> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
> TOKEN:TEQA-DC:S-1-1-0
>
> C:\OPT>curl
> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay@teqa.filetek.com"
> AUTHORIZED:TEQA-DC
> TOKEN:TEQA-DC:S-1-5-32-545
> TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
> TOKEN:TEQA-DC:S-1-1-0
>
> C:\OPT>curl
> "http://localhost:8345/mcf-authority-service/UserACLs?username=katalay@fakedomain"
> USERNOTFOUND:TEQA-DC
> TOKEN:TEQA-DC:DEAD_AUTHORITY
>
> On Wed, May 4, 2011 at 11:26 AM, Karl Wright <da...@gmail.com> wrote:
>>
>> Hi Kadri,
>>
>> Shinichiro Abe has been using the Active Directory authority connector
>> actively and successfully recently. I've asked him to verify the
>> change that I proposed for detecting the user-not-found condition more
>> reliably. I am still waiting for his response.
>>
>> The code would not be adding the S-1-1-0 group if it was being
>> returned by Active Directory, but in my tests (now more than a year
>> ago) on Windows Server 2000 and Windows Server 2003, it never did get
>> returned. And yet it was critically important, which is why I had no
>> choice but to add it manually.
>>
>> Since it is a well-known group with a standard definition, there
>> should be no concern that there would be a conflict. The only
>> potential issue could be that not all users have S-1-1-0. I'd love to
>> see any indication that this can ever be the case. If so, there must
>> be a way to detect this detail through LDAP, which we'd have to learn
>> somehow.
>>
>> Karl
>>
>>
>> On Wed, May 4, 2011 at 11:05 AM, Kadri Atalay <at...@gmail.com>
>> wrote:
>> > Hi Karl,
>> >
>> > You might be remembering the SID's indexed with documents. During
>> > document
>> > indexing correct SID's are stored in the SOlr.
>> > But, while making a request per user, never received a different SID
>> > other
>> > than the everyone group (S-1-1-0) which is artificially inserted within
>> > the
>> > manifold code.
>> > I believe adding this everyone group (S-1-1-0) is wrong, because the
>> > code is
>> > adding something it may not be there. (Not every organization have an
>> > everyone group, or not every user is part of everyone group)
>> > Code should only return the groups truly exist in the active directory..
>> > (Well that's my humble opinion, and we'll use it for my company like
>> > that.)
>> >
>> > I would be curious to see actual test results from different active
>> > directories, and at the mean time will try to create some here.
>> >
>> > Thanks for your help !
>> >
>> > Kadri
>> >
>> >
>> > On Wed, May 4, 2011 at 12:55 AM, Karl Wright <da...@gmail.com> wrote:
>> >>
>> >> 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 <da...@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 <at...@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 <da...@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
>> >> >>> <at...@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 <da...@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
>> >> >>> >> <at...@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
>> >> >>> >> > <da...@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
>> >> >>> >> >> <da...@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
>> >> >>> >> >> > <da...@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
>> >> >>> >> >> >> <at...@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
>> >> >>> >> >> >>> <da...@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
>> >> >>> >> >> >>>> <da...@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
>> >> >>> >> >> >>>> > <at...@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
>> >> >>> >> >> >>>> >> <da...@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
>> >> >>> >> >> >>>> >>> <at...@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
>> >> >>> >> >> >>>> >>> > <da...@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
>> >> >>> >> >> >>>> >>> >> <at...@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
>> >> >>> >> >> >>>> >>> >> > <da...@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
>> >> >>> >> >> >>>> >>> >> >> <da...@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
>> >> >>> >> >> >>>> >>> >> >> > <at...@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
>> >> >>> >> >> >>>> >>> >> >> >> <da...@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
>> >> >>> >> >> >>>> >>> >> >> >>> <at...@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
>> >> >>> >> >> >>>> >>> >> >> >>> > <da...@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
>> >> >>> >> >> >>>> >>> >> >> >>> >> <at...@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
>> >> >>> >> >> >>>> >>> >> >> >>> >> > <da...@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
>> >> >>> >> >> >>>> >>> >> >> >>> >> >> <at...@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
>> >> >>> >> >> >>>> >>> >> >> >>> >> >> >
>> >> >>> >> >> >>>> >>> >> >> >>> >> >
>> >> >>> >> >> >>>> >>> >> >> >>> >> >
>> >> >>> >> >> >>>> >>> >> >> >>> >
>> >> >>> >> >> >>>> >>> >> >> >>> >
>> >> >>> >> >> >>>> >>> >> >> >>
>> >> >>> >> >> >>>> >>> >> >> >>
>> >> >>> >> >> >>>> >>> >> >> >
>> >> >>> >> >> >>>> >>> >> >
>> >> >>> >> >> >>>> >>> >> >
>> >> >>> >> >> >>>> >>> >
>> >> >>> >> >> >>>> >>> >
>> >> >>> >> >> >>>> >>
>> >> >>> >> >> >>>> >>
>> >> >>> >> >> >>>> >
>> >> >>> >> >> >>>
>> >> >>> >> >> >>>
>> >> >>> >> >> >>
>> >> >>> >> >> >
>> >> >>> >> >
>> >> >>> >> >
>> >> >>> >
>> >> >>> >
>> >> >>
>> >> >>
>> >> >
>> >
>> >
>
>
Re: Which version of Solr have implements the Document Level Access Control
Posted by Kadri Atalay <at...@gmail.com>.
Hi Karl,
I have got GOOD news. Finally I get it to work:
The reason my tests were not working was that my domain logon name
"katalay_admin" is different than the cn attribute "Atalay, Kadri (Admin)"
which is also used in display name.
Which I believe is true for most users. The existing code would ONLY work
where logon name is as same as the cn attribute in Active Directory.
As it's indicated in the method parseUser():
//String searchBase =
"CN=Administrator,CN=Users,DC=qa-ad-76,DC=metacarta,DC=com";
First parameter is full name not the logon name (unless they are the same).
This searchBase is used when scope is set to =====
searchCtls.setSearchScope(SearchControls.OBJECT_SCOPE);
So, to retrieve the cn attribute (full name), I have added a new method
called String getCnAttribute(String userName, String searchBase)
which is called from parseUser, and first CN= parameter is correctly
populated filter & scope is changed.
String searchFilter = "(&(objectClass=user)(sAMAccountName=" + userName
+ "))";
searchCtls.setSearchScope(SearchControls.SUBTREE_SCOPE);
I have also added a method to clean this retrieved cn attribute because it
contains cn:, and it may contains commas which are trouble during the query.
Following are the test results, as expected:
If you like, I can check in the changes for CONNECTORS-195 branch.
Thanks
Kadri
C:\OPT>testauthority
C:\OPT>curl "
http://localhost:8345/mcf-authority-service/UserACLs?username=fakeuser"
UNREACHABLEAUTHORITY:TEQA-DC
TOKEN:TEQA-DC:DEAD_AUTHORITY
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
"
AUTHORIZED:TEQA-DC
TOKEN:TEQA-DC:S-1-5-32-545
TOKEN:TEQA-DC:S-1-5-32-544
TOKEN:TEQA-DC:S-1-5-32-555
TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1124
TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-512
TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
TOKEN:TEQA-DC:S-1-1-0
C:\OPT>curl "
http://localhost:8345/mcf-authority-service/UserACLs?username=katalay@teqa.filetek.com
"
AUTHORIZED:TEQA-DC
TOKEN:TEQA-DC:S-1-5-32-545
TOKEN:TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-513
TOKEN:TEQA-DC:S-1-1-0
C:\OPT>curl "
http://localhost:8345/mcf-authority-service/UserACLs?username=katalay@fakedomain
"
USERNOTFOUND:TEQA-DC
TOKEN:TEQA-DC:DEAD_AUTHORITY
On Wed, May 4, 2011 at 11:26 AM, Karl Wright <da...@gmail.com> wrote:
> Hi Kadri,
>
> Shinichiro Abe has been using the Active Directory authority connector
> actively and successfully recently. I've asked him to verify the
> change that I proposed for detecting the user-not-found condition more
> reliably. I am still waiting for his response.
>
> The code would not be adding the S-1-1-0 group if it was being
> returned by Active Directory, but in my tests (now more than a year
> ago) on Windows Server 2000 and Windows Server 2003, it never did get
> returned. And yet it was critically important, which is why I had no
> choice but to add it manually.
>
> Since it is a well-known group with a standard definition, there
> should be no concern that there would be a conflict. The only
> potential issue could be that not all users have S-1-1-0. I'd love to
> see any indication that this can ever be the case. If so, there must
> be a way to detect this detail through LDAP, which we'd have to learn
> somehow.
>
> Karl
>
>
> On Wed, May 4, 2011 at 11:05 AM, Kadri Atalay <at...@gmail.com>
> wrote:
> > Hi Karl,
> >
> > You might be remembering the SID's indexed with documents. During
> document
> > indexing correct SID's are stored in the SOlr.
> > But, while making a request per user, never received a different SID
> other
> > than the everyone group (S-1-1-0) which is artificially inserted within
> the
> > manifold code.
> > I believe adding this everyone group (S-1-1-0) is wrong, because the code
> is
> > adding something it may not be there. (Not every organization have an
> > everyone group, or not every user is part of everyone group)
> > Code should only return the groups truly exist in the active directory..
> > (Well that's my humble opinion, and we'll use it for my company like
> that.)
> >
> > I would be curious to see actual test results from different active
> > directories, and at the mean time will try to create some here.
> >
> > Thanks for your help !
> >
> > Kadri
> >
> >
> > On Wed, May 4, 2011 at 12:55 AM, Karl Wright <da...@gmail.com> wrote:
> >>
> >> 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 <da...@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 <at...@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 <da...@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 <da...@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
> >> >>> >> <at...@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
> >> >>> >> >> <da...@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
> >> >>> >> >> > <da...@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
> >> >>> >> >> >> <at...@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
> >> >>> >> >> >>> <da...@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
> >> >>> >> >> >>>> <da...@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
> >> >>> >> >> >>>> > <at...@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
> >> >>> >> >> >>>> >> <da...@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
> >> >>> >> >> >>>> >>> <at...@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
> >> >>> >> >> >>>> >>> > <da...@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
> >> >>> >> >> >>>> >>> >> <at...@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
> >> >>> >> >> >>>> >>> >> > <da...@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
> >> >>> >> >> >>>> >>> >> >> <da...@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
> >> >>> >> >> >>>> >>> >> >> > <at...@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
> >> >>> >> >> >>>> >>> >> >> >> <da...@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
> >> >>> >> >> >>>> >>> >> >> >>> <at...@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
> >> >>> >> >> >>>> >>> >> >> >>> > <da...@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
> >> >>> >> >> >>>> >>> >> >> >>> >> <at...@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
> >> >>> >> >> >>>> >>> >> >> >>> >> > <da...@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
> >> >>> >> >> >>>> >>> >> >> >>> >> >> <at...@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
> >> >>> >> >> >>>> >>> >> >> >>> >> >> >
> >> >>> >> >> >>>> >>> >> >> >>> >> >
> >> >>> >> >> >>>> >>> >> >> >>> >> >
> >> >>> >> >> >>>> >>> >> >> >>> >
> >> >>> >> >> >>>> >>> >> >> >>> >
> >> >>> >> >> >>>> >>> >> >> >>
> >> >>> >> >> >>>> >>> >> >> >>
> >> >>> >> >> >>>> >>> >> >> >
> >> >>> >> >> >>>> >>> >> >
> >> >>> >> >> >>>> >>> >> >
> >> >>> >> >> >>>> >>> >
> >> >>> >> >> >>>> >>> >
> >> >>> >> >> >>>> >>
> >> >>> >> >> >>>> >>
> >> >>> >> >> >>>> >
> >> >>> >> >> >>>
> >> >>> >> >> >>>
> >> >>> >> >> >>
> >> >>> >> >> >
> >> >>> >> >
> >> >>> >> >
> >> >>> >
> >> >>> >
> >> >>
> >> >>
> >> >
> >
> >
>
Re: Which version of Solr have implements the Document Level Access Control
Posted by Karl Wright <da...@gmail.com>.
Hi Kadri,
Shinichiro Abe has been using the Active Directory authority connector
actively and successfully recently. I've asked him to verify the
change that I proposed for detecting the user-not-found condition more
reliably. I am still waiting for his response.
The code would not be adding the S-1-1-0 group if it was being
returned by Active Directory, but in my tests (now more than a year
ago) on Windows Server 2000 and Windows Server 2003, it never did get
returned. And yet it was critically important, which is why I had no
choice but to add it manually.
Since it is a well-known group with a standard definition, there
should be no concern that there would be a conflict. The only
potential issue could be that not all users have S-1-1-0. I'd love to
see any indication that this can ever be the case. If so, there must
be a way to detect this detail through LDAP, which we'd have to learn
somehow.
Karl
On Wed, May 4, 2011 at 11:05 AM, Kadri Atalay <at...@gmail.com> wrote:
> Hi Karl,
>
> You might be remembering the SID's indexed with documents. During document
> indexing correct SID's are stored in the SOlr.
> But, while making a request per user, never received a different SID other
> than the everyone group (S-1-1-0) which is artificially inserted within the
> manifold code.
> I believe adding this everyone group (S-1-1-0) is wrong, because the code is
> adding something it may not be there. (Not every organization have an
> everyone group, or not every user is part of everyone group)
> Code should only return the groups truly exist in the active directory..
> (Well that's my humble opinion, and we'll use it for my company like that.)
>
> I would be curious to see actual test results from different active
> directories, and at the mean time will try to create some here.
>
> Thanks for your help !
>
> Kadri
>
>
> On Wed, May 4, 2011 at 12:55 AM, Karl Wright <da...@gmail.com> wrote:
>>
>> 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 <da...@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 <at...@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 <da...@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 <at...@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 <da...@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
>> >>> >> <at...@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 <da...@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
>> >>> >> >> <da...@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
>> >>> >> >> > <da...@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
>> >>> >> >> >> <at...@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
>> >>> >> >> >>> <da...@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
>> >>> >> >> >>>> <da...@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
>> >>> >> >> >>>> > <at...@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
>> >>> >> >> >>>> >> <da...@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
>> >>> >> >> >>>> >>> <at...@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
>> >>> >> >> >>>> >>> > <da...@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
>> >>> >> >> >>>> >>> >> <at...@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
>> >>> >> >> >>>> >>> >> > <da...@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
>> >>> >> >> >>>> >>> >> >> <da...@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
>> >>> >> >> >>>> >>> >> >> > <at...@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
>> >>> >> >> >>>> >>> >> >> >> <da...@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
>> >>> >> >> >>>> >>> >> >> >>> <at...@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
>> >>> >> >> >>>> >>> >> >> >>> > <da...@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
>> >>> >> >> >>>> >>> >> >> >>> >> <at...@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
>> >>> >> >> >>>> >>> >> >> >>> >> > <da...@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
>> >>> >> >> >>>> >>> >> >> >>> >> >> <at...@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
>> >>> >> >> >>>> >>> >> >> >>> >> >> >
>> >>> >> >> >>>> >>> >> >> >>> >> >
>> >>> >> >> >>>> >>> >> >> >>> >> >
>> >>> >> >> >>>> >>> >> >> >>> >
>> >>> >> >> >>>> >>> >> >> >>> >
>> >>> >> >> >>>> >>> >> >> >>
>> >>> >> >> >>>> >>> >> >> >>
>> >>> >> >> >>>> >>> >> >> >
>> >>> >> >> >>>> >>> >> >
>> >>> >> >> >>>> >>> >> >
>> >>> >> >> >>>> >>> >
>> >>> >> >> >>>> >>> >
>> >>> >> >> >>>> >>
>> >>> >> >> >>>> >>
>> >>> >> >> >>>> >
>> >>> >> >> >>>
>> >>> >> >> >>>
>> >>> >> >> >>
>> >>> >> >> >
>> >>> >> >
>> >>> >> >
>> >>> >
>> >>> >
>> >>
>> >>
>> >
>
>
Re: Which version of Solr have implements the Document Level Access Control
Posted by Kadri Atalay <at...@gmail.com>.
Hi Karl,
You might be remembering the SID's indexed with documents. During document
indexing correct SID's are stored in the SOlr.
But, while making a request per user, never received a different SID other
than the everyone group (S-1-1-0) which is artificially inserted within the
manifold code.
I believe adding this everyone group (S-1-1-0) is wrong, because the code is
adding something it may not be there. (Not every organization have an
everyone group, or not every user is part of everyone group)
Code should only return the groups truly exist in the active directory..
(Well that's my humble opinion, and we'll use it for my company like that.)
I would be curious to see actual test results from different active
directories, and at the mean time will try to create some here.
Thanks for your help !
Kadri
On Wed, May 4, 2011 at 12:55 AM, Karl Wright <da...@gmail.com> wrote:
> 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 <da...@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 <at...@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 <da...@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 <at...@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 <da...@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 <da...@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
> >>> >> >> >> <at...@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
> >>> >> >> >>>> <da...@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
> >>> >> >> >>>> > <at...@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
> >>> >> >> >>>> >> <da...@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
> >>> >> >> >>>> >>> <at...@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
> >>> >> >> >>>> >>> > <da...@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
> >>> >> >> >>>> >>> >> <at...@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
> >>> >> >> >>>> >>> >> > <da...@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
> >>> >> >> >>>> >>> >> >> <da...@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
> >>> >> >> >>>> >>> >> >> > <at...@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
> >>> >> >> >>>> >>> >> >> >> <da...@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
> >>> >> >> >>>> >>> >> >> >>> <at...@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
> >>> >> >> >>>> >>> >> >> >>> > <da...@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
> >>> >> >> >>>> >>> >> >> >>> >> <at...@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
> >>> >> >> >>>> >>> >> >> >>> >> > <da...@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
> >>> >> >> >>>> >>> >> >> >>> >> >> <at...@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
> >>> >> >> >>>> >>> >> >> >>> >> >> >
> >>> >> >> >>>> >>> >> >> >>> >> >
> >>> >> >> >>>> >>> >> >> >>> >> >
> >>> >> >> >>>> >>> >> >> >>> >
> >>> >> >> >>>> >>> >> >> >>> >
> >>> >> >> >>>> >>> >> >> >>
> >>> >> >> >>>> >>> >> >> >>
> >>> >> >> >>>> >>> >> >> >
> >>> >> >> >>>> >>> >> >
> >>> >> >> >>>> >>> >> >
> >>> >> >> >>>> >>> >
> >>> >> >> >>>> >>> >
> >>> >> >> >>>> >>
> >>> >> >> >>>> >>
> >>> >> >> >>>> >
> >>> >> >> >>>
> >>> >> >> >>>
> >>> >> >> >>
> >>> >> >> >
> >>> >> >
> >>> >> >
> >>> >
> >>> >
> >>
> >>
> >
>
Re: Which version of Solr have implements the Document Level Access Control
Posted by Karl Wright <da...@gmail.com>.
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 <da...@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 <at...@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 <da...@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 <at...@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 <da...@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 <at...@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 <da...@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 <da...@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 <da...@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
>>> >> >> >> <at...@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 <da...@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
>>> >> >> >>>> <da...@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
>>> >> >> >>>> > <at...@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
>>> >> >> >>>> >> <da...@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
>>> >> >> >>>> >>> <at...@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
>>> >> >> >>>> >>> > <da...@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
>>> >> >> >>>> >>> >> <at...@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
>>> >> >> >>>> >>> >> > <da...@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
>>> >> >> >>>> >>> >> >> <da...@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
>>> >> >> >>>> >>> >> >> > <at...@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
>>> >> >> >>>> >>> >> >> >> <da...@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
>>> >> >> >>>> >>> >> >> >>> <at...@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
>>> >> >> >>>> >>> >> >> >>> > <da...@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
>>> >> >> >>>> >>> >> >> >>> >> <at...@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
>>> >> >> >>>> >>> >> >> >>> >> > <da...@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
>>> >> >> >>>> >>> >> >> >>> >> >> <at...@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
>>> >> >> >>>> >>> >> >> >>> >> >> >
>>> >> >> >>>> >>> >> >> >>> >> >
>>> >> >> >>>> >>> >> >> >>> >> >
>>> >> >> >>>> >>> >> >> >>> >
>>> >> >> >>>> >>> >> >> >>> >
>>> >> >> >>>> >>> >> >> >>
>>> >> >> >>>> >>> >> >> >>
>>> >> >> >>>> >>> >> >> >
>>> >> >> >>>> >>> >> >
>>> >> >> >>>> >>> >> >
>>> >> >> >>>> >>> >
>>> >> >> >>>> >>> >
>>> >> >> >>>> >>
>>> >> >> >>>> >>
>>> >> >> >>>> >
>>> >> >> >>>
>>> >> >> >>>
>>> >> >> >>
>>> >> >> >
>>> >> >
>>> >> >
>>> >
>>> >
>>
>>
>
Re: Which version of Solr have implements the Document Level Access Control
Posted by Karl Wright <da...@gmail.com>.
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 <at...@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 <da...@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 <at...@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 <da...@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 <at...@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 <da...@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 <da...@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 <da...@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
>> >> >> >> <at...@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 <da...@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
>> >> >> >>>> <da...@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
>> >> >> >>>> > <at...@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
>> >> >> >>>> >> <da...@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
>> >> >> >>>> >>> <at...@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
>> >> >> >>>> >>> > <da...@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
>> >> >> >>>> >>> >> <at...@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
>> >> >> >>>> >>> >> > <da...@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
>> >> >> >>>> >>> >> >> <da...@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
>> >> >> >>>> >>> >> >> > <at...@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
>> >> >> >>>> >>> >> >> >> <da...@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
>> >> >> >>>> >>> >> >> >>> <at...@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
>> >> >> >>>> >>> >> >> >>> > <da...@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
>> >> >> >>>> >>> >> >> >>> >> <at...@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
>> >> >> >>>> >>> >> >> >>> >> > <da...@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
>> >> >> >>>> >>> >> >> >>> >> >> <at...@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
>> >> >> >>>> >>> >> >> >>> >> >> >
>> >> >> >>>> >>> >> >> >>> >> >
>> >> >> >>>> >>> >> >> >>> >> >
>> >> >> >>>> >>> >> >> >>> >
>> >> >> >>>> >>> >> >> >>> >
>> >> >> >>>> >>> >> >> >>
>> >> >> >>>> >>> >> >> >>
>> >> >> >>>> >>> >> >> >
>> >> >> >>>> >>> >> >
>> >> >> >>>> >>> >> >
>> >> >> >>>> >>> >
>> >> >> >>>> >>> >
>> >> >> >>>> >>
>> >> >> >>>> >>
>> >> >> >>>> >
>> >> >> >>>
>> >> >> >>>
>> >> >> >>
>> >> >> >
>> >> >
>> >> >
>> >
>> >
>
>
Re: Which version of Solr have implements the Document Level Access Control
Posted by Kadri Atalay <at...@gmail.com>.
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 <da...@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 <at...@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 <da...@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 <at...@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 <da...@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 <da...@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 <da...@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
> >> >> >> <at...@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 <da...@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
> >> >> >>>> > <at...@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
> >> >> >>>> >> <da...@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
> >> >> >>>> >>> <at...@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
> >> >> >>>> >>> > <da...@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
> >> >> >>>> >>> >> <at...@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
> >> >> >>>> >>> >> > <da...@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
> >> >> >>>> >>> >> >> <da...@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
> >> >> >>>> >>> >> >> > <at...@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
> >> >> >>>> >>> >> >> >> <da...@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
> >> >> >>>> >>> >> >> >>> <at...@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
> >> >> >>>> >>> >> >> >>> > <da...@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
> >> >> >>>> >>> >> >> >>> >> <at...@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
> >> >> >>>> >>> >> >> >>> >> > <da...@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
> >> >> >>>> >>> >> >> >>> >> >> <at...@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
> >> >> >>>> >>> >> >> >>> >> >> >
> >> >> >>>> >>> >> >> >>> >> >
> >> >> >>>> >>> >> >> >>> >> >
> >> >> >>>> >>> >> >> >>> >
> >> >> >>>> >>> >> >> >>> >
> >> >> >>>> >>> >> >> >>
> >> >> >>>> >>> >> >> >>
> >> >> >>>> >>> >> >> >
> >> >> >>>> >>> >> >
> >> >> >>>> >>> >> >
> >> >> >>>> >>> >
> >> >> >>>> >>> >
> >> >> >>>> >>
> >> >> >>>> >>
> >> >> >>>> >
> >> >> >>>
> >> >> >>>
> >> >> >>
> >> >> >
> >> >
> >> >
> >
> >
>
Re: Which version of Solr have implements the Document Level Access Control
Posted by Karl Wright <da...@gmail.com>.
I thought you were using the Quick Start, whcih does not have a sync directory.
Karl
On Tue, May 3, 2011 at 6:16 PM, Kadri Atalay <at...@gmail.com> wrote:
> Note:
> Did that, still didn't helped, but deleting the contents of mysyncdir
> worked.
>
> On Tue, May 3, 2011 at 5:48 PM, Karl Wright <da...@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 <at...@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 <da...@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 <at...@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 <da...@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 <da...@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 <da...@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
>> >> >> >> <at...@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 <da...@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
>> >> >> >>>> <da...@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
>> >> >> >>>> > <at...@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
>> >> >> >>>> >> <da...@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
>> >> >> >>>> >>> <at...@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
>> >> >> >>>> >>> > <da...@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
>> >> >> >>>> >>> >> <at...@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
>> >> >> >>>> >>> >> > <da...@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
>> >> >> >>>> >>> >> >> <da...@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
>> >> >> >>>> >>> >> >> > <at...@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
>> >> >> >>>> >>> >> >> >> <da...@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
>> >> >> >>>> >>> >> >> >>> <at...@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
>> >> >> >>>> >>> >> >> >>> > <da...@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
>> >> >> >>>> >>> >> >> >>> >> <at...@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
>> >> >> >>>> >>> >> >> >>> >> > <da...@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
>> >> >> >>>> >>> >> >> >>> >> >> <at...@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
>> >> >> >>>> >>> >> >> >>> >> >> >
>> >> >> >>>> >>> >> >> >>> >> >
>> >> >> >>>> >>> >> >> >>> >> >
>> >> >> >>>> >>> >> >> >>> >
>> >> >> >>>> >>> >> >> >>> >
>> >> >> >>>> >>> >> >> >>
>> >> >> >>>> >>> >> >> >>
>> >> >> >>>> >>> >> >> >
>> >> >> >>>> >>> >> >
>> >> >> >>>> >>> >> >
>> >> >> >>>> >>> >
>> >> >> >>>> >>> >
>> >> >> >>>> >>
>> >> >> >>>> >>
>> >> >> >>>> >
>> >> >> >>>
>> >> >> >>>
>> >> >> >>
>> >> >> >
>> >> >
>> >> >
>> >
>> >
>
>
Re: Which version of Solr have implements the Document Level Access Control
Posted by Kadri Atalay <at...@gmail.com>.
Note:
Did that, still didn't helped, but deleting the contents of mysyncdir
worked.
On Tue, May 3, 2011 at 5:48 PM, Karl Wright <da...@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 <at...@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 <da...@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 <at...@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 <da...@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 <da...@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 <da...@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
> >> >> >> <at...@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 <da...@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
> >> >> >>>> > <at...@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
> >> >> >>>> >> <da...@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
> >> >> >>>> >>> <at...@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
> >> >> >>>> >>> > <da...@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
> >> >> >>>> >>> >> <at...@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
> >> >> >>>> >>> >> > <da...@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
> >> >> >>>> >>> >> >> <da...@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
> >> >> >>>> >>> >> >> > <at...@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
> >> >> >>>> >>> >> >> >> <da...@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
> >> >> >>>> >>> >> >> >>> <at...@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
> >> >> >>>> >>> >> >> >>> > <da...@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
> >> >> >>>> >>> >> >> >>> >> <at...@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
> >> >> >>>> >>> >> >> >>> >> > <da...@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
> >> >> >>>> >>> >> >> >>> >> >> <at...@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
> >> >> >>>> >>> >> >> >>> >> >> >
> >> >> >>>> >>> >> >> >>> >> >
> >> >> >>>> >>> >> >> >>> >> >
> >> >> >>>> >>> >> >> >>> >
> >> >> >>>> >>> >> >> >>> >
> >> >> >>>> >>> >> >> >>
> >> >> >>>> >>> >> >> >>
> >> >> >>>> >>> >> >> >
> >> >> >>>> >>> >> >
> >> >> >>>> >>> >> >
> >> >> >>>> >>> >
> >> >> >>>> >>> >
> >> >> >>>> >>
> >> >> >>>> >>
> >> >> >>>> >
> >> >> >>>
> >> >> >>>
> >> >> >>
> >> >> >
> >> >
> >> >
> >
> >
>
Re: Which version of Solr have implements the Document Level Access Control
Posted by Karl Wright <da...@gmail.com>.
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 <at...@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 <da...@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 <at...@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 <da...@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 <da...@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 <da...@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
>> >> >> <at...@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 <da...@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 <da...@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
>> >> >>>> > <at...@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
>> >> >>>> >> <da...@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
>> >> >>>> >>> <at...@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
>> >> >>>> >>> > <da...@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
>> >> >>>> >>> >> <at...@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
>> >> >>>> >>> >> > <da...@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
>> >> >>>> >>> >> >> <da...@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
>> >> >>>> >>> >> >> > <at...@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
>> >> >>>> >>> >> >> >> <da...@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
>> >> >>>> >>> >> >> >>> <at...@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
>> >> >>>> >>> >> >> >>> > <da...@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
>> >> >>>> >>> >> >> >>> >> <at...@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
>> >> >>>> >>> >> >> >>> >> > <da...@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
>> >> >>>> >>> >> >> >>> >> >> <at...@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
>> >> >>>> >>> >> >> >>> >> >> >
>> >> >>>> >>> >> >> >>> >> >
>> >> >>>> >>> >> >> >>> >> >
>> >> >>>> >>> >> >> >>> >
>> >> >>>> >>> >> >> >>> >
>> >> >>>> >>> >> >> >>
>> >> >>>> >>> >> >> >>
>> >> >>>> >>> >> >> >
>> >> >>>> >>> >> >
>> >> >>>> >>> >> >
>> >> >>>> >>> >
>> >> >>>> >>> >
>> >> >>>> >>
>> >> >>>> >>
>> >> >>>> >
>> >> >>>
>> >> >>>
>> >> >>
>> >> >
>> >
>> >
>
>
Re: Which version of Solr have implements the Document Level Access Control
Posted by Kadri Atalay <at...@gmail.com>.
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 <da...@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 <at...@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 <da...@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 <da...@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 <da...@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 <da...@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 <da...@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
> >> >>>> > <at...@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
> >> >>>> >>> <at...@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
> >> >>>> >>> > <da...@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
> >> >>>> >>> >> <at...@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
> >> >>>> >>> >> > <da...@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
> >> >>>> >>> >> >> <da...@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
> >> >>>> >>> >> >> > <at...@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
> >> >>>> >>> >> >> >> <da...@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
> >> >>>> >>> >> >> >>> <at...@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
> >> >>>> >>> >> >> >>> > <da...@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
> >> >>>> >>> >> >> >>> >> <at...@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
> >> >>>> >>> >> >> >>> >> > <da...@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
> >> >>>> >>> >> >> >>> >> >> <at...@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
> >> >>>> >>> >> >> >>> >> >> >
> >> >>>> >>> >> >> >>> >> >
> >> >>>> >>> >> >> >>> >> >
> >> >>>> >>> >> >> >>> >
> >> >>>> >>> >> >> >>> >
> >> >>>> >>> >> >> >>
> >> >>>> >>> >> >> >>
> >> >>>> >>> >> >> >
> >> >>>> >>> >> >
> >> >>>> >>> >> >
> >> >>>> >>> >
> >> >>>> >>> >
> >> >>>> >>
> >> >>>> >>
> >> >>>> >
> >> >>>
> >> >>>
> >> >>
> >> >
> >
> >
>
Re: Which version of Solr have implements the Document Level Access Control
Posted by Karl Wright <da...@gmail.com>.
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 <at...@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 <da...@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 <da...@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 <da...@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 <at...@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 <da...@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 <da...@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
>> >>>> > <at...@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 <da...@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
>> >>>> >>> <at...@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
>> >>>> >>> > <da...@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
>> >>>> >>> >> <at...@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
>> >>>> >>> >> > <da...@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
>> >>>> >>> >> >> <da...@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
>> >>>> >>> >> >> > <at...@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
>> >>>> >>> >> >> >> <da...@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
>> >>>> >>> >> >> >>> <at...@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
>> >>>> >>> >> >> >>> > <da...@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
>> >>>> >>> >> >> >>> >> <at...@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
>> >>>> >>> >> >> >>> >> > <da...@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
>> >>>> >>> >> >> >>> >> >> <at...@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
>> >>>> >>> >> >> >>> >> >> >
>> >>>> >>> >> >> >>> >> >
>> >>>> >>> >> >> >>> >> >
>> >>>> >>> >> >> >>> >
>> >>>> >>> >> >> >>> >
>> >>>> >>> >> >> >>
>> >>>> >>> >> >> >>
>> >>>> >>> >> >> >
>> >>>> >>> >> >
>> >>>> >>> >> >
>> >>>> >>> >
>> >>>> >>> >
>> >>>> >>
>> >>>> >>
>> >>>> >
>> >>>
>> >>>
>> >>
>> >
>
>
Re: Which version of Solr have implements the Document Level Access Control
Posted by Kadri Atalay <at...@gmail.com>.
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 <da...@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 <da...@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 <da...@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 <at...@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 <da...@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 <da...@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 <da...@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
> >>>> >>> >> <at...@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
> >>>> >>> >> > <da...@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
> >>>> >>> >> >> <da...@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
> >>>> >>> >> >> > <at...@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
> >>>> >>> >> >> >> <da...@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
> >>>> >>> >> >> >>> <at...@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
> >>>> >>> >> >> >>> > <da...@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
> >>>> >>> >> >> >>> >> <at...@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
> >>>> >>> >> >> >>> >> > <da...@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
> >>>> >>> >> >> >>> >> >> <at...@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
> >>>> >>> >> >> >>> >> >> >
> >>>> >>> >> >> >>> >> >
> >>>> >>> >> >> >>> >> >
> >>>> >>> >> >> >>> >
> >>>> >>> >> >> >>> >
> >>>> >>> >> >> >>
> >>>> >>> >> >> >>
> >>>> >>> >> >> >
> >>>> >>> >> >
> >>>> >>> >> >
> >>>> >>> >
> >>>> >>> >
> >>>> >>
> >>>> >>
> >>>> >
> >>>
> >>>
> >>
> >
>
Re: Which version of Solr have implements the Document Level Access Control
Posted by Karl Wright <da...@gmail.com>.
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 <da...@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 <da...@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 <da...@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 <at...@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 <da...@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 <da...@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 <at...@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 <da...@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 <at...@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 <da...@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
>>>>> >>> >> <at...@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
>>>>> >>> >> > <da...@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
>>>>> >>> >> >> <da...@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
>>>>> >>> >> >> > <at...@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
>>>>> >>> >> >> >> <da...@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
>>>>> >>> >> >> >>> <at...@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
>>>>> >>> >> >> >>> > <da...@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
>>>>> >>> >> >> >>> >> <at...@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
>>>>> >>> >> >> >>> >> > <da...@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
>>>>> >>> >> >> >>> >> >> <at...@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
>>>>> >>> >> >> >>> >> >> >
>>>>> >>> >> >> >>> >> >
>>>>> >>> >> >> >>> >> >
>>>>> >>> >> >> >>> >
>>>>> >>> >> >> >>> >
>>>>> >>> >> >> >>
>>>>> >>> >> >> >>
>>>>> >>> >> >> >
>>>>> >>> >> >
>>>>> >>> >> >
>>>>> >>> >
>>>>> >>> >
>>>>> >>
>>>>> >>
>>>>> >
>>>>
>>>>
>>>
>>
>
Re: Which version of Solr have implements the Document Level Access Control
Posted by Karl Wright <da...@gmail.com>.
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 <da...@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 <da...@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 <at...@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 <da...@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 <da...@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 <at...@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 <da...@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 <at...@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 <da...@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
>>>> >>> >> <at...@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
>>>> >>> >> > <da...@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
>>>> >>> >> >> <da...@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
>>>> >>> >> >> > <at...@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
>>>> >>> >> >> >> <da...@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
>>>> >>> >> >> >>> <at...@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
>>>> >>> >> >> >>> > <da...@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
>>>> >>> >> >> >>> >> <at...@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
>>>> >>> >> >> >>> >> > <da...@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
>>>> >>> >> >> >>> >> >> <at...@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
>>>> >>> >> >> >>> >> >> >
>>>> >>> >> >> >>> >> >
>>>> >>> >> >> >>> >> >
>>>> >>> >> >> >>> >
>>>> >>> >> >> >>> >
>>>> >>> >> >> >>
>>>> >>> >> >> >>
>>>> >>> >> >> >
>>>> >>> >> >
>>>> >>> >> >
>>>> >>> >
>>>> >>> >
>>>> >>
>>>> >>
>>>> >
>>>
>>>
>>
>
Re: Which version of Solr have implements the Document Level Access Control
Posted by Karl Wright <da...@gmail.com>.
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 <da...@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 <at...@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 <da...@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 <da...@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 <at...@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 <da...@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 <at...@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 <da...@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
>>> >>> >> <at...@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
>>> >>> >> > <da...@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
>>> >>> >> >> <da...@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
>>> >>> >> >> > <at...@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
>>> >>> >> >> >> <da...@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
>>> >>> >> >> >>> <at...@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
>>> >>> >> >> >>> > <da...@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
>>> >>> >> >> >>> >> <at...@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
>>> >>> >> >> >>> >> > <da...@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
>>> >>> >> >> >>> >> >> <at...@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
>>> >>> >> >> >>> >> >> >
>>> >>> >> >> >>> >> >
>>> >>> >> >> >>> >> >
>>> >>> >> >> >>> >
>>> >>> >> >> >>> >
>>> >>> >> >> >>
>>> >>> >> >> >>
>>> >>> >> >> >
>>> >>> >> >
>>> >>> >> >
>>> >>> >
>>> >>> >
>>> >>
>>> >>
>>> >
>>
>>
>
Re: Which version of Solr have implements the Document Level Access Control
Posted by Karl Wright <da...@gmail.com>.
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 <at...@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 <da...@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 <da...@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 <at...@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 <da...@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 <at...@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 <da...@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
>> >>> >> <at...@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
>> >>> >> > <da...@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
>> >>> >> >> <da...@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
>> >>> >> >> > <at...@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
>> >>> >> >> >> <da...@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
>> >>> >> >> >>> <at...@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
>> >>> >> >> >>> > <da...@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
>> >>> >> >> >>> >> <at...@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
>> >>> >> >> >>> >> > <da...@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
>> >>> >> >> >>> >> >> <at...@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
>> >>> >> >> >>> >> >> >
>> >>> >> >> >>> >> >
>> >>> >> >> >>> >> >
>> >>> >> >> >>> >
>> >>> >> >> >>> >
>> >>> >> >> >>
>> >>> >> >> >>
>> >>> >> >> >
>> >>> >> >
>> >>> >> >
>> >>> >
>> >>> >
>> >>
>> >>
>> >
>
>
Re: Which version of Solr have implements the Document Level Access Control
Posted by Karl Wright <da...@gmail.com>.
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 <da...@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 <at...@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 <da...@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 <at...@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 <da...@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 <at...@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 <da...@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 <da...@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
>>> >> >> > <at...@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
>>> >> >> >> <da...@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
>>> >> >> >>> <at...@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
>>> >> >> >>> > <da...@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
>>> >> >> >>> >> <at...@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
>>> >> >> >>> >> > <da...@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
>>> >> >> >>> >> >> <at...@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
>>> >> >> >>> >> >> >
>>> >> >> >>> >> >
>>> >> >> >>> >> >
>>> >> >> >>> >
>>> >> >> >>> >
>>> >> >> >>
>>> >> >> >>
>>> >> >> >
>>> >> >
>>> >> >
>>> >
>>> >
>>
>>
>
Re: Which version of Solr have implements the Document Level Access Control
Posted by Karl Wright <da...@gmail.com>.
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 <at...@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 <da...@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 <at...@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 <da...@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 <at...@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 <da...@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 <da...@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
>> >> >> > <at...@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
>> >> >> >> <da...@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
>> >> >> >>> <at...@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
>> >> >> >>> > <da...@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
>> >> >> >>> >> <at...@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
>> >> >> >>> >> > <da...@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
>> >> >> >>> >> >> <at...@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
>> >> >> >>> >> >> >
>> >> >> >>> >> >
>> >> >> >>> >> >
>> >> >> >>> >
>> >> >> >>> >
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >
>> >> >
>> >
>> >
>
>
Re: Which version of Solr have implements the Document Level Access Control
Posted by Kadri Atalay <at...@gmail.com>.
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 <da...@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 <at...@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 <da...@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 <at...@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 <da...@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 <da...@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
> >> >> > <at...@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
> >> >> >>> <at...@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
> >> >> >>> >> <at...@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
> >> >> >>> >> > <da...@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
> >> >> >>> >> >> <at...@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
> >> >> >>> >> >> >
> >> >> >>> >> >
> >> >> >>> >> >
> >> >> >>> >
> >> >> >>> >
> >> >> >>
> >> >> >>
> >> >> >
> >> >
> >> >
> >
> >
>
Re: Which version of Solr have implements the Document Level Access Control
Posted by Karl Wright <da...@gmail.com>.
"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 <at...@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 <da...@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 <at...@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 <da...@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 <da...@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
>> >> > <at...@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 <da...@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
>> >> >>> <at...@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 <da...@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
>> >> >>> >> <at...@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
>> >> >>> >> > <da...@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
>> >> >>> >> >> <at...@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
>> >> >>> >> >> >
>> >> >>> >> >
>> >> >>> >> >
>> >> >>> >
>> >> >>> >
>> >> >>
>> >> >>
>> >> >
>> >
>> >
>
>