user wants to apply a quite complex "User Search Filter" in his LDAP Configuration - ldap

user have to apply a quite complex "User Search Filter" in his LDAP Configuration.
The filter is too big and exceed the 256 allowed character. For customer business policy is not possible to modify the LDAP structure or data How can we proceed?
Here there is a sample of the filter:
(&
(|
(memberOf=CN=Applicazione_DocB_AmmApplicativo,OU=Intranet,OU=Gruppi,DC=CBMAIN,DC=CBDOM,DC=IT)
(memberOf=CN=Applicazione_DocB_AmmPiattaforma,OU=Intranet,OU=Gruppi,DC=CBMAIN,DC=CBDOM,DC=IT)
(memberOf=CN=Applicazione_DocB_ArchFIRead,OU=Intranet,OU=Gruppi,DC=CBMAIN,DC=CBDOM,DC=IT)
(memberOf=CN=Applicazione_DocB_ArchFIWrite,OU=Intranet,OU=Gruppi,DC=CBMAIN,DC=CBDOM,DC=IT)
(memberOf=CN=Applicazione_DocB_AreaFinanza,OU=Intranet,OU=Gruppi,DC=CBMAIN,DC=CBDOM,DC=IT)
(memberOf=CN=Applicazione_DocB_Arm,OU=Intranet,OU=Gruppi,DC=CBMAIN,DC=CBDOM,DC=IT)
(memberOf=CN=Applicazione_DocB_BoGestCanc,OU=Intranet,OU=Gruppi,DC=CBMAIN,DC=CBDOM,DC=IT)
(memberOf=CN=Applicazione_DocB_BoUpdDocum,OU=Intranet,OU=Gruppi,DC=CBMAIN,DC=CBDOM,DC=IT)
(memberOf=CN=Applicazione_DocB_Crif,OU=Intranet,OU=Gruppi,DC=CBMAIN,DC=CBDOM,DC=IT)
(memberOf=CN=Applicazione_DocB_VisualBase,OU=Intranet,OU=Gruppi,DC=CBMAIN,DC=CBDOM,DC=IT)
(memberOf=CN=Applicazione_DocB_VisualEsteso,OU=Intranet,OU=Gruppi,DC=CBMAIN,DC=CBDOM,DC=IT)
)(|
(userAccountControl=512)
(userAccountControl=544)
(userAccountControl=66048)
)
)

Have the customer create one single group to control access to the application, then they can add all of those groups to that one group. Then you only need to look at that one group. However, you will need to use the LDAP_MATCHING_RULE_IN_CHAIN operator so that it will look at the members of nested groups.
If the name of that new group is Applicazione_DocB, that would look something like this:
(memberOf:1.2.840.113556.1.4.1941:=CN=Applicazione_DocB,OU=Intranet,OU=Gruppi,DC=CBMAIN,DC=CBDOM,DC=IT)
Your conditions on userAccountControl can also be simplified. That attribute is a bit flag, which means that each bit in the binary value is a flag that means something. Those values are listed in the documentation for userAccountControl. The three conditions you are using are:
512: ADS_UF_NORMAL_ACCOUNT
544: ADS_UF_NORMAL_ACCOUNT | ADS_UF_PASSWD_NOTREQD (password not required)
66048: ADS_UF_NORMAL_ACCOUNT | ADS_UF_DONT_EXPIRE_PASSWD (password does not expire)
If the intent is to exclude disabled accounts (514: ADS_UF_NORMAL_ACCOUNT | ADS_UF_ACCOUNTDISABLE), then you can do that by using the LDAP_MATCHING_RULE_BIT_AND operator to check if the second bit is not set (which indicates a disabled account), like this:
(!userAccountControl:1.2.840.113556.1.4.803:=2)
Putting that all together, you get a query that is less than 256 characters:
(&(memberOf:1.2.840.113556.1.4.1941:=CN=Applicazione_DocB,OU=Intranet,OU=Gruppi,DC=CBMAIN,DC=CBDOM,DC=IT)(!userAccountControl:1.2.840.113556.1.4.803:=2))

Related

LDAP Filter Syntax Query

What would be the syntax for LDAP for the below scenario:
Where sAMAccountName = GRA-* without $. I want the records which are highlighted in green.
This is my current LADP Filter for your reference:
(&(objectClass=user)sAMAccountName=GRA-*))
Anyone, Please help with the correct syntax.
Your filter can work, but you're missing a ( in front of sAMAccountName:
(&(objectClass=user)(sAMAccountName=GRA-*))
But you may be able to do better. If those ones that end in $ are computer objects (which always have sAMAccountNames that end in $, but also have an objectClass of user), then you can make sure you only get user objects by including (objectCategory=person):
(&(objectClass=user)(objectCategory=person)(sAMAccountName=GRA-*))
If, for whatever reason, those $ objects are actually user accounts, then you can exclude them with (!sAMAccountName=*$):
(&(objectClass=user)(objectCategory=person)(sAMAccountName=GRA-*)(!sAMAccountName=*$))

LDAP Query for both mail-enabled security groups and distribution mail groups

