LDAP Clarification/Debugging #6077

Closed
opened 2025-11-02 06:44:26 -06:00 by GiteaMirror · 11 comments
Owner

Originally created by @WattsC-90 on GitHub (Oct 1, 2020).

  • Gitea version (or commit ref): 1.12.4
  • Git version: 2.27.0
  • Operating system: Win Server 2012R2
  • Database (use [x]):
    • PostgreSQL
    • MySQL
    • MSSQL
    • SQLite
  • Can you reproduce the bug at https://try.gitea.io:
    • Yes (provide example URL)
    • No
    • Not relevant
  • Log gist:

Description

I wish to seek clarification over how Gitea+LDAP work as my expectation is that Gitea will query the LDAP server, in order to validate the user exists. Some tickets/bits of info I have read indicate that Gitea synchronises its users, replicating(?) the users locally, before a user can then login?

I have tried to setup the LDAP bits, but it isn't working (not sure why), are there particular log messages I should be looking out for to indicate whether the settings are right or not etc?

Screenshots

The settings in use: (LDAP simple)
(I am not sure if these are correct to be honest!) I used ADExplorer and ADInsight to attempt to figure out the LDAP configurations, any tips welcome!
image

Originally created by @WattsC-90 on GitHub (Oct 1, 2020). - Gitea version (or commit ref): 1.12.4 - Git version: 2.27.0 - Operating system: Win Server 2012R2 - Database (use `[x]`): - [ ] PostgreSQL - [ ] MySQL - [ ] MSSQL - [x] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [x] Not relevant - Log gist: ## Description I wish to seek clarification over how Gitea+LDAP work as my expectation is that Gitea will query the LDAP server, in order to validate the user exists. Some tickets/bits of info I have read indicate that Gitea synchronises its users, replicating(?) the users locally, before a user can then login? I have tried to setup the LDAP bits, but it isn't working (not sure why), are there particular log messages I should be looking out for to indicate whether the settings are right or not etc? ## Screenshots The settings in use: (LDAP simple) (I am not sure if these are correct to be honest!) I used ADExplorer and ADInsight to attempt to figure out the LDAP configurations, any tips welcome! ![image](https://user-images.githubusercontent.com/10712792/94828844-d0d48880-0401-11eb-800f-763796a496cd.png)
GiteaMirror added the type/question label 2025-11-02 06:44:26 -06:00
Author
Owner

@zeripath commented on GitHub (Oct 1, 2020):

The logs will generally log errors with ldap somewhere in them.

Have you read https://docs.gitea.io/en-us/authentication/

I think there's also a closed issue somewhere with the suggested configuration for an AD.

@zeripath commented on GitHub (Oct 1, 2020): The logs will generally log errors with ldap somewhere in them. Have you read https://docs.gitea.io/en-us/authentication/ I think there's also a closed issue somewhere with the suggested configuration for an AD.
Author
Owner

@WattsC-90 commented on GitHub (Oct 2, 2020):

nothing about ldap in the logs at all, searched ldap, and searched my email that i was trying to log in with and it just seems to search SQL.

I have read the auth page, but honestly I have no idea about LDAP. I hoped there was a way for it to do it "automagically" as TeamCity does as it is on a domain connected machine, so it should be able to challenge the DC from it's own settings.

Also, slight side note, Verify group membership in LDAP section in the gitea auth settings doesnt exist? I could probably make use of it.

Let me try find the AD ticket, I did look but couldn't find anything at the time

@WattsC-90 commented on GitHub (Oct 2, 2020): nothing about ldap in the logs at all, searched ldap, and searched my email that i was trying to log in with and it just seems to search SQL. I have read the auth page, but honestly I have no idea about LDAP. I hoped there was a way for it to do it "automagically" as TeamCity does as it is on a domain connected machine, so it should be able to challenge the DC from it's own settings. Also, slight side note, Verify group membership in LDAP section in the gitea auth settings doesnt exist? I could probably make use of it. Let me try find the AD ticket, I did look but couldn't find anything at the time
Author
Owner

