sssd-users March 2018

sssd-users@lists.fedorahosted.org

23 participants
20 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

sssd 1.16.1 wont start, Centos 7.4
by Lachlan Musicman 04 Apr '18

04 Apr '18

Using the newly minted SSSD 1.16.1 from COPR, the sssd service doesn't restart. ( https://copr.fedorainfracloud.org/coprs/g/sssd/sssd-1-16/) The journalctl -xe shows: -- Unit sssd.service has begun starting up. Mar 29 09:05:55 linuxclient1.unixdev.company.com sssd[1477]: Starting up Mar 29 09:05:55 linuxclient1.unixdev.company.com systemd[1]: sssd.service: main process exited, code=exited, status=3/NOTIMPLEMENTED Mar 29 09:05:55 linuxclient1.unixdev.company.com systemd[1]: Failed to start System Security Services Daemon. -- Subject: Unit sssd.service has failed -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel The /var/log/sssd/sssd.log shows (Thu Mar 29 09:03:44 2018) [sssd] [server_setup] (0x0400): CONFDB: /var/lib/sss/db/config.ldb (Thu Mar 29 09:03:44 2018) [sssd] [_snotify_create] (0x0400): Added a watch for /etc/resolv.conf with inotify flags 0x8D88 internal flags 0x1 using function resolv_conf_inotify_cb after delay 1.0 (Thu Mar 29 09:03:44 2018) [sssd] [sss_names_init_from_args] (0x0100): Using re [(((?P<domain>[^\\]+)\\(?P<name>.+$))|((?P<name>[^@]+)@(?P<domain>.+$))|(^(?P<name>[^@\\]+)$))]. (Thu Mar 29 09:03:44 2018) [sssd] [sss_fqnames_init] (0x0100): Using fq format [%1$s]. (Thu Mar 29 09:03:44 2018) [sssd] [sysdb_domain_init_internal] (0x0200): DB File for unixdev.company.com: /var/lib/sss/db/cache_unixdev.company.com.ldb (Thu Mar 29 09:03:44 2018) [sssd] [sysdb_domain_init_internal] (0x0200): Timestamp file for unixdev.company.com: /var/lib/sss/db/timestamps_unixdev.company.com.ldb (Thu Mar 29 09:03:44 2018) [sssd] [ldb] (0x0400): asq: Unable to register control with rootdse! (Thu Mar 29 09:03:44 2018) [sssd] [sbus_new_server] (0x0020): dbus_server_listen failed! (name=org.freedesktop.DBus.Error.AccessDenied, message=Failed to bind socket "/var/lib/sss/pipes/private/sbus-monitor": Permission denied) (Thu Mar 29 09:05:55 2018) [sssd] [server_setup] (0x0400): CONFDB: /var/lib/sss/db/config.ldb (Thu Mar 29 09:05:55 2018) [sssd] [_snotify_create] (0x0400): Added a watch for /etc/resolv.conf with inotify flags 0x8D88 internal flags 0x1 using function resolv_conf_inotify_cb after delay 1.0 (Thu Mar 29 09:05:55 2018) [sssd] [sss_names_init_from_args] (0x0100): Using re [(((?P<domain>[^\\]+)\\(?P<name>.+$))|((?P<name>[^@]+)@(?P<domain>.+$))|(^(?P<name>[^@\\]+)$))]. (Thu Mar 29 09:05:55 2018) [sssd] [sss_fqnames_init] (0x0100): Using fq format [%1$s]. (Thu Mar 29 09:05:55 2018) [sssd] [sysdb_domain_init_internal] (0x0200): DB File for unixdev.company.com: /var/lib/sss/db/cache_unixdev.company.com.ldb (Thu Mar 29 09:05:55 2018) [sssd] [sysdb_domain_init_internal] (0x0200): Timestamp file for unixdev.company.com: /var/lib/sss/db/timestamps_unixdev.company.com.ldb (Thu Mar 29 09:05:55 2018) [sssd] [ldb] (0x0400): asq: Unable to register control with rootdse! (Thu Mar 29 09:05:55 2018) [sssd] [sbus_new_server] (0x0020): dbus_server_listen failed! (name=org.freedesktop.DBus.Error.AccessDenied, message=Failed to bind socket "/var/lib/sss/pipes/private/sbus-monitor": Permission denied) /var/lib/sss/pipes/private shows drwxr-x---. 2 sssd root 4096 Mar 29 08:50 . drwxr-xr-x. 3 sssd sssd 71 Mar 29 03:01 .. srw------- 1 root root 0 Mar 19 09:21 pam lrwxrwxrwx 1 root root 62 Mar 19 09:20 sbus-dp_unixdev.company.com -> /var/lib/sss/pipes/private/sbus-dp_unixdev.company.com.758 srw------- 1 root root 0 Sep 18 2017 sbus-dp_unixdev.company.com.732 srw------- 1 root root 0 Dec 28 09:47 sbus-dp_unixdev.company.com.746 It looks like there's some clean up that's not happening? I don't actually know what sbus_dp files do, but the top result (pointing to .758) doesn't exist... How do I fix this? Cheers L. ------ "The antidote to apocalypticism is *apocalyptic civics*. Apocalyptic civics is the insistence that we cannot ignore the truth, nor should we panic about it. It is a shared consciousness that our institutions have failed and our ecosystem is collapsing, yet we are still here — and we are creative agents who can shape our destinies. Apocalyptic civics is the conviction that the only way out is through, and the only way through is together. " *Greg Bloom* @greggish https://twitter.com/greggish/status/873177525903609857

