Support multiple LDAP servers in a auth source #3313

New Issue

GiteaMirror · 2025-11-02T05:07:46-06:00

GiteaMirror commented

2025-11-02 05:07:46 -06:00

Originally created by @silverwind on GitHub (May 10, 2019).

Originally assigned to: @abhishek818 on GitHub.

I have a LDAP auth source which has multiple redundant servers, I think it would be useful if a LDAP auth source would allow to specify more than one server here:

Maybe accept a comma-separated list. Servers should be tried in the order they are defined, or possibly randomly to even the load. All servers should be tried and auth should only fail if it fails on all servers.

Originally created by @silverwind on GitHub (May 10, 2019). Originally assigned to: @abhishek818 on GitHub. I have a LDAP auth source which has multiple redundant servers, I think it would be useful if a LDAP auth source would allow to specify more than one server here: <img width="379" src="https://user-images.githubusercontent.com/115237/57516581-49bad800-7315-11e9-9ce3-ea42d6f4bad8.png"> Maybe accept a comma-separated list. Servers should be tried in the order they are defined, or possibly randomly to even the load. All servers should be tried and auth should only fail if it fails on all servers.

GiteaMirror added the issue/confirmed topic/authentication type/enhancement labels 2025-11-02 05:07:46 -06:00

GiteaMirror commented

2025-11-02 05:07:47 -06:00

@stale[bot] commented on GitHub (Jul 9, 2019):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

@stale[bot] commented on GitHub (Jul 9, 2019): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

GiteaMirror commented

2025-11-02 05:07:47 -06:00

@silverwind commented on GitHub (Jul 9, 2019):

Still want to do this, just haven't gotten around to it yet.

@silverwind commented on GitHub (Jul 9, 2019): Still want to do this, just haven't gotten around to it yet.

GiteaMirror commented

2025-11-02 05:07:47 -06:00

@TheTumultuousUnicornOfDarkness commented on GitHub (May 14, 2022):

Hello,

Any update about this PR? That is a feature I am looking for.
In resilient environments, having at least two LDAP servers is common (in case one server is not working properly for example), so I would like to put 2 URLs for my LDAP source.

I see content of modules/auth/ldap/ldap.go file was moved to services/auth/source/ldap/source_search.go, so this PR must be updated.

@TheTumultuousUnicornOfDarkness commented on GitHub (May 14, 2022): Hello, Any update about this PR? That is a feature I am looking for. In resilient environments, having at least two LDAP servers is common (in case one server is not working properly for example), so I would like to put 2 URLs for my LDAP source. I see content of `modules/auth/ldap/ldap.go` file was moved to `services/auth/source/ldap/source_search.go`, so this PR must be updated.

GiteaMirror commented

2025-11-02 05:07:47 -06:00

@palto42 commented on GitHub (May 27, 2024):

I would also be very interested in this feature in order to support higher availability.

@palto42 commented on GitHub (May 27, 2024): I would also be very interested in this feature in order to support higher availability.

GiteaMirror commented

2025-11-02 05:07:48 -06:00

@luCL21 commented on GitHub (Jul 16, 2024):

4 years after, there's still no changes for an issue related to security (availability is a part of security for me) ????
Are you sure you are right on your "What is Gitea?" page mention :

"Gitea places a strong emphasis on security, offering features such as user permission management, access control lists, and more to ensure the security of code and data."

I think this issue would have a better priority to be resolved in less than 4 years, no ?
As many others, I would also be very interested in this feature.

Thank you !

@luCL21 commented on GitHub (Jul 16, 2024): 4 years after, there's still no changes for an issue related to security (availability is a part of security for me) ???? Are you sure you are right on your "What is Gitea?" page mention : "Gitea places a strong emphasis on security, offering features such as user permission management, access control lists, and more to ensure the security of code and data." I think this issue would have a better priority to be resolved in less than 4 years, no ? As many others, I would also be very interested in this feature. Thank you !

GiteaMirror commented

2025-11-02 05:07:48 -06:00

@techknowlogick commented on GitHub (Jul 16, 2024):

@luCL21 We merge >400 PRs a month, and have thousands of support requests a month through forum, issues reports, emails, chat messages, and more. So while we wish to get to all of the feature requests sometimes it takes longer to get to everything. Part of our long-term strategic roadmap includes improving the high-availability of the project, and this would certainly fit in there.

That being said, we always welcome non-maintainer contributions, so I'll put up a bounty to perhaps usher the progress on this ticket along.

/bounty $200

@techknowlogick commented on GitHub (Jul 16, 2024): @luCL21 We merge >400 PRs a month, and have thousands of support requests a month through forum, issues reports, emails, chat messages, and more. So while we wish to get to all of the feature requests sometimes it takes longer to get to everything. Part of our long-term strategic roadmap includes improving the high-availability of the project, and this would certainly fit in there. That being said, we always welcome non-maintainer contributions, so I'll put up a bounty to perhaps usher the progress on this ticket along. /bounty $200

GiteaMirror commented

2025-11-02 05:07:48 -06:00

@abhishek818 commented on GitHub (Jul 16, 2024):

@techknowlogick Can i get this assigned?

@abhishek818 commented on GitHub (Jul 16, 2024): @techknowlogick Can i get this assigned?

GiteaMirror commented

2025-11-02 05:07:48 -06:00

@techknowlogick commented on GitHub (Jul 16, 2024):

@abhishek818 yup. If you wish to attempt it for the bounty please ensure you follow the steps from algora posted above.

@techknowlogick commented on GitHub (Jul 16, 2024): @abhishek818 yup. If you wish to attempt it for the bounty please ensure you follow the steps from algora posted above.

GiteaMirror commented

2025-11-02 05:07:49 -06:00

@abhishek818 commented on GitHub (Jul 16, 2024):

/attempt #6898

Algora profile	Completed bounties	Tech	Active attempts	Options
@abhishek818	13 bounties from 6 projects	JavaScript, TypeScript		Cancel attempt

@abhishek818 commented on GitHub (Jul 16, 2024): /attempt #6898 <div id="algora-attempt" /> | [Algora profile](https://console.algora.io/@/abhishek818) | Completed bounties | Tech | Active attempts | Options | | --- | --- | --- | --- | --- | | @abhishek818 | 13 bounties from 6 projects | <div align="center">JavaScript, TypeScript</div> | <div align="center"></div> | [Cancel attempt](https://console.algora.io/api/bounties/clyolb37w0004l40ag2gxac5e/cancel-attempt) |

GiteaMirror commented

2025-11-02 05:07:49 -06:00

@algora-pbc[bot] commented on GitHub (Jul 18, 2024):

💡 @abhishek818 submitted a pull request that claims the bounty. You can visit your bounty board to reward.

