6 Commits (317c7b269cbadcefcab727fe7843d2f6404b6f7b)

Author	SHA1	Message	Date
Oleg Gaidarenko	1e5fc76601	LDAP: improve POSIX support (#18235) ... * LDAP: improve POSIX support * Correctly abtain DN attributes result * Allow more flexibility with comparison mapping between POSIX group & user * Add devenv for POSIX LDAP server * Correct the docs Fixes #18140	7 years ago
Oleg Gaidarenko	444c4d5999	LDAP: Divide the requests (#17885) ... * LDAP: Divide the requests Active Directory does indeed have a limitation with 1000 results per search (default of course). However, that limitation can be workaround with the pagination search feature, meaning `pagination` number is how many times LDAP compatible server will be requested by the client with specified amount of users (like 1000). That feature already embeded with LDAP compatible client (including our `go-ldap`). But slapd server has by default stricter settings. First, limitation is not 1000 but 500, second, pagination workaround presumably (information about it a bit scarce and I still not sure on some of the details from my own testing) cannot be workaround with pagination feature. See https://www.openldap.org/doc/admin24/limits.html https://serverfault.com/questions/328671/paging-using-ldapsearch hashicorp/vault#4162 - not sure why they were hitting the limit in the first place, since `go-ldap` doesn't have one by default. But, given all that, for me `ldapsearch` command with same request as with `go-ldap` still returns more then 500 results, it can even return as much as 10500 items (probably more). So either there is some differences with implementation of the LDAP search between `go-ldap` module and `ldapsearch` or I am missing a step :/. In the wild (see serverfault link), apparently, people still hitting that limitation even with `ldapsearch`, so it still seems to be an issue. But, nevertheless, I'm still confused by this incoherence. To workaround it, I divide the request by no more then 500 items per search	7 years ago
Oleg Gaidarenko	1b1d951495	LDAP: refactoring (#17479) ... * LDAP: use only one struct * Use only models.ExternalUserInfo * Add additional helper method :/ * Move all the helpers to one module * LDAP: refactoring * Rename some of the public methods and change their behaviour * Remove outdated methods * Simplify logic * More tests There is no and never were tests for settings.go, added tests for helper methods (cover is now about 100% for them). Added tests for the main LDAP logic, but there is some stuff to add. Dial() is not tested and not decoupled. It might be a challenge to do it properly * Restructure tests: * they wouldn't depend on external modules * more consistent naming * logical division * More guards for erroneous paths * Login: make login service an explicit dependency * LDAP: remove no longer needed test helper fns * LDAP: remove useless import * LDAP: Use new interface in multildap module * LDAP: corrections for the groups of multiple users * In case there is several users their groups weren't detected correctly * Simplify helpers module	7 years ago
Oleg Gaidarenko	de92c360a1	LDAP: reduce API and allow its extension (#17209) ... * Removes Add/Remove methods * Publicise necessary fields and methods so we could extend it * Publicise mock API * More comments and additional simplifications * Sync with master Still having low coverage :/ - should be addressed in #17208	7 years ago
Oleg Gaidarenko	a0f5923b95	LDAP: add tests for initialBind (#17132) ... * LDAP: add tests for initialBind * LDAP: clarify comment for Login()	7 years ago
Oleg Gaidarenko	35f227de11	Feature: LDAP refactoring (#16950) ... * incapsulates multipleldap logic under one module * abstracts users upsert and get logic * changes some of the text error messages and import sort sequence * heavily refactors the LDAP module – LDAP module now only deals with LDAP related behaviour * integrates affected auth_proxy module and their tests * refactoring of the auth_proxy logic	7 years ago