We also see when running either id -a on a user or the groups command sometimes all the users groups will be fully populated and other times we see nothing at all. Only sss_cache -E restores a fully populated listing. Groups in general can have issues. And as you can imagine this can play heck with nfs and 16 group limits or even with linux and manage-gids if the users groups don't show to send to the nfs server, access denied
Apologies sssduser. Will remain quiet for now. Not trying to derail the original purpose here On Fri, Jul 20, 2018 at 5:49 PM, jsl6uy js16uy <js1...@gmail.com> wrote: > Really? no attitude pure question. We see the same thing. These are AD > groups sssd is complaining about. We use 1.16.1 on Ubu and Centos and > see the same behavior > You're saying below should be files vs compat? > passwd: compat sss > group: compat sss > > Don't get me wrong, thanks for the interaction on this and thanks to > sssdusers asking the original posted question. It really annoys our > users > > > > > On Fri, Jul 20, 2018 at 4:55 PM, Joakim Tjernlund > <joakim.tjernl...@infinera.com> wrote: >> Start with replacing compat with files in nsswitch.conf >> >> >> >> ________________________________ >> From: sssdusers.20.retin...@spamgourmet.com >> <sssdusers.20.retin...@spamgourmet.com> >> Sent: Friday, July 20, 2018 21:47 >> To: sssd-users@lists.fedorahosted.org >> Subject: [SSSD-users] "groups: cannot find name for group ID #####" >> >> CAUTION: This email originated from outside of the organization. Do not >> click links or open attachments unless you recognize the sender and know the >> content is safe. >> >> Hi, I was wondering if anyone has successfully fixed this. >> >> I'm working on upgrading servers and client machines, and any time I use a >> newer SSSD package I'm unable to get groups for the users when they log in. >> (This is SSSD 1.16.1 on ubt18.04). >> >> The problem can be summed up as, >> root@ubt18-test:# sssd --version >> 1.16.1 >> root@ubt18-test:# groups user1 >> user1 : groups: cannot find name for group ID 33111 >> 33111 groups: cannot find name for group ID 33118 >> 33118 >> >> root@ubt18-test:# getent group | grep 33111 >> unix_users:*:33111: >> >> root@ubt18-test:# groups user2 >> user2 : groups: cannot find name for group ID 33111 >> 33111 >> >> root@ubt18-test:# su user2 >> groups: cannot find name for group ID 33111 >> >> user2@ubt18-test:$ groups >> groups: cannot find name for group ID 33111 >> 33111 >> -- >> root@ubt18-test:# getent group unix_users >> unix_users:*:33111: >> >> root@ubt18-test:# groups user2 >> user2 : unix_users >> >> root@blair-ubt18-test:/var/log/sssd# groups user1 >> user1 : unix_users groups: cannot find name for group ID 33118 >> 33118 >> >> >> This is an odd sequence of events, but notice that I can't get the group for >> a given user. It shows up only as GID. However, that GID _is_ listed in the >> output of `getent group`, so it's there, the system can see it, and SSSD is >> aware of it. Trying again, that gid still won't map to a name when I get the >> user's groups. >> >> The odd part is that if I get the group specifically (`getent group >> unix_users`), then the mapping for that group thereafter succeeds. Does >> anyone know what's going on? Of course, everything is working as expected >> with an earlier version -- 1.13.4. >> >> The only fix that I've seen is to recreate every LDAP group in the local >> groups file, but that seems contrary to the point of using LDAP. I'd like to >> avoid it. >> >> /etc/nsswitch.conf: >> #passwd: compat systemd sss >> #group: compat systemd sss >> passwd: compat sss >> group: compat sss >> # it's the same with/without systemd >> >> /etc/sssd/sssd.conf: >> [domain/LOCAL] >> enumerate = True >> id_provider = local >> max_id = 9999 >> min_id = 1000 >> >> [domain/MYDOMAIN] >> access_provider = simple >> auth_provider = krb5 >> debug_level = 0xFF0 >> cache_credentials = True >> chpass_provider = krb5 >> enumerate = True >> id_provider = ldap >> krb5_kpasswd = core-dc1.mydomain.cxm >> krb5_realm = mydomain.cxm >> krb5_renewable_lifetime = 7d >> krb5_server = core-dc1.mydomain.cxm >> ldap_default_authtok = thepassword >> ldap_default_authtok_type = password >> ldap_default_bind_dn = cn=LDAP >> Bind,ou=ServiceAccounts,ou=_MyDomain,dc=mydomain,dc=cxm >> ldap_group_object_class = group >> ldap_group_search_base = OU=_MyDomain,DC=MYDOMAIN,DC=CXM >> ldap_search_base = DC=MYDOMAIN,DC=CXM >> ldap_tls_reqcert = never >> ldap_uri = ldap://core-dc1.mydomain.cxm >> ldap_user_home_directory = unixHomeDirectory >> ldap_user_name = sAMAccountName >> ldap_user_object_class = user >> ldap_user_search_base = OU=_MyDomain,DC=MYDOMAIN,DC=CXM >> >> [nss] >> filter_groups = root >> filter_users = root >> reconnection_retries = 50 >> >> [pam] >> pam_verbosity = 3 >> reconnection_retries = 50 >> >> [sssd] >> config_file_version = 2 >> debug_level = 0xFF0 >> domains = LOCAL, MYDOMAIN >> reconnection_retries = 50 >> sbus_timeout = 5 >> services = nss, pam >> >> _______________________________________________ >> sssd-users mailing list -- sssd-users@lists.fedorahosted.org >> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org >> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/2BIF2PIZLWV77GW5P2M4XZEEURMTDN2O/ >> _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/GMIKIJVVWWTAMOEP5FO3M2WWF5V7OPVM/
