* middleware: Move context handler to own service
Signed-off-by: Arve Knudsen <arve.knudsen@gmail.com>
Co-authored-by: Emil Tullsted <sakjur@users.noreply.github.com>
Co-authored-by: Will Browne <wbrowne@users.noreply.github.com>
* Rewrite auth proxy tests to use standard lib
Signed-off-by: Arve Knudsen <arve.knudsen@gmail.com>
* Auth proxy: Use standard error type
Signed-off-by: Arve Knudsen <arve.knudsen@gmail.com>
* Add fallback to search_base_dns if group_search_base_dns is undefined.
refs: #20862
* removed newline to make lint-go happy
* Added requested changes on ldap.md for last commit
Refs: #21263
* LDAP: Show all LDAP groups
* Use the returned LDAP groups as the reference when debugging LDAP
We need to use the LDAP groups returned as the main reference for
assuming what we were able to match and what wasn't. Before, we were
using the configured groups in LDAP TOML configuration file.
* s/User name/Username
* Add a title to for the LDAP mapping results
* LDAP: UI Updates to debug view
* LDAP: Make it explicit when we weren't able to match teams
* Move the ReloadLDAPCfg function to the debug file
Appears to be a better suite place for this.
* LDAP: Return the server information when we find a specific user
We allow you to specify multiple LDAP servers as part of LDAP authentication integration. As part of searching for specific users, we need to understand from which server they come from. Returning the server configuration as part of the search will help us do two things:
- Understand in which server we found the user
- Have access the groups specified as part of the server configuration
* LDAP: Adds the /api/admin/ldap/:username endpoint
This endpoint returns a user found within the configured LDAP server(s). Moreso, it provides the mapping information for the user to help administrators understand how the users would be created within Grafana based on the current configuration.
No changes are executed or saved to the database, this is all an in-memory representation of how the final result would look like.
* LDAP: nitpicks
* Add more tests
* Correct and clarify comment for Login() method
* Rename methods (hail consistency!)
* Uppercases first letter of the logs everywhere
* Moves method definitions around to more appropriate places
Fixes#18295
* 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
* 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
* Add LDAP config instead sed use
* Add container name
* Add SizeLimit option to client and to server.
Probably useless at this point, but it's better to have it then otherwise
* 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
* 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
* Users: add is_disabled column
* Users: disable users removed from LDAP
* Auth: return ErrInvalidCredentials for failed LDAP auth
* User: return isDisabled flag in user search api
* User: mark disabled users at the server admin page
* Chore: refactor according to review
* Auth: prevent disabled user from login
* Auth: re-enable user when it found in ldap
* User: add api endpoint for disabling user
* User: use separate endpoints to disable/enable user
* User: disallow disabling external users
* User: able do disable users from admin UI
* Chore: refactor based on review
* Chore: use more clear error check when disabling user
* Fix login tests
* Tests for disabling user during the LDAP login
* Tests for disable user API
* Tests for login with disabled user
* Remove disable user UI stub
* Sync with latest LDAP refactoring
* 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
* Feature: add cron setting for the ldap settings
* Move ldap configuration read to special function
* Introduce cron setting (no docs for it yet, pending approval)
* Chore: duplicate ldap module as a service
* Feature: implement active sync
This is very early preliminary implementation of active sync.
There is only one thing that's going right for this code - it works.
Aside from that, there is no tests, error handling, docs, transactions,
it's very much duplicative and etc.
But this is the overall direction with architecture I'm going for
* Chore: introduce login service
* Chore: gradually switch to ldap service
* Chore: use new approach for auth_proxy
* Chore: use new approach along with refactoring
* Chore: use new ldap interface for auth_proxy
* Chore: improve auth_proxy and subsequently ldap
* Chore: more of the refactoring bits
* Chore: address comments from code review
* Chore: more refactoring stuff
* Chore: make linter happy
* Chore: add cron dep for grafana enterprise
* Chore: initialize config package var
* Chore: disable gosec for now
* Chore: update dependencies
* Chore: remove unused module
* Chore: address review comments
* Chore: make linter happy
