sssd-users May 2018

sssd-users@lists.fedorahosted.org

24 participants
30 discussions

sssd performance on large domains
by zfnoctis＠gmail.com 03 Feb '22

03 Feb '22

Hi, I'm wondering if there are any plans to improve sssd performance on large active directory domains (100k+ users, 40k+ groups), or if there are settings I am not aware of that can greatly improve performance, specifically for workstation use cases. Currently if I do not set "ignore_group_members = True" in sssd.conf, logins can take upwards of 6 minutes and "sssd_be" will max the CPU for up to 20 minutes after logon, which makes it a non-starter. The reason I want to allow group members to be seen is that I want certain domain groups to be able to perform elevated actions using polkit. If I ignore group members, polkit reports that the group is empty and so no one can elevate in the graphical environment. Ultimately this means that Linux workstations are at a severe disadvantage since they cannot be bound to the domain and have the normal set of access features users and IT expect from macOS or Windows. Distributions used: Ubuntu 16.04 (sssd 1.13.4-1ubuntu1.1), Ubuntu 16.10 (sssd 1.13.4-3) and Fedora 24 (sssd-1.13.4-3.fc24). All exhibit the same problems. I've also tried "ldap_group_nesting_level = 1" without seeing any noticeable improvement with respect to performance. Putting the database on /tmp isn't viable as these are workstations that will reboot semi-frequently, and I don't believe this is an I/O bound performance issue anyways. Thanks for your time.

6 29

Enumerate users from external group from AD trust
by Bolke de Bruin 29 Nov '19

29 Nov '19

Hello, I have sssd 1.13.00 working against FreeIPA 4.2 domain. This domain has a trust relationship with a active directory domain. One of the systems we are using requires to enumerate all users in groups by (unfortunate) design (Apache Ranger). This is done by using “getent group”. During this enumeration the full user list for a group that has a nested external member group* is not always returned so we thought to add “getent group mygroup” in order to get more details. Unfortunately this does not seem to work consistently: sometimes this gives information sometimes it does not: [root@master centos]# getent group ad_users ad_users:*:1950000004: [root@master centos]# id bolke(a)ad.local UID=1796201107(bolke(a)ad.local) GID=1796201107(bolke(a)ad.local) groepen=1796201107(bolke(a)ad.local),1796200513(domain users@ad.local),1796201108(test@ad.local) [root@master centos]# getent group ad_users ad_users:*:1950000004:bolke@ad.local <mailto:bolke@ad.local> If I clear the cache (sss_cache -E) the entry is gone again: [root@master centos]# getent group ad_users ad_users:*:1950000004: My question is how do I get sssd to enumerate *all users* in a group consistently? Thanks! Bolke * https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/trust-gro…

3 15

SSSD strangeness
by simonc99＠hotmail.com 05 Nov '19

05 Nov '19

Hi All We've got SSSD 1.13.0 installed as part of a Centos 7.2.1511 installation. We've used realmd to join the host concerned to our 2008R2 AD system. This went really well, and consequently we've been using SSSD to provide login services and kerberos integration for our fairly large hadoop system. The authconfig that's implicitly run as part of realmd produces the following sssd.conf: [sssd] domains = <joined domain> config_file_version = 2 services = nss, pam [pam] debug_level = 0x0080 [nss] timeout = 20 force_timeout = 600 debug_level = 0x0080 [domain/<joined domain>] ad_domain = <joined domain> krb5_realm = <JOINED DOMAIN> realmd_tags = manages-system joined-with-samba cache_credentials = true id_provider = ad krb5_store_password_if_offline = True default_shell = /bin/bash ldap_id_mapping = True use_fully_qualified_names = False fallback_homedir = /home/%u@%d access_provider = simple simple_allow_groups = <AD group allowing logins> krb5_use_kdc_info = False entry_cache_timeout = 300 debug_level = 0x0080 ad_server = <active directory server> As I've said - this works really well. We did have some stability issues initially, but they've been fixed by defining the 'ad_server' rather than using autodiscovery. Logins work fine, kerberos TGTs are issued on login, and password changes are honoured correctly. However, in general day to day use, we have noticed a few anomalies, that we just can't track down. Firstly (this has happened a few times), a user will change their AD password (via a Windows PC). Subsequent logins - sometimes with specific client software - fail with pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=<remote PC name> user=<username> pam_sss(sshd:auth): received for user <username>: 17 (failure setting user credentials) So in this example, the person concerned has changed their AD password. Further attempts to access this system via SSH work fine. However, using SFTP doesn't work (the above is output into /var/log/secure). There are no local controls on sftp logins, and the user concerned was working fine (using both sftp and ssh) until they updated their password. There is no separate sftp daemon running, and it only affects one individual currently (but we have seen some very similar instances before) The second issue we have is around phantom groups in AD. Hadoop uses an id -Gn command to see group membership for authorisation. With some users - we've seen 6 currently - we see certain groups failing to be looked up: id -Gn <username> id: cannot find name for group ID xxxxyyyyy <group name> <group name> <group name> <group name> <etc...> The xxxxyyyyy indicates: xxxx = hashed realm name yyyyy = RID from group in AD We can't find any group with that number on the AD side! We can work around this by adding a local group (into /etc/group) for the GIDs affected. This means the id -Gn runs correctly, and the hadoop namenode can function correctly - but this is a workaround and we'd like to get to the bottom of the issue. Rather than flooding this post now with logfiles, just thought I'd see if this looked familiar to anyone. Happy to upload any logs, amend logging levels, etc. Many thanks Simon

