[SSSD-users] Re: \groups: cannot find name for group ID #####\

[Joakim Tjernlund]

Yes, that compat. Compat can be a problem, you do not need it. I am on vacation and only
have my phone so no long emails, sorry.

Skaffa Outlook f?r Android<https://aka.ms/ghei36>

________________________________
From: jsl6uy js16uy <js16uy(a)gmail.com&gt;
Sent: Friday, July 20, 2018 6:49:35 PM
To: End-user discussions about the System Security Services Daemon
Subject: [SSSD-users] Re: "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.


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.Tjernlund(a)infinera.com&gt; wrote:
>  Start with replacing compat with files in nsswitch.conf
>
>
>
>  ________________________________
>  From: sssdusers.20.retinkab(a)spamgourmet.com
>  <sssdusers.20.retinkab(a)spamgourmet.com&gt;
>  Sent: Friday, July 20, 2018 21:47
>  To: sssd-users(a)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(a)lists.fedorahosted.org
>  To unsubscribe send an email to sssd-users-leave(a)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/[e-mail]...
>  
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)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/[e-mail]...