Why SCOPE_ONE_LEVEL ?

You should probably return an error if more than 1 user is found

Lokup user DNs ?

Proxy user used to lookup DNs

Password for proxy user used to lookup DNs

Search filter template used to Lookup DNs

-> lookup dn filter template

-> lookup_dn_filter_template

Generally looks good, but see nitpicks

Thanks for the comments, I'll fix up a few of these things. I tried testing this further on one of our actual applications an realized that this does break user info just a bit as well, so I have some more work to make this fully functional. The scope thing also gave me issues. ;-) I'm not totally familiar with the process ... do I just add additional commits to this branch for review?

if your intent is to show differences you can just add commits, but you'll have to rebase and squash stuff later for merging.

I have made the changes you mentioned, but have not committed them yet.

I also found out that in using this change, groups are not looked up properly. We use FreeIPA and be default groups are found by using the filter memberuid=%s where %s is replaced by the passed in UID. I updated the code in ipsilon/info/infoldap.py to have a configurable filter template for finding groups for the user (so we can use a filter such as (member=uid=%s,cn=users,cn=accounts,dc=example,dc=org), for instance. However, I'm finding that when the code creates a new LDAPInfo object (InfoProvider) around line ~83 of the ipsilon/login/authldap.py file, the configured values for the LDAP Info plugin are not read in from the database (all the default values are used), so when this section calls self.ldap_info.get_user_data_from_conn(conn, dn, base, user), my configured group search filter is not used and no groups are found. I've been digging through the code to figure out how I can initialize the LDAPInfo (InfoProvider) object in such a way that the database values are read in, but I'm not having any luck. Any suggestions?

If it's useful, I can commit and push my changes so far so you can follow along with what I'm trying to do with the ldap info plugin as well... let me know.

Ok... I could not figure out how to do what I wanted with the info plugin, so instead I changed the ldap auth plugin to add a new group filter template configuration option, then I pass the group filter to the info plugin. This might not be optimal if, in fact, there is a way to get the info plugin in this context to read in the configured values from the database -- however, this is working as I intend it to now. Please take a look and if you're ok with these changes, I'll squash these changes down on a new branch and re-submit the pull request.

Thanks!

As you are working on this it may be nice to use LDAP URIs instead of just specifying filters.
LDAP URIs gives you a standard format to describe how/where to retrieve objects that make easy to cross-reference and share configurations across multiple systems.

Note that python ldap has an LDAPURL handler which should help (though I haven't used it in a long time and committed the sin of not using it in the original code here).

I believe I have this all working now to fit my specific use case. If what I've got so far looks ok to you, I'll squash this down to a single pull-request and re-submit. I will try to work in the LDAP URIs later this month as time permits as a separate pull request. Thanks for the help!

Any reason to close ?

https://pagure.io/ipsilon/pull-request/300 ;-) I rolled it all into one commit...

Next time you can simply rebase the PR.
Thanks

Ah.. sorry. I'm not so familiar with the process.