2 posixgroups, cn=dw and cn=dww
testgroups.ldif

Could you please include the ldapsearch results so we could compare the groups to see if something is different?

component: SSSD => LDAP Provider

sssd_LDAP.log while 'getent group dw' is called using sssd-1.5.1-34.el6.x86_64
sssd_LDAP.log_getent_group_dw

ldapsearch, cn=dw and cn=dww
ldapsearch.txt

Thanks for pointing;
I discovered 2 factors making the 2 char named group appear:

• using 'enumerate = False' makes the group getting displayed
• the groups gidNumber was not unique. An other posixGroup which was returned to the search sssd does for the enumeration was returned bevore the group in question, with enumerate only that group was honoured.

While my setup (might be our customer is running into the same problem) is fixed now we
have different behaviour for this case, depending on enumerate beeing 0 or 1.
Maybe the behaviour should be the same in both cases.. tend to say yes, but maybe there are arguments against that.

Replying to [comment:2 chorn]:

Thanks for pointing;
I discovered 2 factors making the 2 char named group appear:
- using 'enumerate = False' makes the group getting displayed
- the groups gidNumber was not unique. An other posixGroup which was returned to the search sssd does for the enumeration was returned bevore the group in question, with enumerate only that group was honoured.

While my setup (might be our customer is running into the same problem) is fixed now we
have different behaviour for this case, depending on enumerate beeing 0 or 1.
Maybe the behaviour should be the same in both cases.. tend to say yes, but maybe there are arguments against that.

The behaviour has nothing to do with enumerate being on and off or with group name being two or three characters. You were seeing the other group because the LDAP server had simply returned it first during enumeration.

The real problem is the duplicate GID. This is not a supported directory configuration, GIDs and user UIDs for that matter must be unique.

resolution: => invalid
status: new => closed

True, it is a missconfiguration.

If double GID exist thou and 'enumerate = true' is used then it second groupname will not be looked up by 'getent group <group>'.
We could think of checking for getting a GID a second time and output a warning - such sanity checks should probably done on the server database instead of all clients.

Thanks for great help.

Fields changed

rhbz: => 0

Fields changed

milestone: NEEDS_TRIAGE => void

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/2004

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.