@zeripath commented on GitHub (Oct 9, 2020):

In the case of the logs, most of the interesting logs around LDAP are at Trace level. I wouldn't recommend setting your logging at trace in general because it's very noisy - the best thing to do is to add a logger that will trace ldap:

[database]
log_sql=false; logging SQL is rarely helpful - but set this to true if it is ever needed
...

[log]
mode=console,traceconsole ; traceconsole is the name of the new logger - this could be anything so long as it matches below
level=debug
macaron=console
router=console
redirect_macaron_log=true

[log.traceconsole]
mode=console ; output this logger to the console
level=trace
expression=ldap ; only output log lines with ldap
@zeripath commented on GitHub (Oct 9, 2020): In the case of the logs, most of the interesting logs around LDAP are at Trace level. I wouldn't recommend setting your logging at trace in general because it's very noisy - the best thing to do is to add a logger that will trace ldap: ```ini [database] log_sql=false; logging SQL is rarely helpful - but set this to true if it is ever needed ... [log] mode=console,traceconsole ; traceconsole is the name of the new logger - this could be anything so long as it matches below level=debug macaron=console router=console redirect_macaron_log=true [log.traceconsole] mode=console ; output this logger to the console level=trace expression=ldap ; only output log lines with ldap ```
Author
Owner

@WattsC-90 commented on GitHub (Oct 9, 2020):

@zeripath interesting information, wasnt aware you could do that with the logger!
after spending some time on the auth documentation, i realised at the bottom is a more appropriate type for me - SPNEGO with SSPI. This way the server doesnt synchronise over 5000 users from AD!
I still cannot get it to work, but I think its the more appropriate route! In the logs, all I get is this (see below). Any ideas?

2020/10/02 16:38:19 ...s/context/context.go:330:func1() [D] Session ID: 4dbc22bebc2e561e
2020/10/02 16:38:19 ...s/context/context.go:331:func1() [D] CSRF Token: cVe2O5ggV-Rstb00zQxF4cuhtrQ6MTYwMTU2ODQ1OTk0MTIxODMwMA
2020/10/02 16:38:20 ...m.io/xorm/core/db.go:154:QueryContext() [I] [SQL] SELECT `id`, `type`, `name`, `is_actived`, `is_sync_enabled`, `cfg`, `created_unix`, `updated_unix` FROM `login_source` WHERE (is_actived = ? and type = ?) [true 7]
2020/10/02 16:38:20 ...m.io/xorm/core/db.go:154:QueryContext() [I] [SQL] SELECT `id`, `type`, `name`, `is_actived`, `is_sync_enabled`, `cfg`, `created_unix`, `updated_unix` FROM `login_source` WHERE (is_actived = ? and type = ?) [true 7]
2020/10/02 16:38:20 ...i/websspi_windows.go:281:GetCtxHandle() [I] CtxHandle: 0x{318790 dab48032f0}
2020/10/02 16:38:20 ...i/websspi_windows.go:302:SetCtxHandle() [I] New context: 0x{0 0}
2020/10/02 16:38:20 .../sso/sspi_windows.go:80:VerifyAuthData() [W] Authentication failed with error: AcceptOrContinue failed: call to AcceptSecurityContext failed with code 0x80090308
@WattsC-90 commented on GitHub (Oct 9, 2020): @zeripath interesting information, wasnt aware you could do that with the logger! after spending some time on the auth documentation, i realised at the bottom is a more appropriate type for me - SPNEGO with SSPI. This way the server doesnt synchronise over 5000 users from AD! I still cannot get it to work, but I think its the more appropriate route! In the logs, all I get is this (see below). Any ideas? ``` 2020/10/02 16:38:19 ...s/context/context.go:330:func1() [D] Session ID: 4dbc22bebc2e561e 2020/10/02 16:38:19 ...s/context/context.go:331:func1() [D] CSRF Token: cVe2O5ggV-Rstb00zQxF4cuhtrQ6MTYwMTU2ODQ1OTk0MTIxODMwMA 2020/10/02 16:38:20 ...m.io/xorm/core/db.go:154:QueryContext() [I] [SQL] SELECT `id`, `type`, `name`, `is_actived`, `is_sync_enabled`, `cfg`, `created_unix`, `updated_unix` FROM `login_source` WHERE (is_actived = ? and type = ?) [true 7] 2020/10/02 16:38:20 ...m.io/xorm/core/db.go:154:QueryContext() [I] [SQL] SELECT `id`, `type`, `name`, `is_actived`, `is_sync_enabled`, `cfg`, `created_unix`, `updated_unix` FROM `login_source` WHERE (is_actived = ? and type = ?) [true 7] 2020/10/02 16:38:20 ...i/websspi_windows.go:281:GetCtxHandle() [I] CtxHandle: 0x{318790 dab48032f0} 2020/10/02 16:38:20 ...i/websspi_windows.go:302:SetCtxHandle() [I] New context: 0x{0 0} 2020/10/02 16:38:20 .../sso/sspi_windows.go:80:VerifyAuthData() [W] Authentication failed with error: AcceptOrContinue failed: call to AcceptSecurityContext failed with code 0x80090308 ```
Author
Owner

