how will be the query if I want only users from OU's having name started with "sales".
for example:
(&(objectCategory=person))
Generally speaking there are no ways to query users by their OU name, because a) users do not usually contain any knowledge about OU they belong to (unlike groups membership for example) and therefore nothing can be added to filter b) LDAP filters are quite limited and there are no such thing as sub-filter or sub-query.
Partial solution of the problem could be setting ldap_search's BaseDN parameter to OU path.
More complex queries are usually handled with help of some kind of client side code.
It looks like you are working on Active Directory, and I'am not sure that it works. But on pure LDAP implementation exists a feature called ExtensibleMatch wich seems to be correctly explained in this wiki article . You will also found something helpfull examples here.
Active directory seems not to support this.
JP
Objects in the directory database have associated with them an attribute objectClass which values determine which attributes must or may be included in the object. The organizationalPerson and its descendant inetOrgPerson allow the inclusion of the ou attribute in the object. If your application requires locating objects that have an ou attribute with a particular value, include the ou in an equality filter:
(ou=organization name)
or to limit the objects returned from the search request to those with an ou attribute of the exact case, use an extensible match filter (professional quality servers that are LDAP compliant support the extensible match filter):
(ou:caseExactMatch:=Organization Name)
or to make a similar determination if the object is subordinate to an ou, that is, the entry's DN is something like uid=user.0,ou=people,dc=example,dc=com use an extensible match filter that includes the DN:
(ou:dn:caseExactMatch:=people)
or to determine which objects have the attribute ou use a "presence filter":
(ou=*)
All of the above techniques most likely require that the ou attribute be indexed. See "Using ldapsearch" for more general information about search requests and responses.
Related
To reduce clutter in a selector GUI element I need a way to
tell OUs that ship with AD and Exchange by default (builtins, schema
defined, security or whatever) from such that the admin
created to organize their domain. E. g. the filter should
ignore OUs like:
OU=Domain Controllers,DC=example,DC=com
OU=Microsoft Exchange Security Groups,DC=example,DC=com
and only let those pass that were manually added.
So far I’ve been investigating the bits in the systemFlags:
attribute.
The values are inconclusive though as some bits e. g. non-removability
are set for basic AD objects but don’t appear so for objects added
by Exchange.
I’m not sure if the attribute itself can be present in user
defined OUs. If not, that would be a sufficient signal to
base the filter on. [MS-ADTS] lists it as optional though.
You can't filter by OU in an LDAP query, since a query cannot do partial matches on the distinguishedName (e.g. this won't work: (!disginguishedName=*OU=Domain Controllers*))
If you want to exclude objects in certain OUs, you have two options:
Do it after the query, in your own code, where you can do partial comparisons on the distinguishedName, or
Make separate searches in the OUs that you do want. You can set the search root in each query to the OU you want, then repeat that for every OU you want to include.
Depending what you are trying to search for and the number of results, the first method might be faster than the second.
I would need to retrieve a certain attribute value from AD for a list of persons. Can this be done in one request, or do I need to make as many requests as there are persons for whom this attribute is to be retrieved?
search scope is wholeSubtree
I should also be able to identify the attribute value to its corresponding person.
Transmit a search request to the directory server using the appropriate base object, scope, the list of attribute values required, and a filter that will match all the entries in the list. The directory server will return search results - one for each entry returned, if any - an integer describing the results of the search request, and an integer with the number of entries returned, if any. Each search result will contain the distinguished name of the entry and the attributes that were requested, assuming the access controls for the authorization state of the connection allows the attribute values to be returned.
see also
LDAP: Mastering Search Filters
LDAP: Search best practices
LDAP: Programming practices
I am trying to get all group members from "Domain Users". When using AD Users MMC tab, I get a lot of results. When using ADSI - not. The following DOESN'T work as expected:
looking at members attribute of the group entry via LDAP/ADSI. It returns only 56 members when there are considerably more.
searching by memberOf (returns just a few entries)
searching by primaryGroup (it is not a primary group)
searching by tokenGrops (it is a constructed attribute)
any ideas appreciated.
(I just read more carefully and saw that you mentioend it's not primary group...but I'm suspicious this is the answer anyway :))
There is another mechanism by which a user can be a member of a group, and it's controlled by the primaryGroupID attribute of the user in the group.
If the primaryGroupID of a user is set to some RID of a group, the user is functionally in the group, even though they don't show up in the member attribute of the group. Tools like ADUC are wise enough to look for this. When you step a bit lower in the stack and hit the directory over LDAP, it is up to you to be smart enough to go hunting for it.
You can either do searches for this or use constructed attributes in the directory that take this in to account.
For example I have Documents A, B, C. User 1 must only be able to see Documents A, B. User 2 must only be able to see Document C. Is it possible to do it in SOLR without filtering by metadata? If I use metadata filter, everytime there are access right changes, I have to reindex.
[update 2/14/2012] Unfortunately, in the client's case, change is frequent. Data is confidential and usually only managed by the owners which are internal users. Then the specific case is they need to be able to share those documents to certain external users and specify access levels for those users. And most of the time this is an adhoc task, and not identified ahead of time
I would suggest storing the access roles (yes, its plural) as document metadata. Here the required field access_roles is a facet-able multi-valued string field.
Doc1: access_roles:[user_jane, manager_vienna] // Jane and the Vienna branch manager may see it
Doc2: access_roles:[user_john, manager_vienna, special_team] // Jane, the Vienna branch manager and a member of special team may see it
The user owning the document is a default access role for that document.
To change the access roles of a document, you edit access_roles.
When Jane searches, the access roles she belongs to will be part of the query. Solr will retrieve only the documents that match the user's access role.
When Jane (user_jane), manager at vienna office (manager_vienna) searches, her searches go like:
q=mainquery
&fq=access_roles:user_jane
&fq=access_roles:manager_vienna
&facet=on
&facet.field=access_roles
which fetches all documents which contains user_jane OR manager_vienna in access_roles; Doc1 and Doc2.
When Bob, (user_bob), member of a special team (specia_team) searches,
q=mainquery
&fq=access_roles:user_bob
&fq=access_roles:special_team
&facet=on
&facet.field=access_roles
which fetches Doc2 for him.
Queries adapted from http://wiki.apache.org/solr/SimpleFacetParameters#Multi-Select_Faceting_and_LocalParams
Might want to check the Document level Security patches.
https://issues.apache.org/jira/browse/SOLR-1872
https://issues.apache.org/jira/browse/SOLR-1834
I think my approach would be similar to #aitchnyu's answer. I would however NOT use individual users in the meta data.
If you create groups for each document, then you will have to reindex for security reason less often.
For a given document, you might have access_roles: group_1, group_3
In this way, the group_1 and group_3 always retain rights to the document. However, I can vary what groups each user belongs to and adjust the query accordingly.
When the query then is generated, it always passes as a part of the query the user's groups. If I belong to group_1 and group_2, my query will look like this:
q=mainquery
&fq=access_roles:group_1
&fq=access_roles:group_2
Since the groups are dynamically generated in the query, I simply remove a user from the group, and when a new query is issued, they will no longer include the removed group in the query. So removing the user from group_1 would new create a query like this:
q=mainquery
&fq=access_roles:group_2
All documents that require group 1 will no longer be accessible to the user.
This allows most changes to be done in real-time w/out the need to reindex the documents. The only reason you would have to reindex for security reasons is if you decided that a particular group should no longer have access to a document.
In many real-world scenarios, that should be a relatively uncommon occurrence. It seems much more likely that HR documents will always be available to the HR department, however a specific user may not always be part of the HR group.
Hope that helps.
You can implement your security model using Solr's PostFilter. For more information see http://searchhub.org/2012/02/22/custom-security-filtering-in-solr/
Note: you should probably cache your access rights otherwise performance will be terrible.
Keeping in mind that solr is pure text based search engine,indexing system,to facilitate fast searching, you should not expect RDMS style capabilities from it. solr does not provide security for documents being indexed, you have to write such an implementation if you want. In that case you have two options.
1)Just index documents into solr and keep authorization details into RDBMS.Now query solr for your search and collect the results returned.Now fire another query to DB for the doc ids returned by solr to see if the user has an access to them or not.Filter out those documents on which user in action has no access.You are done ! But not really, your problem starts from here only.Assume, what if all results returned by solr gets filtered out ? (Assuming you are not accessing all the documents at a time,means you are retrieving top 1000 results only from solr result set,otherwise you can not get fast search) You have to query solr again for next bunch of result set and have to iterate these steps until you get enough results to display.
2)Second approach to this is to index authorization meta data along with document in solr.Same as aitchnyu has explained.But to answer your query for document sharing to an external user,along with usergroup and role detail, you index these external user's userid into access_roles field or you can just add an another field to your schema 'access_user' too. Now you can modify search queries for external user's sharing to include access_user field into your filter query.
e.g
q=mainquery
&fq=access_roles:group_1
&fq=access_user:externaluserid
Now the most important thing, update to an indexed documents.Well its off course tedious task, but with careful design and async processing along with solrs partial document update feature(solr 4.0=>), you can achieve reasonably good TPS with solr. If you are using solr <4.0 you can have separate systems for both searching and updates and with care full use of load balancer and master slave replication strategies you will have smile on your face !
There are no built in mechanisms for Solr that I am aware of that will allow you to control access to documents without maintaining the rights in the metadata. The approach outlined by aitchnyu seems reasonable if you keep it a true role level and not assign user specific permissions to a document. That way you can assign roles to users and this will grant them the ability to see documents in the index. Granted you will still need to reindex documents when the roles change, but hopefully you can identify most of the needed roles ahead if time and reduce the need for frequent reindexing.
I am fairly new to LDAP and AD. I want to create an LDAP filter to show all the students in the AD. But the problem is that the students are in different BASE DN:
OU=STUDENTS,OU=USERS,OU=SOE,OU=FOAE,OU=UNIVERSITY,DC=sepang
OU=STUDENTS,OU=USERS,OU=SOMLC,OU=FOAE,OU=UNIVERSITY,DC=sepang
OU=STUDENTS,OU=USERS,OU=SOCS,OU=FOS,OU=UNIVERSITY,DC=sepang
i.e for each student it is like
CN =khx72b,OU=STUDENTS,OU=USERS,OU=SOCS,OU=FOS,OU=UNIVERSITY,DC=sepang
As you can see students from different faculties are in different places.
Given an username how can I search and find if the given user is in the directory?
The objectClass for all the students is 'user'.
As it seems you are searching for objects of type 'user' which are in OUs called 'STUDENTS' but otherwise have no common parent.
This cannot be done in one step (i.e. with a single LDAP query).
You must either retrieve all OUs named 'STUDENTS' and use them as Base DNs one by one, like you've already indicated.
Or you find a property that all students share (a direct group membership, for example, or a special value somewhere) and use that as the filter. This is a more dangerous approach since nothing guarantees that every student actually has the feature you rely on - some might have been not entered into AD correctly.
Tomalak, is right, Microsoft does provide many attributes that you could use for this purpose such as "employeeType", "comment", "department", "company", "department", "divison", etc, but the problem with these is that they are not prepopulated with any information that can help you now. You can start using one of these for future purposes, but then you must maintain that practice in order for it to be consistent. I thing the easiest solution for you is to probably put each of the users into a group that is named similar to the OU name, which should be an really easy task if they're currently in the same OU. then once this is done you can easily create a LDAP query which will then look at the membership of that group like this:
((objectCategory=person)(objectClass=user)(memberOf=CN=STUDENTS GROUP,OU=USERS,OU=SOCS,OU=FOS,OU=UNIVERSITY,DC=sepang))
Please note when using the "memberOf" in an LDAP filter the search value must be a complete string to a group, and so you CAN'T use a wildcard such as: memberOf=CN=STUDENTS GROUP*).
You will still have to maintain a practice that you or someone or something (such as an automated schedule script task) which maintains the group membership to ensure that your LDAP query will be accurate.
I did see this post which says what your trying to do is possible without having to do anything extra by "Matching Components of Distinguished Names", but I have never seen this before and I could not get it to work. Also take a look at this tutorial on ADO searches to learn more about these things work
Search for objects in an OU by setting "searchRoot" to teh LDAP path to the OU. all searches will then be confined to that OU.