Learn more about these different git repos.
Other Git URLs
Output for: "getent group admins"
Server one: admins:*:1000000000:admin,raivo
Server two: admins:*:3000000004:raivo
Server three: admins:*:3000000002:raivo
Server four: admins:*:3000000004:raivo
Server five: admins:*:3000000002:raivo
sssd.conf {{{ [sssd] config_file_version = 2 debug_level = 10 reconnection_retries = 3 sbus_timeout = 30 services = nss, pam
domains = d
[nss] filter_groups = root filter_users = root reconnection_retries = 3 entry_cache_timeout = 60 entry_cache_nowait_timeout = 30
[pam] reconnection_retries = 3
[domain/d] id_provider = ldap auth_provider = ldap access_provider = ldap ldap_schema = rfc2307bis ldap_uri = ldaps://d-1.d, ldaps://d-2.d/ ldap_group_search_base = cn=groups,cn=accounts,dc=d ldap_user_search_base = cn=users,cn=accounts,dc=d ldap_access_filter = memberOf=cn=server,cn=groups,cn=accounts,dc=d ldap_tls_reqcert = demand cache_credentials = False enumerate = true ldap_tls_cacert = /etc/openldap/ssl/ca.crt ldap_id_use_start_tls = False min_id = 1000000001 max_id = 3000000001 entry_cache_timeout = 120 }}}
Some more output: {{{
uidNumber: 3000000001 gidNumber: 3000000001 gidNumber: 3000000001
dn: cn=admins,cn=groups,cn=accounts,dc=d gidnumber: 1000000000
search: 2 result: 0 Success
}}}
Where does >3000000001 gid number come from and why admins group have wrong gid number?
Can you try adding "debug_level = 9" into the [sssd] section of your sssd.conf, restarting SSSD, getting the groups with getent and posting the contents of /var/log/sssd/ ?
Also, there seems to be another issue - with "max_id = 3000000001", SSSD should never return a gid of 3000000004 or 3000000002 as seen in the opening comment.
Oh, sorry, there's also "min_id = 1000000001", so the admins group ID is out of range. I think this is a duplicate of https://fedorahosted.org/sssd/ticket/834 - can you tell us what SSSD version are you running?
Version is 1.5.6.1 right now but I have used pretty much all version starting from 1.2 series.
After removing sssd database non existing gid's did disappear. But now user groups only report primary group.
{{{
uid=1000000002(raivo) gid=1000000001(ipausers) groups=1000000001(ipausers)
management-1::1000000013:raivo server-1::1000000012:raivo server-2::1000000014:raivo server-3::1000000006:raivo server-4::1000000008:raivo server-5::1000000007:raivo server-6::1000000011:raivo server-7::1000000015:raivo server-8::1000000009:raivo server-9::1000000010:raivo server-10::1000000004:raivo server-11::1000000016:raivo server-12::1000000005:raivo server-13::1000000003:raivo ipausers:*:1000000001:raivo }}}
This is probably some other bug?
No, this is the same as the other bug, but it's manifesting differently.
The "admins" group should be filtered out (since it is lower than min_id). However, due to the bug in ticket #834, it's not filtered out when running the 'id' command.
This is causing it to fall through unintentionally into the code that creates a new group in the SSSD, which automatically assigns a GID greater than the highest one available (in your case, the max_id).
It's a very nuanced issue.
Fields changed
milestone: NEEDS_TRIAGE => SSSD 1.6.0
Marking this bug as a duplicate.
Sala, please file a bug downstream for whatever distribution you are running on. The package maintainer can pull the patch at https://fedorahosted.org/sssd/changeset/89e594e4c5fb392a3ec9507b3f12a4edd339c5c9?format=diff&new=89e594e4c5fb392a3ec9507b3f12a4edd339c5c9 to fix the issue.
resolution: => duplicate status: new => closed
I'm using rhel and gentoo. Gentoo does not have sssd on official portage yet.
Thanks. This patch worked.
rhbz: => 0
Metadata Update from @sala: - Issue set to the milestone: SSSD 1.6.0
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/1896
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.