sssd-users July 2018

sssd-users@lists.fedorahosted.org

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

1.16.2 test failure: sss_nss_idmap-tests
by Andreas Hasenack 09 Aug '18

09 Aug '18

Hi, I'm building 1.16.2 with just https://pagure.io/SSSD/sssd/c/a2cc554f438c220b3cc73eb93879dd87795a86cd?bran… applied (without it, it doesn't build in Ubuntu currently) and I'm seeing this test failure: [==========] Running 2 test(s). [ RUN ] test_getsidbyname [ ERROR ] --- 0x2 != 0 [ LINE ] --- ../src/tests/cmocka/sss_nss_idmap-tests.c:121: error: Failure! [ FAILED ] test_getsidbyname [ RUN ] test_getorigbyname [ ERROR ] --- 0x2 != 0 [ LINE ] --- ../src/tests/cmocka/sss_nss_idmap-tests.c:140: error: Failure! [ FAILED ] test_getorigbyname [==========] 2 test(s) run. [ PASSED ] 0 test(s). [ FAILED ] 2 test(s), listed below: [ FAILED ] test_getsidbyname [ FAILED ] test_getorigbyname 2 FAILED TEST(S) FAIL sss_nss_idmap-tests (exit status: 2) I tried with samba 4.7.6 and 4.8.2 installed, and also with --with-smb-idmap-interface-version 5 and 6, same result. Debian is at 1.16.2 and the tests pass there just fine, so I think I'm looking at some dependency problem. ldb is 1.3.1 tdb is 1.3.15 Any pointers? Maybe a way to run just that test, so I can add debugging statements? Thanks!

4 9

id: cannot find name for group ID
by Mario Rossi 07 Aug '18

07 Aug '18