3 7

Ubuntu 16.04.4 LTS 4.4.0-108+ and sssd freezes virtual server
by David Hunter 19 Mar '18

19 Mar '18

*Guest OS*: Ubuntu 16.04.4 LTS (kernel versions 4.4.0-108 to current 116) *Virtualization env*: VMWare ESXi 6.0 *Host hardware*: Dell R720 Using SSSD to bind linux servers to the AD domain for authentication. This was working fine right up to 4.4.0-104. After the update to -108,-109,-112, or -116, if sssd is enabled OR if it is disabled but then started after a successful boot and you perform a lookup (i.e. id some_domain_user), the entire system will freeze, and you have to force a reboot. There's even a blip in the syslog when it happens. I increased loglevel to 9 in the sssd.conf file in all the sections, and then started SSSD and tried to lookup a user. The most meaningful things I've been able to pull out are: sssd.log: (Fri Mar 16 13:06:03 2018) [sssd] [service_send_ping] (0x2000): Pinging ad.domain.com (Fri Mar 16 13:06:03 2018) [sssd] [sbus_add_timeout] (0x2000): 0x88a9d0 (Fri Mar 16 13:06:03 2018) [sssd] [service_send_ping] (0x2000): Pinging nss (Fri Mar 16 13:06:03 2018) [sssd] [sbus_add_timeout] (0x2000): 0x8904c0 (Fri Mar 16 13:06:03 2018) [sssd] [service_send_ping] (0x2000): Pinging pam (Fri Mar 16 13:06:03 2018) [sssd] [sbus_add_timeout] (0x2000): 0x88ede0 (Fri Mar 16 13:06:03 2018) [sssd] [service_send_ping] (0x2000): Pinging ssh (Fri Mar 16 13:06:03 2018) [sssd] [sbus_add_timeout] (0x2000): 0x889710 (Fri Mar 16 13:06:03 2018) [sssd] [sbus_remove_timeout] (0x2000): 0x88a9d0 (Fri Mar 16 13:06:03 2018) [sssd] [sbus_dispatch] (0x4000): dbus conn: 0x888c10 (Fri Mar 16 13:06:03 2018) [sssd] [sbus_dispatch] (0x4000): Dispatching. (Fri Mar 16 13:06:03 2018) [sssd] [ping_check] (0x2000): Service ad.domain.com replied to ping (Fri Mar 16 13:06:03 2018) [sssd] [sbus_remove_timeout] (0x2000): 0x88ede0 (Fri Mar 16 13:06:03 2018) [sssd] [sbus_dispatch] (0x4000): dbus conn: 0x890e00 (Fri Mar 16 13:06:03 2018) [sssd] [sbus_dispatch] (0x4000): Dispatching. (Fri Mar 16 13:06:03 2018) [sssd] [ping_check] (0x2000): Service pam replied to ping (Fri Mar 16 13:06:03 2018) [sssd] [sbus_remove_timeout] (0x2000): 0x889710 (Fri Mar 16 13:06:03 2018) [sssd] [sbus_dispatch] (0x4000): dbus conn: 0x88d5f0 (Fri Mar 16 13:06:03 2018) [sssd] [sbus_dispatch] (0x4000): Dispatching. (Fri Mar 16 13:06:03 2018) [sssd] [ping_check] (0x2000): Service ssh replied to ping (Fri Mar 16 13:06:03 2018) [sssd] [sbus_remove_timeout] (0x2000): 0x8904c0 (Fri Mar 16 13:06:03 2018) [sssd] [sbus_dispatch] (0x4000): dbus conn: 0x88eae0 (Fri Mar 16 13:06:03 2018) [sssd] [sbus_dispatch] (0x4000): Dispatching. (Fri Mar 16 13:06:03 2018) [sssd] [ping_check] (0x2000): Service nss replied to ping sssd_nss.log: (Fri Mar 16 13:05:06 2018) [sssd[nss]] [id_callback] (0x0010): The Monitor returned an error [org.freedesktop.DBus.Error.NoReply] sssd_ad.domain.com.log: (Fri Mar 16 13:05:13 2018) [sssd[be[ad.domain.com]]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.service.ping on path /org/freedesktop/sssd/service (Fri Mar 16 13:05:13 2018) [sssd[be[ad.domain.com]]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Fri Mar 16 13:05:23 2018) [sssd[be[ad.domain.com]]] [sbus_dispatch] (0x4000): dbus conn: 0xf1e840 (Fri Mar 16 13:05:23 2018) [sssd[be[ad.domain.com]]] [sbus_dispatch] (0x4000): Dispatching. sssd_ssh.log: (Fri Mar 16 13:06:53 2018) [sssd[ssh]] [sbus_dispatch] (0x4000): dbus conn: 0x1817880 (Fri Mar 16 13:06:53 2018) [sssd[ssh]] [sbus_dispatch] (0x4000): Dispatching. (Fri Mar 16 13:06:53 2018) [sssd[ssh]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.service.ping on path /org/freedesktop/sssd/service (Fri Mar 16 13:06:53 2018) [sssd[ssh]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit sssd.conf: [sssd] domains = ad.domain.com config_file_version = 2 services = nss, pam, ssh # default_domain_suffix = ad.domain.com [ssh] [domain/ad.domain.com] ad_domain = ad.domain.com krb5_realm = AD.DOMAIN.COM 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 fallback_homedir = /home/%d/%u access_provider = ad # use_fully_qualified_names = True ad_gpo_access_control = permissive ad_access_filter = ad.domain.com:(memberOf=CN=Information Technology,CN=Users,DC=ad,DC=domain,DC=com) ldap_sasl_authid = ServicePrincipalName | userPrincipalName ldap_user_ssh_public_key = sshPublicKeys ldap_user_certificate = noSuchAttribute Trying to capture boot time logs wasn't successful (with sssd enabled with systemd). Just a big gap in kernel.log and syslog. Watching the boot process shows that it hangs at: Started D-Bus System Messaging Bus Which appears to be corroborate the problems being indicated in the sssd logs. Some kinda problem with sssd sending dbus messages, right? If I revert to -104, all good. Anything above that version, sadness. What is weird is that I do not have these problems on a test system using VirtualBox on my MacBook Pro running the same version of Ubuntu 16.04.4 LTS. I'm wondering if this might be a Meltdown related issue, as it happened with the kernel version that was initially released to address it (-108). We applied updates to our physical hosts, ESXi and the fixes for the guest OS. I'm afraid it is a weird confluence of host+vmware+guest OS problems. Already tried making sssd.service the last service to start. No change in behavior other than it hangs later in the boot process. Any insight or help appreciated! Thanks! Dave

3 3

nss_getpwnam: name 'tom@my.dom@localdomain' does not map into domain 'nix.my.dom'
by TomK 18 Mar '18

18 Mar '18

Hey Guy's, Getting below message which in turn fails to list proper UID / GID on NFSv4 mounts from within an unprivileged account. All files show up with owner and group as nobody / nobody when viewed from the client. Is there a way to structure /etc/idmapd.conf to allow for proper UID / GID resolution? Or perhaps another solution? [root@client01 etc]# cat /etc/idmapd.conf|grep -v "#"| sed -e "/^$/d" [General] Verbosity = 7 Domain = nix.my.dom [Mapping] [Translation] [Static] [UMICH_SCHEMA] LDAP_server = ldap-server.local.domain.edu LDAP_base = dc=local,dc=domain,dc=edu [root@client01 etc]# Mount looks like this: nfs-c01.nix.my.dom:/n/my.dom on /n/my.dom type nfs4 (rw,relatime,vers=4.0,rsize=8192,wsize=8192,namlen=255,hard,proto=tcp,port=0,timeo=10,retrans=2,sec=sys,clientaddr=192.168.0.236,local_lock=none,addr=192.168.0.80) /var/log/messages Mar 6 00:17:27 client01 nfsidmap[14396]: key: 0x3f2c257b type: uid value: tom@my.dom@localdomain timeout 600 Mar 6 00:17:27 client01 nfsidmap[14396]: nfs4_name_to_uid: calling nsswitch->name_to_uid Mar 6 00:17:27 client01 nfsidmap[14396]: nss_getpwnam: name 'tom@my.dom@localdomain' domain 'nix.my.dom': resulting localname '(null)' Mar 6 00:17:27 client01 nfsidmap[14396]: nss_getpwnam: name 'tom@my.dom@localdomain' does not map into domain 'nix.my.dom' Mar 6 00:17:27 client01 nfsidmap[14396]: nfs4_name_to_uid: nsswitch->name_to_uid returned -22 Mar 6 00:17:27 client01 nfsidmap[14396]: nfs4_name_to_uid: final return value is -22 Mar 6 00:17:27 client01 nfsidmap[14396]: nfs4_name_to_uid: calling nsswitch->name_to_uid Mar 6 00:17:27 client01 nfsidmap[14396]: nss_getpwnam: name 'nobody(a)nix.my.dom' domain 'nix.my.dom': resulting localname 'nobody' Mar 6 00:17:27 client01 nfsidmap[14396]: nfs4_name_to_uid: nsswitch->name_to_uid returned 0 Mar 6 00:17:27 client01 nfsidmap[14396]: nfs4_name_to_uid: final return value is 0 Mar 6 00:17:27 client01 nfsidmap[14398]: key: 0x324b0048 type: gid value: tom@my.dom@localdomain timeout 600 Mar 6 00:17:27 client01 nfsidmap[14398]: nfs4_name_to_gid: calling nsswitch->name_to_gid Mar 6 00:17:27 client01 nfsidmap[14398]: nfs4_name_to_gid: nsswitch->name_to_gid returned -22 Mar 6 00:17:27 client01 nfsidmap[14398]: nfs4_name_to_gid: final return value is -22 Mar 6 00:17:27 client01 nfsidmap[14398]: nfs4_name_to_gid: calling nsswitch->name_to_gid Mar 6 00:17:27 client01 nfsidmap[14398]: nfs4_name_to_gid: nsswitch->name_to_gid returned 0 Mar 6 00:17:27 client01 nfsidmap[14398]: nfs4_name_to_gid: final return value is 0 Mar 6 00:17:31 client01 systemd-logind: Removed session 23. Result of: systemctl restart rpcidmapd /var/log/messages ------------------- Mar 5 23:46:12 client01 systemd: Stopping Automounts filesystems on demand... Mar 5 23:46:13 client01 systemd: Stopped Automounts filesystems on demand. Mar 5 23:48:51 client01 systemd: Stopping NFSv4 ID-name mapping service... Mar 5 23:48:51 client01 systemd: Starting Preprocess NFS configuration... Mar 5 23:48:51 client01 systemd: Started Preprocess NFS configuration. Mar 5 23:48:51 client01 systemd: Starting NFSv4 ID-name mapping service... Mar 5 23:48:51 client01 rpc.idmapd[14117]: libnfsidmap: using domain: nix.my.dom Mar 5 23:48:51 client01 rpc.idmapd[14117]: libnfsidmap: Realms list: 'NIX.MY.DOM' Mar 5 23:48:51 client01 rpc.idmapd: rpc.idmapd: libnfsidmap: using domain: nix.my.dom Mar 5 23:48:51 client01 rpc.idmapd: rpc.idmapd: libnfsidmap: Realms list: 'NIX.MY.DOM' Mar 5 23:48:51 client01 rpc.idmapd: rpc.idmapd: libnfsidmap: loaded plugin /lib64/libnfsidmap/nsswitch.so for method nsswitch Mar 5 23:48:51 client01 rpc.idmapd[14117]: libnfsidmap: loaded plugin /lib64/libnfsidmap/nsswitch.so for method nsswitch Mar 5 23:48:51 client01 rpc.idmapd[14118]: Expiration time is 600 seconds. Mar 5 23:48:51 client01 systemd: Started NFSv4 ID-name mapping service. Mar 5 23:48:51 client01 rpc.idmapd[14118]: Opened /proc/net/rpc/nfs4.nametoid/channel Mar 5 23:48:51 client01 rpc.idmapd[14118]: Opened /proc/net/rpc/nfs4.idtoname/channel -- Cheers, Tom K. ------------------------------------------------------------------------------------- Living on earth is expensive, but it includes a free trip around the sun.

2 10

Multiple logins by the same user at the same host at nearly the exact time
by Jim Richard 15 Mar '18

15 Mar '18

result in: pam_sss(sshd:account): Access denied for user rundeck: 4 (System error) I know this has been an issue in the past per some info I see in places like: https://access.redhat.com/solutions/1477473 <https://access.redhat.com/solutions/1477473> any chance there's been a regression bringing this issue back? <http://www.placeiq.com/> <http://www.placeiq.com/> <http://www.placeiq.com/> Jim Richard <https://twitter.com/placeiq> <https://twitter.com/placeiq> <https://twitter.com/placeiq> <https://www.facebook.com/PlaceIQ> <https://www.facebook.com/PlaceIQ> <https://www.linkedin.com/company/placeiq> <https://www.linkedin.com/company/placeiq> SYSTEM ADMINISTRATOR III (646) 338-8905 <http://www.placeiq.com/2015/05/26/placeiq-named-winner-of-prestigious-2015-…> <http://placeiq.com/2015/12/18/accuracy-vs-precision-in-location-data-mma-we…> <http://placeiq.com/2015/12/18/accuracy-vs-precision-in-location-data-mma-we…> <http://placeiq.com/2015/12/18/accuracy-vs-precision-in-location-data-mma-we…> <http://placeiq.com/2015/12/18/accuracy-vs-precision-in-location-data-mma-we…> <http://placeiq.com/2016/03/08/measuring-addressable-tv-campaigns-is-now-pos…> <http://placeiq.com/2016/04/13/placeiq-joins-the-network-advertising-initiat…> <http://placeiq.com/2016/04/13/placeiq-joins-the-network-advertising-initiat…> <http://placeiq.com/2016/04/13/placeiq-joins-the-network-advertising-initiat…> <http://placeiq.com/2016/04/13/placeiq-joins-the-network-advertising-initiat…> <http://placeiq.com/2016/04/13/placeiq-joins-the-network-advertising-initiat…> <http://pages.placeiq.com/Location-Data-Accuracy-Whitepaper-Download.html?ut…> <http://placeiq.com/2016/08/03/placeiq-bolsters-location-intelligence-platfo…> <http://placeiq.com/2016/10/26/the-making-of-a-location-data-industry-milest…> <http://placeiq.com/2016/12/07/placeiq-introduces-landmark-a-groundbreaking-…> <http://placeiq.com/2016/12/07/placeiq-introduces-landmark-a-groundbreaking-…> <https://www.placeiq.com/2017/05/placeiqs-landmark-powers-location-based-ins…>

2 5

SSSD and Firewalls
by Roger Mårtensson 14 Mar '18

14 Mar '18

Hello! Got tasked to look at firewall rules and am now wondering if there is a document anywhere that describes the ports and protocols used by SSSD? My list currently consist of: 53 (udp/tcp), 88 (udp), 389 (tcp), 636 (tcp) and 3268 (tcp) and 3269 (tcp) If I search on "Windows Client" and ports I get tons of ports and port-ranges I may need to open. But what do SSSD use?

4 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users March 2018