sssd-users April 2018

sssd-users@lists.fedorahosted.org

18 participants
19 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

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

SSSD for one-way trusted AD domain
by Ondrej Valousek 15 May '18

15 May '18

Hi List, Question, we have joined machine into AD domain B. This domain has one way trust to domain A. No direct connection from domain B network to DCs in domain A is possible. Can we use SSSD to authenticate members in domain A. In windows, this works - but can't get it working in Linux via SSSD (Fedora 25, used realmd for AD join). Thanks, Ondrej ----- The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications(a)s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18.

3 2

Strangeness with groups returned using id user
by Max DiOrio 04 May '18

04 May '18

So we are having issues with a couple servers where users suddenly won't be able to log in. All our auth is done through AD and not a thing has changed. On a working server, I can do 'id username' and get back the proper list of groups the user is a member of. On the non-working server, 'id username' returns *mostly* the same list. However the one group that the user needs to be a member to log in is missing. There are some groups in both lists that that have a group ID, but not a group name. And the one non-working server has a single group entry duplicated. The results of 'id username' match throughout, except the noted areas below and a few entries that are listed out of order between the two. Here are the differences "non-working" on top, "working" on bottom (gs-technology is the group in question that I need on the non-working server). It doesn't make sense that 1002201991 is showing up twice in the list. 1002201991 1002201991(fs01-technology-all(rw)) 1002201620(infrastructureteam) 1002201620 1002201991 1002204761(gs-technology) Thanks! Max

3 7

AD in mixed OS environment with SSSD
by Zdravko Zdravkov 01 May '18

01 May '18

HI all. I've got working samba AD server. It is playing nicely with Windows 10 and also successfully authenticating Linux machines with SSSD. On the Windows machines I have our EMC storage smb mounted via group policy. Managing permissions for users and groups there, as you know, happens with right click, security etc.. As you may have already guessed the troubles come when my Linux machines, that access the storage via nfs mount, need to work with folders and files created from the Windows PCs. Linux doesn't "see" the actual user/group that owns given folder. It interprets it into ID numbers starting from 1000. I'm quite sure that this is common and known issue, but I don't know what is the right way to deal with it, so any wisdom will be helpful. Here's smb.conf from server [global] > netbios name = AD > realm = XXXXXX > server role = active directory domain controller > server services = s3fs, rpc, nbt, wrepl, ldap, cldap, kdc, drepl, > winbindd, ntp_signd, kcc, dnsupdate > workgroup = XXXX > idmap config XXXX:unix_nss_info = yes > log file = /var/log/samba/samba.log > log level = 3 > [netlogon] > path = /usr/local/samba/var/locks/sysvol/XXXXXX/scripts > read only = No > [sysvol] > path = /usr/local/samba/var/locks/sysvol > read only = No also, sssd.conf from client [sssd] > domains = xxxx > config_file_version = 2 > services = nss, pam > [domain/xxxx] > ad_domain = xxxx > krb5_realm = XXXX > 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 > access_provider = ad and nsswitch.conf passwd: files sss > shadow: files sss > group: files sss Will appreciate any wisdom. Thanks! Z

2 2

Realm says Necessary packages are not installed
by JOHE (John Hearns) 26 Apr '18

26 Apr '18