Hi All! I am running into an issue where groups cannot be resolved upon login. All servers on CentOS 6 work fine, so this is isolated to newer sssd version on CentOS 7. [user@snoopy ~]$ id uid=100001012(user) *gid=1001* *groups=1001*,10(wheel),1102 [user@snoopy ~]$ getent -s sss passwd user user:*:100001012:1001:User Name:/home/user:/bin/bash However, a quick lookup against the group: [user@snoopy ~]$ *getent -s sss group security* security:*:1001:user Subsequent id lookup works: [user@snoopy ~]$ id uid=100001012(user) *gid=1001(security) **groups=1001(security)*,10(wheel),1102 Sudo also complains about the user, even after above command succeeds [user@snoopy ~]$*sudo su -* *sudo: unknown uid 100001012: who are you?* A few seconds later sudo is no longer confused: [user@snoopy ~]$*sudo su -* *LDAP OnePassword for **user**:* root@snoopy[~]# SSSD config: [sssd] config_file_version = 2 sbus_timeout = 30 services = nss, pam, sudo, ssh # BOUNCE DEV domains = LOCAL, HOSTOPIA, DOMAIN1, DOMAIN2, DOMAIN3 [nss] filter_users = adm,apache,avahi,bin,daemon,dbus,ecryptfs,ftp,git,games,gopher,haldaemon,halt,hfallback,hdeploy,influxdb,ldap,lp,mail,mailnull,named,news,nfsnobody,nobody,nscd,nslcd,ntp,operator,oprofile,osse c,postfix,puppet,puppet-dashboard,pulse,pulse-access,radiusd,root,rpc,rpcuser,rtkit,saslauth,sfallback,shutdown,slocate,smmsp,sshd,sync,tcpdump,tss,uucp,vcsa filter_groups = adm,apache,audio,bin,cdrom,cgred,daemon,dbus,dialout,dip,disk,ecryptfs,floppy,fuse,git,hfallback,hdeploy,influxdb,kmem,ldap,lock,lp,mail,mailnull,man,mem,nfsnobody,nobody,nscd,ntp,ossec,oprof ile,postdrop,postfix,puppet,puppet-dashboard,pulse,pulse-access,root,rpc,rpcuser,rtkit,saslauth,sfallback,slocate,smmsp,sshd,sys,tape,tcpdump,tss,tty,users,utempter,utmp,vcsa,video [pam] debug_level = 0 reconnection_retries = 3 offline_credentials_expiration = 2 offline_failed_login_attempts = 3 offline_failed_login_delay = 5 pam_verbosity = 1 pam_pwd_expiration_warning = 21 pam_account_expired_message = Your LDAP password has expired, please use selfservice portal to change your LDAP password. [sudo] debug_level = 0 [ssh] # debug_level = 0 [domain/LOCAL] description = LOCAL Users domain id_provider = local enumerate = true min_id = 500 max_id = 999 default_shell = /bin/bash base_directory = /home create_homedir = false remove_homedir = true homedir_umask = 077 skel_dir = /etc/skel mail_dir = /var/spool/mail All domains have the following options set: ######### SECTION: HOSTOPIA [domain/HOSTOPIA] min_id = 499 debug_level = 0 cache_credentials = True entry_cache_timeout = 864000 auth_provider = ldap id_provider = ldap access_provider = ldap chpass_provider = none sudo_provider = ldap selinux_provider = none autofs_provider = none hostid_provider = none ldap_use_tokengroups = false # https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-… #ignore_group_members=True lookup_family_order = ipv4_only # LDAP Search ldap_search_base = dc=hostopia,dc=com ldap_group_search_base = ou=groups,o=Hostopia,dc=hostopia,dc=com?subtree?(|(cn=almighties)(cn=security)(cn=systems)(cn=bounce-development)(cn=development-wholesale)(cn=development-retail)(cn=abuse)) ldap_user_search_base = ou=users,o=hostopia,dc=hostopia,dc=com?subtree?(|(description=cn=bounce-development,ou=groups,o=Hostopia,dc=hostopia,dc=com)(description=cn=almighties,ou=groups,o=Hostopia,dc=hostopia ,dc=com)(description=cn=security,ou=groups,o=Hostopia,dc=hostopia,dc=com)) # LDAP Custom Schema ldap_group_member = hMemberDN ldap_user_member_of = description # ldap_schema can be set to "rfc2307", which stores group member names in the # "memberuid" attribute, or to "rfc2307bis", which stores group member DNs in # the "member" attribute. If you do not know this value, ask your LDAP # administrator. ldap_schema = rfc2307bis ldap_network_timeout = 3 ldap_id_use_start_tls = False ldap_tls_reqcert = never ldap_tls_cacertdir = /etc/openldap/cacerts # Ldap Servers ldap_uri = ldaps://SERVER1, ldaps://SERVER2, ldaps://SERVER3 ldap_backup_uri = ldaps://1.1.1.1 ldap_default_authtok_type = obfuscated_password ldap_default_bind_dn = **** ldap_default_authtok = ****** ldap_user_ssh_public_key = sshPublicKey ldap_pwd_policy = none ldap_account_expire_policy = shadow ldap_user_shadow_expire = shadowExpire # shadowExpire: days since Jan 1, 1970 that account is disabled: $ echo $(($(date --utc --date "$1" +%s)/86400)) ldap_chpass_update_last_change = false ldap_access_order = filter, expire ldap_access_filter = (&(objectClass=posixAccount)(uidNumber=*)(hAccountInitialSetup=1)(|(description=cn=bounce-development,ou=groups,o=Hostopia,dc=hostopia,dc=com)(description=cn=almighties,ou=groups,o=Hosto pia,dc=hostopia,dc=com)(description=cn=security,ou=groups,o=Hostopia,dc=hostopia,dc=com))) # SUDO ldap_sudo_search_base = ou=sudoers,o=Hostopia,dc=hostopia,dc=com ldap_sudo_full_refresh_interval = 86400 ldap_sudo_smart_refresh_interval = 3600 #entry_cache_sudo_timeout = 5400 ##### END DOMAIN SECTION #####

2 4

sssd connecting to two AD domains
by Ondrej Valousek 07 Aug '18

07 Aug '18

