I would like to restrict certain OUs from access to ldap. That is users who belong to a certain OU might be able or unable to authenticate. Is that possible with this module?
For example my baseDN is something like this OU=Users, OU=Company DC=domainname,DC=com
I would like to allow a few sub OUs but not all since some of them are for generic accounts.

Comments

blc’s picture

blc CreditAttribution: blc commented

In the advanced config section, you can specify an LDAP filter. So, you can get as fancy as you want with which accounts SimpleLdap will find, and can use.

modulo’s picture

modulo CreditAttribution: modulo commented

I just want to be clear about the syntax for the search filter field. What is the correct syntax? Since I am trying to restrict by OU should I change my option in the User objectClass to organizationalUnit?

blc’s picture

blc CreditAttribution: blc commented

The User objectClass should stay the same. That is used in the base search filter to find account objects.

The search filter accepts any valid LDAP search filter, and appends it to the base filter to refine the search it does to find a user.

Some examples of how to build LDAP filters can be found at

http://social.technet.microsoft.com/wiki/contents/articles/5392.active-d...

ctgraham’s picture

ctgraham CreditAttribution: ctgraham commented
Issue summary: View changes

I was confused by this feature. I initially entered a valid LDAP filter (including the parentheses), and ended up locked out because of the exception:
SimpleLdapException: Bad search filter in SimpleLdap::ldap_list()
It took some digging to realize that the leading parenthesis and trailing parenthesis was hardcoded.

I'd suggest a slight change to the instructions to clarify this.
https://github.com/ulsdevteam/simple_ldap/commit/5ff01671ee51f14ce22ab8219f4bba3baf4786b6.patch

It might also be worth checking the filter in a non-blocking way so that a filter error doesn't lock the admin out.

emsearcy’s picture

emsearcy CreditAttribution: emsearcy commented

The search filter accepts any valid LDAP search filter

+1 for not realizing that I wasn't supposed to include leading and trailing parenthesis in simple_ldap filters (I was actually setting up a filter for simple_ldap_role). I also had to dive into the code to figure out what was going on.

"attribute=foo" is not a "valid LDAP search filter". "(attribute=foo)" is. [1] I think the behavior should be changed to explicitly configure the filter with leading and trailing parentheses; this is much more intuitive for anybody who is familiar with LDAP, especially if you are trying to write a complex filter that starts off with a logical operator. With an update hook to convert existing filter variables to prefix & append parentheses, and a sample attribute filter like "(mail=*)" or "(description=*)" so that existing simple_ldap admins understand that filters that should look like this now, I think we could make the change without causing too much confusion to the existing admins.

[1] according to RFC 4515, http://tools.ietf.org/search/rfc4515#section-3 filter = LPAREN filtercomp RPAREN

John Franklin’s picture

John Franklin CreditAttribution: John Franklin commented

We can add a validate function with a regex that checks the filter for correct syntax. Anyone want to write up that regex?