Following a lovely day of fun and games with my physical workstation, where I borked the authentication so much that I had to boot it from a sysrescue thumb drive (http://www.system-rescue-cd.org/ I sleep with one of these under my pillow) I have decided to experiment with some VMs (Vagrant / Virtualbox / Ubuntu) When I run realm join domainname I get: realmd[7008]: ! Necessary packages are not installed: sssd-tools sssd libnss-sss libpam-sss adcli Those packages definitely are installed... I guess others have seen this message? Yeah, Google is my friend.... SystemRescueCd - System Rescue Cd Homepage<http://www.system-rescue-cd.org/> www.system-rescue-cd.org About SystemRescueCd. Description: SystemRescueCd is a Linux system rescue disk available as a bootable CD-ROM or USB stick for administrating or repairing your system and data after a crash.

2 2

Missing keytab == no login ?
by Joakim Tjernlund 24 Apr '18

24 Apr '18

It seems like a missing keytab file prevents any login i a AD connected sssd. Does it need to be so? I have a vague memory from the past that a missing/invalid keytab file only prevented SSO but allowed login using your password ? Jocke

5 9

sssd-1.16.1 loses POSIX group mapped from AD trusted domain
by A.Miroshnichenko＠rtk-dc.ru 24 Apr '18

24 Apr '18

Hi, We have AD-trusted FreeIPA environment. I installed sssd-1.16.1 on IPA servers and client hosts. Posix user group "ad_app_admins" mapped to app-admins@ADTrustedDomain. Sometimes AD user fails to login on hosts. sssd can not see mapping. AD user groups show correct for user, but POSIX user group lost. When login success: sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] [hbac_eval_user_element] (0x1000): [16] groups for [ADuser@ADTrustedDomain] sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] [hbac_eval_user_element] (0x0200): Skipping non-IPA group name=group1@ADTrustedDomain,cn=groups,cn=ADTrustedDomain,cn=sysdb ... sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] [hbac_eval_user_element] (0x0200): Skipping non-IPA group name=app-admins@ADTrustedDomain,cn=groups,cn=ADTrustedDomain,cn=sysdb sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] [hbac_eval_user_element] (0x1000): Added group [ad_app_admins] for user [ADuser] sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] [hbac_rule_debug_print] (0x2000): RULE [allow_admin_mgmt_hosts] [ENABLED]: sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] [hbac_rule_debug_print] (0x2000): services: sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] [hbac_rule_element_debug_print] (0x2000): category [0] [NONE] sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] [hbac_rule_element_debug_print] (0x2000): services_names: sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] [hbac_rule_element_debug_print] (0x2000): [sshd] sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] [hbac_rule_element_debug_print] (0x2000): services_groups (none) sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] [hbac_rule_debug_print] (0x2000): users: sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] [hbac_rule_element_debug_print] (0x2000): category [0] [NONE] sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] [hbac_rule_element_debug_print] (0x2000): users_names (none) sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] [hbac_rule_element_debug_print] (0x2000): users_groups: ... sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] [hbac_rule_element_debug_print] (0x2000): [ad_app_admins] ... sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] [hbac_rule_debug_print] (0x2000): targethosts: sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] [hbac_rule_element_debug_print] (0x2000): category [0] [NONE] sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] [hbac_rule_element_debug_print] (0x2000): targethosts_names (none) sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] [hbac_rule_element_debug_print] (0x2000): targethosts_groups: sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] [hbac_rule_element_debug_print] (0x2000): [admin-mng-hosts] sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] [hbac_rule_debug_print] (0x2000): srchosts: sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] [hbac_rule_element_debug_print] (0x2000): category [0x1] [ALL] sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] [hbac_evaluate] (0x0100): ALLOWED by rule [allow_admin_mgmt_hosts]. sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] [hbac_evaluate] (0x0100): hbac_evaluate() >] sssd_ipa.domain.log:(Wed Apr 11 15:05:36 2018) [sssd[be[ipa.domain]]] [ipa_hbac_evaluate_rules] (0x0080): Access granted by HBAC rule [allow_admin_mgmt_hosts] ======================================================== When login failed: sssd_ipa.domain.log:(Wed Apr 11 14:15:09 2018) [sssd[be[ipa.domain]]] [hbac_eval_user_element] (0x1000): [15] groups for [ADuser@ADTrustedDomain] sssd_ipa.domain.log:(Wed Apr 11 14:15:09 2018) [sssd[be[ipa.domain]]] [hbac_eval_user_element] (0x0200): Skipping non-IPA group name=group1@ADTrustedDomain,cn=groups,cn=ADTrustedDomain,cn=sysdb ... sssd_ipa.domain.log:(Wed Apr 11 14:15:09 2018) [sssd[be[ipa.domain]]] [hbac_eval_user_element] (0x0200): Skipping non-IPA group name=app-admins@ADTrustedDomain,cn=groups,cn=ADTrustedDomain,cn=sysdb <----- There is no message "Added group [ad_app_admins] for user [ADuser]" sssd_ipa.domain.log:(Wed Apr 11 14:15:09 2018) [sssd[be[ipa.domain]]] [hbac_rule_debug_print] (0x2000): RULE [allow_admin_mgmt_hosts] [ENABLED]: sssd_ipa.domain.log:(Wed Apr 11 14:15:09 2018) [sssd[be[ipa.domain]]] [hbac_rule_debug_print] (0x2000): services: sssd_ipa.domain.log:(Wed Apr 11 14:15:09 2018) [sssd[be[ipa.domain]]] [hbac_rule_element_debug_print] (0x2000): category [0] [NONE] sssd_ipa.domain.log:(Wed Apr 11 14:15:09 2018) [sssd[be[ipa.domain]]] [hbac_rule_element_debug_print] (0x2000): services_names: sssd_ipa.domain.log:(Wed Apr 11 14:15:09 2018) [sssd[be[ipa.domain]]] [hbac_rule_element_debug_print] (0x2000): [sshd] sssd_ipa.domain.log:(Wed Apr 11 14:15:09 2018) [sssd[be[ipa.domain]]] [hbac_rule_element_debug_print] (0x2000): services_groups (none) sssd_ipa.domain.log:(Wed Apr 11 14:15:09 2018) [sssd[be[ipa.domain]]] [hbac_rule_debug_print] (0x2000): users: sssd_ipa.domain.log:(Wed Apr 11 14:15:09 2018) [sssd[be[ipa.domain]]] [hbac_rule_element_debug_print] (0x2000): category [0] [NONE] sssd_ipa.domain.log:(Wed Apr 11 14:15:09 2018) [sssd[be[ipa.domain]]] [hbac_rule_element_debug_print] (0x2000): users_names (none) sssd_ipa.domain.log:(Wed Apr 11 14:15:09 2018) [sssd[be[ipa.domain]]] [hbac_rule_element_debug_print] (0x2000): users_groups: ... sssd_ipa.domain.log:(Wed Apr 11 14:15:09 2018) [sssd[be[ipa.domain]]] [hbac_rule_element_debug_print] (0x2000): [ad_app_admins] ... sssd_ipa.domain.log:(Wed Apr 11 14:15:09 2018) [sssd[be[ipa.domain]]] [hbac_rule_debug_print] (0x2000): targethosts: sssd_ipa.domain.log:(Wed Apr 11 14:15:09 2018) [sssd[be[ipa.domain]]] [hbac_rule_element_debug_print] (0x2000): category [0] [NONE] sssd_ipa.domain.log:(Wed Apr 11 14:15:09 2018) [sssd[be[ipa.domain]]] [hbac_rule_element_debug_print] (0x2000): targethosts_names (none) sssd_ipa.domain.log:(Wed Apr 11 14:15:09 2018) [sssd[be[ipa.domain]]] [hbac_rule_element_debug_print] (0x2000): targethosts_groups: sssd_ipa.domain.log:(Wed Apr 11 14:15:09 2018) [sssd[be[ipa.domain]]] [hbac_rule_element_debug_print] (0x2000): [admin-mng-hosts] sssd_ipa.domain.log:(Wed Apr 11 14:15:09 2018) [sssd[be[ipa.domain]]] [hbac_rule_debug_print] (0x2000): srchosts: sssd_ipa.domain.log:(Wed Apr 11 14:15:09 2018) [sssd[be[ipa.domain]]] [hbac_rule_element_debug_print] (0x2000): category [0x1] [ALL] sssd_ipa.domain.log:(Wed Apr 11 14:15:09 2018) [sssd[be[ipa.domain]]] [hbac_evaluate] (0x0100): The rule [allow_admin_mgmt_hosts] did not match. sssd_ipa.domain.log:(Wed Apr 11 14:15:09 2018) [sssd[be[ipa.domain]]] [ipa_hbac_evaluate_rules] (0x0080): Access denied by HBAC rules

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users April 2018