Hi all, I have a machine joined to AD domain "mydomain.com" and there is also domain "mydomain2.com". The two are connected with full two way trust. SSSD can happily recognize users from "mydomain.com", but fails with users from "mydomain2.com" - sssd complains that: (Mon Jul 30 08:26:38 2018) [sssd[be[adesto]]] [get_port_status] (0x1000): Port status of port 389 for server 'server.mydomain2.com' is 'not working' (Mon Jul 30 08:26:38 2018) [sssd[be[adesto]]] [get_port_status] (0x0080): SSSD is unable to complete the full connection request, this internal status does not necessarily indicate network port issues. But I can connect to that server with ldapsearch just fine (using a TGT obtained with kinit -k hostname$). Earlier in the logs I spotted that SSSD is trying to obtain TGT with a wrong principal "host/hostname@REALM" instead of "hostname$@REALM": (Mon Jul 30 08:32:34 2018) [sssd[be[adesto]]] [sdap_get_tgt_recv] (0x0400): Child responded: 14 [Client 'host/hostname(a)mydomain.COM' not found in Kerberos database], expired on [0] (Mon Jul 30 08:32:34 2018) [sssd[be[adesto]]] [sdap_kinit_done] (0x0100): Could not get TGT: 14 [Bad address] (Mon Jul 30 08:32:34 2018) [sssd[be[adesto]]] [sdap_cli_kinit_done] (0x0400): Cannot get a TGT: ret [1432158226](Authentication Failed) I am wondering why is SSSD trying now, all of sudden, to obtain a TGT using wrong principal? Using RHEL-7. 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 7

sssd 1.9.6
by Laack, Andrea P 31 Jul '18

31 Jul '18

I downloaded sssd 1.9.6 for centos 5 from https://copr-be.cloud.fedoraproject.org/results/sgallagh/sssd-1.9-rhel5/epe…. Unfortunately the contents of krb5-1.12.2-14.fc21/ are not there. I have downloaded krb5-workstation, libs, and devel for krb-1.12.2-14 from other places, but the list of dependencies are daunting. Is there anyplace I can get the original contents of this directory? Thanks Andrea Andrea Laack Host Systems [cid:image002.jpg@01D428D3.44B28E30] 2401 S. 31st Street Temple, TX 76508 Mailstop: MS-2-1.41 Office: 254-724-9490 andrea.laack(a)bswhealth.org<mailto:andrea.laack@bswhealth.org> [cid:image003.png@01D428D0.527EFE70] <https://www.youracclaim.com/badges/d2b9b13f-0db9-4666-860e-146c70d45d36> [cid:image004.png@01D428D0.527EFE70] ********************************************************************** The information contained in this e-mail may be privileged and/or confidential, and protected from disclosure, and no waiver of any attorney-client, work product, or other privilege is intended. If you are the intended recipient, further disclosures are prohibited without proper authorization. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden and possibly a violation of federal or state law and regulations. The sender and Baylor Scott & White Health, and its affiliated entities, hereby expressly reserve all privileges and confidentiality that might otherwise be waived as a result of an erroneous or misdirected e-mail transmission. No employee or agent is authorized to conclude any binding agreement on behalf of Baylor Scott & White Health, or any affiliated entity, by e-mail without express written confirmation by the CEO, the Senior Vice President of Supply Chain Services or other duly authorized representative of Baylor Scott & White Health.

1 0

one user can't be looked up
by Peter Moody 29 Jul '18

29 Jul '18

