I have a series of users and groups. Users' DNs can be added to the group's uniquemember attribute. How can I query LDAP such that I send a user dn and it returns to me the OU of the group that user belongs to?
I am doing this based on the LDAP at ldap.forumsys.com.
See the screenshot below:
Thanks.
What you want is a pretty common equality match filter, for example:
(uniquemember=uid=einstein,dc=example,dc=com)
Note, that the value is not quoted. You only need to escape / replace special characters (e.g. parenthesis). More information about LDAP filter syntax can be found in RFC 4515.
Also keep in mind that LDAP filters are very simple and provide only simple value matching (this can be confusing to people used to SQL and complex queries with joins, subselects, functions, etc.).
Related
I understand you can't simply filter on dn, but I have something like this:
dc=lvl3,dc=lvl2,dc=lvl1, and someone could have a dn like this:
CN=Last, First,OU=ou1,OU=retired,OU=ou1,DC=lvl3,DC=lvl2,DC=lvl1.
Is there a way I can filter results for those who do not have 'retired' in any ou?
No. Not as an LDAP filter.
You could of course do a search and then sort on the CLient-side.
Generally organization of "characteristics" of users should be done using Attributes and not by the Directory Structure.
Something like:
employeeType=Active
employeeType=Retired
employeeType=etc
To avoid these conditions.
Maybe, but it depends on the server's LDAP implementation.
There is a filter syntax which allows matching against DN attributes (in addition to entry attributes):
(ou:dn:=Retired)
(Within the LDAP specification this is known as the 'dnAttributes' field, part of the 'extensibleMatch' filter type. See RFC 4511 section 4.5.1.7.7)
Not all directory servers support this. For example, OpenLDAP handles it correctly, but Active Directory (MS AD and Samba) will ignore it, behaving as if you used (ou=Retired) instead.
If your server supports this, then a negative match is simply done by wrapping the filter in (!(...)) as you would normally do.
However, in other cases you should either a) use a custom attribute, or b) perhaps check for membership in a global "Active employees" group or something similar.
I'm trying to secure a login endpoint by attempting to bypass the login that uses LDAP.
It employs a search query of "cn=" + username + ", dc=example, dc=com" with a filter of "(objectClass=*)".
Is an LDAP injection attack possible here with username? Obviously, I will eventually escape all the queries and filters.
LDAP injection attacks can't do anything useful.
In your case, you're injecting the user input into the base DN (also called "search root") of the search. The base DN must be a valid DN (distinguished name). Any attempt at injecting some clever value there will likely result in something that is not a valid DN, and the search will fail (or return nothing). Even if it did result in a valid DN, I assume you are still asking for the user's password, so they'd have to know the password for that account.
But if you want to prevent that, just replace , in the input to \,. That's likely something you should do anyway, since if the account has a comma in the name, it will be escaped like that in the DN. This is an odd way of doing it though. Usually the base DN would always be the same and you would use the search filter to find the right account (i.e. (&(objectClass=user)(cn={whatever})))
If you are injecting user input into the search filter, the end user could change the query, but there is still nothing useful that can be done since the query can only read values. (although you can still protect against that if you want by escaping ( and ) with \28 and \29)
LDAP queries are not like SQL, where an injection attack can end the SELECT statement and begin another statement.
We have an LDAP with a number of groups that follow this pattern:
Acme-MyApp-ABC-Admin
Acme-MyApp-ABC-Bottlewasher
Acme-MyApp-ABC-Cook
Acme-MyApp-DEF-Admin
Acme-MyApp-DEF-Bottlewasher
Acme-MyApp-DEF-Cook
etc repeated many times.
(&(objectClass=person)(memberOf=cn=Acme-MyApp-ABC-Admin,ou=Groups,dc=acme,dc=com))
correctly returns members of the Acme-MyApp-ABC-Admin group. We'd like to find members of all of the Admin groups.
(&(objectClass=person)(memberOf=cn=*-Admin,ou=Groups,dc=acme,dc=com))
Is it possible to put a wildcard within a DN?
Generally, Wildcard searches on DN's syntax attributes are not supported.
Some LDAP server implementation may support them. You question is tagged as OpenLDAP but the search filter appears to be more like an AD implementation.
I did find "Question about using an LDAP filter to get memberOf from an AD Group" on TechNet stating, ".. that wildcards are no allowed." (I am assuming he met NOT vs no)
-jim
While I do not think that this can be done with the ldap filter directly. I have faced similar requirements many times and my go to method is as following:
Create a group that encapsles all relevant groups, in your case the admin groups.
Acme-MyApp-Admins
Acme-MyApp-ABC-Admin
Acme-MyApp-DEF-Admin
Then setup a filter based on the recursive membership of that group.
(&(objectClass=person)(memberOf:1.2.840.113556.1.4.1941:=CN=Acme-MyApp-Admins,ou=Groups,dc=acme,dc=com))
This way you only need to take care that every new admin group is added as a member of the access group, but you do not need to modify the ldap filter.
I am setting up a software package to work with our LDAP server. Since we have limited licenses, I need to limit what group a user can be a member of to be included. I have a field called LDAP Search Base where I can specify something like this:
(sAMAccountName={0})
The {0} is filled in with the login name. I would like to limit the users to be part of our Development LDAP group, but the memberOf group can have multiple values, Doing something like this:
(&(sAMAccountName={0})(memberOf=*Development*))
doesn't work.
Is there a way to query LDAP to specify that I am looking through all of the values of memberOf looking for a groups that matches *Development*?
Looks like memberOf is a Distinguished name. Substring matches using wildcards are not supported on DNs
This LDAP query successfully enumerates all users within a group:
memberOf=CN=MySubGroup1,OU=MyGroup1,OU=Global Groups,DC=mycompany,DC=com
The group MyGroup1 has two subgroups: MySubGroup1, MySubGroup2.
In order to get all the users of MyGroup1, I could make a query to get the users of MySubGroup1, another query to get the users of MySubGroup1, and then make the union.
However, I am asking how I can achieve the same results with only one LDAP query,
asking for all the users within MyGroup1 and sub-groups.
Any idea?
There is no such thing as a subgroup, just groups. The correct term is subordinate,
i.e., cn=mysubgroup1 is subordinate to ou=mygroup1, and so forth.
Use the following parameters in an LDAP search request:
base object: OU=MyGroup1,OU=Global Groups,DC=mycompany,DC=com
search scope: sub if there is more than one 'level' beneath ou=mygroup1, one otherwise
filter: (|(cn=mysubgroup1)(cn=mysubgroup2))
requested attribute: whichever multi-valued attribute whose value is the distinguished name
of each member of the group
These search request parameters should result in a search result with two entries, the distinguished
of each entry, and the attributes whose values are the distinguished names of the members of each group.
see also
LDAP: Seach best practices
LDAP: Programming practices
If your server is Microsoft Active Directory then you can use some extended rules. One of those rules does basically what you are looking for. Look at this answer.
Try this:
memberof:1.2.840.113556.1.4.1941:=CN=Some Group,OU=My Organization Unit,DC=company,DC=com
Quoting from that answer:
[...] it is possible, when using Microsoft AD LDAP, to do authorization using nested groups by using LDAP_MATCHING_RULE_IN_CHAIN matching rule. This is much faster than searching subgroups on the client, because it is done on the DC server with less queries over network.
1.2.840.113556.1.4.1941 LDAP_MATCHING_RULE_IN_CHAIN This rule is limited to filters that apply to the DN. This is a special "extended match operator that walks the chain of ancestry in objects all the way to the root until it finds a match.