@zeripath commented on GitHub (Oct 11, 2020):

I unfortunately know nothing about sspi .

Google the error code - it's a Windows specific error code and that should tell you what is going on

@zeripath commented on GitHub (Oct 11, 2020): I unfortunately know nothing about sspi . Google the error code - it's a Windows specific error code and that should tell you what is going on
Author
Owner

@WattsC-90 commented on GitHub (Oct 12, 2020):

The interesting/annoying thing is that all articles on google point to basically incorrect arguments. But I don't supply anything to the SSPI configuration, it seems to do it all itself! With SSPI there is 0 configuration in Gitea UI, so for an error code essentially saying that the call failed or in the latest logs (where I set LAN Manager authentication level to Send NTLM Response Only as per: https://bugzilla.mozilla.org/show_bug.cgi?id=468334)

Unfortunately, to me, it should be transparent, certainly from the configurations (which are as default as it gets).

./sso/sspi_windows.go:80:VerifyAuthData() [W] Authentication failed with error: could not get auth data: the Authorization header is not provided

image

@WattsC-90 commented on GitHub (Oct 12, 2020): The interesting/annoying thing is that all articles on google point to basically incorrect arguments. But I don't supply anything to the SSPI configuration, it seems to do it all itself! With SSPI there is 0 configuration in Gitea UI, so for an error code essentially saying that the call failed or in the latest logs (where I set `LAN Manager authentication level` to `Send NTLM Response Only` as per: https://bugzilla.mozilla.org/show_bug.cgi?id=468334) Unfortunately, to me, it should be transparent, certainly from the configurations (which are as default as it gets). ``` ./sso/sspi_windows.go:80:VerifyAuthData() [W] Authentication failed with error: could not get auth data: the Authorization header is not provided ``` ![image](https://user-images.githubusercontent.com/10712792/95719769-388f9c80-0c68-11eb-9ca3-8590e951cc8c.png)
Author
Owner

@zeripath commented on GitHub (Oct 12, 2020):

@quasoft are you able to shed any light?

@zeripath commented on GitHub (Oct 12, 2020): @quasoft are you able to shed any light?
Author
Owner

@quasoft commented on GitHub (Oct 13, 2020):

It's true there are few configuration options for SSPI in gitea, but some configuration is required in the AD environment (eg. creating a dedicated user account, setting spn on it, running gitea with this account, etc.) and the browser.

You probably already did that, but just in case, go again over the steps outlined in https://docs.gitea.io/en-us/authentication/

