Nested AD groups to grant access in the organization #10833

New Issue

GiteaMirror · 2025-11-02T09:19:29-06:00

GiteaMirror commented

2025-11-02 09:19:29 -06:00

Originally created by @Mamoob on GitHub (May 12, 2023).

Feature Description

Hello dear Gitea team!
Is it possible to set up nested AD groups to grant access in the organization?
for example, I have a general group in AD with groups nested in it, how can I make Gitea look at the nested groups in the "Map LDAP groups to Organization teams" parameter? for example: "CN=Eng-All,OU=Eng,OU=Sf,OU=Groups,DC=some,DC=dc":{"some":["some"],"Viewers":["view" ]} but it has no users, only nested groups. (Group attribute containing list of users = member , User attribute in group = distinguishedName)

Screenshots

No response

Originally created by @Mamoob on GitHub (May 12, 2023). ### Feature Description Hello dear Gitea team! Is it possible to set up nested AD groups to grant access in the organization? for example, I have a general group in AD with groups nested in it, how can I make Gitea look at the nested groups in the "Map LDAP groups to Organization teams" parameter? for example: "CN=Eng-All,OU=Eng,OU=Sf,OU=Groups,DC=some,DC=dc":{"some":["some"],"Viewers":["view" ]} but it has no users, only nested groups. (Group attribute containing list of users = member , User attribute in group = distinguishedName) ### Screenshots _No response_

GiteaMirror added the topic/authentication type/proposal type/feature labels 2025-11-02 09:19:29 -06:00

GiteaMirror commented

2025-11-02 09:19:29 -06:00

@Terrorwolf01 commented on GitHub (May 29, 2023):

Hi,
Is here any update?
I'm asking, since I ran in the same problem today.
BR

@Terrorwolf01 commented on GitHub (May 29, 2023): Hi, Is here any update? I'm asking, since I ran in the same problem today. BR

GiteaMirror commented

2025-11-02 09:19:30 -06:00

@Mamoob commented on GitHub (Jul 17, 2023):