(apologies if this gets sent twice, there was apparently an issue with my subscription to the sssd-users list) this is admittedly low priority since this is all just a test network at this point, but we're looking to deploy sssd at work so I'd like to make sure all the kinks I know about are well understood/fixed I have an openldap install with the following users (pmoody, peter) with uidNumbers (1001, 1002) respectively. sssd works for both users from freebsd 11.2 prelease (sssd-1.11.7_11, whew, that's old). sssd works for pmoody from debian stretch (1.15.0-3). it does *not* work for the user peter. this is what happens for the user peter. pmoody@deb:~$ sudo sss_cache -E pmoody@deb:~$ getent passwd pmoody pmoody:*:1001:500:Peter Moody:/home/pmoody:/bin/bash pmoody@deb:~$ getent passwd peter pmoody:*:1001:500:Peter Moody:/home/pmoody:/bin/bash pmoody@deb:~$ I've tried version 1.16.1-1, same results. These are the ldap entries for the aforementioned users: # peter, people, x.com dn: uid=peter,ou=people,dc=x,dc=com cn: peter givenName: peter sn: moody uid: peter uidNumber: 1002 homeDirectory: /home/peter objectClass: top objectClass: posixAccount objectClass: shadowAccount objectClass: inetOrgPerson objectClass: organizationalPerson gidNumber: 500 loginShell: /usr/local/bin/fish # pmoody, people, x.com dn: uid=pmoody,ou=people,dc=x,dc=com cn: Peter Moody givenName: Peter sn: Moody uid: pmoody uidNumber: 1001 homeDirectory: /home/pmoody objectClass: top objectClass: posixAccount objectClass: shadowAccount objectClass: inetOrgPerson objectClass: organizationalPerson loginShell: /usr/local/bin/fish gidNumber: 500 on the debian box that exhibits this error, I see the following in the logs: (Mon Jun 18 20:39:44 2018) [sssd[be[x.com]]] [ldb] (0x4000): cancel ldb transaction (nesting: 2) (Mon Jun 18 20:39:44 2018) [sssd[be[x.com]]] [sysdb_set_cache_entry_attr] (0x0080): ldb_modify failed: [No such object](32)[ldb_wait from ldb_modify with LDB_WAIT_ALL: No such object (32)] (Mon Jun 18 20:39:44 2018) [sssd[be[x.com]]] [sysdb_set_cache_entry_attr] (0x0400): No such entry (Mon Jun 18 20:39:44 2018) [sssd[be[x.com]]] [sysdb_set_entry_attr] (0x0080): Cannot set attrs for name=peter(a)x.com,cn=users,cn=x.com,cn=sysdb, 2 [No such file or directory] (Mon Jun 18 20:39:44 2018) [sssd[be[x.com]]] [sysdb_store_user] (0x0040): Cache update failed: 2 (Mon Jun 18 20:39:44 2018) [sssd[be[x.com]]] [ldb] (0x4000): cancel ldb transaction (nesting: 1) (Mon Jun 18 20:39:44 2018) [sssd[be[x.com]]] [sysdb_store_user] (0x0400): Error: 2 (No such file or directory) (Mon Jun 18 20:39:44 2018) [sssd[be[x.com]]] [sdap_save_user] (0x0020): Failed to save user [peter(a)x.com] (Mon Jun 18 20:39:44 2018) [sssd[be[x.com]]] [sdap_save_users] (0x0040): Failed to store user 0. Ignoring. it kind of looks like what was reported here : https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.… but I don't see a resolution to that report. any suggestions on what I can do to fix this? logs/configs I can provide to help isolate the problem? Cheers, peter

4 11

Missing group memberships with sssd (when using tokengroups)
by Spike White 27 Jul '18

27 Jul '18

All, Below is a writeup of missing AD groups for accounts when using tokengroups. When not using tokengroups, sssd is rock solid. Yes, most of the missing AD groups are universal or global groups -- but not all! For some accounts, even domain-local AD groups are missed from their group memberships. (when using tokengroups). *Missing group memberships with sssd (when using tokengroups):* July, 2018. Cross-subdomain AD authentication partially working. (fully working with ldap_use_tokengroups = False) When set ldap_use_tokengroups = True, some AD groups for some accounts missing. Full details below. Test server is in AMER.DELL.COM *Accounts and their missing AD group memberships (when ldap_use_tokengroups = True)* *AdmJesse_Chan *(account resides in APAC.DELL.COM) tokengroups-enabled SSSD reports membership in: uid=525641(admjesse_chan) gid=525641(admjesse_chan) groups=525641(admjesse_chan),1008(apacunixusers),1000(apaclinuxeng),1001(apaclinuxsup) vas-enabled Linux server reports membership in: uid=525641(admjesse_chan) gid=525641(admjesse_chan) groups=525641(admjesse_chan),1000(apaclinuxeng),1001(apaclinuxsup),1008(apacunixusers), 1041(linux-core-engineering),1069(users) diff is: 1041(linux-core-engineering),1069(users) Both are AMER-only "local domain" groups. linux-core-engineering is a AMER-only "domain local" group with GID 1041. And actually, admjesse_chan is a member of 'users', but that's an APAC.DELL.COM domain AD group (that's not unix-enabled). VAS is (mistakenly) reporting Jesse as a member of the AMER.DELL.COM 'users' group, which has a GID of 1069. *AdmPaulBowen *(account resides in EMEA.DELL.COM) tokengroups-enabled SSSD reports membership in: uid=2103156(admpaul_bowen) gid=2103156(admpaul_bowen) groups=2103156(admpaul_bowen),1009(emeaunixusers) vas-enabled Linux server reports membership in: uid=2103156(admpaul_bowen) gid=2103156(admpaul_bowen) groups=2103156(admpaul_bowen),1153(emea_server_mgmt),1005(emealinuxsup) ,1009(emeaunixusers) diff is: 1153(emea_server_mgmt),1005(emealinuxsup), EMEA_SERVER_MGMT is a universal AD group. with GID 1153. EMEALINUXSUP is a universal AD group. with GID 1005. EMEAUNIXUSERS is a global AD group. with GID 1009. *AdmDennis_Kennedy* (account resides in EMEA.DELL.COM) tokengroups-enabled SSSD: uid=2890335(admdennis_kennedy) gid=2890335(admdennis_kennedy) groups=2890335(admdennis_kennedy),1009(emeaunixusers) vas: uid=2890335(admdennis_kennedy) gid=2890335(admdennis_kennedy) groups=2890335(admdennis_kennedy),1153(emea_server_mgmt),1004(emealinuxeng), 1009(emeaunixusers),1041(linux-core-engineering) diff: 1153(emea_server_mgmt),1004(emealinuxeng),1041(linux-core-engineering) EMEA_SERVER_MGMT is a universal AD group. with GID 1153. EMEALINUXENG is a universal AD group. with GID 1003. linux-core-engineering is a AMER-only "domain local" group with GID 1041. *AdmSpike_White* (account resides in AMER.DELL.COM) tokengroups-enabled SSSD: uid=2025431(admspike_white) gid=2025431(admspike_white) groups=2025431(admspike_white),1002(amerlinuxeng) vas: uid=2025431(admspike_white) gid=2025431(admspike_white) groups=2025431(admspike_white),1002(amerlinuxeng), 1041(linux-core-engineering),1069(users) diff: 1041(linux-core-engineering),1069(users) linux-core-engineering is a AMER-only "domain local" group with GID 1041. users is an AMER-only "builtin local" group with GID 1069. *AdmCesar_Guillen* (account found in AMER.DELL.COM) NOTE: AdmCesar_Guillen is found in AMERICAS. tokengroups-enabled SSSD: uid=2669411(admcesar_guillen) gid=2669411(admcesar_guillen) groups=2669411(admcesar_guillen),1010(amerunixusers) vas: uid=2669411(admcesar_guillen) gid=2669411(admcesar_guillen) groups=2669411(admcesar_guillen),1033(amer_server_mgmt),1002(amerlinuxeng) ,1010(amerunixusers),2284031(esg_bios_code_rw) diff: 1033(amer_server_mgmt),1002(amerlinuxeng),2284031(esg_bios_code_rw) amer_server_mgmt is an AMER global group with GID 1033. <--- why is sssd not reporting this?!? amerlinuxeng is a universal AD group with GID 1002. <---------- why is sssd not reporting this?!? It's reported for AdmSpike_White, but not for AdmPatrick_Wheeler or AdmCesar_Guillen. esg_bios_code_rw is a universal AD group with GID 2284031. <---------- why is sssd not reporting this?!? *Admpatrick_wheeler* (account resides in AMER.DELL.COM) tokengroups-enabled SSSD: uid=2604370(admpatrick_wheeler) gid=2604370(admpatrick_wheeler) groups=2604370(admpatrick_wheeler),1010(amerunixusers) tokengroups-disabled SSSD: uid=2604370(admpatrick_wheeler) gid=2604370(admpatrick_wheeler) groups=2604370(admpatrick_wheeler),1033(amer_server_mgmt),1010(amerunixusers),1003(amerlinuxsup),1156(gbl_server_support),2284161(amerserveradministrator),2283573(dfs_gil_sit_auth),2283577(delta_bd_create_emea),2283643(gebs_read_prd),2283611(xxgl0370_prod),2283578(delta_bd_create),2283256(infa_developer),2283623(xxgl0363_prod),2283615(xxgl0503_prod),2283607(xxpa2891_prod),2283869(cowcprodsupport) vas: uid=2604370(admpatrick_wheeler) gid=2604370(admpatrick_wheeler) groups=2604370(admpatrick_wheeler), 1033(amer_server_mgmt),1003(amerlinuxsup),1010(amerunixusers) diff is: 1033(amer_server_mgmt) 1003(amerlinuxsup) amer_server_mgmt is an AMER global group with GID 1033. <--- why is sssd not reporting this?!? amerlinuxsup is an AMER universal group with GID 1003. Here is my /etc/sssd/sssd.conf file: [nss] debug_level = 9 filter_groups = root filter_users = root #entry_cache_timeout = 300 entry_cache_nowait_percentage = 75 [sssd] debug_level = 6 #domains = amer.dell.com,apac.dell.com,emea.dell.com,japn.dell.com,dell.com domains = amer.dell.com,apac.dell.com,emea.dell.com,japn.dell.com # Unnecessary. If missing, will search in order specified in "domains" lines above. #domain_resolution_order = amer.dell.com, emea.dell.com, apac.dell.com, japn.dell.com, dell.com config_file_version = 2 services = nss,pam reconnection_retries = 3 #ldap_user_member_of = member [pam] pam_verbosity = 3 debug_level = 9 [domain/amer.dell.com] debug_level = 9 id_provider = ad access_provider = simple #access_provider = ad auth_provider = ad ad_domain = amer.dell.com krb5_realm = AMER.DELL.COM default_shell = /bin/bash #use_fully_qualified_names = False ldap_id_mapping = False subdomains_provider = none auto_private_groups = True realmd_tags = joined-with-adcli cache_credentials = True krb5_store_password_if_offline = True fallback_homedir = /home/%u ldap_schema = rfc2307bis ldap_sasl_authid = host/spikerealmd02.us.dell.com(a)AMER.DELL.COM #ldap_sasl_authid = SPIKEREALMD02$(a)AMER.DELL.COM #ldap_sasl_authid = spikerealmd02(a)AMER.DELL.COM #TEST REMOVAL. July 4 2018. SW #ad_enabled_domains = amer.dell.com,apac.dell.com,emea.dell.com, japn.dell.com,dell.com dyndns_update = False # TEST -- commented out July 4 to not use tokengroups. ldap_use_tokengroups = False simple_allow_groups = amerlinuxsup(a)AMER.DELL.COM, amerlinuxeng(a)AMER.DELL.COM, emealinuxsup(a)EMEA.DELL.COM, AMER.DELL.COM, emealinuxeng(a)EMEA.DELL.COM, apaclinuxsup(a)EMEA.DELL.COM, apaclinuxeng(a)EMEA.DELL.COM # also look at https://lists.fedorahosted.org/pipermail/sssd-users/2015-February/002648.ht… [domain/apac.dell.com] debug_level = 9 auto_private_groups = True #use_fully_qualified_names = False ad_domain = apac.dell.com krb5_realm = APAC.DELL.COM cache_credentials = True id_provider = ad auth_provider = ad krb5_store_password_if_offline = True default_shell = /bin/bash ldap_id_mapping = False fallback_homedir = /home/%u access_provider = simple ldap_schema = rfc2307bis ldap_sasl_authid = host/spikerealmd02.us.dell.com(a)AMER.DELL.COM #ldap_sasl_authid = SPIKEREALMD02$(a)AMER.DELL.COM #ldap_sasl_authid = spikerealmd02(a)AMER.DELL.COM #TEST REMOVAL. July 4 2018. SW #ad_enabled_domains = amer.dell.com, apac.dell.com, apac.dell.com, japn.dell.com, dell.com dyndns_update = False subdomains_provider = none # TEST -- commented out July 4 to not use tokengroups. ldap_use_tokengroups = False simple_allow_groups = apaclinuxsup(a)APAC.DELL.COM, apaclinuxeng(a)APAC.DELL.COM [domain/emea.dell.com] debug_level = 9 auto_private_groups = True #use_fully_qualified_names = False ad_domain = emea.dell.com krb5_realm = EMEA.DELL.COM cache_credentials = True id_provider = ad auth_provider = ad krb5_store_password_if_offline = True default_shell = /bin/bash ldap_id_mapping = False fallback_homedir = /home/%u access_provider = simple ldap_schema = rfc2307bis ldap_sasl_authid = host/spikerealmd02.us.dell.com(a)AMER.DELL.COM #ldap_sasl_authid = SPIKEREALMD02$(a)AMER.DELL.COM #ldap_sasl_authid = spikerealmd02(a)AMER.DELL.COM #TEST REMOVAL. July 4 2018. SW #ad_enabled_domains = amer.dell.com, apac.dell.com, emea.dell.com, japn.dell.com, dell.com dyndns_update = False subdomains_provider = none # TEST -- commented out July 4 to not use tokengroups. ldap_use_tokengroups = False simple_allow_groups = emealinuxsup(a)EMEA.DELL.COM, emealinuxeng(a)EMEA.DELL.COM [domain/japn.dell.com] debug_level = 9 auto_private_groups = True #use_fully_qualified_names = False ad_domain = japn.dell.com krb5_realm = JAPN.DELL.COM cache_credentials = True id_provider = ad auth_provider = ad krb5_store_password_if_offline = True default_shell = /bin/bash ldap_id_mapping = False fallback_homedir = /home/%u access_provider = simple ldap_schema = rfc2307bis ldap_sasl_authid = host/spikerealmd02.us.dell.com(a)AMER.DELL.COM #ldap_sasl_authid = SPIKEREALMD02$(a)AMER.DELL.COM #ldap_sasl_authid = spikerealmd02(a)AMER.DELL.COM #TEST REMOVAL. July 4 2018. SW #ad_enabled_domains = amer.dell.com, apac.dell.com, japn.dell.com, japn.dell.com, dell.com dyndns_update = False subdomains_provider = none # TEST -- commented out July 4 to not use tokengroups. ldap_use_tokengroups = False simple_allow_groups = japnlinuxsup(a)JAPN.DELL.COM, japnlinuxeng(a)JAPN.DELL.COM