When setting things for the first time, I usually try with Internet Explorer or Chrome first, because they require less configuration, which helps to confirm if it works.

@quasoft commented on GitHub (Oct 13, 2020): It's true there are few configuration options for SSPI in gitea, but some configuration is required in the AD environment (eg. creating a dedicated user account, setting spn on it, running gitea with this account, etc.) and the browser. You probably already did that, but just in case, go again over the steps outlined in https://docs.gitea.io/en-us/authentication/ When setting things for the first time, I usually try with Internet Explorer or Chrome first, because they require less configuration, which helps to confirm if it works.
Author
Owner

@WattsC-90 commented on GitHub (Nov 9, 2020):

@quasoft so i refollowed the steps.. i think the one i probably glazed over was the AD http command line step.. after rerunning i realised it was failing.. eventually (27 days later) the IT group have actioned the ticket.. and it works! so that makes me feel stupid.. sorry!

I have a follow up question though. Looking at the login/account created, there is no way to specify the fields that can be used for names/emails etc. a default user is created with a wierd guid email address (see below). Is there a way to customise this? to specify what fields should be pulled out from the domain controller when it creates the account locally? Is the guid email actually valid in Gitea land? I am unsure whether this would hinder usability of the platform or not at this point so I am reluctant to change it. (obviously there would be no password reset, but you may trigger a notification from an issue being raised I guess(?), so would that still work with the guid emails?)

image

@WattsC-90 commented on GitHub (Nov 9, 2020): @quasoft so i refollowed the steps.. i think the one i probably glazed over was the AD http command line step.. after rerunning i realised it was failing.. eventually (27 days later) the IT group have actioned the ticket.. and it works! so that makes me feel stupid.. sorry! I have a follow up question though. Looking at the login/account created, there is no way to specify the fields that can be used for names/emails etc. a default user is created with a wierd guid email address (see below). Is there a way to customise this? to specify what fields should be pulled out from the domain controller when it creates the account locally? Is the guid email actually valid in Gitea land? I am unsure whether this would hinder usability of the platform or not at this point so I am reluctant to change it. (obviously there would be no password reset, but you may trigger a notification from an issue being raised I guess(?), so would that still work with the guid emails?) ![image](https://user-images.githubusercontent.com/10712792/98518083-cdd18100-2266-11eb-8eb0-acdce0de278a.png)
Author
Owner

@quasoft commented on GitHub (Nov 9, 2020):

@WattsC-90 Unfortunately the SSPI method currently does not support reading attributes from active directory. This is why it generates a random fake email address in the corresponding field.

It is possible to use LDAP to query the active directory for those fields, after automatically creating the account, but it would require a code change. I cannot engage with making such a change right now.

But you could also use the LDAP authentication method instead. It does not support single sign-on, but it does fill those fields automatically.

@quasoft commented on GitHub (Nov 9, 2020): @WattsC-90 Unfortunately the SSPI method currently does not support reading attributes from active directory. This is why it generates a random fake email address in the corresponding field. It is possible to use LDAP to query the active directory for those fields, after automatically creating the account, but it would require a code change. I cannot engage with making such a change right now. But you could also use the LDAP authentication method instead. It does not support single sign-on, but it does fill those fields automatically.
Author
Owner

@WattsC-90 commented on GitHub (Nov 9, 2020):

The reason I investigated this method in the first place was that the LDAP method indicated user synchronisation, i.e. the gitea system will create a user entry for every use found on the domain, approx 5000 users rather than the people who actually need access.. Approximately 150 to 200. It would definitely be worth trying to get the info via LDAP for a complete solution (in the future)

@WattsC-90 commented on GitHub (Nov 9, 2020): The reason I investigated this method in the first place was that the LDAP method indicated user synchronisation, i.e. the gitea system will create a user entry for every use found on the domain, approx 5000 users rather than the people who actually need access.. Approximately 150 to 200. It would definitely be worth trying to get the info via LDAP for a complete solution (in the future)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#6077