4 7

Multiple GPOs and order processing issue
by Max DiOrio 21 Jun '18

21 Jun '18

Hi! So it seems that I’m having an issue with GPO processing. I have an OU (Servers/Infrastructure) that contains a few servers. In this OU, I have a few GPO’s applied. Once is “generic” that should applied to every server in this OU - which allows Remote Interactive Login and Logon Locally to Domain Admins. I also have a GPO that applies to a specific server in this out that grants access to a service account to log on to terminal services and log on as a service. For this GPO, I have a security filter to the specific computer object it is supposed to apply to - and I think this is the root of my issue. The GPOs are listed 1) Infrastructure servers Access Control (that should apply to them all) 2) Single Computer policy for service account When looking at the sssd_domain logs, I can see that it’s processing both GPO’s, but only adding the account from policy 2 to the ad_gpo_access_check, meaning domain admins can’t log in to either server, only the service account can to both of them. So we have multiple issues: 1) It’s not combining the GPO access policies, but only taking the last one found 2) It’s not abiding by the Security Filtering on the GPO So in my case - how would I go about making this work? Would I need a separate GPO for each server I want to apply individual rights to and explicitly include the domain admins group in it, then using delegation allow the single computer read and deny read of every other computer? Seems like this also means you can’t do GPO inheritance if it only takes the last found GPO and ignores the settings configured in previous GPO’s it checked. Any ideas? Thanks! Max

3 11

Nested LDAP groups and filtering
by Christian Svensson 04 Jun '18

04 Jun '18

Hi sssd-users, My LDAP setup contains two bases: dc=office1,dc=company,dc=tld dc=office2,dc=company,dc=tld Groups can cross-reference other groups in the two bases, like this: cn=printer-access,ou=groups,dc=office1,dc=company,dc=tld - member: cn=everybody,ou=groups,dc=office1,dc=company,dc=tld - member: cn=everybody,ou=groups,dc=office2,dc=company,dc=tld cn=printer-access,ou=groups,dc=office2,dc=company,dc=tld - member: cn=everybody,ou=groups,dc=office2,dc=company,dc=tld What I'm trying achieve is to have a server belonging to office1 being able to expand all groups, even if the references are across office boundary, but only see the leaf groups that are in its own base. What I've tried is something like this: [domain/office1] debug_level = 9 enumerate = true cache_credentials = true entry_cache_timeout = 600 id_provider = ldap auth_provider = ldap chpass_provider = ldap ldap_search_base = dc=company,dc=tld ldap_group_search_base = dc=office1,dc=company,dc=tld # Also tried with: # ldap_group_search_base = dc=company,dc=tld?subtree?(dc:dn:=office1) ldap_schema = rfc2307bis ldap_group_member = member ldap_group_nesting_level = 5 ldap_uri = ldaps://xxx ldap_tls_reqcert = hard ldap_tls_cacert = /etc/ssl/ldap-ca.crt Sadly this does not work, which I'm not that surprised over. The lookup logic reports: (Sun May 20 14:00:29 2018) [sssd[be[ office1]]] [sdap_save_grpmem] (0x0400): Adding member users to group [printer-access@office1] (Sun May 20 14:00:29 2018) [sssd[be[ office1]]] [sdap_find_entry_by_origDN] (0x4000): Searching cache for [ cn=everybody,ou=groups,dc=office2,dc=company,dc=tld]. (Sun May 20 14:00:29 2018) [sssd[be[ office1]]] [sdap_fill_memberships] (0x0080): Member [ cn=everybody,ou=groups,dc=office2,dc=company,dc=tld] was not found in cache. Is it out of scope? Looking at the way things are executed in code and logs it seems like there is no "post processing" to drop groups based on LDAP attributes, nor is there any way for me to add attributes to the full name of the resource to disambiguate them. Those are the two ways I've been attacking this, and both seems to not be supported. Are my observations correct? Is there a workaround other than making sure groups have unique names across the whole company? When groups are not colliding in name everything works just fine if I put " ldap_group_search_base = dc=company,dc=tld", but I'd prefer if I could avoid having to resort to globally unique group names. Thanks, P.S. My groups are named differently and have been renamed in the log messages. Let me know if something doesn't make sense and I might have typo'd a replacement.