@algora-pbc[bot] commented on GitHub (Jul 18, 2024): 💡 @abhishek818 submitted a [pull request](https://github.com/go-gitea/gitea/pull/31649) that claims the bounty. You can [visit your bounty board](https://console.algora.io/org/go-gitea/bounties) to reward.

GiteaMirror commented

2025-11-02 05:07:49 -06:00

@algora-pbc[bot] commented on GitHub (Jul 19, 2024):

Here are some steps and pointers to help you get started on resolving this issue:

Modify the Source struct:
- Update the Host field to accept a comma-separated list of servers.
- Add a method to parse and return the list of servers.
Update the Authenticate method:
- Modify the Authenticate method to iterate over the list of servers and attempt authentication with each one until a successful authentication or all servers fail.
Update the configuration parsing:
- Ensure that the configuration parsing logic can handle the new format for the Host field.

Step-by-Step Implementation

1. Modify the `Source` struct

In source.go, update the Source struct and add a method to parse the list of servers:

type Source struct {
    Name                  string // canonical name (ie. corporate.ad)
    Hosts                 string // Comma-separated list of LDAP hosts
    Port                  int    // port number
    // ... other fields ...
}

// GetHosts returns the list of LDAP hosts.
func (source *Source) GetHosts() []string {
    return strings.Split(source.Hosts, ",")
}

2. Update the `Authenticate` method

In source_authenticate.go, update the Authenticate method to try each server in the list:

func (source *Source) Authenticate(ctx context.Context, user *user_model.User, userName, password string) (*user_model.User, error) {
    loginName := userName
    if user != nil {
        loginName = user.LoginName
    }

    var lastErr error
    for _, host := range source.GetHosts() {
        source.Host = host
        sr := source.SearchEntry(loginName, password, source.authSource.Type == auth.DLDAP)
        if sr != nil {
            // Successful authentication
            // ... existing logic ...
            return user, nil
        }
        lastErr = user_model.ErrUserNotExist{Name: loginName}
    }

    // All servers failed
    return nil, lastErr
}

3. Update the configuration parsing

In admin_auth_ldap.go, ensure that the Hosts field is correctly parsed:

func parseLdapConfig(c *cli.Context, config *ldap.Source) error {
    if c.IsSet("name") {
        config.Name = c.String("name")
    }
    if c.IsSet("host") {
        config.Hosts = c.String("host")
    }
    // ... other fields ...
    return nil
}

Potential Implications

Security: Ensure that the connection to each LDAP server is secure, especially if using different security protocols for different servers.
Stability: The new logic should handle cases where some servers are down or unreachable without causing significant delays or failures in the authentication process.
Potential Bugs: Thoroughly test the new feature to ensure that it correctly falls back to the next server in case of failure and that it does not introduce any regressions in the existing authentication logic.

Relevant Files

@algora-pbc[bot] commented on GitHub (Jul 19, 2024): Here are some steps and pointers to help you get started on resolving this issue: 1. **Modify the `Source` struct**: - Update the `Host` field to accept a comma-separated list of servers. - Add a method to parse and return the list of servers. 2. **Update the `Authenticate` method**: - Modify the `Authenticate` method to iterate over the list of servers and attempt authentication with each one until a successful authentication or all servers fail. 3. **Update the configuration parsing**: - Ensure that the configuration parsing logic can handle the new format for the `Host` field. ### Step-by-Step Implementation #### 1. Modify the `Source` struct In `source.go`, update the `Source` struct and add a method to parse the list of servers: ```go type Source struct { Name string // canonical name (ie. corporate.ad) Hosts string // Comma-separated list of LDAP hosts Port int // port number // ... other fields ... } // GetHosts returns the list of LDAP hosts. func (source *Source) GetHosts() []string { return strings.Split(source.Hosts, ",") } ``` #### 2. Update the `Authenticate` method In `source_authenticate.go`, update the `Authenticate` method to try each server in the list: ```go func (source *Source) Authenticate(ctx context.Context, user *user_model.User, userName, password string) (*user_model.User, error) { loginName := userName if user != nil { loginName = user.LoginName } var lastErr error for _, host := range source.GetHosts() { source.Host = host sr := source.SearchEntry(loginName, password, source.authSource.Type == auth.DLDAP) if sr != nil { // Successful authentication // ... existing logic ... return user, nil } lastErr = user_model.ErrUserNotExist{Name: loginName} } // All servers failed return nil, lastErr } ``` #### 3. Update the configuration parsing In `admin_auth_ldap.go`, ensure that the `Hosts` field is correctly parsed: ```go func parseLdapConfig(c *cli.Context, config *ldap.Source) error { if c.IsSet("name") { config.Name = c.String("name") } if c.IsSet("host") { config.Hosts = c.String("host") } // ... other fields ... return nil } ``` ### Potential Implications 1. **Security**: Ensure that the connection to each LDAP server is secure, especially if using different security protocols for different servers. 2. **Stability**: The new logic should handle cases where some servers are down or unreachable without causing significant delays or failures in the authentication process. 3. **Potential Bugs**: Thoroughly test the new feature to ensure that it correctly falls back to the next server in case of failure and that it does not introduce any regressions in the existing authentication logic. ### Relevant Files - [`/services/auth/source/ldap/source.go`](https://github.com/go-gitea/gitea/blob/main/services/auth/source/ldap/source.go) - [`/services/auth/source/ldap/source_authenticate.go`](https://github.com/go-gitea/gitea/blob/main/services/auth/source/ldap/source_authenticate.go) - [`/cmd/admin_auth_ldap.go`](https://github.com/go-gitea/gitea/blob/main/cmd/admin_auth_ldap.go)

GiteaMirror commented

2025-11-02 05:07:50 -06:00

@wxiaoguang commented on GitHub (Nov 28, 2024):

The "steps" proposed by algora-pbc seem to be easy but not quite right.

https://github.com/go-gitea/gitea/pull/31649#issuecomment-2505555133

It needs to completely refactor the existing LDAP config related code, the key points (in my mind) could be:

use full LDAP URLs for servers, eg: ldap://server:port/, ldaps://server:port/, ldap+starttls://server:port/

keep backwards compatibility (eg: avoid changing unnecessary CLI arguments, could re-use/migrate existing LDAP server configs in database)

@wxiaoguang commented on GitHub (Nov 28, 2024): The "steps" proposed by algora-pbc seem to be easy but not quite right. https://github.com/go-gitea/gitea/pull/31649#issuecomment-2505555133 > It needs to completely refactor the existing LDAP config related code, the key points (in my mind) could be: > > 1. use full LDAP URLs for servers, eg: `ldap://server:port/`, `ldaps://server:port/`, `ldap+starttls://server:port/` > 1. keep backwards compatibility (eg: avoid changing unnecessary CLI arguments, could re-use/migrate existing LDAP server configs in database)

GiteaMirror commented

2025-11-02 05:07:50 -06:00

@lunny commented on GitHub (Dec 12, 2024):

Given that this issue is far more complicated than we initially expected, it is not feasible to address it through the bounty program. Consequently, we have decided to remove it from the bounty list.

@lunny commented on GitHub (Dec 12, 2024): Given that this issue is far more complicated than we initially expected, it is not feasible to address it through the bounty program. Consequently, we have decided to remove it from the bounty list.

GiteaMirror referenced this issue

2025-11-02 12:21:11 -06:00

[PR #3313] [MERGED] Add myself to MAINTAINERS #16878

Sign in to join this conversation.