Hi,
unfortunately not.
right now I have one huge json with a description of each group and access to organizations (

@Mamoob commented on GitHub (Jul 17, 2023): Hi, unfortunately not. right now I have one huge json with a description of each group and access to organizations (

GiteaMirror commented

2025-11-02 09:19:30 -06:00

@systemofapwne commented on GitHub (Jul 28, 2023):

I am also waiting for a proper implementation of this feature. Right now, using member:1.2.840.113556.1.4.1941: as the Group-Member attribute seems to work, however the LDAP query against our AD (~2k people) becomes super slow and takes more than two minutes instead of only a few seconds. So I would not call this a proper solution.

Here is a screenshot of our configuration

~~Ideally, gitea would not search the AD/LDAP for groups and check out the groups' "member" attributes but rather resolve each user's "memberOf" attribute recursively for group memberships.~~
Ideally, gitea would retrieve all relevant groups from the AD/LDAP (recursively) just once and then performs a check against a user being in it or not.

Right now, the sync code is written such, that gitea first retrieves all users with an LDAP query and then loops over all users. In that loop, it queries the AD again for every single user in order to fetch his groups. For 2000 users, that are 2000 queries.
Adding a recursive group lookup (like I have demonstrated above) causes the AD to recursively look up all groups it finds (7866a6e0e2/services/auth/source/ldap/source_search.go (L214)). We have about 200 groups. The amplification factor is 2000*200!

It would be way more clever to fetch all groups (here 200), resolve the member attribute recursively just in one query and check the member Attribute in gitea. This would speed up the lookup by a factor of 2000 (amount of users) for our case.

But I see, why the implementation is, like it is: When a user logs in via AD backend, doing a fully query for that user makes sense.
When however syncing the full user DB, doing this for every single user hammers the AD by a lot.

Conclusion: The groups feature in combination with sync in the AD/LDAP backend right now should be considered NEEDS IMPROVEMENT

@systemofapwne commented on GitHub (Jul 28, 2023): I am also waiting for a proper implementation of this feature. Right now, using ``member:1.2.840.113556.1.4.1941:`` as the Group-Member attribute seems to work, however the LDAP query against our AD (~2k people) becomes super slow and takes more than two minutes instead of only a few seconds. So I would not call this a proper solution. Here is a screenshot of our configuration ![image](https://github.com/go-gitea/gitea/assets/30482165/2dc8ca7a-25eb-4eb6-bff6-298829435b9c) ~~Ideally, gitea would not search the AD/LDAP for groups and check out the groups' "member" attributes but rather resolve each user's "memberOf" attribute recursively for group memberships.~~ Ideally, gitea would retrieve all relevant groups from the AD/LDAP (recursively) **just once** and then performs a check against a user being in it or not. Right now, the sync code is written such, that gitea first retrieves all users with an LDAP query and then loops over all users. In that loop, it queries the AD again for every single user in order to fetch his groups. For 2000 users, that are 2000 queries. Adding a recursive group lookup (like I have demonstrated above) causes the AD to recursively look up all groups it finds (https://github.com/go-gitea/gitea/blob/7866a6e0e25cf87b298e046bb38f4d68c35529a7/services/auth/source/ldap/source_search.go#L214). We have about 200 groups. The amplification factor is 2000*200! It would be way more clever to fetch all groups (here 200), resolve the member attribute recursively **just in one query** and check the member Attribute in gitea. This would speed up the lookup by a factor of 2000 (amount of users) for our case. But I see, why the implementation is, like it is: When a user logs in via AD backend, doing a fully query for that user makes sense. When however syncing the full user DB, doing this for every single user hammers the AD by a lot. Conclusion: The groups feature in combination with sync in the AD/LDAP backend right now should be considered **NEEDS IMPROVEMENT**

GiteaMirror commented

2025-11-02 09:19:30 -06:00

@davidhulick commented on GitHub (Nov 21, 2023):

@systemofapwne Do you know if your sample configuration works against FreeIPA or is it strictly Active Directory specific?

It seems to me that Gitea is making some AD-specific assumptions about the structure of the LDAP objects it receives that makes it impossible to retrieve users in nested groups using FreeIPA or other non-AD directory services. (Though I may be missing something, I don't confess to have anything near exhaustive knowledge about LDAP.)

@davidhulick commented on GitHub (Nov 21, 2023): @systemofapwne Do you know if your sample configuration works against FreeIPA or is it strictly Active Directory specific? It seems to me that Gitea is making some AD-specific assumptions about the structure of the LDAP objects it receives that makes it impossible to retrieve users in nested groups using FreeIPA or other non-AD directory services. (Though I may be missing something, I don't confess to have anything near exhaustive knowledge about LDAP.)

GiteaMirror commented

2025-11-02 09:19:31 -06:00

@systemofapwne commented on GitHub (Nov 21, 2023):

I have not checked against FreeIPA. Our institution uses Samba as an AD controler.
So far, I worked around the issue, by not using recursive lookups but explicit lookups. This of course needs manual management as the AD tree grows. This is somewhet unsatisfactory, but does the job. But I wont call this a solution.

@systemofapwne commented on GitHub (Nov 21, 2023): I have not checked against FreeIPA. Our institution uses Samba as an AD controler. So far, I worked around the issue, by not using recursive lookups but explicit lookups. This of course needs manual management as the AD tree grows. This is somewhet unsatisfactory, but does the job. But I wont call this a solution.

GiteaMirror commented

2025-11-02 09:19:31 -06:00

@sgabenov commented on GitHub (Jan 18, 2024):

Relates to https://github.com/go-gitea/gitea/issues/16583

@sgabenov commented on GitHub (Jan 18, 2024): Relates to https://github.com/go-gitea/gitea/issues/16583

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#10833