Skip to content

[Admin] LDAP: user's attribute gidNumber is used for group relations #11148

Description

@Antreesy

If gidNumber from user entry matches gidNumber from group, user will also be considered as part of this group. Then after removing a user from LDAP group, and cleanup with ldap:show-remnants, user is still shown as a group member in web-interface and occ output.

Should be noted in documentation, as it may lead to raising a ticket from customers, who tries to remove users

Documentation source:
https://github.com/nextcloud/documentation/blob/master/admin_manual/configuration_user/user_auth_ldap_api.rst
or
https://github.com/nextcloud/documentation/blob/master/admin_manual/configuration_user/user_auth_ldap_cleanup.rst

Activity

  1. come-nc commented on Sep 26, 2023

    @come-nc
    Contributor

    ldap:show-remnants is only useful for deleted users and has nothing to do with this.

    Otherwise yes we should document that gidNumber is used for group membership even when something else (like member) is set for group<>member association.
    Also note that there is a config entry for which attribute stores the gidNumber but it seems not exposed in the UI, should be double-checked.

  2. removed theissue type on Dec 18, 2025
  3. skjnldsv commented on May 14, 2026

    @skjnldsv
    Member

    The behavior is real and undocumented. When a user's gidNumber attribute matches the gidNumber of a group entry, Nextcloud treats the user as a member of that group regardless of what ldapGroupMemberAssocAttr is configured to (e.g. member, memberUid). This is the POSIX primary group mechanism.

    The relevant doc file is admin_manual/configuration_user/user_auth_ldap_api.rst. The ldapGidNumber config key is shown in examples (line 125) and gidNumber appears as a valid value for ldapGroupMemberAssocAttr (line 260), but neither place explains the implicit primary-group matching side effect or that it operates independently of the member association attribute setting.

    Worth adding a note to the group membership section explaining this behavior, including the fact that the ldapGidNumber attribute name is configurable but not exposed in the UI.

  4. come-nc commented on May 26, 2026

    @come-nc
    Contributor

    Same thing for primaryGroupID I believe (which is the equivalent of gidNumber but for ActiveDirectory as far as I understand).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions