🚀 Feature: Support addition LDAP group membership attributes #155

New Issue

OVERLORD · 2026-02-04T17:35:40+03:00

OVERLORD commented

2026-02-04 17:35:40 +03:00

Originally created by @koalaeagle on GitHub (Feb 14, 2025).

Originally assigned to: @kmendell on GitHub.

Feature description

I have recently setup pocket id with LDAP sync, and it is working great!

However, I did run into one issue in my environment. Group membership mappings were not working correctly. Looking through the source code, I found that the logic is querying for the "member" attribute of each group. However, my LDAP server (glauth) appears to be using the attribute "uniqueMember".

As a quick and dirty test, I replaced the two relevant occurrences of "member" (in searchAttrs and groupMembers declaration) in backend/internal/service/ldap_service.go and built the docker container. This immediately fixed my issue.

I am not sure how to best address this, but understand that due to the nature of LDAP there can be inconsistencies with mappings. If there aren't too many different commonly used identifiers for group members, perhaps it is worth implementing logic to discover what attribute is in use? Alternatively, this could be implemented as a configuration option like the other attribute mappings.

Pitch

This feature would ensure that group mappings work in different LDAP implementations/environments.

Originally created by @koalaeagle on GitHub (Feb 14, 2025). Originally assigned to: @kmendell on GitHub. ### Feature description I have recently setup pocket id with LDAP sync, and it is working great! However, I did run into one issue in my environment. Group membership mappings were not working correctly. Looking through the source code, I found that the logic is querying for the "member" attribute of each group. However, my LDAP server (glauth) appears to be using the attribute "uniqueMember". As a quick and dirty test, I replaced the two relevant occurrences of "member" (in searchAttrs and groupMembers declaration) in backend/internal/service/ldap_service.go and built the docker container. This immediately fixed my issue. I am not sure how to best address this, but understand that due to the nature of LDAP there can be inconsistencies with mappings. If there aren't too many different commonly used identifiers for group members, perhaps it is worth implementing logic to discover what attribute is in use? Alternatively, this could be implemented as a configuration option like the other attribute mappings. ### Pitch This feature would ensure that group mappings work in different LDAP implementations/environments.

OVERLORD added the feature label 2026-02-04 17:35:40 +03:00

OVERLORD closed this issue

2026-02-04 17:35:42 +03:00

OVERLORD commented

2026-02-04 17:35:50 +03:00

@kmendell commented on GitHub (Feb 14, 2025):

@koalaeagle I opened a PR here https://github.com/pocket-id/pocket-id/pull/236 , can you verify this is what you changed and is what your were asking for?

@kmendell commented on GitHub (Feb 14, 2025): @koalaeagle I opened a PR here https://github.com/pocket-id/pocket-id/pull/236 , can you verify this is what you changed and is what your were asking for?

OVERLORD commented

2026-02-04 17:36:09 +03:00

@stonith404 commented on GitHub (Feb 14, 2025):

You can test it with the ghcr.io/pocket-id/pocket-id:development image.

@stonith404 commented on GitHub (Feb 14, 2025): You can test it with the `ghcr.io/pocket-id/pocket-id:development` image.

OVERLORD commented

2026-02-04 17:36:12 +03:00

@kmendell commented on GitHub (Feb 14, 2025):

It is working as expected for the member attribute i cant not say for certain for @koalaeagle use case though.

@kmendell commented on GitHub (Feb 14, 2025): It is working as expected for the `member` attribute i cant not say for certain for @koalaeagle use case though.

OVERLORD commented

2026-02-04 17:36:19 +03:00

@koalaeagle commented on GitHub (Feb 16, 2025):

This worked perfectly for me!

Steps taken:

Switched to ghcr.io/pocket-id/pocket-id:development image
Tested a sync with defaults - groups reset back to 0 members
Updated "Group Members Attribute" from member (default) > uniqueMember (based on glauth attribute)
Tested another sync, group membership populated as expected based on LDAP server group mappings
Tested an application restricted via group membership and all working as expected

@koalaeagle commented on GitHub (Feb 16, 2025): This worked perfectly for me! Steps taken: 1. Switched to `ghcr.io/pocket-id/pocket-id:development` image 2. Tested a sync with defaults - groups reset back to 0 members 3. Updated "Group Members Attribute" from **member** (default) > **uniqueMember** (based on glauth attribute) 4. Tested another sync, group membership populated as expected based on LDAP server group mappings 5. Tested an application restricted via group membership and all working as expected

OVERLORD commented

2026-02-04 17:36:26 +03:00

@kmendell commented on GitHub (Feb 16, 2025):

@stonith404 Should be good to merge this in if the code looks good to you.

@kmendell commented on GitHub (Feb 16, 2025): @stonith404 Should be good to merge this in if the code looks good to you.

OVERLORD referenced this issue

2026-02-04 20:45:30 +03:00

[PR #155] [CLOSED] draft: feat: ISP (AS) names and numbers #665

Sign in to join this conversation.