Nested AD groups to grant access in the organization

[Mamoob]

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

[Terrorwolf01]

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

[Mamoob]

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

[systemofapwne]

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 (

gitea/services/auth/source/ldap/source_search.go

Line 214 in 7866a6e

searchFilter = fmt.Sprintf("(%s=%s)", source.GroupMemberUID, ldap.EscapeFilter(uid))

). 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

[davidhulick]

@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.)

[systemofapwne]

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.

[sgabenov]

Relates to #16583