July 2018 - sssd-users - Fedora mailing-lists

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

AD user account get Permission denied when trying to login
by Farshid Mahdavipour 25 Jul '18

25 Jul '18

Hi, Could you please help me to resolve this issue! When i want to login to the RHEL 7.5 machine with AD account, i get permission denied: `Permission denied, please try again.` password for the user is correct, have tried it multiple times. Log for sshd: [root@azrclchefvm01 ~]# tail /var/log/secure Jul 23 21:47:01 azrclchefvm01 sshd[35436]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=172.17.253.11 user=mahdavif Jul 23 21:47:01 azrclchefvm01 sshd[35436]: pam_sss(sshd:auth): received for user mahdavif: 6 (Permission denied) Jul 23 21:47:03 azrclchefvm01 sshd[35436]: Failed password for mahdavif from 172.17.253.11 port 36262 ssh2 Jul 23 21:47:17 azrclchefvm01 sshd[35436]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=172.17.253.11 user=mahdavif Jul 23 21:47:17 azrclchefvm01 sshd[35436]: pam_sss(sshd:auth): received for user mahdavif: 6 (Permission denied) Jul 23 21:47:19 azrclchefvm01 sshd[35436]: Failed password for mahdavif from 172.17.253.11 port 36262 ssh2 Jul 23 21:47:25 azrclchefvm01 sshd[35436]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=172.17.253.11 user=mahdavif Jul 23 21:47:25 azrclchefvm01 sshd[35436]: pam_sss(sshd:auth): received for user mahdavif: 6 (Permission denied) Jul 23 21:47:28 azrclchefvm01 sshd[35436]: Failed password for mahdavif from 172.17.253.11 port 36262 ssh2 Jul 23 21:47:28 azrclchefvm01 sshd[35436]: Connection closed by 172.17.253.11 port 36262 [preauth] Log for sssd: [root@azrclchefvm01 ~]# tail /var/log/sssd/* ==> /var/log/sssd/krb5_child.log <== (Mon Jul 23 21:59:34 2018) [[sssd[krb5_child[35846]]]] [become_user] (0x0200): Trying to become user [39599][59900]. (Mon Jul 23 21:59:34 2018) [[sssd[krb5_child[35846]]]] [set_lifetime_options] (0x0100): No specific renewable lifetime requested. (Mon Jul 23 21:59:34 2018) [[sssd[krb5_child[35846]]]] [set_lifetime_options] (0x0100): No specific lifetime requested. (Mon Jul 23 21:59:34 2018) [[sssd[krb5_child[35846]]]] [set_canonicalize_option] (0x0100): Canonicalization is set to [true] (Mon Jul 23 21:59:34 2018) [[sssd[krb5_child[35846]]]] [main] (0x0400): Will perform online auth (Mon Jul 23 21:59:34 2018) [[sssd[krb5_child[35846]]]] [get_and_save_tgt] (0x0400): Attempting kinit for realm [CORP.example.net] (Mon Jul 23 21:59:35 2018) [[sssd[krb5_child[35846]]]] [get_and_save_tgt] (0x0020): 1544: [-1765328366][Client's credentials have been revoked] (Mon Jul 23 21:59:35 2018) [[sssd[krb5_child[35846]]]] [map_krb5_error] (0x0020): 1657: [-1765328366][Client's credentials have been revoked] (Mon Jul 23 21:59:35 2018) [[sssd[krb5_child[35846]]]] [k5c_send_data] (0x0200): Received error code 1432158272 (Mon Jul 23 21:59:35 2018) [[sssd[krb5_child[35846]]]] [main] (0x0400): krb5_child completed successfully ==> /var/log/sssd/ldap_child.log <== (Mon Jul 23 21:59:07 2018) [[sssd[ldap_child[35808]]]] [prepare_response] (0x0400): Building response for result [0] (Mon Jul 23 21:59:07 2018) [[sssd[ldap_child[35808]]]] [main] (0x0400): ldap_child completed successfully (Mon Jul 23 21:59:19 2018) [[sssd[ldap_child[35835]]]] [main] (0x0400): ldap_child started. (Mon Jul 23 21:59:19 2018) [[sssd[ldap_child[35835]]]] [unpack_buffer] (0x0200): Will run as [0][0]. (Mon Jul 23 21:59:19 2018) [[sssd[ldap_child[35835]]]] [become_user] (0x0200): Trying to become user [0][0]. (Mon Jul 23 21:59:19 2018) [[sssd[ldap_child[35835]]]] [become_user] (0x0200): Already user [0]. (Mon Jul 23 21:59:19 2018) [[sssd[ldap_child[35835]]]] [ldap_child_get_tgt_sync] (0x0100): Principal name is: [AZRCLCHEFVM01$@ CORP.example.net] (Mon Jul 23 21:59:19 2018) [[sssd[ldap_child[35835]]]] [ldap_child_get_tgt_sync] (0x0100): Using keytab [MEMORY:/etc/krb5.keytab] (Mon Jul 23 21:59:19 2018) [[sssd[ldap_child[35835]]]] [prepare_response] (0x0400): Building response for result [0] (Mon Jul 23 21:59:19 2018) [[sssd[ldap_child[35835]]]] [main] (0x0400): ldap_child completed successfully ==> /var/log/sssd/sssd_corp.example.net.log <== (Mon Jul 23 21:59:34 2018) [sssd[be[corp.example.net]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'AD' (Mon Jul 23 21:59:34 2018) [sssd[be[corp.example.net]]] [be_resolve_server_process] (0x0200): Found address for server srv_waddcs001: [10.4.20.32] TTL 1200 (Mon Jul 23 21:59:34 2018) [sssd[be[corp.example.net]]] [write_pipe_handler] (0x0400): All data has been sent! (Mon Jul 23 21:59:35 2018) [sssd[be[corp.example.net]]] [child_sig_handler] (0x0100): child [35846] finished successfully. (Mon Jul 23 21:59:35 2018) [sssd[be[corp.example.net]]] [read_pipe_handler] (0x0400): EOF received, client finished (Mon Jul 23 21:59:35 2018) [sssd[be[corp.example.net]]] [dp_req_done] (0x0400): DP Request [PAM Authenticate #6]: Request handler finished [0]: Success (Mon Jul 23 21:59:35 2018) [sssd[be[corp.example.net]]] [_dp_req_recv] (0x0400): DP Request [PAM Authenticate #6]: Receiving request data. (Mon Jul 23 21:59:35 2018) [sssd[be[corp.example.net]]] [dp_req_destructor] (0x0400): DP Request [PAM Authenticate #6]: Request removed. (Mon Jul 23 21:59:35 2018) [sssd[be[corp.example.net]]] [dp_req_destructor] (0x0400): Number of active DP request: 0 (Mon Jul 23 21:59:35 2018) [sssd[be[corp.example.net]]] [dp_method_enabled] (0x0400): Target selinux is not configured ==> /var/log/sssd/sssd.log <== (Mon Jul 23 21:59:07 2018) [sssd] [sbus_conn_register_path] (0x0400): Registering object path /org/freedesktop/sssd/monitor with D-Bus connection (Mon Jul 23 21:59:07 2018) [sssd] [sbus_opath_hash_add_iface] (0x0400): Registering interface org.freedesktop.DBus.Properties with path /org/freedesktop/sssd/monitor (Mon Jul 23 21:59:07 2018) [sssd] [sbus_opath_hash_add_iface] (0x0400): Registering interface org.freedesktop.DBus.Introspectable with path /org/freedesktop/sssd/monitor (Mon Jul 23 21:59:07 2018) [sssd] [client_registration] (0x0100): Received ID registration: (pam,1) (Mon Jul 23 21:59:07 2018) [sssd] [mark_service_as_started] (0x0200): Marking pam as started. (Mon Jul 23 21:59:07 2018) [sssd] [client_registration] (0x0100): Received ID registration: (nss,1) (Mon Jul 23 21:59:07 2018) [sssd] [mark_service_as_started] (0x0200): Marking nss as started. (Mon Jul 23 21:59:07 2018) [sssd] [mark_service_as_started] (0x0400): All services have successfully started, creating pid file (Mon Jul 23 21:59:07 2018) [sssd] [notify_startup] (0x0400): Sending startup notification to systemd (Mon Jul 23 21:59:12 2018) [sssd] [services_startup_timeout] (0x0400): Handling timeout ==> /var/log/sssd/sssd_nss.log <== (Mon Jul 23 21:59:14 2018) [sssd[nss]] [cache_req_prepare_domain_data] (0x0400): CR #1: Preparing input data for domain [corp.example.net] rules (Mon Jul 23 21:59:14 2018) [sssd[nss]] [cache_req_search_send] (0x0400): CR #1: Looking up mahdavif(a)corp.example.net (Mon Jul 23 21:59:14 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR #1: Checking negative cache for [mahdavif(a)corp.example.net] (Mon Jul 23 21:59:14 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR #1: [mahdavif(a)corp.example.net] is not present in negative cache (Mon Jul 23 21:59:14 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #1: Looking up [mahdavif(a)corp.example.net] in cache (Mon Jul 23 21:59:14 2018) [sssd[nss]] [cache_req_search_send] (0x0400): CR #1: Returning [mahdavif(a)corp.example.net] from cache (Mon Jul 23 21:59:14 2018) [sssd[nss]] [cache_req_search_ncache_filter] (0x0400): CR #1: This request type does not support filtering result by negative cache (Mon Jul 23 21:59:14 2018) [sssd[nss]] [cache_req_create_and_add_result] (0x0400): CR #1: Found 23 entries in domain corp.example.net (Mon Jul 23 21:59:14 2018) [sssd[nss]] [cache_req_done] (0x0400): CR #1: Finished: Success (Mon Jul 23 21:59:37 2018) [sssd[nss]] [client_recv] (0x0200): Client disconnected! ==> /var/log/sssd/sssd_pam.log <== (Mon Jul 23 21:59:34 2018) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 (Mon Jul 23 21:59:34 2018) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 (Mon Jul 23 21:59:34 2018) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 35831 (Mon Jul 23 21:59:34 2018) [sssd[pam]] [pam_print_data] (0x0100): logon name: mahdavif (Mon Jul 23 21:59:34 2018) [sssd[pam]] [pam_dom_forwarder] (0x0100): pam_dp_send_req returned 0 (Mon Jul 23 21:59:35 2018) [sssd[pam]] [pam_dp_process_reply] (0x0200): received: [6 (Permission denied)][corp.example.net] (Mon Jul 23 21:59:35 2018) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [6]: Permission denied. (Mon Jul 23 21:59:35 2018) [sssd[pam]] [filter_responses] (0x0100): [pam_response_filter] not available, not fatal. (Mon Jul 23 21:59:35 2018) [sssd[pam]] [pam_reply] (0x0200): blen: 33 (Mon Jul 23 21:59:37 2018) [sssd[pam]] [client_recv] (0x0200): Client disconnected! thanks for your help! farshid

2 1

Re: "groups: cannot find name for group ID #####"
by sssdusers.20.retinkab＠spamgourmet.com 25 Jul '18

25 Jul '18

