So there is a feature called auto_private_groups that will turn the primary gid, into a secondary group. I haven't tested this with a missing primary group, but my guess is that it should work.

Could you give it a try?

auto_private_groups = false

getent passwd testuser

=> Nothing
auto_private_groups = true

getent passwd testuser

testuser:*:123456:123456:testuser:/home/testuser:

But if the user has a LDAP attribute with a gidNumber then it will be overwritten with the auto_private groups generated groups.

It would be nice if this option only gets active if the attribute is not configured.

Yes, it is sort of overwritten, but the group is still used. If you have a user with gidNumber, try running "id" for this user. You should still see the original gidNumber represented as a secondary group, so for the purposes of permissions to e.g. files or so, the user is still a member of that group. Is there some use-case in your environment that needs that particular gidNumber to be set?

btw I'm right now working on a similar, but a bit different use-case for one RHEL customer. In their environment, they would like to only generate the group for users whose uidNumber equals the gidNumber and for users where the values are different, use the gidNumber from the entry. Maybe this would also help in your case in the sense that you would just need to define a gidNumber with the same value as uidNumber, but you wouldn't have to create a group object to match this gidNumber.

Your use-case is somewhere in between what that customer requested and the fully automatic mode. It would of course be possible to fix code-wise, but of course using what is available now means you wouldn't have to wait for the feature to be implemented :-)

Yes, the other secondary groups are still visible.
The solution is for me okay, as I can switch the group with "newgrp", which is okay in most cases.
If you think this feature makes sense then leave the request open, if not I'm also happy if you close it.

Thank you very much for your quick support.

I think it makes sense to leave the request open, at the very least for visibility. But I don't think that it would get implemented in the near future unless more people ask.

btw the 'hybrid' mode of generating the private groups based on uidNumber and gidNumber equality is https://github.com/SSSD/sssd/pull/650 and would be merged into the next version.

Thank you for taking time to submit this request for SSSD. Unfortunately this issue was not given priority and the team lacks the capacity to work on it at this time.

Given that we are unable to fulfill this request I am closing the issue as wontfix.

If the issue still persist on recent SSSD you can request re-consideration of this decision by reopening this issue. Please provide additional technical details about its importance to you.

Thank you for understanding.

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/4871

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.