We have some security groups that are mail enabled. Because of that , I need a query within ADUC that will give me a list of all my mail-enabled security groups and distribution mail groups.
I am able to getting distribution mail groups LDAP query like below.
(&(&(&(objectClass=group)(!(groupType:1.2.840.113556.1.4.803:=2147483648)))))
Wrapped for legibility (put it back in a single line for use in Active Directory Users and Computers):
(&
(objectClass=group)
(|
(&
(groupType:1.2.840.113556.1.4.803:=2147483648)
(mail=*)
)
(!
(groupType:1.2.840.113556.1.4.803:=2147483648)
)
)
)
In English:
The objectClass is "group", AND
the groupType is "security" AND mail is set, OR
the groupType is NOT "security".
But I assume something simple like the following would also work - after all, you are looking for groups that have an email address. The group type is completely irrelevant.
(&
(objectClass=group)
(mail=*)
)

Using wildcard and required operator in an Elasticsearch search

We have various rows inside our Elasticsearch index that contain the text
"... 2% milk ...".
User enters a query like "2% milk" into a search field and we transform it internally to a query
title:(+milk* +2%*)
because all terms should be required and we are possibly interested into rows that contain "2% milkfat".
This query above return zero hits. Changing the query to
title:(+milk* +2%)
returns reasonable results. So why does the '*' operator in the first query not work?
Unless you set a mapping, the "%" sign will get removed in the tokenization process. Basically "2% milk" will get turned into the tokens 2 and milk.
When you search for "2%*" it looks for tokens like: 2%, 2%a, 2%b, etc... and not match any indexed tokens, giving no hits.
When you search for "2%", it will go through the same tokenization process as at index-time (you can specify this, but the default tokenization is the same) and you will be looking for documents matching the token 2, which will give you a hit.
You can read more about the analysis/tokenization process here and you can set up the analysis you want by defining a custom mapping
Good luck!
Prefix and Wildcard queries do not appear to apply the Analyzer to their content. To provide a few examples:
title:(+milk* +2%) --> +title:milk* +title:2
title:(+milk* +2%*) --> +title:milk* +title:2%*
title:(+milk* +2%3) --> +title:milk* +(title:2 title:3)
title:(+milk* +2%3*) --> +title:milk* +title:2%3*
+title:super\\-milk --> +title:super title:milk
+title:super\\-milk* --> +title:super-milk*
It does make some sense to prevent tokenization of wildcard queries, since wildcard phrase queries are not allowed. If tokenization were allowed, it would seem to beg the question, especially with embeded wildcards, of just how many terms that wildcard can span.

Is there a way to do an LDAP query to get records where a particular attribute is the same?

I am trying to find an example LDAP query where I can find records where a particular attribute matches one or more other records. For instance, a user object where the userid is different, but the employee ids are the same. Is this even possible?
From a single LDAP query no. Unless you know the emplyeeID value you are looking for.
We created an LDAP tool, Duplicate Attribute Value Locater Tool, that will do this.
-jim
It's not possible to do sub queries within the filter itself. In this case, as long as I understand correctly, you'd like to find users that match :
objectClass of User
match on the value of employeeID
Out of the above subset, find all with a DISTINCT 'userid'
If you knew what userid to look for, or NOT look for, you could expand the inital AND clause to include finding, or not finding, that attribute :
userid not equal to 12345 :
(&(objectClass=person)(employeeID=JSmith)(!(userid=12345)))
userid equal to 12345 :
(&(objectClass=person)(employeeID=JSmith)(userid=12345)
I found this example for 'myattribute'. Needs some polish, and depending on the size of your directory, it could take a while to run. If that's the case, I'd break it up by attribute sections {attr=aa*, attr=ab*, attr=ac*, etc.}.
ldapsearch -x -h ldapserver.domain.com -b ou=myldap,o=mydomain.com "(&(myattribute=aa*))" myattribute | grep '^myattribute:' | sort | uniq -c| sort -n|awk '$1 > 1 { print }'

Using DN in Search Filter

In my LDAP Client program sometimes I have to include the DN value within the search filter. But this DN is changing frequently and every I have to change this filter in my code.
When I googled it for that I got something like this
Suppose you want to pull all users of ObjectType = Person from the R&D and HR ous, but not any users from Marketing and PM. The filter would be:
(&(objectClass=person)(|(ou:dn:=ResearchAndDevelopment)(ou:dn:=HumanResources)))
Can anybody explain this more in detail?
You should check RFC 2254 (The String Representation of LDAP Search Filters).
LDAP filters use polish notation for the boolean operators. So the operator is written before its operands:
(&(condition1)(condition2)(condition3)...)
The example above means that you want all LDAP entries which satisfy condition1 AND condition2 AND condition3 and so on.
Then there are condition themselves. They are very simple and can consist only of few types:
present condition - (attrName=*)
simple condition - (attrName>=value) / (attrName<=value) / (attrNamevalue=value) / (attrName~=value)
substring condition - (attrName=*value*) / (attrName=*value) / (attrName=value*)
extensible condition - (attrName:dn:=value) / (attrName:matchingRule:=value)
The extensible condition with the :dn: keyword means, that you want attributes from the entry DN to be considered as well. So for your case entry cn=John Doe,ou=HumanResources,ou=Users,dc=example,dc=com would match the filter (ou:dn:=HumanResource).
Translating your example filter to an English sentence would be:
Find me all LDAP entries which have objectClass equal to person and have either ResearchAndDevelopment or HumanResources in their ou attribute or somewhere on their DN.
You can use dn into base and set search scope as base.
That is, set dn value into base, and set search scope as base(search scope is one of base, sub and one).
If you really need to search by the whole DN, you can search with:
(distinguishedName=CN=MyCommonName,OU=SomeEnv,...,DC=SomeDir)