2 3

Server not found in Kerberos database and debug level 11
by JOHE (John Hearns) 01 Jun '18

01 Jun '18

I would appreciate some pointers. I have a sandbox setup running on VMs. There is an AD controller using the VM image which Microsoft has available for testing. I have created a domain called ad.test On my client machine I am continually getting this error: [sssd[be[adtest.private]]] [ad_sasl_log] (0x0040): SASL: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server not found in Kerberos database) On the client klist-k | uniq returns KVNO Principal ---- -------------------------------------------------------------------------- 3 CLIENT1$(a)ADTEST.PRIVATE 3 host/CLIENT1(a)ADTEST.PRIVATE 3 host/client1(a)ADTEST.PRIVATE 3 RestrictedKrbHost/CLIENT1(a)ADTEST.PRIVATE 3 RestrictedKrbHost/client1(a)ADTEST.PRIVATE The funny thing is ONLY kinit -k CLIENT1$\(a)ADTEST.PRIVATE will work. I do get a tgt: Ticket cache: FILE:/tmp/krb5cc_0 Default principal: CLIENT1$(a)ADTEST.PRIVATE Just in the sandbox I am also setting: ldap_auth_disable_tls_never_use_in_production = true Any pointers please? I have cranked debug up to 8 and this error message seems to be the crucial one. By the way, why does the debug level not go up to 11?

4 7

Long groups resolution time
by JOHE (John Hearns) 29 May '18

29 May '18

I am still having a lot of problems with group resolution in sssd. User logins can take anything up to two minutes, or longer. When I time the command groups username for a selected username thish can take two or more minutes to return. I have this set: ldap_schema = ad ldap_group_nesting_level = 0 ldap_groups_use_matching_rule_in_chain = True ldap_initgroups_use_matching_rule_in_chain = True How can one tell what the appropriate ldap_schema is for our AD controllers? Also the information is not cached for long enough. I set enum_cache_timeout = 1200 entry_cache_timeout = 5400 entry_cache_user_timeout = 5400 entry_cache_group_timeput = 5400 I really do not see groups information being cached for 90 minutes

1 0

Recommended ldb version
by Joakim Tjernlund 26 May '18

26 May '18

