Allow user defined ldap filters

[keith-minnig]

The current ldap authentication hardcodes the search filter:

val filter = "%s=%s".format(userattrib, username) val searchRoot = "%s,%s".format(usersub, searchbase) val res = ctx.search(searchRoot, filter, searchControls)

This breaks in the scenario where a user is in one OU, but a bot is in another:

• User 'John'
  • searchbase = "ou=hq,dc=AD,dc=company,dc=com"
  • usersub = "ou=Users"
• Non-user 'Collins-bot'
  • searchbase = "ou=hq,dc=AD,dc=company,dc=com"
  • usersub = "ou=Bots"

Either setting will work individually in authentication.conf, but not to allow both to authenticate. I'm not sure if the best route is to allow usersub to contain wildcards or to have an optional filter config value that would be included. The userattrib=username comparison is always going to be needed, but some additional filters could be applied around it, such as (&(|(ou=Users)(ou=Bots))(userattrib=username)), ref ldap link.

As a work around, I've tried adjusting the scope via ldap.conf such that scope=sub and

searchbase = "dc=AD,dc=company,dc=com" usersub="ou=hq"

However, it still fails to authenticate.

[byxorna]

@roymarantz @maddalab @defect @Primer42

[yl3w]

@yafsn Keith, any idea why the work around did not work? I'd assume it has something to do with determining the users groups. Can you drop the relevant snippet of the ldap configuration?

[keith-minnig]

This is what was in /etc/ldap/ldap.conf. I'd tried both SUB and ONE for the scope.

TLS_CACERT /etc/ssl/certs/ca-certificates.crt HOST 1.2.3.4 PORT 636 SCOPE SUB

[roymarantz]

I would think you should have "base" and maybe other parameters in /etc/ldap/ldap.conf. I'd suggest using ldapsearch with minimal arguments to test that everything is setup correctly. e.g. $ ldapsearch -x -LLL -ZZ 'uid=marantz' sn dn: uid=marantz,ou=People,dc=TTTTTT,dc=XXX sn: Marantz but the particulars will vary with which software you use and how it is setup.

On Mon, Jun 15, 2015 at 3:38 PM, Keith Minnig [email protected] wrote:

This is what was in /etc/ldap/ldap.conf. I'd tried both SUB and ONE for the scope.

TLS_CACERT /etc/ssl/certs/ca-certificates.crt HOST 1.2.3.4 PORT 636 SCOPE SUB

— Reply to this email directly or view it on GitHub https://github.com/tumblr/collins/issues/312#issuecomment-112183051.