Unfortunately it seems to not be so easy: rtadmin@ubt18-test:~$ cat /etc/nsswitch.conf ... #passwd: compat systemd sss #group: compat systemd sss passwd: files sss group: files sss shadow: files sss gshadow: files ... rtadmin@ubt18-test:~$ getent passwd user1 user1:*:30335:33111:User One:/users/user1:/bin/bash rtadmin@ubt18-test:~$ groups user1 user1 : unix_users groups: cannot find name for group ID 33118 33118 Curiously, when I did `getent passwd user1` it seems to have resolved and cached the primary group, but not any secondary groups. Discussing `sss_cache -E`, rtadmin@ubt18-test:~$ sudo sss_cache -E rtadmin@ubt18-test:~$ groups user1 user1 : groups: cannot find name for group ID 33111 33111 groups: cannot find name for group ID 33118 33118 rtadmin@ubt18-test:~$ groups user2 user2 : groups: cannot find name for group ID 33111 33111 rtadmin@ubt18-test:~$ getent passwd user2 user2:*:30255:33111:User Two:/users/user2:/bin/bash rtadmin@ubt18-test:~$ groups user2 user2 : groups: cannot find name for group ID 33111 33111 # (note that user2 is not in group 33118.) -- and that also shoots down my assumption regarding `getent passwd <user>` causing the primary group to be cached. On Fri, Jul 20, 2018 at 5:55 PM, Joakim Tjernlund - Joakim.Tjernlund(a)infinera.com < sssdusers.retinkab.d133d58ee0.Joakim.Tjernlund#sssd-users(a)lists.fedorahosted.org> wrote: > Start with replacing compat with files in nsswitch.conf > >

3 2

SSSD on CentOS 7 failing to start when connecting to Samba 4.8.3 AD via LDAP
by Mark Johnson 24 Jul '18

24 Jul '18