Which version(s) of ldb (http://ldb.samba.org) works well for sssd? I noticed I have 1.1.29 here which feels a bit old. Jocke

3 5

Re: Experiencing a bug on users' name and ID
by Asif Iqbal 25 May '18

25 May '18

I still like some help with any workaround in dealing with string. IT LDAP team do not have any attribute value with real number. Is it possible to create a local DB to map the mnetid to a real number and then use that table as a reference for ID mapping? I am not sure if this discussion should be in developer mailing list. Appreciate any help On Mar 8, 2018 11:29 PM, "Asif Iqbal" <vadud3(a)gmail.com> wrote: On Wed, Feb 28, 2018 at 4:27 PM, Jakub Hrozek <jhrozek(a)redhat.com> wrote: > I think the next good step would be to show the LDIF and logs of a > resolution of a single faulty entry, e.g. 80974 which you used earlier as > an example of an entry that doesn’t work. > Here are some logs for this account dn: uid=mwvande,ou=People,dc=mnet,dc=qintra,dc=com mnetid: 004311 (Thu Mar 8 22:10:22 2018) [sssd[be[LDAP]]] [dp_get_account_info_handler] (0x0200): Got request for [0x1][BE_REQ_USER][idnumber=4311] (Thu Mar 8 22:10:22 2018) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(mnetid=4311)(objectclass= mnetPerson)(uid=*)(&(mnetid=*)(!(mnetid=0))))][ou=People,dc= mnet,dc=qintra,dc=com]. (Thu Mar 8 22:10:22 2018) [sssd[be[LDAP]]] [dp_table_value_destructor] (0x0400): Removing [0:1:0x0001:1::LDAP:idnumber=4311] from reply table (Thu Mar 8 22:10:29 2018) [sssd[be[LDAP]]] [dp_get_account_info_handler] (0x0200): Got request for [0x2][BE_REQ_GROUP][idnumber=4311] (Thu Mar 8 22:10:29 2018) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(mnetid=4311)(objectClass= inetOrgPerson)(uid=*)(&(mnetid=*)(!(mnetid=0))))][ou= People,dc=mnet,dc=qintra,dc=com]. (Thu Mar 8 22:10:29 2018) [sssd[be[LDAP]]] [dp_table_value_destructor] (0x0400): Removing [0:1:0x0001:2::LDAP:idnumber=4311] from reply table (Thu Mar 8 22:11:14 2018) [sssd[be[LDAP]]] [dp_get_account_info_handler] (0x0200): Got request for [0x1][BE_REQ_USER][name=4311@ldap] (Thu Mar 8 22:11:14 2018) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(uid=4311)(objectclass= mnetPerson)(uid=*)(&(mnetid=*)(!(mnetid=0))))][ou=People,dc= mnet,dc=qintra,dc=com]. (Thu Mar 8 22:11:14 2018) [sssd[be[LDAP]]] [dp_table_value_destructor] (0x0400): Removing [0:1:0x0001:1::LDAP:name=4311@ldap] from reply table (Thu Mar 8 22:11:14 2018) [sssd[be[LDAP]]] [dp_get_account_info_handler] (0x0200): Got request for [0x1][BE_REQ_USER][idnumber=4311] (Thu Mar 8 22:11:14 2018) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(mnetid=4311)(objectclass= mnetPerson)(uid=*)(&(mnetid=*)(!(mnetid=0))))][ou=People,dc= mnet,dc=qintra,dc=com]. (Thu Mar 8 22:11:14 2018) [sssd[be[LDAP]]] [dp_table_value_destructor] (0x0400): Removing [0:1:0x0001:1::LDAP:idnumber=4311] from reply table (Thu Mar 8 22:11:38 2018) [sssd[be[LDAP]]] [dp_get_account_info_handler] (0x0200): Got request for [0x2][BE_REQ_GROUP][idnumber=4311] (Thu Mar 8 22:11:38 2018) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(mnetid=4311)(objectClass= inetOrgPerson)(uid=*)(&(mnetid=*)(!(mnetid=0))))][ou= People,dc=mnet,dc=qintra,dc=com]. (Thu Mar 8 22:11:38 2018) [sssd[be[LDAP]]] [dp_table_value_destructor] (0x0400): Removing [0:1:0x0001:2::LDAP:idnumber=4311] from reply table (Thu Mar 8 22:12:00 2018) [sssd[be[LDAP]]] [dp_get_account_info_handler] (0x0200): Got request for [0x2][BE_REQ_GROUP][idnumber=4311] (Thu Mar 8 22:12:00 2018) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(mnetid=4311)(objectClass= inetOrgPerson)(uid=*)(&(mnetid=*)(!(mnetid=0))))][ou= People,dc=mnet,dc=qintra,dc=com]. (Thu Mar 8 22:12:00 2018) [sssd[be[LDAP]]] [dp_table_value_destructor] (0x0400): Removing [0:1:0x0001:2::LDAP:idnumber=4311] from reply table (Thu Mar 8 22:10:22 2018) [sssd[nss]] [nss_getby_id] (0x0400): Input ID: 4311 (Thu Mar 8 22:10:22 2018) [sssd[nss]] [cache_req_search_send] (0x0400): CR #913574: Looking up UID:4311@LDAP (Thu Mar 8 22:10:22 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR #913574: Checking negative cache for [UID:4311@LDAP] (Thu Mar 8 22:10:22 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR #913574: [UID:4311@LDAP] is not present in negative cache (Thu Mar 8 22:10:22 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #913574: Looking up [UID:4311@LDAP] in cache (Thu Mar 8 22:10:22 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #913574: Object [UID:4311@LDAP] was not found in cache (Thu Mar 8 22:10:22 2018) [sssd[nss]] [cache_req_search_dp] (0x0400): CR #913574: Looking up [UID:4311@LDAP] in data provider (Thu Mar 8 22:10:22 2018) [sssd[nss]] [sss_dp_issue_request] (0x0400): Issuing request for [0x5641be284b10:1:4311@LDAP] (Thu Mar 8 22:10:22 2018) [sssd[nss]] [sss_dp_get_account_msg] (0x0400): Creating request for [LDAP][0x1][BE_REQ_USER][idnumber=4311:-] (Thu Mar 8 22:10:22 2018) [sssd[nss]] [sss_dp_internal_get_send] (0x0400): Entering request [0x5641be284b10:1:4311@LDAP] (Thu Mar 8 22:10:22 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #913574: Looking up [UID:4311@LDAP] in cache (Thu Mar 8 22:10:22 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #913574: Object [UID:4311@LDAP] was not found in cache (Thu Mar 8 22:10:22 2018) [sssd[nss]] [cache_req_global_ncache_add] (0x0400): CR #913574: Adding [UID:4311@LDAP] to global negative cache (Thu Mar 8 22:10:22 2018) [sssd[nss]] [sss_ncache_set_str] (0x0400): Adding [NCE/UID/4311] to negative cache (Thu Mar 8 22:10:22 2018) [sssd[nss]] [sss_dp_req_destructor] (0x0400): Deleting request: [0x5641be284b10:1:4311@LDAP] (Thu Mar 8 22:10:29 2018) [sssd[nss]] [nss_getby_id] (0x0400): Input ID: 4311 (Thu Mar 8 22:10:29 2018) [sssd[nss]] [cache_req_search_send] (0x0400): CR #913598: Looking up GID:4311@LDAP (Thu Mar 8 22:10:29 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR #913598: Checking negative cache for [GID:4311@LDAP] (Thu Mar 8 22:10:29 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR #913598: [GID:4311@LDAP] is not present in negative cache (Thu Mar 8 22:10:29 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #913598: Looking up [GID:4311@LDAP] in cache (Thu Mar 8 22:10:29 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #913598: Object [GID:4311@LDAP] was not found in cache (Thu Mar 8 22:10:29 2018) [sssd[nss]] [cache_req_search_dp] (0x0400): CR #913598: Looking up [GID:4311@LDAP] in data provider (Thu Mar 8 22:10:29 2018) [sssd[nss]] [sss_dp_issue_request] (0x0400): Issuing request for [0x5641be284b10:2:4311@LDAP] (Thu Mar 8 22:10:29 2018) [sssd[nss]] [sss_dp_get_account_msg] (0x0400): Creating request for [LDAP][0x2][BE_REQ_GROUP][idnumber=4311:-] (Thu Mar 8 22:10:29 2018) [sssd[nss]] [sss_dp_internal_get_send] (0x0400): Entering request [0x5641be284b10:2:4311@LDAP] (Thu Mar 8 22:10:29 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #913598: Looking up [GID:4311@LDAP] in cache (Thu Mar 8 22:10:29 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #913598: Object [GID:4311@LDAP] was not found in cache (Thu Mar 8 22:10:29 2018) [sssd[nss]] [cache_req_global_ncache_add] (0x0400): CR #913598: Adding [GID:4311@LDAP] to global negative cache (Thu Mar 8 22:10:29 2018) [sssd[nss]] [sss_ncache_set_str] (0x0400): Adding [NCE/GID/4311] to negative cache (Thu Mar 8 22:10:29 2018) [sssd[nss]] [sss_dp_req_destructor] (0x0400): Deleting request: [0x5641be284b10:2:4311@LDAP] (Thu Mar 8 22:11:14 2018) [sssd[nss]] [nss_getby_name] (0x0400): Input name: 4311 (Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_process_input] (0x0400): CR #913740: Parsing input name [4311] (Thu Mar 8 22:11:14 2018) [sssd[nss]] [sss_parse_name_for_domains] (0x0200): name '4311' matched without domain, user is 4311 (Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_set_name] (0x0400): CR #913740: Setting name [4311] (Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_search_send] (0x0400): CR #913740: Looking up 4311@ldap (Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR #913740: Checking negative cache for [4311@ldap] (Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR #913740: [4311@ldap] is not present in negative cache (Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #913740: Looking up [4311@ldap] in cache (Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #913740: Object [4311@ldap] was not found in cache (Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_search_dp] (0x0400): CR #913740: Looking up [4311@ldap] in data provider (Thu Mar 8 22:11:14 2018) [sssd[nss]] [sss_dp_issue_request] (0x0400): Issuing request for [0x5641be284b10:1:4311@ldap@LDAP] (Thu Mar 8 22:11:14 2018) [sssd[nss]] [sss_dp_get_account_msg] (0x0400): Creating request for [LDAP][0x1][BE_REQ_USER][name=4311@ldap:-] (Thu Mar 8 22:11:14 2018) [sssd[nss]] [sss_dp_internal_get_send] (0x0400): Entering request [0x5641be284b10:1:4311@ldap@LDAP] (Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #913740: Looking up [4311@ldap] in cache (Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #913740: Object [4311@ldap] was not found in cache (Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_search_ncache_add] (0x0400): CR #913740: Adding [4311@ldap] to negative cache (Thu Mar 8 22:11:14 2018) [sssd[nss]] [sss_ncache_set_str] (0x0400): Adding [NCE/USER/LDAP/4311@ldap] to negative cache (Thu Mar 8 22:11:14 2018) [sssd[nss]] [sss_dp_req_destructor] (0x0400): Deleting request: [0x5641be284b10:1:4311@ldap@LDAP] (Thu Mar 8 22:11:14 2018) [sssd[nss]] [nss_getby_id] (0x0400): Input ID: 4311 (Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_search_send] (0x0400): CR #913741: Looking up UID:4311@LDAP (Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR #913741: Checking negative cache for [UID:4311@LDAP] (Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR #913741: [UID:4311@LDAP] is not present in negative cache (Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #913741: Looking up [UID:4311@LDAP] in cache (Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #913741: Object [UID:4311@LDAP] was not found in cache (Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_search_dp] (0x0400): CR #913741: Looking up [UID:4311@LDAP] in data provider (Thu Mar 8 22:11:14 2018) [sssd[nss]] [sss_dp_issue_request] (0x0400): Issuing request for [0x5641be284b10:1:4311@LDAP] (Thu Mar 8 22:11:14 2018) [sssd[nss]] [sss_dp_get_account_msg] (0x0400): Creating request for [LDAP][0x1][BE_REQ_USER][idnumber=4311:-] (Thu Mar 8 22:11:14 2018) [sssd[nss]] [sss_dp_internal_get_send] (0x0400): Entering request [0x5641be284b10:1:4311@LDAP] (Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #913741: Looking up [UID:4311@LDAP] in cache (Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #913741: Object [UID:4311@LDAP] was not found in cache (Thu Mar 8 22:11:14 2018) [sssd[nss]] [cache_req_global_ncache_add] (0x0400): CR #913741: Adding [UID:4311@LDAP] to global negative cache (Thu Mar 8 22:11:14 2018) [sssd[nss]] [sss_ncache_set_str] (0x0400): Adding [NCE/UID/4311] to negative cache (Thu Mar 8 22:11:14 2018) [sssd[nss]] [sss_dp_req_destructor] (0x0400): Deleting request: [0x5641be284b10:1:4311@LDAP] (Thu Mar 8 22:11:15 2018) [sssd[nss]] [nss_getby_name] (0x0400): Input name: 4311 (Thu Mar 8 22:11:15 2018) [sssd[nss]] [cache_req_process_input] (0x0400): CR #913742: Parsing input name [4311] (Thu Mar 8 22:11:15 2018) [sssd[nss]] [sss_parse_name_for_domains] (0x0200): name '4311' matched without domain, user is 4311 (Thu Mar 8 22:11:15 2018) [sssd[nss]] [cache_req_set_name] (0x0400): CR #913742: Setting name [4311] (Thu Mar 8 22:11:15 2018) [sssd[nss]] [cache_req_search_send] (0x0400): CR #913742: Looking up 4311@ldap (Thu Mar 8 22:11:15 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR #913742: Checking negative cache for [4311@ldap] (Thu Mar 8 22:11:15 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR #913742: [4311@ldap] does not exist (negative cache) (Thu Mar 8 22:11:15 2018) [sssd[nss]] [nss_getby_id] (0x0400): Input ID: 4311 (Thu Mar 8 22:11:15 2018) [sssd[nss]] [cache_req_search_send] (0x0400): CR #913743: Looking up UID:4311@LDAP (Thu Mar 8 22:11:15 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR #913743: Checking negative cache for [UID:4311@LDAP] (Thu Mar 8 22:11:15 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR #913743: [UID:4311@LDAP] does not exist (negative cache) (Thu Mar 8 22:11:38 2018) [sssd[nss]] [nss_getby_id] (0x0400): Input ID: 4311 (Thu Mar 8 22:11:38 2018) [sssd[nss]] [cache_req_search_send] (0x0400): CR #913764: Looking up GID:4311@LDAP (Thu Mar 8 22:11:38 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR #913764: Checking negative cache for [GID:4311@LDAP] (Thu Mar 8 22:11:38 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR #913764: [GID:4311@LDAP] is not present in negative cache (Thu Mar 8 22:11:38 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #913764: Looking up [GID:4311@LDAP] in cache (Thu Mar 8 22:11:38 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #913764: Object [GID:4311@LDAP] was not found in cache (Thu Mar 8 22:11:38 2018) [sssd[nss]] [cache_req_search_dp] (0x0400): CR #913764: Looking up [GID:4311@LDAP] in data provider (Thu Mar 8 22:11:38 2018) [sssd[nss]] [sss_dp_issue_request] (0x0400): Issuing request for [0x5641be284b10:2:4311@LDAP] (Thu Mar 8 22:11:38 2018) [sssd[nss]] [sss_dp_get_account_msg] (0x0400): Creating request for [LDAP][0x2][BE_REQ_GROUP][idnumber=4311:-] (Thu Mar 8 22:11:38 2018) [sssd[nss]] [sss_dp_internal_get_send] (0x0400): Entering request [0x5641be284b10:2:4311@LDAP] (Thu Mar 8 22:11:38 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #913764: Looking up [GID:4311@LDAP] in cache (Thu Mar 8 22:11:38 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #913764: Object [GID:4311@LDAP] was not found in cache (Thu Mar 8 22:11:38 2018) [sssd[nss]] [cache_req_global_ncache_add] (0x0400): CR #913764: Adding [GID:4311@LDAP] to global negative cache (Thu Mar 8 22:11:38 2018) [sssd[nss]] [sss_ncache_set_str] (0x0400): Adding [NCE/GID/4311] to negative cache (Thu Mar 8 22:11:38 2018) [sssd[nss]] [sss_dp_req_destructor] (0x0400): Deleting request: [0x5641be284b10:2:4311@LDAP] (Thu Mar 8 22:12:00 2018) [sssd[nss]] [nss_getby_id] (0x0400): Input ID: 4311 (Thu Mar 8 22:12:00 2018) [sssd[nss]] [cache_req_search_send] (0x0400): CR #913765: Looking up GID:4311@LDAP (Thu Mar 8 22:12:00 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR #913765: Checking negative cache for [GID:4311@LDAP] (Thu Mar 8 22:12:00 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR #913765: [GID:4311@LDAP] is not present in negative cache (Thu Mar 8 22:12:00 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #913765: Looking up [GID:4311@LDAP] in cache (Thu Mar 8 22:12:00 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #913765: Object [GID:4311@LDAP] was not found in cache (Thu Mar 8 22:12:00 2018) [sssd[nss]] [cache_req_search_dp] (0x0400): CR #913765: Looking up [GID:4311@LDAP] in data provider (Thu Mar 8 22:12:00 2018) [sssd[nss]] [sss_dp_issue_request] (0x0400): Issuing request for [0x5641be284b10:2:4311@LDAP] (Thu Mar 8 22:12:00 2018) [sssd[nss]] [sss_dp_get_account_msg] (0x0400): Creating request for [LDAP][0x2][BE_REQ_GROUP][idnumber=4311:-] (Thu Mar 8 22:12:00 2018) [sssd[nss]] [sss_dp_internal_get_send] (0x0400): Entering request [0x5641be284b10:2:4311@LDAP] (Thu Mar 8 22:12:00 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #913765: Looking up [GID:4311@LDAP] in cache (Thu Mar 8 22:12:00 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #913765: Object [GID:4311@LDAP] was not found in cache (Thu Mar 8 22:12:00 2018) [sssd[nss]] [cache_req_global_ncache_add] (0x0400): CR #913765: Adding [GID:4311@LDAP] to global negative cache (Thu Mar 8 22:12:00 2018) [sssd[nss]] [sss_ncache_set_str] (0x0400): Adding [NCE/GID/4311] to negative cache (Thu Mar 8 22:12:00 2018) [sssd[nss]] [sss_dp_req_destructor] (0x0400): Deleting request: [0x5641be284b10:2:4311@LDAP] > > > On 28 Feb 2018, at 01:30, Asif Iqbal <vadud3(a)gmail.com> wrote: > > > > > > > > On Tue, Feb 27, 2018 at 1:12 PM, Asif Iqbal <vadud3(a)gmail.com> wrote: > > > > > > On Tue, Feb 27, 2018 at 3:37 AM, Sumit Bose <sbose(a)redhat.com> wrote: > > On Mon, Feb 26, 2018 at 10:21:14PM -0500, Asif Iqbal wrote: > > > I have 300 out of 3000 users whose /home/<username> dir shows uid and > gid > > > instead of username and groupname. > > > > > > It seems to be behaving like a bug > > > > > > As soon I become a user with `sudo su - username' the uid of the home > dir > > > changes to username but gid still does not change to groupname. > > > > > > I also get an error message, but still successfully become that user > > > > > > $ ls -ld /home/mbniels > > > drwx------. 3 80974 80974 4096 Feb 27 02:15 /home/mbniels > > > > > > $ su - mbniels > > > Last login: Tue Feb 27 02:34:04 UTC 2018 on pts/39 > > > /usr/bin/id: cannot find name for group ID 80974 > > > groups: cannot find name for group ID 80974 > > > > > > $ ls -ld /home/mbniels > > > drwx------. 3 mbniels 80974 4096 Feb 27 02:15 /home/mbniels > > > > > > Then to check the groups of username I get another error which then > gets > > > cleared by next command. > > > > > > $ groups mbniels > > > mbniels : groups: cannot find name for group ID 80974 > > > 80974 users > > > > > > $ getent group mbniels > > > mbniels:*:80974 > > > > > > $ groups mbniels > > > mbniels : mbniels users > > > > > > It also fixes the gid to groupname > > > > > > $ ls -ld /home/mbniels/ > > > drwx------. 3 mbniels mbniels 4096 Feb 27 02:15 /home/mbniels/ > > > > > > I noticed it reverts after may be within half an hour, not exact sure > when. > > > Almost behaves like `quantum entanglement'. > > > As soon as I try to check by trying to become that user the issue > > > disappears. > > > > > > This is not just cosmetic issue, when the home dir shows ownership with > > > uid, instead of username, the user fails some commands. > > > > > > We just started noticing today, since we just built this box and only > few > > > months ago and users are being invited to start using this server > > > > > > Some annoying error it is showing like below and user then fails to ssh > > > > > > $ ssh remote > > > No user exists for uid 80974 > > > > > > I am using centos 7 and sssd 1.15.2 > > > > > > $ cat /etc/redhat-release > > > CentOS Linux release 7.4.1708 (Core) > > > > > > $ sssd --version > > > 1.15.2 > > > > > > Here are some relevant logs > > > https://paste.fedoraproject.org/paste/gBaZ-Vr8Urh-M5ABpaRNuA > > > > It looks like you are not using a plain RFC2307bis LDAP schema. Can you > > send you sssd.conf and a typical LDAP user and group object? > > > > bye, > > Sumit > > > > > > Here is an ldap user and I using same info as group (sanitized) > > > > dn: uid=mbniels,ou=People,dc=example,dc=com > > roomNumber: 123456 > > departmentNumber: 3.11.3 > > tier1: Technology > > joblevel: 6 > > legacycompany: G > > mobile: +11234567890 > > manager: uid=managerid,ou=People,dc=example,dc=com > > departmentname: TESTING & INTEG > > costcenter: S0019751 > > companynumber: S001 > > companyname: EXAMPLE COMPANY > > displayName: FOO, BAR > > preferredname: Mark > > docshareaccess: TRUE > > sAMAccountName: mbniels > > l: XX > > street: 123 example ave > > saploginid: foobar > > title: LEAD ARCHITECT > > postalCode: 123456 > > employeeNumber: 00112233 > > mail: foo.bar(a)example.com > > objectClass: top > > objectClass: person > > objectClass: organizationalPerson > > objectClass: inetOrgPerson > > objectClass: mnetPerson > > mnetid: 080974 > > uid: mbniels > > givenName: Mark > > st: XX > > cn: Foo Bar > > sn: Bar > > employeeType: Management > > initials: X > > nationnumber: USA > > nationname: United States > > > > > > > > I am still looking for some help on this. > > > > > > > > -- > > Asif Iqbal > > PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu > > A: Because it messes up the order in which people normally read text. > > Q: Why is top-posting such a bad thing? > > > > _______________________________________________ > > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org > > To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org > _______________________________________________ > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org > To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org > -- Asif Iqbal PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

2 21

Cacheing of group entries
by JOHE (John Hearns) 23 May '18

23 May '18

Another thing which is driving me batty.... I log in via ssh. there is a long pause while the 'groups' utility is run. When I get a prompt I can type 'id myusername' and get an instant response. Five minutes later I open a new terminal on my desktop, and it hangs, again in the groups utility I have set enum_cache_timeout to be 1200. Should I be looking at other cacehing parameters please? From my nss stanza: [nss] filter_users = root, postfix, lightdm filter_groups = root enum_cache_timeout = 1200 entry_negative_timeout = 600

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users May 2018