* LDAP:Docs: `active_sync_enabled` setting
Mention `active_sync_enabled` setting and enable it by default
* LDAP: move "disableExternalUser" method
Idea behind new design of the LDAP module is to minimise conflation
between other parts of the system, so it would decoupled as much as
possible from stuff like database, HTTP transport and etc.
Following "Do One Thing and Do It Well" Unix philosophy principal, other things
could be better fitted on the consumer side of things.
Which what this commit trying to archive
* LDAP: correct user/admin binding
The second binding was not happening, so if the admin login/password
in LDAP configuration was correct, anyone could had login as anyone using
incorrect password
* 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.htmlhttps://serverfault.com/questions/328671/paging-using-ldapsearchhashicorp/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
* 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