I've been going around in circles with this for days and I'm stuck. I'm trying to run up a new AD environment with only Samba 4.8.3 servers that we'll authenticate user server access against via SSSD/LDAP using a simple bind. All of our servers are either CentOS 6 or 7. I've created a test environment with a single Samba AD 4.8.3 server as the AD server, a Windows 7 client to run RSAT and a CentOS 6 and CentOS 7 server to test user authentication. The Samba server is up and running and I can manage the directory via RSAT. I've set up the CentOS 6 server and can successfully authenticate user logins on this via using SSSD/LDAP to the AD. However, the issue I have is with the CentOS 7 server. I've basically copied the SSSD config from the CentOS 6 server so everything is the same. However, when I start SSSD on the CentOS 7 server, it binds successfully and does an initial searchRequest which it gets a result from but after doing the subsequent searchRequests on Configuration, ForestDnsZones and DomainDnsZones I just see a RST from the server and the whole process starts over again. Over the third failure, SSSD fails to start and stops trying. Comparing packet captures on the AD server when starting SSSD on both servers, the initial ROOT search request and response are identical as is the bind request and response. However, the first wholeSubtree search request is where things start looking different. On the CentOS 6 server, it shows a filter in the request of: Filter: (&(&(cn=smtp)(ipServiceProtocol=dccp))(objectclass=ipService)) and there are 4 attributes in the request - objectClass, cn, ipServicePort, ipServiceProtocol Whereas on the CentOS 7 server, the filter looks like this: Filter: (&(objectClass=sudoRole)(|(|(|(|(|(|(|(|(|(!(sudoHost=*))( sudoHost=ALL))(sudoHost=ldaptest7.company.com))(sudoHost= ldaptest7))(sudoHost=192.168.193.62))(sudoHost=192.168.192. 0/23))(sudoHost=fe80::5054:ff:fef2:26ed))(sudoHost=fe80::/6 with 13 attributes - objectClass, cn, and a bunch of sudo attributes. The response from the Samba server to each of these is nearly identical. Both servers then send searchRequests for Configuration, ForestDnsZones and DomainDnsZones but with the same filter differences above. This is the point of failure for the CentOS 7 server. The other server gets a successful response from the Samba server, but the CentOS 7 server just gets an ACK. When I up the debug level on SSSD on the CentOS 7 server, I see a few different errors but I'm not sure which of these show cause or effect. Examples... (Thu Jul 19 23:40:34 2018) [sssd[be[AD.COMPANY.COM]]] [common_parse_search_base] (0x0100): Search base added: [SUDO][dc=ad,dc=company,dc=com][SUBTREE][] (Thu Jul 19 23:40:34 2018) [sssd[be[AD.COMPANY.COM]]] [common_parse_search_base] (0x0100): Search base added: [AUTOFS][dc=ad,dc=company,dc=com][SUBTREE][] (Thu Jul 19 23:40:34 2018) [sssd[be[AD.COMPANY.COM]]] [dp_client_register] (0x0100): Cancel DP ID timeout [0x55941e9a6860] (Thu Jul 19 23:40:34 2018) [sssd[be[AD.COMPANY.COM]]] [dp_find_method] (0x0100): Target [subdomains] is not initialized (Thu Jul 19 23:40:34 2018) [sssd[be[AD.COMPANY.COM]]] [dp_req_reply_gen_error] (0x0080): DP Request [Subdomains #0]: Finished. Target is not supported with this configuration. (Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'LDAP' (Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]] [set_server_common_status] (0x0100): Marking server '192.168.192.50' as 'resolving name' (Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]] [set_server_common_status] (0x0100): Marking server '192.168.192.50' as 'name resolved' (Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]] [sdap_get_server_opts_from_rootdse] (0x0100): Setting AD compatibility level to [4] (Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]] [sdap_cli_auth_step] (0x0100): expire timeout is 900 (Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]] [simple_bind_send] (0x0100): Executing simple bind as: sssd(a)ad.company.com (Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]] [fo_set_port_status] (0x0100): Marking port 389 of server '192.168.192.50' as 'working' (Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]] [set_server_common_status] (0x0100): Marking server '192.168.192.50' as 'working' (Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]] [be_run_online_cb] (0x0080): Going online. Running callbacks. (Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]] [be_ptask_enable] (0x0080): Task [SUDO Smart Refresh]: already enabled (Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]] [sdap_process_result] (0x0040): ldap_result error: [Can't contact LDAP server] sssd_be: io.c:224: ber_flush2: Assertion `( (sb)->sb_opts.lbo_valid == 0x3 )' failed. (Thu Jul 19 23:40:44 2018) [sssd] [svc_child_info] (0x0040): Child [1570] terminated with signal [6] I get the feeling that the issue is around sudo somehow, but I don't believe I have sudo enabled in my sssd. Here's my sssd.conf from the CentOS 7 server: [sssd] config_file_version = 2 reconnection_retries = 3 sbus_timeout = 30 services = nss, pam domains = AD.COMPANY.COM [nss] filter_groups = root,bin,daemon,sys,adm,tty,disk,lp,mem,kmem,wheel,mail, uucp,man,games,gopher,video,dip,ftp,lock,audio,nobody, users,floppy,vcsa,utmp,utempter,rpc,cdrom,tape,dialout,rpcuser,nfsnobody, sshd,cgred,screen,saslauth,apache,mailnull,smmsp,mysql filter_users = root,bin,daemon,adm,lp,sync,shutdown,halt,mail,uucp, operator,games,gopher,ftp,nobody,vcsa,rpc,rpcuser,nfsnobody,sshd,saslauth, apache,mailnull,smmsp,mysql,apache reconnection_retries = 3 #entry_cache_timeout = 300 entry_cache_nowait_percentage = 75 [domain/AD.COMPANY.COM] enumerate = false cache_credentials = true id_provider = ldap #auth_provider = ldap ldap_schema = rfc2307bis ldap_user_principal = userPrincipalName ldap_user_fullname = displayName ldap_user_name = sAMAccountName ldap_user_object_class = user ldap_user_home_directory = unixHomeDirectory ldap_user_shell = loginShell ldap_group_object_class = group ldap_force_upper_case_realm = True ldap_uri = ldap://192.168.192.50 ldap_search_base = dc=ad,dc=company,dc=com ldap_id_use_start_tls = false ldap_tls_reqcert = never ldap_tls_cacert = /etc/sssd/ca.company.com.crt access_provider = ldap ldap_access_filter = memberOf=cn=ServerAdmins,ou= Groups,dc=ad,dc=company,dc=com ldap_default_authtok_type = password ldap_default_bind_dn = sssd(a)ad.company.com ldap_default_authtok = Password1 [pam] I tried adding the sudo roles schema to active directory to see if it would resolve the sssd not starting issue, but while I was able to successfully import the schema via ldifde and create the sudoers OU in the root, but when it came to adding the sudoRole object via ADSIEdit, I got an Operation Failed error - "An invalid directory pathname was passed". So, I'm not sure if adding this will resolve the issue or not. There was no sudoers entry in nsswitch.conf so I tried specifically adding the following line to explicitly omit sss in case it has become a default setting: sudoers: files But that made no difference. I've tried all of the above twice from scratch to be sure and I got the same results both times. I can successfully query the directory via the same ldapsearch command from both CentOS servers. I don't know if I'm completely barking up the wrong tree. I'm just going around in circles now and I can't think of anything new to try. Oh, and here's my smb.conf... # Global parameters [global] bind interfaces only = Yes dns forwarder = 192.168.192.1 interfaces = lo eth0 netbios name = TUG-SAMBA realm = AD.COMPANY.COM server role = active directory domain controller workgroup = COMPANY idmap_ldb:use rfc2307 = yes dsdb:schema update allowed = yes ldap server require strong auth = no [netlogon] path = /var/lib/samba/sysvol/ad.company.com/scripts read only = No [sysvol] path = /var/lib/samba/sysvol read only = No

3 3

problem login in with AD account after joined to the AD domain
by Farshid Mahdavipour 23 Jul '18

23 Jul '18

Hi, I have configured sssd.service to authenticate to AD on RHEL 7.5 and i have successfully joined the rhel machine to AD. but i cannot login to the machine with the AD account. *here is the error when i try to login with the AD credential:* mahdavif(a)172.17.248.71's password: Last login: Sun Jul 22 18:59:23 2018 from 172.17.253.11 This account is currently not available. Connection to 172.17.248.71 closed. *here is the sssd.conf:* *# cat /etc/sssd/sssd.conf*ad_server = srv_addcp001, srv_addcp002 [sssd] domains = corp.example.com config_file_version = 2 services = nss, pam [domain/corp.example.com] ad_domain = corp.example.com krb5_realm = CORP.example.com krb5_auth_timeout = 60 realmd_tags = manages-system joined-with-adcli cache_credentials = True id_provider = ad krb5_store_password_if_offline = True default_shell = /bin/bash override_shell = /bin/bash ldap_id_mapping = False use_fully_qualified_names = False fallback_homedir = /home/%u@%d access_provider = ad ad_server = srv_addcp001, srv_addcp002 *here is the output of the realm list:* *# realm list*corp.example.com type: kerberos realm-name: CORP.example.com domain-name: corp.example.com configured: kerberos-member server-software: active-directory client-software: sssd required-package: oddjob required-package: oddjob-mkhomedir required-package: sssd required-package: adcli required-package: samba-common-tools login-formats: %U login-policy: allow-realm-logins *This is the /var/log/secure when trying to login :*Jul 22 17:13:05 azrlvm003 sshd[7202]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=172.17.253.11 user=mahdavif Jul 22 17:13:05 azrlvm003 sshd[7202]: Accepted password for mahdavif from 172.17.253.11 port 41628 ssh2 Jul 22 17:13:06 azrlvm003 sshd[7202]: pam_unix(sshd:session): session opened for user mahdavif by (uid=0) Jul 22 17:13:06 azrlvm003 sshd[7209]: Received disconnect from 172.17.253.11 port 41628:11: disconnected by user Jul 22 17:13:06 azrlvm003 sshd[7209]: Disconnected from 172.17.253.11 port 41628 Jul 22 17:13:06 azrlvm003 sshd[7202]: pam_unix(sshd:session): session closed for user mahdavif sssd --version 1.16.0 I really appreciate if you can help me. Thanks Farshid

3 5

Am I blocked on sssd-users mailing list?
by Spike White 23 Jul '18

23 Jul '18

All, I fear I may be blocked. I responded to an email thread, with an email that had two small attachments. That was wrong. I read the mailing list by-laws and I realize that was wrong. I will not repeat that offense. As the guidelines suggest, if I need to send logs I'll post somewhere publicly and reference those URLs. But I fear my transgression seems to have blocked my email address on sssd-users mailing list. Sending this short email to confirm. Spike

2 1

Re: \groups: cannot find name for group ID #####\
by jsl6uy js16uy 20 Jul '18

20 Jul '18

roger roger understood. no worries thanks! I will definitely try On Fri, Jul 20, 2018 at 6:19 PM, Joakim Tjernlund <Joakim.Tjernlund(a)infinera.com> wrote: > Yes, that compat. Compat can be a problem, you do not need it. I am on > vacation and only have my phone so no long emails, sorry. > > Skaffa Outlook för Android > > ________________________________ > From: jsl6uy js16uy <js16uy(a)gmail.com> > Sent: Friday, July 20, 2018 6:49:35 PM > To: End-user discussions about the System Security Services Daemon > Subject: [SSSD-users] Re: "groups: cannot find name for group ID #####" > > CAUTION: This email originated from outside of the organization. Do not > click links or open attachments unless you recognize the sender and know the > content is safe. > > > Really? no attitude pure question. We see the same thing. These are AD > groups sssd is complaining about. We use 1.16.1 on Ubu and Centos and > see the same behavior > You're saying below should be files vs compat? > passwd: compat sss > group: compat sss > > Don't get me wrong, thanks for the interaction on this and thanks to > sssdusers asking the original posted question. It really annoys our > users > > > > > On Fri, Jul 20, 2018 at 4:55 PM, Joakim Tjernlund > <Joakim.Tjernlund(a)infinera.com> wrote: >> Start with replacing compat with files in nsswitch.conf >> >> >> >> ________________________________ >> From: sssdusers.20.retinkab(a)spamgourmet.com >> <sssdusers.20.retinkab(a)spamgourmet.com> >> Sent: Friday, July 20, 2018 21:47 >> To: sssd-users(a)lists.fedorahosted.org >> Subject: [SSSD-users] "groups: cannot find name for group ID #####" >> >> CAUTION: This email originated from outside of the organization. Do not >> click links or open attachments unless you recognize the sender and know >> the >> content is safe. >> >> Hi, I was wondering if anyone has successfully fixed this. >> >> I'm working on upgrading servers and client machines, and any time I use a >> newer SSSD package I'm unable to get groups for the users when they log >> in. >> (This is SSSD 1.16.1 on ubt18.04). >> >> The problem can be summed up as, >> root@ubt18-test:# sssd --version >> 1.16.1 >> root@ubt18-test:# groups user1 >> user1 : groups: cannot find name for group ID 33111 >> 33111 groups: cannot find name for group ID 33118 >> 33118 >> >> root@ubt18-test:# getent group | grep 33111 >> unix_users:*:33111: >> >> root@ubt18-test:# groups user2 >> user2 : groups: cannot find name for group ID 33111 >> 33111 >> >> root@ubt18-test:# su user2 >> groups: cannot find name for group ID 33111 >> >> user2@ubt18-test:$ groups >> groups: cannot find name for group ID 33111 >> 33111 >> -- >> root@ubt18-test:# getent group unix_users >> unix_users:*:33111: >> >> root@ubt18-test:# groups user2 >> user2 : unix_users >> >> root@blair-ubt18-test:/var/log/sssd# groups user1 >> user1 : unix_users groups: cannot find name for group ID 33118 >> 33118 >> >> >> This is an odd sequence of events, but notice that I can't get the group >> for >> a given user. It shows up only as GID. However, that GID _is_ listed in >> the >> output of `getent group`, so it's there, the system can see it, and SSSD >> is >> aware of it. Trying again, that gid still won't map to a name when I get >> the >> user's groups. >> >> The odd part is that if I get the group specifically (`getent group >> unix_users`), then the mapping for that group thereafter succeeds. Does >> anyone know what's going on? Of course, everything is working as expected >> with an earlier version -- 1.13.4. >> >> The only fix that I've seen is to recreate every LDAP group in the local >> groups file, but that seems contrary to the point of using LDAP. I'd like >> to >> avoid it. >> >> /etc/nsswitch.conf: >> #passwd: compat systemd sss >> #group: compat systemd sss >> passwd: compat sss >> group: compat sss >> # it's the same with/without systemd >> >> /etc/sssd/sssd.conf: >> [domain/LOCAL] >> enumerate = True >> id_provider = local >> max_id = 9999 >> min_id = 1000 >> >> [domain/MYDOMAIN] >> access_provider = simple >> auth_provider = krb5 >> debug_level = 0xFF0 >> cache_credentials = True >> chpass_provider = krb5 >> enumerate = True >> id_provider = ldap >> krb5_kpasswd = core-dc1.mydomain.cxm >> krb5_realm = mydomain.cxm >> krb5_renewable_lifetime = 7d >> krb5_server = core-dc1.mydomain.cxm >> ldap_default_authtok = thepassword >> ldap_default_authtok_type = password >> ldap_default_bind_dn = cn=LDAP >> Bind,ou=ServiceAccounts,ou=_MyDomain,dc=mydomain,dc=cxm >> ldap_group_object_class = group >> ldap_group_search_base = OU=_MyDomain,DC=MYDOMAIN,DC=CXM >> ldap_search_base = DC=MYDOMAIN,DC=CXM >> ldap_tls_reqcert = never >> ldap_uri = ldap://core-dc1.mydomain.cxm >> ldap_user_home_directory = unixHomeDirectory >> ldap_user_name = sAMAccountName >> ldap_user_object_class = user >> ldap_user_search_base = OU=_MyDomain,DC=MYDOMAIN,DC=CXM >> >> [nss] >> filter_groups = root >> filter_users = root >> reconnection_retries = 50 >> >> [pam] >> pam_verbosity = 3 >> reconnection_retries = 50 >> >> [sssd] >> config_file_version = 2 >> debug_level = 0xFF0 >> domains = LOCAL, MYDOMAIN >> reconnection_retries = 50 >> sbus_timeout = 5 >> services = nss, pam >> >> _______________________________________________ >> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org >> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org >> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> >> https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted… >> > _______________________________________________ > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org > To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted… > > _______________________________________________ > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org > To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted… >

1 0

Re: "groups: cannot find name for group ID #####"
by jsl6uy js16uy 20 Jul '18

20 Jul '18

Really? no attitude pure question. We see the same thing. These are AD groups sssd is complaining about. We use 1.16.1 on Ubu and Centos and see the same behavior You're saying below should be files vs compat? passwd: compat sss group: compat sss Don't get me wrong, thanks for the interaction on this and thanks to sssdusers asking the original posted question. It really annoys our users On Fri, Jul 20, 2018 at 4:55 PM, Joakim Tjernlund <Joakim.Tjernlund(a)infinera.com> wrote: > Start with replacing compat with files in nsswitch.conf > > > > ________________________________ > From: sssdusers.20.retinkab(a)spamgourmet.com > <sssdusers.20.retinkab(a)spamgourmet.com> > Sent: Friday, July 20, 2018 21:47 > To: sssd-users(a)lists.fedorahosted.org > Subject: [SSSD-users] "groups: cannot find name for group ID #####" > > CAUTION: This email originated from outside of the organization. Do not > click links or open attachments unless you recognize the sender and know the > content is safe. > > Hi, I was wondering if anyone has successfully fixed this. > > I'm working on upgrading servers and client machines, and any time I use a > newer SSSD package I'm unable to get groups for the users when they log in. > (This is SSSD 1.16.1 on ubt18.04). > > The problem can be summed up as, > root@ubt18-test:# sssd --version > 1.16.1 > root@ubt18-test:# groups user1 > user1 : groups: cannot find name for group ID 33111 > 33111 groups: cannot find name for group ID 33118 > 33118 > > root@ubt18-test:# getent group | grep 33111 > unix_users:*:33111: > > root@ubt18-test:# groups user2 > user2 : groups: cannot find name for group ID 33111 > 33111 > > root@ubt18-test:# su user2 > groups: cannot find name for group ID 33111 > > user2@ubt18-test:$ groups > groups: cannot find name for group ID 33111 > 33111 > -- > root@ubt18-test:# getent group unix_users > unix_users:*:33111: > > root@ubt18-test:# groups user2 > user2 : unix_users > > root@blair-ubt18-test:/var/log/sssd# groups user1 > user1 : unix_users groups: cannot find name for group ID 33118 > 33118 > > > This is an odd sequence of events, but notice that I can't get the group for > a given user. It shows up only as GID. However, that GID _is_ listed in the > output of `getent group`, so it's there, the system can see it, and SSSD is > aware of it. Trying again, that gid still won't map to a name when I get the > user's groups. > > The odd part is that if I get the group specifically (`getent group > unix_users`), then the mapping for that group thereafter succeeds. Does > anyone know what's going on? Of course, everything is working as expected > with an earlier version -- 1.13.4. > > The only fix that I've seen is to recreate every LDAP group in the local > groups file, but that seems contrary to the point of using LDAP. I'd like to > avoid it. > > /etc/nsswitch.conf: > #passwd: compat systemd sss > #group: compat systemd sss > passwd: compat sss > group: compat sss > # it's the same with/without systemd > > /etc/sssd/sssd.conf: > [domain/LOCAL] > enumerate = True > id_provider = local > max_id = 9999 > min_id = 1000 > > [domain/MYDOMAIN] > access_provider = simple > auth_provider = krb5 > debug_level = 0xFF0 > cache_credentials = True > chpass_provider = krb5 > enumerate = True > id_provider = ldap > krb5_kpasswd = core-dc1.mydomain.cxm > krb5_realm = mydomain.cxm > krb5_renewable_lifetime = 7d > krb5_server = core-dc1.mydomain.cxm > ldap_default_authtok = thepassword > ldap_default_authtok_type = password > ldap_default_bind_dn = cn=LDAP > Bind,ou=ServiceAccounts,ou=_MyDomain,dc=mydomain,dc=cxm > ldap_group_object_class = group > ldap_group_search_base = OU=_MyDomain,DC=MYDOMAIN,DC=CXM > ldap_search_base = DC=MYDOMAIN,DC=CXM > ldap_tls_reqcert = never > ldap_uri = ldap://core-dc1.mydomain.cxm > ldap_user_home_directory = unixHomeDirectory > ldap_user_name = sAMAccountName > ldap_user_object_class = user > ldap_user_search_base = OU=_MyDomain,DC=MYDOMAIN,DC=CXM > > [nss] > filter_groups = root > filter_users = root > reconnection_retries = 50 > > [pam] > pam_verbosity = 3 > reconnection_retries = 50 > > [sssd] > config_file_version = 2 > debug_level = 0xFF0 > domains = LOCAL, MYDOMAIN > reconnection_retries = 50 > sbus_timeout = 5 > services = nss, pam > > _______________________________________________ > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org > To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted… >

2 2

"groups: cannot find name for group ID #####"
by sssdusers.20.retinkab＠spamgourmet.com 20 Jul '18

20 Jul '18

Hi, I was wondering if anyone has successfully fixed this. I'm working on upgrading servers and client machines, and any time I use a newer SSSD package I'm unable to get groups for the users when they log in. (This is SSSD 1.16.1 on ubt18.04). The problem can be summed up as, root@ubt18-test:# sssd --version 1.16.1 root@ubt18-test:# groups user1 user1 : groups: cannot find name for group ID 33111 33111 groups: cannot find name for group ID 33118 33118 root@ubt18-test:# getent group | grep 33111 unix_users:*:33111: root@ubt18-test:# groups user2 user2 : groups: cannot find name for group ID 33111 33111 root@ubt18-test:# su user2 groups: cannot find name for group ID 33111 user2@ubt18-test:$ groups groups: cannot find name for group ID 33111 33111 -- root@ubt18-test:# getent group unix_users unix_users:*:33111: root@ubt18-test:# groups user2 user2 : unix_users root@blair-ubt18-test:/var/log/sssd# groups user1 user1 : unix_users groups: cannot find name for group ID 33118 33118 This is an odd sequence of events, but notice that I can't get the group for a given user. It shows up only as GID. However, that GID _is_ listed in the output of `getent group`, so it's there, the system can see it, and SSSD is aware of it. Trying again, that gid still won't map to a name when I get the user's groups. The odd part is that if I get the group specifically (`getent group unix_users`), then the mapping for that group thereafter succeeds. Does anyone know what's going on? Of course, everything is working as expected with an earlier version -- 1.13.4. The only fix that I've seen is to recreate every LDAP group in the local groups file, but that seems contrary to the point of using LDAP. I'd like to avoid it. /etc/nsswitch.conf: #passwd: compat systemd sss #group: compat systemd sss passwd: compat sss group: compat sss # it's the same with/without systemd /etc/sssd/sssd.conf: [domain/LOCAL] enumerate = True id_provider = local max_id = 9999 min_id = 1000 [domain/MYDOMAIN] access_provider = simple auth_provider = krb5 debug_level = 0xFF0 cache_credentials = True chpass_provider = krb5 enumerate = True id_provider = ldap krb5_kpasswd = core-dc1.mydomain.cxm krb5_realm = mydomain.cxm krb5_renewable_lifetime = 7d krb5_server = core-dc1.mydomain.cxm ldap_default_authtok = thepassword ldap_default_authtok_type = password ldap_default_bind_dn = cn=LDAP Bind,ou=ServiceAccounts,ou=_ MyDomain,dc=mydomain,dc=cxm ldap_group_object_class = group ldap_group_search_base = OU=_MyDomain,DC=MYDOMAIN,DC=CXM ldap_search_base = DC=MYDOMAIN,DC=CXM ldap_tls_reqcert = never ldap_uri = ldap://core-dc1.mydomain.cxm ldap_user_home_directory = unixHomeDirectory ldap_user_name = sAMAccountName ldap_user_object_class = user ldap_user_search_base = OU=_MyDomain,DC=MYDOMAIN,DC=CXM [nss] filter_groups = root filter_users = root reconnection_retries = 50 [pam] pam_verbosity = 3 reconnection_retries = 50 [sssd] config_file_version = 2 debug_level = 0xFF0 domains = LOCAL, MYDOMAIN reconnection_retries = 50 sbus_timeout = 5 services = nss, pam

2 1

"groups: cannot find name for group ID #####"
by sss.retinkab＠spamgourmet.com 20 Jul '18

20 Jul '18

Hi, I was wondering if anyone has successfully fixed this. I'm working on upgrading servers and client machines, and any time I use a newer SSSD package I'm unable to get groups for the users when they log in. (This is SSSD 1.16.1 on ubt18.04). The problem can be summed up as, root@ubt18-test:# sssd --version 1.16.1 root@ubt18-test:# groups user1 user1 : groups: cannot find name for group ID 33111 33111 groups: cannot find name for group ID 33118 33118 root@ubt18-test:# getent group | grep 33111 unix_users:*:33111: root@ubt18-test:# groups user2 user2 : groups: cannot find name for group ID 33111 33111 root@ubt18-test:# su user2 groups: cannot find name for group ID 33111 user2@ubt18-test:$ groups groups: cannot find name for group ID 33111 33111 -- root@ubt18-test:# getent group unix_users unix_users:*:33111: root@ubt18-test:# groups user2 user2 : unix_users root@blair-ubt18-test:/var/log/sssd# groups user1 user1 : unix_users groups: cannot find name for group ID 33118 33118 This is an odd sequence of events, but notice that I can't get the group for a given user. It shows up only as GID. However, that GID _is_ listed in the output of `getent group`, so it's there, the system can see it, and SSSD is aware of it. Trying again, that gid still won't map to a name when I get the user's groups. The odd part is that if I get the group specifically (`getent group unix_users`), then the mapping for that group thereafter succeeds. Does anyone know what's going on? Of course, everything is working as expected with an earlier version -- 1.13.4. The only fix that I've seen is to recreate every LDAP group in the local groups file, but that seems contrary to the point of using LDAP. I'd like to avoid it. /etc/nsswitch.conf: #passwd: compat systemd sss #group: compat systemd sss passwd: compat sss group: compat sss # it's the same with/without systemd /etc/sssd/sssd.conf: [domain/LOCAL] enumerate = True id_provider = local max_id = 9999 min_id = 1000 [domain/MYDOMAIN] access_provider = simple auth_provider = krb5 debug_level = 0xFF0 cache_credentials = True chpass_provider = krb5 enumerate = True id_provider = ldap krb5_kpasswd = core-dc1.mydomain.cxm krb5_realm = mydomain.cxm krb5_renewable_lifetime = 7d krb5_server = core-dc1.mydomain.cxm ldap_default_authtok = thepassword ldap_default_authtok_type = password ldap_default_bind_dn = cn=LDAP Bind,ou=ServiceAccounts,ou=_MyDomain,dc=mydomain,dc=cxm ldap_group_object_class = group ldap_group_search_base = OU=_MyDomain,DC=MYDOMAIN,DC=CXM ldap_search_base = DC=MYDOMAIN,DC=CXM ldap_tls_reqcert = never ldap_uri = ldap://core-dc1.mydomain.cxm ldap_user_home_directory = unixHomeDirectory ldap_user_name = sAMAccountName ldap_user_object_class = user ldap_user_search_base = OU=_MyDomain,DC=MYDOMAIN,DC=CXM [nss] filter_groups = root filter_users = root reconnection_retries = 50 [pam] pam_verbosity = 3 reconnection_retries = 50 [sssd] config_file_version = 2 debug_level = 0xFF0 domains = LOCAL, MYDOMAIN reconnection_retries = 50 sbus_timeout = 5 services = nss, pam

1 0

sss_override and ssh keys
by John Hearns 19 Jul '18

19 Jul '18

I have set up an sss_override for my user account johe:*:1234:1234:John Hearns,,,:/home/johe:/bin/bash I also have an entry in the locla /etc/passwd file. When I ssh to a server running sssd my ssh key is accepted. When I have no local /etc/passwd When I ssh to a server running sssd my ssh key is not used and I am prompted for a password Can anyone explain please? The answer will be along the lines of at what stage in the ssh login the override is being 'honoured' However this is a bit of a major problem. I guess also I will be told that I have done something wrong.

2 3

Re: problems with sssd-1.9
by Jakub Hrozek 19 Jul '18

19 Jul '18

> On 18 Jul 2018, at 21:13, Laack, Andrea P <Andrea.Laack(a)BSWHealth.org> wrote: > > I have been tasked with joining a number of redhat/centos 5 servers to a domain. I found sssd-1.9 that would allow id_provider ad. This is Centos 5.11. Well, the upstream 1.9 had the ad_provider bits, but they are not built by default IIRC, because the samba libraries on RHEL-5 were too old. You can check by running rpm -ql sssd and checking if there is libsss_ad.so..

2 1

Problem with kinit
by John Hearns 19 Jul '18

19 Jul '18

I have had my head inside the ldap_child.c source code all morning. I am getting these errors logged: [ldap_child_get_tgt_sync] (0x0100): Using keytab [MEMORY:/etc/krb5.keytab] [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Client 'host/ IBIS(a)NZWW.NZCORP.NET' not found in Kerberos database However the dialy ksktutil cron job I have running completes OK, and msktutil --auto-update tells me the machine password was renewed two days ago. Here is what happens when I run kinit from the command line. My workstation is called ibis. Please someone hit me with a clue stick. # kinit -k kinit: Client 'host/ibis(a)NZWW.NZCORP.NET' not found in Kerberos database while getting initial credentials # kinit -V -k ibis$ Using default cache: /tmp/krb5cc_0 Using principal: ibis$(a)NZWW.NZCORP.NET Authenticated to Kerberos v5 # kinit -V -k IBIS\$(a)NZWW.NZCORP.NET Using default cache: /tmp/krb5cc_0 Using principal: IBIS$(a)NZWW.NZCORP.NET Authenticated to Kerberos v5

2 2

Re: problems with sssd-1.9
by JOHE (John Hearns) 19 Jul '18

19 Jul '18

[domain\xxx.pvt] Is the backslash valid here? I am sure an expert will say yes.. You are well aware that RHEL 5 is out of support lifetime? I would imagine that you have some critical applications which run on these machines though. ________________________________ From: Laack, Andrea P <Andrea.Laack(a)BSWHealth.org> Sent: 18 July 2018 21:13:47 To: sssd-users(a)lists.fedorahosted.org Subject: [SSSD-users] problems with sssd-1.9 I have been tasked with joining a number of redhat/centos 5 servers to a domain. I found sssd-1.9 that would allow id_provider ad. This is Centos 5.11. Here is what I got: [root@testcentos5 db]# /usr/sbin/sssd -i -d9 (Wed Jul 18 13:18:49:136142 2018) [sssd] [ldb] (0x0400): server_sort:Unable to register control with rootdse! (Wed Jul 18 13:18:49:137532 2018) [sssd] [ldb] (0x4000): start ldb transaction (nesting: 0) (Wed Jul 18 13:18:49:137857 2018) [sssd] [ldb] (0x4000): start ldb transaction (nesting: 1) (Wed Jul 18 13:18:49:137962 2018) [sssd] [ldb] (0x4000): commit ldb transaction (nesting: 1) (Wed Jul 18 13:18:49:138029 2018) [sssd] [ldb] (0x4000): start ldb transaction (nesting: 1) (Wed Jul 18 13:18:49:138161 2018) [sssd] [ldb] (0x4000): commit ldb transaction (nesting: 1) (Wed Jul 18 13:18:49:138226 2018) [sssd] [ldb] (0x4000): start ldb transaction (nesting: 1) (Wed Jul 18 13:18:49:138343 2018) [sssd] [ldb] (0x4000): commit ldb transaction (nesting: 1) (Wed Jul 18 13:18:49:138404 2018) [sssd] [ldb] (0x4000): start ldb transaction (nesting: 1) (Wed Jul 18 13:18:49:138502 2018) [sssd] [ldb] (0x4000): commit ldb transaction (nesting: 1) (Wed Jul 18 13:18:49:138660 2018) [sssd] [confdb_create_ldif] (0x0400): Processing config section [sssd] (Wed Jul 18 13:18:49:138784 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [config_file_version] (Wed Jul 18 13:18:49:138870 2018) [sssd] [confdb_create_ldif] (0x4000): config_file_version: 2 (Wed Jul 18 13:18:49:138945 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [domains] (Wed Jul 18 13:18:49:139034 2018) [sssd] [confdb_create_ldif] (0x4000): domains: xxx.pvt (Wed Jul 18 13:18:49:139130 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [services] (Wed Jul 18 13:18:49:139214 2018) [sssd] [confdb_create_ldif] (0x4000): services: nss, pam (Wed Jul 18 13:18:49:139295 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [debug_level] (Wed Jul 18 13:18:49:139374 2018) [sssd] [confdb_create_ldif] (0x4000): debug_level: 9 (Wed Jul 18 13:18:49:139539 2018) [sssd] [confdb_create_ldif] (0x4000): Section dn dn: cn=sssd,cn=config cn: sssd config_file_version: 2 domains: xxx.pvt services: nss, pam debug_level: 9 (Wed Jul 18 13:18:49:139873 2018) [sssd] [confdb_create_ldif] (0x0400): Processing config section [nss] (Wed Jul 18 13:18:49:139972 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [debug_level] (Wed Jul 18 13:18:49:140046 2018) [sssd] [confdb_create_ldif] (0x4000): debug_level: 9 (Wed Jul 18 13:18:49:140113 2018) [sssd] [confdb_create_ldif] (0x4000): Section dn dn: cn=nss,cn=config cn: nss debug_level: 9 (Wed Jul 18 13:18:49:140193 2018) [sssd] [confdb_create_ldif] (0x0400): Processing config section [domain\xxx.pvt] (Wed Jul 18 13:18:49:140280 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [fallback_homedir] (Wed Jul 18 13:18:49:140372 2018) [sssd] [confdb_create_ldif] (0x4000): fallback_homedir: /home/%u (Wed Jul 18 13:18:49:140372 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [default_shell] (Wed Jul 18 13:18:49:140372 2018) [sssd] [confdb_create_ldif] (0x4000): default_shell: /bin/bash (Wed Jul 18 13:18:49:140372 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [ad_domain] (Wed Jul 18 13:18:49:140377 2018) [sssd] [confdb_create_ldif] (0x4000): ad_domain: xxx.pvt (Wed Jul 18 13:18:49:140453 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [krb5_realm] (Wed Jul 18 13:18:49:140536 2018) [sssd] [confdb_create_ldif] (0x4000): krb5_realm: xxx.PVT (Wed Jul 18 13:18:49:140613 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [krb5_server] (Wed Jul 18 13:18:49:140690 2018) [sssd] [confdb_create_ldif] (0x4000): krb5_server: xxxxc02.xxx.pvt (Wed Jul 18 13:18:49:140765 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [auth_provider] (Wed Jul 18 13:18:49:140842 2018) [sssd] [confdb_create_ldif] (0x4000): auth_provider: krb5 (Wed Jul 18 13:18:49:141316 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [cache_credentials] (Wed Jul 18 13:18:49:141640 2018) [sssd] [confdb_create_ldif] (0x4000): cache_credentials: True (Wed Jul 18 13:18:49:141839 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [id_provider] (Wed Jul 18 13:18:49:141945 2018) [sssd] [confdb_create_ldif] (0x4000): id_provider: ad (Wed Jul 18 13:18:49:142023 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [ad_server] (Wed Jul 18 13:18:49:142102 2018) [sssd] [confdb_create_ldif] (0x4000): ad_server: xxxxc01, xxxxc01, xxxxc01, xxxxc02, xxxxc03 (Wed Jul 18 13:18:49:142186 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [krb5_store_password_if_offline] (Wed Jul 18 13:18:49:142267 2018) [sssd] [confdb_create_ldif] (0x4000): krb5_store_password_if_offline: True (Wed Jul 18 13:18:49:142344 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [access_provider] (Wed Jul 18 13:18:49:142357 2018) [sssd] [confdb_create_ldif] (0x4000): access_provider: simple (Wed Jul 18 13:18:49:142357 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [ldap_schema] (Wed Jul 18 13:18:49:142435 2018) [sssd] [confdb_create_ldif] (0x4000): ldap_schema: ad (Wed Jul 18 13:18:49:142518 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [ldap_id_mappings] (Wed Jul 18 13:18:49:142599 2018) [sssd] [confdb_create_ldif] (0x4000): ldap_id_mappings: True (Wed Jul 18 13:18:49:142675 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [simple_allow_groups] (Wed Jul 18 13:18:49:142753 2018) [sssd] [confdb_create_ldif] (0x4000): simple_allow_groups: linux@admins@xxx.pvt (Wed Jul 18 13:18:49:142829 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [simple_allow_users] (Wed Jul 18 13:18:49:142922 2018) [sssd] [confdb_create_ldif] (0x4000): simple_allow_users: rapid7scan(a)xxx.pvt (Wed Jul 18 13:18:49:143005 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [debug_level] (Wed Jul 18 13:18:49:143079 2018) [sssd] [confdb_create_ldif] (0x4000): debug_level: 9 (Wed Jul 18 13:18:49:143166 2018) [sssd] [confdb_create_ldif] (0x4000): Section dn dn: cn=domain\xxx.pvt,cn=config cn: domain\xxx.pvt fallback_homedir: /home/%u default_shell: /bin/bash ad_domain: xxx.pvt krb5_realm: XXX.PVT krb5_server: xxx02.xxx.pvt auth_provider: krb5 cache_credentials: True id_provider: ad ad_server: xxxxc01, xxxxc01, xxxxc01, xxxxc02, xxxxc03 krb5_store_password_if_offline: True access_provider: simple ldap_schema: ad ldap_id_mappings: True simple_allow_groups: linux@admins@xxx.pvt simple_allow_users: rapid7scan(a)xxx.pvt debug_level: 9 (Wed Jul 18 13:18:49:143281 2018) [sssd] [confdb_init_db] (0x1000): LDIF file to import: dn: cn=config version: 2 dn: cn=sssd,cn=config cn: sssd config_file_version: 2 domains: xxx.pvt services: nss, pam debug_level: 9 dn: cn=nss,cn=config cn: nss debug_level: 9 dn: cn=domain\bhcs.pvt,cn=config cn: domain\bhcs.pvt fallback_homedir: /home/%u default_shell: /bin/bash ad_domain: xxx.pvt krb5_realm: XXX.PVT krb5_server: xxxxxdc02.xxx.pvt auth_provider: krb5 cache_credentials: True id_provider: ad ad_server: xxxxxc01, xxxxxc01, xxxxxc01, xxxxxc02, xxxxxc03 krb5_store_password_if_offline: True access_provider: simple ldap_schema: ad ldap_id_mappings: True simple_allow_groups: linux@admins@xxx.pvt simple_allow_users: rapid7scan(a)xxx.pvt debug_level: 9 (Wed Jul 18 13:18:49:143420 2018) [sssd] [ldb] (0x4000): start ldb transaction (nesting: 1) (Wed Jul 18 13:18:49:143639 2018) [sssd] [ldb] (0x4000): commit ldb transaction (nesting: 1) (Wed Jul 18 13:18:49:143862 2018) [sssd] [ldb] (0x4000): start ldb transaction (nesting: 1) (Wed Jul 18 13:18:49:143983 2018) [sssd] [ldb] (0x4000): commit ldb transaction (nesting: 1) (Wed Jul 18 13:18:49:144062 2018) [sssd] [ldb] (0x4000): start ldb transaction (nesting: 1) (Wed Jul 18 13:18:49:144166 2018) [sssd] [ldb] (0x4000): commit ldb transaction (nesting: 1) (Wed Jul 18 13:18:49:144275 2018) [sssd] [ldb] (0x4000): start ldb transaction (nesting: 1) (Wed Jul 18 13:18:49:144372 2018) [sssd] [ldb] (0x4000): commit ldb transaction (nesting: 1) (Wed Jul 18 13:18:49:144520 2018) [sssd] [ldb] (0x4000): start ldb transaction (nesting: 1) (Wed Jul 18 13:18:49:144805 2018) [sssd] [ldb] (0x4000): commit ldb transaction (nesting: 1) (Wed Jul 18 13:18:49:158827 2018) [sssd] [ldb] (0x4000): commit ldb transaction (nesting: 0) (Wed Jul 18 13:18:49:159670 2018) [sssd] [add_implicit_services] (0x0040): id_provider is not set for domain [xxx.pvt], trying next domain. (Wed Jul 18 13:18:49:159863 2018) [sssd] [confdb_get_domain_internal] (0x0010): Unknown domain [xxx.pvt] (Wed Jul 18 13:18:49:159970 2018) [sssd] [confdb_get_domains] (0x0010): Error (2 [No such file or directory]) retrieving domain [xxx.pvt], skipping! (Wed Jul 18 13:18:49:160014 2018) [sssd] [confdb_get_domains] (0x0010): No properly configured domains, fatal error! (Wed Jul 18 13:18:49:160068 2018) [sssd] [get_monitor_config] (0x0010): No domains configured. (Wed Jul 18 13:18:49:160179 2018) [sssd] [main] (0x0020): Error loading configuration database: [2]: No such file or directory Sssd.conf [sssd] config_file_version = 2 domains = bhcs.pvt services = nss, pam debug_level = 9 [nss] debug_level = 9 [domain\xxx.pvt] fallback_homedir = /home/%u default_shell = /bin/bash ad_domain = xxx.pvt krb5_realm = xxx.PVT krb5_server = xxxxc02.bhcs.pvt auth_provider = krb5 cache_credentials = True id_provider = ad ad_server = xxxxc01, xxxxc01, xxxxdc01, xxxxdc02, xxxxc03 krb5_store_password_if_offline = True access_provider = simple ldap_schema = ad ldap_id_mappings = True # ldap_sasl_mech=GSSAPI simple_allow_groups = linux@admins@xxx.pvt simple_allow_users = rapid7scan(a)xxx.pvt debug_level = 9 Would appreciate any assistance you could offer. Thanks Andrea Andrea Laack Host Systems [cid:image002.jpg@01D41EA1.8969FEA0] 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@01D41EA0.4137E5D0] <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.your…> [cid:image004.png@01D41EA0.4137E5D0] ________________________________ 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

problems with sssd-1.9
by Laack, Andrea P 18 Jul '18

18 Jul '18

I have been tasked with joining a number of redhat/centos 5 servers to a domain. I found sssd-1.9 that would allow id_provider ad. This is Centos 5.11. Here is what I got: [root@testcentos5 db]# /usr/sbin/sssd -i -d9 (Wed Jul 18 13:18:49:136142 2018) [sssd] [ldb] (0x0400): server_sort:Unable to register control with rootdse! (Wed Jul 18 13:18:49:137532 2018) [sssd] [ldb] (0x4000): start ldb transaction (nesting: 0) (Wed Jul 18 13:18:49:137857 2018) [sssd] [ldb] (0x4000): start ldb transaction (nesting: 1) (Wed Jul 18 13:18:49:137962 2018) [sssd] [ldb] (0x4000): commit ldb transaction (nesting: 1) (Wed Jul 18 13:18:49:138029 2018) [sssd] [ldb] (0x4000): start ldb transaction (nesting: 1) (Wed Jul 18 13:18:49:138161 2018) [sssd] [ldb] (0x4000): commit ldb transaction (nesting: 1) (Wed Jul 18 13:18:49:138226 2018) [sssd] [ldb] (0x4000): start ldb transaction (nesting: 1) (Wed Jul 18 13:18:49:138343 2018) [sssd] [ldb] (0x4000): commit ldb transaction (nesting: 1) (Wed Jul 18 13:18:49:138404 2018) [sssd] [ldb] (0x4000): start ldb transaction (nesting: 1) (Wed Jul 18 13:18:49:138502 2018) [sssd] [ldb] (0x4000): commit ldb transaction (nesting: 1) (Wed Jul 18 13:18:49:138660 2018) [sssd] [confdb_create_ldif] (0x0400): Processing config section [sssd] (Wed Jul 18 13:18:49:138784 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [config_file_version] (Wed Jul 18 13:18:49:138870 2018) [sssd] [confdb_create_ldif] (0x4000): config_file_version: 2 (Wed Jul 18 13:18:49:138945 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [domains] (Wed Jul 18 13:18:49:139034 2018) [sssd] [confdb_create_ldif] (0x4000): domains: xxx.pvt (Wed Jul 18 13:18:49:139130 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [services] (Wed Jul 18 13:18:49:139214 2018) [sssd] [confdb_create_ldif] (0x4000): services: nss, pam (Wed Jul 18 13:18:49:139295 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [debug_level] (Wed Jul 18 13:18:49:139374 2018) [sssd] [confdb_create_ldif] (0x4000): debug_level: 9 (Wed Jul 18 13:18:49:139539 2018) [sssd] [confdb_create_ldif] (0x4000): Section dn dn: cn=sssd,cn=config cn: sssd config_file_version: 2 domains: xxx.pvt services: nss, pam debug_level: 9 (Wed Jul 18 13:18:49:139873 2018) [sssd] [confdb_create_ldif] (0x0400): Processing config section [nss] (Wed Jul 18 13:18:49:139972 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [debug_level] (Wed Jul 18 13:18:49:140046 2018) [sssd] [confdb_create_ldif] (0x4000): debug_level: 9 (Wed Jul 18 13:18:49:140113 2018) [sssd] [confdb_create_ldif] (0x4000): Section dn dn: cn=nss,cn=config cn: nss debug_level: 9 (Wed Jul 18 13:18:49:140193 2018) [sssd] [confdb_create_ldif] (0x0400): Processing config section [domain\xxx.pvt] (Wed Jul 18 13:18:49:140280 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [fallback_homedir] (Wed Jul 18 13:18:49:140372 2018) [sssd] [confdb_create_ldif] (0x4000): fallback_homedir: /home/%u (Wed Jul 18 13:18:49:140372 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [default_shell] (Wed Jul 18 13:18:49:140372 2018) [sssd] [confdb_create_ldif] (0x4000): default_shell: /bin/bash (Wed Jul 18 13:18:49:140372 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [ad_domain] (Wed Jul 18 13:18:49:140377 2018) [sssd] [confdb_create_ldif] (0x4000): ad_domain: xxx.pvt (Wed Jul 18 13:18:49:140453 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [krb5_realm] (Wed Jul 18 13:18:49:140536 2018) [sssd] [confdb_create_ldif] (0x4000): krb5_realm: xxx.PVT (Wed Jul 18 13:18:49:140613 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [krb5_server] (Wed Jul 18 13:18:49:140690 2018) [sssd] [confdb_create_ldif] (0x4000): krb5_server: xxxxc02.xxx.pvt (Wed Jul 18 13:18:49:140765 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [auth_provider] (Wed Jul 18 13:18:49:140842 2018) [sssd] [confdb_create_ldif] (0x4000): auth_provider: krb5 (Wed Jul 18 13:18:49:141316 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [cache_credentials] (Wed Jul 18 13:18:49:141640 2018) [sssd] [confdb_create_ldif] (0x4000): cache_credentials: True (Wed Jul 18 13:18:49:141839 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [id_provider] (Wed Jul 18 13:18:49:141945 2018) [sssd] [confdb_create_ldif] (0x4000): id_provider: ad (Wed Jul 18 13:18:49:142023 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [ad_server] (Wed Jul 18 13:18:49:142102 2018) [sssd] [confdb_create_ldif] (0x4000): ad_server: xxxxc01, xxxxc01, xxxxc01, xxxxc02, xxxxc03 (Wed Jul 18 13:18:49:142186 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [krb5_store_password_if_offline] (Wed Jul 18 13:18:49:142267 2018) [sssd] [confdb_create_ldif] (0x4000): krb5_store_password_if_offline: True (Wed Jul 18 13:18:49:142344 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [access_provider] (Wed Jul 18 13:18:49:142357 2018) [sssd] [confdb_create_ldif] (0x4000): access_provider: simple (Wed Jul 18 13:18:49:142357 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [ldap_schema] (Wed Jul 18 13:18:49:142435 2018) [sssd] [confdb_create_ldif] (0x4000): ldap_schema: ad (Wed Jul 18 13:18:49:142518 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [ldap_id_mappings] (Wed Jul 18 13:18:49:142599 2018) [sssd] [confdb_create_ldif] (0x4000): ldap_id_mappings: True (Wed Jul 18 13:18:49:142675 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [simple_allow_groups] (Wed Jul 18 13:18:49:142753 2018) [sssd] [confdb_create_ldif] (0x4000): simple_allow_groups: linux@admins@xxx.pvt (Wed Jul 18 13:18:49:142829 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [simple_allow_users] (Wed Jul 18 13:18:49:142922 2018) [sssd] [confdb_create_ldif] (0x4000): simple_allow_users: rapid7scan(a)xxx.pvt (Wed Jul 18 13:18:49:143005 2018) [sssd] [confdb_create_ldif] (0x0400): Processing attribute [debug_level] (Wed Jul 18 13:18:49:143079 2018) [sssd] [confdb_create_ldif] (0x4000): debug_level: 9 (Wed Jul 18 13:18:49:143166 2018) [sssd] [confdb_create_ldif] (0x4000): Section dn dn: cn=domain\xxx.pvt,cn=config cn: domain\xxx.pvt fallback_homedir: /home/%u default_shell: /bin/bash ad_domain: xxx.pvt krb5_realm: XXX.PVT krb5_server: xxx02.xxx.pvt auth_provider: krb5 cache_credentials: True id_provider: ad ad_server: xxxxc01, xxxxc01, xxxxc01, xxxxc02, xxxxc03 krb5_store_password_if_offline: True access_provider: simple ldap_schema: ad ldap_id_mappings: True simple_allow_groups: linux@admins@xxx.pvt simple_allow_users: rapid7scan(a)xxx.pvt debug_level: 9 (Wed Jul 18 13:18:49:143281 2018) [sssd] [confdb_init_db] (0x1000): LDIF file to import: dn: cn=config version: 2 dn: cn=sssd,cn=config cn: sssd config_file_version: 2 domains: xxx.pvt services: nss, pam debug_level: 9 dn: cn=nss,cn=config cn: nss debug_level: 9 dn: cn=domain\bhcs.pvt,cn=config cn: domain\bhcs.pvt fallback_homedir: /home/%u default_shell: /bin/bash ad_domain: xxx.pvt krb5_realm: XXX.PVT krb5_server: xxxxxdc02.xxx.pvt auth_provider: krb5 cache_credentials: True id_provider: ad ad_server: xxxxxc01, xxxxxc01, xxxxxc01, xxxxxc02, xxxxxc03 krb5_store_password_if_offline: True access_provider: simple ldap_schema: ad ldap_id_mappings: True simple_allow_groups: linux@admins@xxx.pvt simple_allow_users: rapid7scan(a)xxx.pvt debug_level: 9 (Wed Jul 18 13:18:49:143420 2018) [sssd] [ldb] (0x4000): start ldb transaction (nesting: 1) (Wed Jul 18 13:18:49:143639 2018) [sssd] [ldb] (0x4000): commit ldb transaction (nesting: 1) (Wed Jul 18 13:18:49:143862 2018) [sssd] [ldb] (0x4000): start ldb transaction (nesting: 1) (Wed Jul 18 13:18:49:143983 2018) [sssd] [ldb] (0x4000): commit ldb transaction (nesting: 1) (Wed Jul 18 13:18:49:144062 2018) [sssd] [ldb] (0x4000): start ldb transaction (nesting: 1) (Wed Jul 18 13:18:49:144166 2018) [sssd] [ldb] (0x4000): commit ldb transaction (nesting: 1) (Wed Jul 18 13:18:49:144275 2018) [sssd] [ldb] (0x4000): start ldb transaction (nesting: 1) (Wed Jul 18 13:18:49:144372 2018) [sssd] [ldb] (0x4000): commit ldb transaction (nesting: 1) (Wed Jul 18 13:18:49:144520 2018) [sssd] [ldb] (0x4000): start ldb transaction (nesting: 1) (Wed Jul 18 13:18:49:144805 2018) [sssd] [ldb] (0x4000): commit ldb transaction (nesting: 1) (Wed Jul 18 13:18:49:158827 2018) [sssd] [ldb] (0x4000): commit ldb transaction (nesting: 0) (Wed Jul 18 13:18:49:159670 2018) [sssd] [add_implicit_services] (0x0040): id_provider is not set for domain [xxx.pvt], trying next domain. (Wed Jul 18 13:18:49:159863 2018) [sssd] [confdb_get_domain_internal] (0x0010): Unknown domain [xxx.pvt] (Wed Jul 18 13:18:49:159970 2018) [sssd] [confdb_get_domains] (0x0010): Error (2 [No such file or directory]) retrieving domain [xxx.pvt], skipping! (Wed Jul 18 13:18:49:160014 2018) [sssd] [confdb_get_domains] (0x0010): No properly configured domains, fatal error! (Wed Jul 18 13:18:49:160068 2018) [sssd] [get_monitor_config] (0x0010): No domains configured. (Wed Jul 18 13:18:49:160179 2018) [sssd] [main] (0x0020): Error loading configuration database: [2]: No such file or directory Sssd.conf [sssd] config_file_version = 2 domains = bhcs.pvt services = nss, pam debug_level = 9 [nss] debug_level = 9 [domain\xxx.pvt] fallback_homedir = /home/%u default_shell = /bin/bash ad_domain = xxx.pvt krb5_realm = xxx.PVT krb5_server = xxxxc02.bhcs.pvt auth_provider = krb5 cache_credentials = True id_provider = ad ad_server = xxxxc01, xxxxc01, xxxxdc01, xxxxdc02, xxxxc03 krb5_store_password_if_offline = True access_provider = simple ldap_schema = ad ldap_id_mappings = True # ldap_sasl_mech=GSSAPI simple_allow_groups = linux@admins@xxx.pvt simple_allow_users = rapid7scan(a)xxx.pvt debug_level = 9 Would appreciate any assistance you could offer. Thanks Andrea Andrea Laack Host Systems [cid:image002.jpg@01D41EA1.8969FEA0] 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@01D41EA0.4137E5D0] <https://www.youracclaim.com/badges/d2b9b13f-0db9-4666-860e-146c70d45d36> [cid:image004.png@01D41EA0.4137E5D0] ********************************************************************** 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

groups missing when using tokengroups...
by Spike White 16 Jul '18

16 Jul '18

Jakub, Thank you to answering so promptly. We are currently testing this in a lab before full deployment, so I have some degree of time before we deploy sssd in a bigger context. If you would prefer for me to work with you directly off-line, please advise. As an example, the attached sssd_amer.dell.com.log file was originally 40 MB. (I presume because of debugging level). Out of respect for others on the mailing list, I severely trimmed the log file to only the lines of interest (I hope). But it's entirely possible I may have over-trimmed. You asked: Can you send logs for a single lookup of "id username" with tokengroups enabled? Last week, I attached the logs. for one specific lookup. Even though I severely trimmed the logs, it exceeded the max file size for this mailing list. It was the sssd_amer.dell.com.log and sssd_nss.log, for this lookup: [root@spikerealmd02 sssd]# id admpatrick_wheeler uid=2604370(admpatrick_wheeler) gid=2604370(admpatrick_wheeler) groups=2604370(admpatrick_wheeler),1010(amerunixusers) This is with ldap_use_tokengroups = True, so the above lookup is incorrect. What it should show is: id admpatrick_wheeler uid=2604370(admpatrick_wheeler) gid=2604370(admpatrick_wheeler) groups=2604370(admpatrick_wheeler),1033(amer_server_mgmt),1003(amerlinuxsup),1010(amerunixusers) You asked: Why do you disable the subdomains provider? Isn't it easier to just list the domains you want to enable using the ad_enabled_domains option? btw this can actually cause issues because the subdomains provider is needed to fetch the joined domain SID at least, among other things. When I ran with: ad_enabled_domains = amer.dell.com, apac.dell.com, emea.dell.com, japn.dell.com, dell.com it broke cross-subdomain authentication. that is, I could resolve accounts from the local domain (AMER), but not from any other domain (like apac). When I reviewed the logs, I saw the sssd_nss.log would do a dispatch to the apac.dell.com child, but the dispatch would always fail. In sssd_apac.dell.com.log -- the dispatch was never picked up. I also noticed that sssctl domain-list gave me this: amer.dell.com apac.dell.com emea.dell.com japn.dell.com dell.com amer.dell.com apac.dell.com emea.dell.com japn.dell.com I suspect that sssd_nss was attempting to dispatch into this apac.dell.com "ghost" domain and failing. When I removed ad_enabled_domains (& commented out dell.com as a domain), I noticed sssctl domain-list gave me the expected: amer.dell.com apac.dell.com emea.dell.com japn.dell.com And cross-subdomain authentication worked (modulo this tokengroups problem where not all groups show up when tokengroups == True). You stated: > ldap_schema = rfc2307bis Please don't set ldap_schema to anything else than 'ad' (the default) with id_provider=ad. Unfortunately, our erstwhile AD administrators when they extended our AD schema years ago did not use an rfc2307 schema extension. They used a rfc2307bis schema extension instead. I had fits with even basic sssd AD integration until I realized this. (I thought I was going to have to manually set up ldap_filters for the few quirky LDAP attributes associated with an account, but then I realized this conformed 100% to rfc2307bis.) When I set ldap_schema to rfc2307bis, the basic (same domain) authentication worked (without tokengroups).

1 0

recreate machine keytab file
by Ondrej Valousek 10 Jul '18

10 Jul '18

Hi List, Is there any way how can we recreate system keytab file of a machine joined to AD if the file has been broken/deleted? I want to avoid doing join again as this would probably delete the existing account (with all attributes we have set). 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.

5 10

sssd id getent and secondary groups in active directory
by Ratliff, John 09 Jul '18

09 Jul '18

I'm using SSSD and realmd to join a machine to active directory. When I run id on my user, I only get the primary group. If I run getent group "groupname", it works...sometimes. Other times, it returns blank. This is on a CentOS 7 machine (sssd 1.16.0) $ id jdratlif uid=752603752(jdratlif) gid=1572000513(domain users) groups=1572000513(domain users) $ getent group ssh-test-users2 ssh-test-users2:*:752629809: $ sss_cache -E $ getent group ssh-test-users2 ssh-test-users2:*:752629809:jdratlif $ id jdratlif uid=752603752(jdratlif) gid=1572000513(domain users) groups=1572000513(domain users) $ getent group ssh-test-users2 ssh-test-users2:*:752629809: $ id jdratlif uid=752603752(jdratlif) gid=1572000513(domain users) groups=1572000513(domain users) This was all in the span of 2 minutes. Let me know what other information would be helpful. Thanks. -- John Ratliff Research Storage / UITS / Pervasive Technology Institute Indiana University | https://pti.iu.edu

4 8

Why is my sssd deployment not doing cross-subdomain AD authentication?
by Spike White 08 Jul '18

08 Jul '18

sssd subject matter experts, Why is my sssd deployment not doing cross-subdomain AD authentication? *Background:* I have a parent AD domain DELL.COM with trusted subdomains AMER.DELL.COM, APAC.DELL.COM, EMEA.DELL.COM and JAPN.DELL.COM Each subdomain has a transitive trust with DELL.COM. So all subdomains trust each other. I set up a first test VM deployment using sssd. I set up the cross subdomain auth as in: https://lists.fedorahosted.org/pipermail/sssd-users/2015-February/002648.ht… It worked great – allowed cross subdomain authentication. The only thing it would not do was use tokengroups. That is, the VM was fully functional, but I had to add ‘ldap_use_tokengroups = false’ to the sssd.conf file. My AD experts have advised me that ‘tokengroups’ are an important AD optimization and I should use them, if at all possible. Using ldapsearch, I was able to verify that machine account didn’t have the necessary privileges to query a user’s tokengroups. Thus, the fault was mine – that this first sssd deployment couldn’t use tokengroups. So I did another sssd deployment, using another test VM. Apparently, I did the realm join command correct this time, as it’s able to use tokengroups. BUT! This second test VM is not allowing cross subdomain authentication and login. How do I fix this so that I have use of both tokengroups and cross subdomain authentication? (BTW -- Both test VMs are still up and operational, as described above.) *Details:* Here is the realm join command used in the second test VM (spikerealmd02): kinit serviceunixinstall realm join -v --automatic-id-mapping=no --computer-ou='OU=Servers,OU=UNIX,DC=AMER,DC=DELL,DC=COM' --user-principal="host/`hostname --fqdn`(a)AMER.DELL.COM" AMER.DELL.COM Here is the /etc/realmd.conf file from this second test VM: [root@spikerealmd02 etc]# cat realmd.conf [AMER.DELL.COM] computer-ou = OU=SERVERS,OU=UNIX,DC=AMER,DC=DELL,DC=COM automatic-id-mapping = no manage-system = no fully-qualified-names = no # THIS FAILS AT DELL; serviceunixinstall apparently not allowed to create UPNs associated with machine account. # Set the user-prinicpal to yes to create userPrincipalName attributes for the computer account in the realm, in the form host/computer@REALM #user-principal = yes [active-directory] default_client = sssd [service] automatic-install = no [users] # shouldn't need this; should be set in AD for each UNIX-enabled user. default-home = /home/%U # shouldn't need this; should be set in AD for each UNIX-enabled user. default-shell = /bin/bash Here’s the /etc/sssd/sssd.conf file for this second test VM: [root@spikerealmd02 sssd]# cat sssd.conf [sssd] debug_level = 6 domains = amer.dell.com,apac.dell.com,emea.dell.com,japn.dell.com domain_resolution_order = amer.dell.com, emea.dell.com, apac.dell.com, japn.dell.com config_file_version = 2 services = nss,pam #ldap_user_member_of = member [pam] pam_verbosity = 3 debug_level = 9 [nss] debug_level = 9 filter_groups = root filter_users = root reconnection_retries = 3 #entry_cache_timeout = 300 entry_cache_nowait_percentage = 75 [domain/amer.dell.com] debug_level = 9 auto_private_groups = True use_fully_qualified_names = False ad_domain = amer.dell.com krb5_realm = AMER.DELL.COM realmd_tags = joined-with-adcli 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 #access_provider = ad 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 ad_enabled_domains = amer.dell.com,apac.dell.com,emea.dell.com,japn.dell.com ,dell.com dyndns_update = False subdomains_provider = none ldap_use_tokengroups = true 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 ad_enabled_domains = amer.dell.com, apac.dell.com, apac.dell.com, japn.dell.com, dell.com dyndns_update = False subdomains_provider = none 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 ad_enabled_domains = amer.dell.com, apac.dell.com, emea.dell.com, japn.dell.com, dell.com dyndns_update = False subdomains_provider = none ldap_use_tokengroups = true 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 ad_enabled_domains = amer.dell.com, apac.dell.com, japn.dell.com, japn.dell.com, dell.com dyndns_update = False subdomains_provider = none ldap_use_tokengroups = true simple_allow_groups = japnlinuxsup(a)JAPN.DELL.COM, japnlinuxeng(a)JAPN.DELL.COM and here’s the /etc/krb5.conf file: # Configuration snippets may be placed in this directory as well includedir /etc/krb5.conf.d/ includedir /var/lib/sss/pubconf/krb5.include.d/ [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] # SW mod 5/12/2018 # dns_lookup_realm = false dns_lookup_realm = false ticket_lifetime = 24h renew_lifetime = 7d forwardable = true rdns = false # default_realm = EXAMPLE.COM default_ccache_name = KEYRING:persistent:%{uid} default_realm = AMER.DELL.COM [realms] # EXAMPLE.COM = { # kdc = kerberos.example.com # admin_server = kerberos.example.com # } # AMER.DELL.COM = { # } [domain_realm] # .example.com = EXAMPLE.COM # example.com = EXAMPLE.COM amer.dell.com = AMER.DELL.COM .amer.dell.com = AMER.DELL.COM *Comparing with first VM that does cross subdomain auth:* Here’s /etc/realmd.conf of first test VM that does cross subdomain auth (spikerealmd01): [root@spikerealmd01 krb5.include.d]# cat /etc/realmd.conf [AMER.DELL.COM] computer-ou = OU=SERVERS,OU=UNIX,DC=AMER,DC=DELL,DC=COM automatic-id-mapping = no manage-system = no fully-qualified-names = no # THIS FAILS AT DELL; serviceunixinstall apparently not allowed to create UPNs associated with machine account. # Set the user-prinicpal to yes to create userPrincipalName attributes for the computer account in the realm, in the form host/computer@REALM #user-principal = yes [active-directory] default_client = sssd [service] automatic-install = no [users] # shouldn't need this; should be set in AD for each UNIX-enabled user. default-home = /home/%U # shouldn't need this; should be set in AD for each UNIX-enabled user. default-shell = /bin/bash Here’s /etc/sssd/sssd.conf file from same first test VM: [root@spikerealmd01 sssd]# cat sssd.conf [sssd] debug_level = 6 domains = amer.dell.com, apac.dell.com, emea.dell.com, japn.dell.com domain_resolution_order = amer.dell.com, emea.dell.com, apac.dell.com, japn.dell.com config_file_version = 2 services = nss, pam #ldap_user_member_of = member [pam] pam_verbosity = 3 debug_level = 9 [nss] debug_level = 9 filter_groups = root filter_users = root reconnection_retries = 3 #entry_cache_timeout = 300 entry_cache_nowait_percentage = 75 [domain/amer.dell.com] debug_level = 9 auto_private_groups = True use_fully_qualified_names = False ad_domain = amer.dell.com krb5_realm = AMER.DELL.COM realmd_tags = joined-with-adcli 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/spikerealmd01.us.dell.com #ldap_sasl_authid = SPIKEREALMD01$(a)AMER.DELL.COM ldap_sasl_authid = spikerealmd01(a)AMER.DELL.COM ad_enabled_domains = amer.dell.com, apac.dell.com, emea.dell.com, japn.dell.com, dell.com dyndns_update = False subdomains_provider = none ldap_use_tokengroups = false simple_allow_groups = amerlinuxsup(a)AMER.DELL.COM, amerlinuxeng(a)AMER.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 realmd_tags = joined-with-adcli 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/spikerealmd01.us.dell.com #ldap_sasl_authid = SPIKEREALMD01$(a)AMER.DELL.COM ldap_sasl_authid = spikerealmd01(a)AMER.DELL.COM ad_enabled_domains = amer.dell.com, apac.dell.com, emea.dell.com, japn.dell.com, dell.com dyndns_update = False subdomains_provider = none 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 realmd_tags = joined-with-adcli 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/spikerealmd01.us.dell.com #ldap_sasl_authid = SPIKEREALMD01$(a)AMER.DELL.COM ldap_sasl_authid = spikerealmd01(a)AMER.DELL.COM ad_enabled_domains = amer.dell.com, apac.dell.com, emea.dell.com, japn.dell.com, dell.com dyndns_update = False subdomains_provider = none 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 realmd_tags = joined-with-adcli 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/spikerealmd01.us.dell.com #ldap_sasl_authid = SPIKEREALMD01$(a)AMER.DELL.COM ldap_sasl_authid = spikerealmd01(a)AMER.DELL.COM ad_enabled_domains = amer.dell.com, apac.dell.com, emea.dell.com, japn.dell.com, dell.com dyndns_update = False subdomains_provider = none ldap_use_tokengroups = false simple_allow_groups = japnlinuxsup(a)JAPN.DELL.COM, japnlinuxeng(a)JAPN.DELL.COM, linux-core-engineering, amer.dell.com Here’s /etc/krb5.conf file: [root@spikerealmd01 etc]# cat krb5.conf # Configuration snippets may be placed in this directory as well includedir /etc/krb5.conf.d/ includedir /var/lib/sss/pubconf/krb5.include.d/ [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] # SW mod 5/12/2018 # dns_lookup_realm = false dns_lookup_realm = false ticket_lifetime = 24h renew_lifetime = 7d forwardable = true rdns = false # default_realm = EXAMPLE.COM default_ccache_name = KEYRING:persistent:%{uid} default_realm = AMER.DELL.COM [realms] # EXAMPLE.COM = { # kdc = kerberos.example.com # admin_server = kerberos.example.com # } # AMER.DELL.COM = { # } [domain_realm] # .example.com = EXAMPLE.COM # example.com = EXAMPLE.COM amer.dell.com = AMER.DELL.COM .amer.dell.com = AMER.DELL.COM [root@spikerealmd01 etc]# *Other details:* If I query group membership of an engineer in APAC: id admjesse_chan on the good VM (spikerealmd01) I see all expected groups and I see this in the /var/log/sssd/sssd_apac.dell.com.log file: … (Sun Jul 1 15:14:30 2018) [sssd[be[apac.dell.com]]] [sdap_initgr_rfc2307bis_next_base] (0x0400): Searching for parent groups for user [CN=AdmJesse_Chan,OU=ADMAccounts,DC=apac,DC=dell,DC=com] with base [DC=apac,DC=dell,DC=com] (Sun Jul 1 15:14:30 2018) [sssd[be[apac.dell.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(member=CN=AdmJesse_Chan,OU=ADMAccounts,DC=apac,DC=dell,DC=com)(objectClass=group)(sAMAccountName=*))][DC=apac,DC=dell,DC=com]. (Sun Jul 1 15:14:31 2018) [sssd[be[apac.dell.com]]] [sdap_initgr_rfc2307bis_process] (0x1000): Found 4 parent groups for user [ AdmJesse_Chan(a)apac.dell.com] (Sun Jul 1 15:14:31 2018) [sssd[be[apac.dell.com]]] [sysdb_get_direct_parents] (0x2000): searching sysdb with filter [(&(objectCategory=group)(member=name=AdmJesse_Chan(a)apac.dell.com ,cn=users,cn=apac.dell.com,cn=sysdb))] (Sun Jul 1 15:14:31 2018) [sssd[be[apac.dell.com]]] [sysdb_get_direct_parents] (0x1000): AdmJesse_Chan(a)apac.dell.com is a member of 4 sysdb groups (Sun Jul 1 15:14:31 2018) [sssd[be[apac.dell.com]]] [save_rfc2307bis_user_memberships] (0x2000): Updating memberships for AdmJesse_Chan(a)apac.dell.com (Sun Jul 1 15:14:31 2018) [sssd[be[apac.dell.com]]] [sysdb_set_entry_attr] (0x0200): Entry [name=AdmJesse_Chan(a)apac.dell.com,cn=users,cn=apac.dell.com,cn=sysdb] has set [ts_cache] attrs. (Sun Jul 1 15:14:31 2018) [sssd[be[apac.dell.com]]] [dp_table_value_destructor] (0x0400): Removing [0:1:0x0001:3::apac.dell.com: name=admjesse_chan(a)apac.dell.com] from reply table (Sun Jul 1 15:14:35 2018) [sssd[be[apac.dell.com]]] [sdap_asq_search_parse_entry] (0x2000): Matched objectclass [user] on DN [CN=AdmJesse_Chan,OU=ADMAccounts,DC=apac,DC=dell,DC=com], will use associated map (Sun Jul 1 15:14:35 2018) [sssd[be[apac.dell.com]]] [sdap_parse_entry] (0x1000): OriginalDN: [CN=AdmJesse_Chan,OU=ADMAccounts,DC=apac,DC=dell,DC=com]. (Sun Jul 1 15:14:35 2018) [sssd[be[apac.dell.com]]] [sdap_asq_search_parse_entry] (0x2000): DN [CN=AdmJesse_Chan,OU=ADMAccounts,DC=apac,DC=dell,DC=com] did not match the objectClass [group] (Sun Jul 1 15:14:36 2018) [sssd[be[apac.dell.com]]] [sdap_nested_group_hash_insert] (0x4000): Inserting [CN=AdmJesse_Chan,OU=ADMAccounts,DC=apac,DC=dell,DC=com] into hash table [users] (Sun Jul 1 15:14:37 2018) [sssd[be[apac.dell.com]]] [sdap_get_primary_name] (0x0400): Processing object AdmJesse_Chan (Sun Jul 1 15:14:37 2018) [sssd[be[apac.dell.com]]] [sysdb_cache_search_users] (0x2000): Search users with filter: (&(objectCategory=user)(originalDN=CN=AdmJesse_Chan,OU=ADMAccounts,DC=apac,DC=dell,DC=com)) (Sun Jul 1 15:14:37 2018) [sssd[be[apac.dell.com]]] [sdap_find_entry_by_origDN] (0x4000): Searching cache for [CN=AdmJesse_Chan,OU=ADMAccounts,DC=apac,DC=dell,DC=com]. (Sun Jul 1 15:14:37 2018) [sssd[be[apac.dell.com]]] [sdap_fill_memberships] (0x1000): member #2019 (CN=AdmJesse_Cha ,OU=ADMAccounts,DC=apac,DC=dell,DC=com): [name=AdmJesse_Chan(a)apac.dell.com ,cn=users,cn=apac.dell.com,cn=sysdb] If I do the same query on the bad VM (spikerealmd02): [root@spikerealmd02 sssd]# id admjesse_chan id: admjesse_chan: no such user and I see nothing in the sssd_apac.dell.com.log file: [root@spikerealmd02 sssd]# grep -i admjesse_chan sssd_apac.dell.com.log [root@spikerealmd02 sssd]# Please help, Spike

4 9

Nested group lookups
by Tom 06 Jul '18

06 Jul '18

Hey All, If I want sssd to lookup if I belong in any groups or nested groups based on a string ( wildcard) in a group, what be my best options? I would like to keep the ad_access_filter to a minimum and grant access if a user is part of a subgroup. If user is in B and B is in A, allow access as long as A appears on the filter list for example. Cheers, Tom Sent from my iPhone

2 2

Behaviour of refresh_expired_interval
by John Hearns 05 Jul '18

05 Jul '18

I have an AD setup where users can be a member of perhaps 130 groups. When I run 'groups jbloggs' this can take 90 seconds or even longer. I have reduced that time to perhaps 20 seconds by setting ignore_group_members = TRUE Once the information is cached the groups command returns in less that one second. However, after a length of time the cache seems to be invalidated and the information is fetched again from the server, taking 20 seconds again. The cacheing parameters are set to: entry_cache_timeout = 5400 entry_cache_user_timeout = 5400 entry_cache_group_timeout = 5400 refresh_expired_interval = 4000 Surely this means that after 4000 seconds the user and group information is refreshed in the background. So a user running the groups command would always see freshly cached values? Clearly I am not understanding something here.

2 6

sss_override - when to run it?
by John Hearns 05 Jul '18

05 Jul '18

We have an existing set of users in a local passwd file I want to run sss_override to create mappings from the AD SID numbers to the existing uid numbers. What is the concensus on running sss_override? I can script it to either parse through the existing passwd file and make an override entry per user, or to parse the file and create an import file which is run once with import-user But when is a good time to run this? In a daily cron job When sssd is started, which would involve editing the systemd unit file Creating a new systemd service which depends on sssd.service . This service runs sss_override and then restarts sssd.service Or am I misunderstanding something? I am assuming here we have on-disk sssd databases. If the databases are on a tmpfs then clearly the sss_override must be run at boot time by one of the above methods also.

2 5

sss_override user-export is empty
by vadud3＠gmail.com 04 Jul '18

04 Jul '18

I made a change in UID for a user with sss_override but user-export to a file does not export anything. I am using sssd version 1.15.2. Is this a bug or may be I am doing something wrong? I followed the steps from this https://jhrozek.wordpress.com/2016/02/15/sssd-local-overrides/ I ran these as root # sssd --version 1.15.2 # sss_override user-add mwvande -u 4311 # systemctl restart sssd # sss_override user-export foo # cat foo (no output) I also tried it without the restart # sss_override user-add mwvande -u 4311 # sss_override user-export foo # cat foo (no output) -- 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?

5 5

Logging of scheduled tasks - password renewal
by John Hearns 04 Jul '18

04 Jul '18

After 30 days of running sssd I found that my test workstation no longer connected to the domain. The machine account password had timed out. I now run a daily cron job using msktutil wihch will auto-update the password. However I should not have to do this. sssd should update the machine password. I can see entries in the logs such that the machine account password renewal task is enabled. Then: [be_ptask_execute] (0x0400): Task [AD machine account password renewal]: executing task, timeout 60 seconds How though can I see if this taks is successful or not? I realise that if the machine account is less than 30 days old the task probably silently completes OK without any logging. The version of sssd is 16.1 running on Ubuntu John Hearns

2 3

Who and w not nss aware?
by John Hearns 04 Jul '18

04 Jul '18

It seems bizarre, but the who and w utilities say there are no users on my system. My account is an Active Direcotry account and sssd is running. johe@ibis:~$ who johe@ibis:~$ w 10:09:26 up 16:47, 0 users, load average: 0.60, 0.59, 0.48 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT I guess this is known behaviour?

2 4

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users July 2018