3 9

Group members are ignored, nothing to do. If you see this message it might indicate an error in the group processing logic.
by TomK 27 Jul '18

27 Jul '18

Hey Guy's, After implementing the LDAP_MATCHING_RULE_IN_CHAIN , we're seeing these messages in the sssd domain log file: (Tue Jul 24 12:59:41 2018) [sssd[be[MYDOM]]] [child_sig_handler] (0x0020): child [17444] failed with status [1]. (Tue Jul 24 12:59:41 2018) [sssd[be[MYDOM]]] [child_sig_handler] (0x0020): child [17451] failed with status [1]. (Tue Jul 24 12:59:41 2018) [sssd[be[MYDOM]]] [child_sig_handler] (0x0020): child [17457] failed with status [1]. (Tue Jul 24 12:59:41 2018) [sssd[be[MYDOM]]] [child_sig_handler] (0x0020): child [17463] failed with status [1]. (Tue Jul 24 12:59:42 2018) [sssd[be[MYDOM]]] [child_sig_handler] (0x0020): child [17469] failed with status [1]. (Tue Jul 24 12:59:42 2018) [sssd[be[MYDOM]]] [child_sig_handler] (0x0020): child [17477] failed with status [1]. (Tue Jul 24 12:59:42 2018) [sssd[be[MYDOM]]] [child_sig_handler] (0x0020): child [17486] failed with status [1]. (Tue Jul 24 12:59:42 2018) [sssd[be[MYDOM]]] [child_sig_handler] (0x0020): child [17493] failed with status [1]. (Tue Jul 24 12:59:42 2018) [sssd[be[MYDOM]]] [child_sig_handler] (0x0020): child [17500] failed with status [1]. (Tue Jul 24 12:59:42 2018) [sssd[be[MYDOM]]] [child_sig_handler] (0x0020): child [17506] failed with status [1]. (Tue Jul 24 12:59:42 2018) [sssd[be[MYDOM]]] [child_sig_handler] (0x0020): child [17512] failed with status [1]. (Tue Jul 24 12:59:42 2018) [sssd[be[MYDOM]]] [child_sig_handler] (0x0020): child [17519] failed with status [1]. (Tue Jul 24 12:59:42 2018) [sssd[be[MYDOM]]] [child_sig_handler] (0x0020): child [17525] failed with status [1]. (Tue Jul 24 12:59:42 2018) [sssd[be[MYDOM]]] [child_sig_handler] (0x0020): child [17532] failed with status [1]. (Tue Jul 24 12:59:42 2018) [sssd[be[MYDOM]]] [child_sig_handler] (0x0020): child [17540] failed with status [1]. (Tue Jul 24 13:12:11 2018) [sssd[be[MYDOM]]] [child_sig_handler] (0x0020): child [34068] failed with status [2]. (Tue Jul 24 13:13:54 2018) [sssd[be[MYDOM]]] [sdap_save_grpmem] (0x0020): Group members are ignored, nothing to do. If you see this message it might indicate an error in the group processing logic. (Tue Jul 24 13:15:39 2018) [sssd[be[MYDOM]]] [sdap_save_grpmem] (0x0020): Group members are ignored, nothing to do. If you see this message it might indicate an error in the group processing logic. (Tue Jul 24 13:15:39 2018) [sssd[be[MYDOM]]] [sdap_save_grpmem] (0x0020): Group members are ignored, nothing to do. If you see this message it might indicate an error in the group processing logic. (Tue Jul 24 13:16:07 2018) [sssd[be[MYDOM]]] [sdap_save_grpmem] (0x0020): Group members are ignored, nothing to do. If you see this message it might indicate an error in the group processing logic. (Tue Jul 24 13:16:07 2018) [sssd[be[MYDOM]]] [sdap_save_grpmem] (0x0020): Group members are ignored, nothing to do. If you see this message it might indicate an error in the group processing logic. (Tue Jul 24 13:17:18 2018) [sssd[be[MYDOM]]] [ad_get_slave_domain_done] (0x0020): Unable to lookup slave domain data [110]: Connection timed out (Tue Jul 24 13:19:20 2018) [sssd[be[MYDOM]]] [sdap_save_grpmem] (0x0020): Group members are ignored, nothing to do. If you see this message it might indicate an error in the group processing logic. (Tue Jul 24 13:19:20 2018) [sssd[be[MYDOM]]] [sdap_save_grpmem] (0x0020): Group members are ignored, nothing to do. If you see this message it might indicate an error in the group processing logic. (Tue Jul 24 13:19:20 2018) [sssd[be[MYDOM]]] [sdap_save_grpmem] (0x0020): Group members are ignored, nothing to do. If you see this message it might indicate an error in the group processing logic. (Tue Jul 24 13:19:20 2018) [sssd[be[MYDOM]]] [sdap_save_grpmem] (0x0020): Group members are ignored, nothing to do. If you see this message it might indicate an error in the group processing logic. (Tue Jul 24 13:19:20 2018) [sssd[be[MYDOM]]] [sdap_save_grpmem] (0x0020): Group members are ignored, nothing to do. If you see this message it might indicate an error in the group processing logic. (Tue Jul 24 13:19:20 2018) [sssd[be[MYDOM]]] [sdap_save_grpmem] (0x0020): Group members are ignored, nothing to do. If you see this message it might indicate an error in the group processing logic. ad_access_filter = DOM:MYDOM:(|(memberOf=CN=group01,OU=Groups,OU=MYOU,DC=MYDOM,DC=COM)(memberOf:1.2.840.113556.1.4.1941:=CN=group02,OU=Groups,OU=MYOU,DC=MYDOM,DC=COM)) python2-sssdconfig-1.15.3-0.el6.noarch sssd-ldap-1.15.3-0.el6.x86_64 sssd-ad-1.15.3-0.el6.x86_64 sssd-ipa-1.15.3-0.el6.x86_64 sssd-1.15.3-0.el6.x86_64 sssd-krb5-common-1.15.3-0.el6.x86_64 sssd-krb5-1.15.3-0.el6.x86_64 sssd-common-pac-1.15.3-0.el6.x86_64 sssd-common-1.15.3-0.el6.x86_64 sssd-client-1.15.3-0.el6.x86_64 sssd-proxy-1.15.3-0.el6.x86_64 We're not using NFS NFS at all here. Did a number of searches but wasn't able to find out more online. Has anyone encountered the same and nudge me further along? Authentication works and we can login however even with DEBUG LEVEL at 10, that's pretty much all that's printed in the above log file. -- Cheers, Tom K. ------------------------------------------------------------------------------------- Living on earth is expensive, but it includes a free trip around the sun.

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users July 2018