SSSD team, A curious issue after walking through the implementation of the socket activated responders.
System is a new RHEL 7.7 host with SSSD v1.16.4-21 using the AD providers.
Essentially user resolution (NSS), user login (PAM) and sssctl (IFP) worked when specifying the responders in the SSSD.conf file.
[root@darkvixen241 ~]# id msteele uid=1727401116(msteele) gid=1727401151(primary_unix_g) groups=1727401151(primary_unix_g),1727402106(darkvixen_hpc_admin_g),1727401607(darkvixen_hpc_g),1727402101(darkvixen100_g),1727401603(darkvixen101_g),1727401604(darkvixen102_g),1727401174(darkvixen240_g),1727401175(darkvixen241_g),1727401145(marketing_g),1727402105(bioinf_lab_g),1727400513(domain users)
[root@darkvixen241 ~]# sssctl user-checks msteele user: msteele action: acct service: system-auth
SSSD nss user lookup result: - user name: msteele - user id: 1727401116 - group id: 1727401151 - gecos: Ming Steele - home directory: /home/dvc.darkvixen.com/msteele - shell: /bin/bash
SSSD InfoPipe user lookup result: - name: msteele - uidNumber: 1727401116 - gidNumber: 1727400513 - gecos: Ming Steele - homeDirectory: /home/msteele - loginShell: /bin/bash
testing pam_acct_mgmt
pam_acct_mgmt: Success
PAM Environment: - no env -
After implementing the desired socket activated responders I cannot login as users via SSH, but can su as them from a root session. User resolution and sssctl still work.
[root@darkvixen241 ~]# systemctl list-units -a -t socket | grep sssd- sssd-autofs.socket loaded active listening SSSD AutoFS Service responder socket sssd-kcm.socket loaded active listening SSSD Kerberos Cache Manager responder socket sssd-nss.socket loaded active running SSSD NSS Service responder socket sssd-pac.socket loaded active listening SSSD PAC Service responder socket sssd-pam-priv.socket loaded active listening SSSD PAM Service responder private socket sssd-pam.socket loaded active listening SSSD PAM Service responder socket sssd-secrets.socket loaded active listening SSSD Secrets Service responder socket sssd-ssh.socket loaded active listening SSSD SSH Service responder socket sssd-sudo.socket loaded active listening SSSD Sudo Service responder socket
[root@darkvixen241 ~]# id msteele uid=1727401116(msteele) gid=1727401151(primary_unix_g) groups=1727401151(primary_unix_g),1727402106(darkvixen_hpc_admin_g),1727401607(darkvixen_hpc_g),1727402101(darkvixen100_g),1727401603(darkvixen101_g),1727401604(darkvixen102_g),1727401174(darkvixen240_g),1727401175(darkvixen241_g),1727401145(marketing_g),1727402105(bioinf_lab_g),1727400513(domain users)
[root@darkvixen241 ~]# sssctl user-checks msteele user: msteele action: acct service: system-auth
SSSD nss user lookup result: - user name: msteele - user id: 1727401116 - group id: 1727401151 - gecos: Ming Steele - home directory: /home/dvc.darkvixen.com/msteele - shell: /bin/bash
SSSD InfoPipe user lookup result: - name: msteele - uidNumber: 1727401116 - gidNumber: 1727400513 - gecos: Ming Steele - homeDirectory: /home/msteele - loginShell: /bin/bash
testing pam_acct_mgmt
pam_acct_mgmt: Authentication service cannot retrieve authentication info
PAM Environment: - no env -
My sssd.conf is provided below:
[sssd] config_file_version = 2 # services = nss,pam,pac,ssh,autofs,sudo domains = dvc.darkvixen.com
[nss] filter_users = root,bin,daemon,adm,lp,sync,shutdown,halt,mail,operator,games,ftp,nobody,systemd-network,dbus,polkitd,sshd,postfix,chrony,sssd,apache,rpc,rpcuser,nfsnobody
filter_groups = root,bin,daemon,sys,adm,tty,disk,lp,mem,kmem,wheel,cdrom,mail,man,dialout,floppy,games,tape,video,ftp,lock,audio,nobody,users,utmp,utempter,input,systemd-journal,systemd-network,dbus,polkitd,ssh_keys,sshd,postdrop,postfix,chrony,printadmin,cgred,sssd,apache,rpc,rpcuser,nfsnobody
[pam] pam_account_expired_message = "Account expired, please contact help desk." pam_account_locked_message = "Account locked, please contact help desk." pam_verbosity = 3
[pac]
[ssh]
[autofs]
[sudo]
[ifp]
[domain/dvc.darkvixen.com] id_provider = ad access_provider = ad
cache_credentials = true
override_homedir = /home/%d/%u override_shell = /bin/bash override_gid = 1727401151
ad_access_filter = DOM:DVC.DARKVIXEN.COM: (|(memberOf=CN=DARKVIXEN241_G,OU=LDAP,OU=SVS,DC=dvc,DC=darkvixen,DC=com)(memberOf=CN=DARKVIXEN_HPC_ADMIN_G,OU=CLUSTERS,OU=SVS,DC=dvc,DC=darkvixen,DC=com))
Nothing remarkable shows up in the logs after issuing "sssctl debug-level 7" and curiously there are no sssd_pam or sssd_pac log files created.
Any assistance would be appreciated,
-- lawrence
... I did notice this after a login attempt:
[root@darkvixen241 ~]# systemctl list-units -a -t socket | grep sssd-
sssd-autofs.socket loaded active listening SSSD AutoFS Service responder socket sssd-kcm.socket loaded active listening SSSD Kerberos Cache Manager responder socket sssd-nss.socket loaded active running SSSD NSS Service responder socket sssd-pac.socket loaded active listening SSSD PAC Service responder socket sssd-pam-priv.socket loaded failed failed SSSD PAM Service responder private socket sssd-pam.socket loaded inactive dead SSSD PAM Service responder socket sssd-secrets.socket loaded active listening SSSD Secrets Service responder socket sssd-ssh.socket loaded active listening SSSD SSH Service responder socket sssd-sudo.socket loaded active listening SSSD Sudo Service responder socket
Both PAM responders were running/active/listening prior to the auth attempt following a fresh reboot.
/var/log/secure also contains:
pam_sss(sshd:auth): Request to sssd failed. Bad address Failed password for msteele from 192.168.2.1 port 53357 ssh2
-- lawrence
On Sun, Nov 10, 2019 at 12:32 PM Lawrence Kearney hangarbait@gmail.com wrote:
SSSD team, A curious issue after walking through the implementation of the socket activated responders.
System is a new RHEL 7.7 host with SSSD v1.16.4-21 using the AD providers.
Essentially user resolution (NSS), user login (PAM) and sssctl (IFP) worked when specifying the responders in the SSSD.conf file.
[root@darkvixen241 ~]# id msteele uid=1727401116(msteele) gid=1727401151(primary_unix_g) groups=1727401151(primary_unix_g),1727402106(darkvixen_hpc_admin_g),1727401607(darkvixen_hpc_g),1727402101(darkvixen100_g),1727401603(darkvixen101_g),1727401604(darkvixen102_g),1727401174(darkvixen240_g),1727401175(darkvixen241_g),1727401145(marketing_g),1727402105(bioinf_lab_g),1727400513(domain users)
[root@darkvixen241 ~]# sssctl user-checks msteele user: msteele action: acct service: system-auth
SSSD nss user lookup result:
- user name: msteele
- user id: 1727401116
- group id: 1727401151
- gecos: Ming Steele
- home directory: /home/dvc.darkvixen.com/msteele
- shell: /bin/bash
SSSD InfoPipe user lookup result:
- name: msteele
- uidNumber: 1727401116
- gidNumber: 1727400513
- gecos: Ming Steele
- homeDirectory: /home/msteele
- loginShell: /bin/bash
testing pam_acct_mgmt
pam_acct_mgmt: Success
PAM Environment:
- no env -
After implementing the desired socket activated responders I cannot login as users via SSH, but can su as them from a root session. User resolution and sssctl still work.
[root@darkvixen241 ~]# systemctl list-units -a -t socket | grep sssd- sssd-autofs.socket loaded active listening SSSD AutoFS Service responder socket sssd-kcm.socket loaded active listening SSSD Kerberos Cache Manager responder socket sssd-nss.socket loaded active running SSSD NSS Service responder socket sssd-pac.socket loaded active listening SSSD PAC Service responder socket sssd-pam-priv.socket loaded active listening SSSD PAM Service responder private socket sssd-pam.socket loaded active listening SSSD PAM Service responder socket sssd-secrets.socket loaded active listening SSSD Secrets Service responder socket sssd-ssh.socket loaded active listening SSSD SSH Service responder socket sssd-sudo.socket loaded active listening SSSD Sudo Service responder socket
[root@darkvixen241 ~]# id msteele uid=1727401116(msteele) gid=1727401151(primary_unix_g) groups=1727401151(primary_unix_g),1727402106(darkvixen_hpc_admin_g),1727401607(darkvixen_hpc_g),1727402101(darkvixen100_g),1727401603(darkvixen101_g),1727401604(darkvixen102_g),1727401174(darkvixen240_g),1727401175(darkvixen241_g),1727401145(marketing_g),1727402105(bioinf_lab_g),1727400513(domain users)
[root@darkvixen241 ~]# sssctl user-checks msteele user: msteele action: acct service: system-auth
SSSD nss user lookup result:
- user name: msteele
- user id: 1727401116
- group id: 1727401151
- gecos: Ming Steele
- home directory: /home/dvc.darkvixen.com/msteele
- shell: /bin/bash
SSSD InfoPipe user lookup result:
- name: msteele
- uidNumber: 1727401116
- gidNumber: 1727400513
- gecos: Ming Steele
- homeDirectory: /home/msteele
- loginShell: /bin/bash
testing pam_acct_mgmt
pam_acct_mgmt: Authentication service cannot retrieve authentication info
PAM Environment:
- no env -
My sssd.conf is provided below:
[sssd] config_file_version = 2 # services = nss,pam,pac,ssh,autofs,sudo domains = dvc.darkvixen.com
[nss] filter_users = root,bin,daemon,adm,lp,sync,shutdown,halt,mail,operator,games,ftp,nobody,systemd-network,dbus,polkitd,sshd,postfix,chrony,sssd,apache,rpc,rpcuser,nfsnobody
filter_groups = root,bin,daemon,sys,adm,tty,disk,lp,mem,kmem,wheel,cdrom,mail,man,dialout,floppy,games,tape,video,ftp,lock,audio,nobody,users,utmp,utempter,input,systemd-journal,systemd-network,dbus,polkitd,ssh_keys,sshd,postdrop,postfix,chrony,printadmin,cgred,sssd,apache,rpc,rpcuser,nfsnobody
[pam] pam_account_expired_message = "Account expired, please contact help desk." pam_account_locked_message = "Account locked, please contact help desk." pam_verbosity = 3
[pac]
[ssh]
[autofs]
[sudo]
[ifp]
[domain/dvc.darkvixen.com] id_provider = ad access_provider = ad
cache_credentials = true
override_homedir = /home/%d/%u override_shell = /bin/bash override_gid = 1727401151
ad_access_filter = DOM:DVC.DARKVIXEN.COM: (|(memberOf=CN=DARKVIXEN241_G,OU=LDAP,OU=SVS,DC=dvc,DC=darkvixen,DC=com)(memberOf=CN=DARKVIXEN_HPC_ADMIN_G,OU=CLUSTERS,OU=SVS,DC=dvc,DC=darkvixen,DC=com))
Nothing remarkable shows up in the logs after issuing "sssctl debug-level 7" and curiously there are no sssd_pam or sssd_pac log files created.
Any assistance would be appreciated,
-- lawrence
-- Lawrence Kearney
w: www.lawrencekearney.com l: www.linkedin.com/in/lawrencekearney
SSSD team, Just checking in on this post. Any thoughts why the socket based responders would be crashing? Is there any additional info I could provide that would be useful?
Thank you as always!
-- lawrence
On Mon, Nov 11, 2019 at 6:31 AM Lawrence Kearney hangarbait@gmail.com wrote:
... I did notice this after a login attempt:
[root@darkvixen241 ~]# systemctl list-units -a -t socket | grep sssd-
sssd-autofs.socket loaded active listening SSSD AutoFS Service responder socket sssd-kcm.socket loaded active listening SSSD Kerberos Cache Manager responder socket sssd-nss.socket loaded active running SSSD NSS Service responder socket sssd-pac.socket loaded active listening SSSD PAC Service responder socket sssd-pam-priv.socket loaded failed failed SSSD PAM Service responder private socket sssd-pam.socket loaded inactive dead SSSD PAM Service responder socket sssd-secrets.socket loaded active listening SSSD Secrets Service responder socket sssd-ssh.socket loaded active listening SSSD SSH Service responder socket sssd-sudo.socket loaded active listening SSSD Sudo Service responder socket
Both PAM responders were running/active/listening prior to the auth attempt following a fresh reboot.
/var/log/secure also contains:
pam_sss(sshd:auth): Request to sssd failed. Bad address Failed password for msteele from 192.168.2.1 port 53357 ssh2
-- lawrence
On Sun, Nov 10, 2019 at 12:32 PM Lawrence Kearney hangarbait@gmail.com wrote:
SSSD team, A curious issue after walking through the implementation of the socket activated responders.
System is a new RHEL 7.7 host with SSSD v1.16.4-21 using the AD providers.
Essentially user resolution (NSS), user login (PAM) and sssctl (IFP) worked when specifying the responders in the SSSD.conf file.
[root@darkvixen241 ~]# id msteele uid=1727401116(msteele) gid=1727401151(primary_unix_g) groups=1727401151(primary_unix_g),1727402106(darkvixen_hpc_admin_g),1727401607(darkvixen_hpc_g),1727402101(darkvixen100_g),1727401603(darkvixen101_g),1727401604(darkvixen102_g),1727401174(darkvixen240_g),1727401175(darkvixen241_g),1727401145(marketing_g),1727402105(bioinf_lab_g),1727400513(domain users)
[root@darkvixen241 ~]# sssctl user-checks msteele user: msteele action: acct service: system-auth
SSSD nss user lookup result:
- user name: msteele
- user id: 1727401116
- group id: 1727401151
- gecos: Ming Steele
- home directory: /home/dvc.darkvixen.com/msteele
- shell: /bin/bash
SSSD InfoPipe user lookup result:
- name: msteele
- uidNumber: 1727401116
- gidNumber: 1727400513
- gecos: Ming Steele
- homeDirectory: /home/msteele
- loginShell: /bin/bash
testing pam_acct_mgmt
pam_acct_mgmt: Success
PAM Environment:
- no env -
After implementing the desired socket activated responders I cannot login as users via SSH, but can su as them from a root session. User resolution and sssctl still work.
[root@darkvixen241 ~]# systemctl list-units -a -t socket | grep sssd- sssd-autofs.socket loaded active listening SSSD AutoFS Service responder socket sssd-kcm.socket loaded active listening SSSD Kerberos Cache Manager responder socket sssd-nss.socket loaded active running SSSD NSS Service responder socket sssd-pac.socket loaded active listening SSSD PAC Service responder socket sssd-pam-priv.socket loaded active listening SSSD PAM Service responder private socket sssd-pam.socket loaded active listening SSSD PAM Service responder socket sssd-secrets.socket loaded active listening SSSD Secrets Service responder socket sssd-ssh.socket loaded active listening SSSD SSH Service responder socket sssd-sudo.socket loaded active listening SSSD Sudo Service responder socket
[root@darkvixen241 ~]# id msteele uid=1727401116(msteele) gid=1727401151(primary_unix_g) groups=1727401151(primary_unix_g),1727402106(darkvixen_hpc_admin_g),1727401607(darkvixen_hpc_g),1727402101(darkvixen100_g),1727401603(darkvixen101_g),1727401604(darkvixen102_g),1727401174(darkvixen240_g),1727401175(darkvixen241_g),1727401145(marketing_g),1727402105(bioinf_lab_g),1727400513(domain users)
[root@darkvixen241 ~]# sssctl user-checks msteele user: msteele action: acct service: system-auth
SSSD nss user lookup result:
- user name: msteele
- user id: 1727401116
- group id: 1727401151
- gecos: Ming Steele
- home directory: /home/dvc.darkvixen.com/msteele
- shell: /bin/bash
SSSD InfoPipe user lookup result:
- name: msteele
- uidNumber: 1727401116
- gidNumber: 1727400513
- gecos: Ming Steele
- homeDirectory: /home/msteele
- loginShell: /bin/bash
testing pam_acct_mgmt
pam_acct_mgmt: Authentication service cannot retrieve authentication info
PAM Environment:
- no env -
My sssd.conf is provided below:
[sssd] config_file_version = 2 # services = nss,pam,pac,ssh,autofs,sudo domains = dvc.darkvixen.com
[nss] filter_users = root,bin,daemon,adm,lp,sync,shutdown,halt,mail,operator,games,ftp,nobody,systemd-network,dbus,polkitd,sshd,postfix,chrony,sssd,apache,rpc,rpcuser,nfsnobody
filter_groups = root,bin,daemon,sys,adm,tty,disk,lp,mem,kmem,wheel,cdrom,mail,man,dialout,floppy,games,tape,video,ftp,lock,audio,nobody,users,utmp,utempter,input,systemd-journal,systemd-network,dbus,polkitd,ssh_keys,sshd,postdrop,postfix,chrony,printadmin,cgred,sssd,apache,rpc,rpcuser,nfsnobody
[pam] pam_account_expired_message = "Account expired, please contact help desk." pam_account_locked_message = "Account locked, please contact help desk." pam_verbosity = 3
[pac]
[ssh]
[autofs]
[sudo]
[ifp]
[domain/dvc.darkvixen.com] id_provider = ad access_provider = ad
cache_credentials = true
override_homedir = /home/%d/%u override_shell = /bin/bash override_gid = 1727401151
ad_access_filter = DOM:DVC.DARKVIXEN.COM: (|(memberOf=CN=DARKVIXEN241_G,OU=LDAP,OU=SVS,DC=dvc,DC=darkvixen,DC=com)(memberOf=CN=DARKVIXEN_HPC_ADMIN_G,OU=CLUSTERS,OU=SVS,DC=dvc,DC=darkvixen,DC=com))
Nothing remarkable shows up in the logs after issuing "sssctl debug-level 7" and curiously there are no sssd_pam or sssd_pac log files created.
Any assistance would be appreciated,
-- lawrence
-- Lawrence Kearney
w: www.lawrencekearney.com l: www.linkedin.com/in/lawrencekearney
-- Lawrence Kearney
e: lawrence.kearney@earthlink.net t: +001 706.951.6257 w: www.lawrencekearney.com l: www.linkedin.com/in/lawrencekearney
On Fri, Nov 15, 2019 at 05:23:35AM -0500, Lawrence Kearney wrote:
SSSD team, Just checking in on this post. Any thoughts why the socket based responders would be crashing? Is there any additional info I could provide that would be useful?
Hi,
can you try to add 'debug_level = 9' to the [pam] section of sssd.conf? With this the PAM responder should at least add some log messages if systemd tries to start it.
bye, Sumit
Thank you as always!
-- lawrence
On Mon, Nov 11, 2019 at 6:31 AM Lawrence Kearney hangarbait@gmail.com wrote:
... I did notice this after a login attempt:
[root@darkvixen241 ~]# systemctl list-units -a -t socket | grep sssd-
sssd-autofs.socket loaded active listening SSSD AutoFS Service responder socket sssd-kcm.socket loaded active listening SSSD Kerberos Cache Manager responder socket sssd-nss.socket loaded active running SSSD NSS Service responder socket sssd-pac.socket loaded active listening SSSD PAC Service responder socket sssd-pam-priv.socket loaded failed failed SSSD PAM Service responder private socket sssd-pam.socket loaded inactive dead SSSD PAM Service responder socket sssd-secrets.socket loaded active listening SSSD Secrets Service responder socket sssd-ssh.socket loaded active listening SSSD SSH Service responder socket sssd-sudo.socket loaded active listening SSSD Sudo Service responder socket
Both PAM responders were running/active/listening prior to the auth attempt following a fresh reboot.
/var/log/secure also contains:
pam_sss(sshd:auth): Request to sssd failed. Bad address Failed password for msteele from 192.168.2.1 port 53357 ssh2
-- lawrence
On Sun, Nov 10, 2019 at 12:32 PM Lawrence Kearney hangarbait@gmail.com wrote:
SSSD team, A curious issue after walking through the implementation of the socket activated responders.
System is a new RHEL 7.7 host with SSSD v1.16.4-21 using the AD providers.
Essentially user resolution (NSS), user login (PAM) and sssctl (IFP) worked when specifying the responders in the SSSD.conf file.
[root@darkvixen241 ~]# id msteele uid=1727401116(msteele) gid=1727401151(primary_unix_g) groups=1727401151(primary_unix_g),1727402106(darkvixen_hpc_admin_g),1727401607(darkvixen_hpc_g),1727402101(darkvixen100_g),1727401603(darkvixen101_g),1727401604(darkvixen102_g),1727401174(darkvixen240_g),1727401175(darkvixen241_g),1727401145(marketing_g),1727402105(bioinf_lab_g),1727400513(domain users)
[root@darkvixen241 ~]# sssctl user-checks msteele user: msteele action: acct service: system-auth
SSSD nss user lookup result:
- user name: msteele
- user id: 1727401116
- group id: 1727401151
- gecos: Ming Steele
- home directory: /home/dvc.darkvixen.com/msteele
- shell: /bin/bash
SSSD InfoPipe user lookup result:
- name: msteele
- uidNumber: 1727401116
- gidNumber: 1727400513
- gecos: Ming Steele
- homeDirectory: /home/msteele
- loginShell: /bin/bash
testing pam_acct_mgmt
pam_acct_mgmt: Success
PAM Environment:
- no env -
After implementing the desired socket activated responders I cannot login as users via SSH, but can su as them from a root session. User resolution and sssctl still work.
[root@darkvixen241 ~]# systemctl list-units -a -t socket | grep sssd- sssd-autofs.socket loaded active listening SSSD AutoFS Service responder socket sssd-kcm.socket loaded active listening SSSD Kerberos Cache Manager responder socket sssd-nss.socket loaded active running SSSD NSS Service responder socket sssd-pac.socket loaded active listening SSSD PAC Service responder socket sssd-pam-priv.socket loaded active listening SSSD PAM Service responder private socket sssd-pam.socket loaded active listening SSSD PAM Service responder socket sssd-secrets.socket loaded active listening SSSD Secrets Service responder socket sssd-ssh.socket loaded active listening SSSD SSH Service responder socket sssd-sudo.socket loaded active listening SSSD Sudo Service responder socket
[root@darkvixen241 ~]# id msteele uid=1727401116(msteele) gid=1727401151(primary_unix_g) groups=1727401151(primary_unix_g),1727402106(darkvixen_hpc_admin_g),1727401607(darkvixen_hpc_g),1727402101(darkvixen100_g),1727401603(darkvixen101_g),1727401604(darkvixen102_g),1727401174(darkvixen240_g),1727401175(darkvixen241_g),1727401145(marketing_g),1727402105(bioinf_lab_g),1727400513(domain users)
[root@darkvixen241 ~]# sssctl user-checks msteele user: msteele action: acct service: system-auth
SSSD nss user lookup result:
- user name: msteele
- user id: 1727401116
- group id: 1727401151
- gecos: Ming Steele
- home directory: /home/dvc.darkvixen.com/msteele
- shell: /bin/bash
SSSD InfoPipe user lookup result:
- name: msteele
- uidNumber: 1727401116
- gidNumber: 1727400513
- gecos: Ming Steele
- homeDirectory: /home/msteele
- loginShell: /bin/bash
testing pam_acct_mgmt
pam_acct_mgmt: Authentication service cannot retrieve authentication info
PAM Environment:
- no env -
My sssd.conf is provided below:
[sssd] config_file_version = 2 # services = nss,pam,pac,ssh,autofs,sudo domains = dvc.darkvixen.com
[nss] filter_users = root,bin,daemon,adm,lp,sync,shutdown,halt,mail,operator,games,ftp,nobody,systemd-network,dbus,polkitd,sshd,postfix,chrony,sssd,apache,rpc,rpcuser,nfsnobody
filter_groups = root,bin,daemon,sys,adm,tty,disk,lp,mem,kmem,wheel,cdrom,mail,man,dialout,floppy,games,tape,video,ftp,lock,audio,nobody,users,utmp,utempter,input,systemd-journal,systemd-network,dbus,polkitd,ssh_keys,sshd,postdrop,postfix,chrony,printadmin,cgred,sssd,apache,rpc,rpcuser,nfsnobody
[pam] pam_account_expired_message = "Account expired, please contact help desk." pam_account_locked_message = "Account locked, please contact help desk." pam_verbosity = 3
[pac]
[ssh]
[autofs]
[sudo]
[ifp]
[domain/dvc.darkvixen.com] id_provider = ad access_provider = ad
cache_credentials = true
override_homedir = /home/%d/%u override_shell = /bin/bash override_gid = 1727401151
ad_access_filter = DOM:DVC.DARKVIXEN.COM: (|(memberOf=CN=DARKVIXEN241_G,OU=LDAP,OU=SVS,DC=dvc,DC=darkvixen,DC=com)(memberOf=CN=DARKVIXEN_HPC_ADMIN_G,OU=CLUSTERS,OU=SVS,DC=dvc,DC=darkvixen,DC=com))
Nothing remarkable shows up in the logs after issuing "sssctl debug-level 7" and curiously there are no sssd_pam or sssd_pac log files created.
Any assistance would be appreciated,
-- lawrence
-- Lawrence Kearney
w: www.lawrencekearney.com l: www.linkedin.com/in/lawrencekearney
-- Lawrence Kearney
e: lawrence.kearney@earthlink.net t: +001 706.951.6257 w: www.lawrencekearney.com l: www.linkedin.com/in/lawrencekearney
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
Sumit, Good to hear back from you and thank you! I had already added the directive to the [pam] responder stanza but the responder doesn't write a log file. Doing a little more testing I can reproduce the responser crash (assumed) using sssctl to check the user status:
[root@darkvixen241 ~]# systemctl list-units -a -t socket | grep sssd- sssd-autofs.socket loaded active listening SSSD AutoFS Service responder socket sssd-kcm.socket loaded active listening SSSD Kerberos Cache Manager responder socket sssd-nss.socket loaded active running SSSD NSS Service responder socket sssd-pac.socket loaded active listening SSSD PAC Service responder socket sssd-pam-priv.socket loaded active listening SSSD PAM Service responder private socket sssd-pam.socket loaded active listening SSSD PAM Service responder socket sssd-secrets.socket loaded active listening SSSD Secrets Service responder socket sssd-ssh.socket loaded active listening SSSD SSH Service responder socket sssd-sudo.socket loaded active listening SSSD Sudo Service responder socket
[root@darkvixen241 ~]# sssctl user-checks msteele user: msteele action: acct service: system-auth
SSSD nss user lookup result: - user name: msteele - user id: 1727401116 - group id: 1727401151 - gecos: Ming Steele - home directory: /home/dvc.darkvixen.com/msteele - shell: /bin/bash
SSSD InfoPipe user lookup result: - name: msteele - uidNumber: 1727401116 - gidNumber: 1727400513 - gecos: Ming Steele - homeDirectory: /home/msteele - loginShell: /bin/bash
testing pam_acct_mgmt
pam_acct_mgmt: Authentication service cannot retrieve authentication info
PAM Environment: - no env -
[root@darkvixen241 ~]# systemctl list-units -a -t socket | grep sssd- sssd-autofs.socket loaded active listening SSSD AutoFS Service responder socket sssd-kcm.socket loaded active listening SSSD Kerberos Cache Manager responder socket sssd-nss.socket loaded active running SSSD NSS Service responder socket sssd-pac.socket loaded active listening SSSD PAC Service responder socket ● sssd-pam-priv.socket loaded failed failed SSSD PAM Service responder private socket sssd-pam.socket loaded inactive dead SSSD PAM Service responder socket sssd-secrets.socket loaded active listening SSSD Secrets Service responder socket sssd-ssh.socket loaded active listening SSSD SSH Service responder socket sssd-sudo.socket loaded active listening SSSD Sudo Service responder socket
How would you recommend moving forward with assessment?
-- lawrence
On Tue, Nov 19, 2019 at 1:31 AM Sumit Bose sbose@redhat.com wrote:
On Fri, Nov 15, 2019 at 05:23:35AM -0500, Lawrence Kearney wrote:
SSSD team, Just checking in on this post. Any thoughts why the socket based
responders
would be crashing? Is there any additional info I could provide that
would
be useful?
Hi,
can you try to add 'debug_level = 9' to the [pam] section of sssd.conf? With this the PAM responder should at least add some log messages if systemd tries to start it.
bye, Sumit
Thank you as always!
-- lawrence
On Mon, Nov 11, 2019 at 6:31 AM Lawrence Kearney hangarbait@gmail.com wrote:
... I did notice this after a login attempt:
[root@darkvixen241 ~]# systemctl list-units -a -t socket | grep sssd-
sssd-autofs.socket loaded active listening SSSD AutoFS
Service
responder socket sssd-kcm.socket loaded active listening SSSD Kerberos
Cache
Manager responder socket sssd-nss.socket loaded active running SSSD NSS Service responder socket sssd-pac.socket loaded active listening SSSD PAC Service responder socket sssd-pam-priv.socket loaded failed failed SSSD PAM Service responder private socket sssd-pam.socket loaded inactive dead SSSD PAM Service responder socket sssd-secrets.socket loaded active listening SSSD Secrets Service responder socket sssd-ssh.socket loaded active listening SSSD SSH Service responder socket sssd-sudo.socket loaded active listening SSSD Sudo
Service
responder socket
Both PAM responders were running/active/listening prior to the auth attempt following a fresh reboot.
/var/log/secure also contains:
pam_sss(sshd:auth): Request to sssd failed. Bad address Failed password for msteele from 192.168.2.1 port 53357 ssh2
-- lawrence
On Sun, Nov 10, 2019 at 12:32 PM Lawrence Kearney <
hangarbait@gmail.com>
wrote:
SSSD team, A curious issue after walking through the implementation of the socket activated responders.
System is a new RHEL 7.7 host with SSSD v1.16.4-21 using the AD
providers.
Essentially user resolution (NSS), user login (PAM) and sssctl (IFP) worked when specifying the responders in the SSSD.conf file.
[root@darkvixen241 ~]# id msteele uid=1727401116(msteele) gid=1727401151(primary_unix_g)
groups=1727401151(primary_unix_g),1727402106(darkvixen_hpc_admin_g),1727401607(darkvixen_hpc_g),1727402101(darkvixen100_g),1727401603(darkvixen101_g),1727401604(darkvixen102_g),1727401174(darkvixen240_g),1727401175(darkvixen241_g),1727401145(marketing_g),1727402105(bioinf_lab_g),1727400513(domain
users)
[root@darkvixen241 ~]# sssctl user-checks msteele user: msteele action: acct service: system-auth
SSSD nss user lookup result:
- user name: msteele
- user id: 1727401116
- group id: 1727401151
- gecos: Ming Steele
- home directory: /home/dvc.darkvixen.com/msteele
- shell: /bin/bash
SSSD InfoPipe user lookup result:
- name: msteele
- uidNumber: 1727401116
- gidNumber: 1727400513
- gecos: Ming Steele
- homeDirectory: /home/msteele
- loginShell: /bin/bash
testing pam_acct_mgmt
pam_acct_mgmt: Success
PAM Environment:
- no env -
After implementing the desired socket activated responders I cannot
login
as users via SSH, but can su as them from a root session. User
resolution
and sssctl still work.
[root@darkvixen241 ~]# systemctl list-units -a -t socket | grep sssd- sssd-autofs.socket loaded active listening SSSD AutoFS Service responder socket sssd-kcm.socket loaded active listening SSSD Kerberos Cache Manager responder socket sssd-nss.socket loaded active running SSSD NSS
Service
responder socket sssd-pac.socket loaded active listening SSSD PAC
Service
responder socket sssd-pam-priv.socket loaded active listening SSSD PAM
Service
responder private socket sssd-pam.socket loaded active listening SSSD PAM
Service
responder socket sssd-secrets.socket loaded active listening SSSD Secrets Service responder socket sssd-ssh.socket loaded active listening SSSD SSH
Service
responder socket sssd-sudo.socket loaded active listening SSSD Sudo
Service
responder socket
[root@darkvixen241 ~]# id msteele uid=1727401116(msteele) gid=1727401151(primary_unix_g)
groups=1727401151(primary_unix_g),1727402106(darkvixen_hpc_admin_g),1727401607(darkvixen_hpc_g),1727402101(darkvixen100_g),1727401603(darkvixen101_g),1727401604(darkvixen102_g),1727401174(darkvixen240_g),1727401175(darkvixen241_g),1727401145(marketing_g),1727402105(bioinf_lab_g),1727400513(domain
users)
[root@darkvixen241 ~]# sssctl user-checks msteele user: msteele action: acct service: system-auth
SSSD nss user lookup result:
- user name: msteele
- user id: 1727401116
- group id: 1727401151
- gecos: Ming Steele
- home directory: /home/dvc.darkvixen.com/msteele
- shell: /bin/bash
SSSD InfoPipe user lookup result:
- name: msteele
- uidNumber: 1727401116
- gidNumber: 1727400513
- gecos: Ming Steele
- homeDirectory: /home/msteele
- loginShell: /bin/bash
testing pam_acct_mgmt
pam_acct_mgmt: Authentication service cannot retrieve authentication
info
PAM Environment:
- no env -
My sssd.conf is provided below:
[sssd] config_file_version = 2 # services = nss,pam,pac,ssh,autofs,sudo domains = dvc.darkvixen.com
[nss] filter_users =
root,bin,daemon,adm,lp,sync,shutdown,halt,mail,operator,games,ftp,nobody,systemd-network,dbus,polkitd,sshd,postfix,chrony,sssd,apache,rpc,rpcuser,nfsnobody
filter_groups =
root,bin,daemon,sys,adm,tty,disk,lp,mem,kmem,wheel,cdrom,mail,man,dialout,floppy,games,tape,video,ftp,lock,audio,nobody,users,utmp,utempter,input,systemd-journal,systemd-network,dbus,polkitd,ssh_keys,sshd,postdrop,postfix,chrony,printadmin,cgred,sssd,apache,rpc,rpcuser,nfsnobody
[pam] pam_account_expired_message = "Account expired, please contact help
desk."
pam_account_locked_message = "Account locked, please contact help
desk."
pam_verbosity = 3
[pac]
[ssh]
[autofs]
[sudo]
[ifp]
[domain/dvc.darkvixen.com] id_provider = ad access_provider = ad
cache_credentials = true
override_homedir = /home/%d/%u override_shell = /bin/bash override_gid = 1727401151
ad_access_filter = DOM:DVC.DARKVIXEN.COM:
(|(memberOf=CN=DARKVIXEN241_G,OU=LDAP,OU=SVS,DC=dvc,DC=darkvixen,DC=com)(memberOf=CN=DARKVIXEN_HPC_ADMIN_G,OU=CLUSTERS,OU=SVS,DC=dvc,DC=darkvixen,DC=com))
Nothing remarkable shows up in the logs after issuing "sssctl
debug-level
7" and curiously there are no sssd_pam or sssd_pac log files created.
Any assistance would be appreciated,
-- lawrence
-- Lawrence Kearney
w: www.lawrencekearney.com l: www.linkedin.com/in/lawrencekearney
-- Lawrence Kearney
e: lawrence.kearney@earthlink.net t: +001 706.951.6257 w: www.lawrencekearney.com l: www.linkedin.com/in/lawrencekearney
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o... _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
On Tue, Nov 19, 2019 at 09:10:29AM -0500, Lawrence Kearney wrote:
Sumit, Good to hear back from you and thank you! I had already added the directive to the [pam] responder stanza but the responder doesn't write a log file. Doing a little more testing I can reproduce the responser crash (assumed) using sssctl to check the user status:
[root@darkvixen241 ~]# systemctl list-units -a -t socket | grep sssd- sssd-autofs.socket loaded active listening SSSD AutoFS Service responder socket sssd-kcm.socket loaded active listening SSSD Kerberos Cache Manager responder socket sssd-nss.socket loaded active running SSSD NSS Service responder socket sssd-pac.socket loaded active listening SSSD PAC Service responder socket sssd-pam-priv.socket loaded active listening SSSD PAM Service responder private socket sssd-pam.socket loaded active listening SSSD PAM Service responder socket sssd-secrets.socket loaded active listening SSSD Secrets Service responder socket sssd-ssh.socket loaded active listening SSSD SSH Service responder socket sssd-sudo.socket loaded active listening SSSD Sudo Service responder socket
[root@darkvixen241 ~]# sssctl user-checks msteele user: msteele action: acct service: system-auth
SSSD nss user lookup result:
- user name: msteele
- user id: 1727401116
- group id: 1727401151
- gecos: Ming Steele
- home directory: /home/dvc.darkvixen.com/msteele
- shell: /bin/bash
SSSD InfoPipe user lookup result:
- name: msteele
- uidNumber: 1727401116
- gidNumber: 1727400513
- gecos: Ming Steele
- homeDirectory: /home/msteele
- loginShell: /bin/bash
testing pam_acct_mgmt
pam_acct_mgmt: Authentication service cannot retrieve authentication info
PAM Environment:
- no env -
[root@darkvixen241 ~]# systemctl list-units -a -t socket | grep sssd- sssd-autofs.socket loaded active listening SSSD AutoFS Service responder socket sssd-kcm.socket loaded active listening SSSD Kerberos Cache Manager responder socket sssd-nss.socket loaded active running SSSD NSS Service responder socket sssd-pac.socket loaded active listening SSSD PAC Service responder socket ● sssd-pam-priv.socket loaded failed failed SSSD PAM Service responder private socket sssd-pam.socket loaded inactive dead SSSD PAM Service responder socket sssd-secrets.socket loaded active listening SSSD Secrets Service responder socket sssd-ssh.socket loaded active listening SSSD SSH Service responder socket sssd-sudo.socket loaded active listening SSSD Sudo Service responder socket
How would you recommend moving forward with assessment?
Are there related systemd messages in the system logs? You might need to send SIGRTMIN+22 to systemd to enable debug logging, see man systemd fir details.
bye, Sumit
-- lawrence
On Tue, Nov 19, 2019 at 1:31 AM Sumit Bose sbose@redhat.com wrote:
On Fri, Nov 15, 2019 at 05:23:35AM -0500, Lawrence Kearney wrote:
SSSD team, Just checking in on this post. Any thoughts why the socket based
responders
would be crashing? Is there any additional info I could provide that
would
be useful?
Hi,
can you try to add 'debug_level = 9' to the [pam] section of sssd.conf? With this the PAM responder should at least add some log messages if systemd tries to start it.
bye, Sumit
Thank you as always!
-- lawrence
On Mon, Nov 11, 2019 at 6:31 AM Lawrence Kearney hangarbait@gmail.com wrote:
... I did notice this after a login attempt:
[root@darkvixen241 ~]# systemctl list-units -a -t socket | grep sssd-
sssd-autofs.socket loaded active listening SSSD AutoFS
Service
responder socket sssd-kcm.socket loaded active listening SSSD Kerberos
Cache
Manager responder socket sssd-nss.socket loaded active running SSSD NSS Service responder socket sssd-pac.socket loaded active listening SSSD PAC Service responder socket sssd-pam-priv.socket loaded failed failed SSSD PAM Service responder private socket sssd-pam.socket loaded inactive dead SSSD PAM Service responder socket sssd-secrets.socket loaded active listening SSSD Secrets Service responder socket sssd-ssh.socket loaded active listening SSSD SSH Service responder socket sssd-sudo.socket loaded active listening SSSD Sudo
Service
responder socket
Both PAM responders were running/active/listening prior to the auth attempt following a fresh reboot.
/var/log/secure also contains:
pam_sss(sshd:auth): Request to sssd failed. Bad address Failed password for msteele from 192.168.2.1 port 53357 ssh2
-- lawrence
On Sun, Nov 10, 2019 at 12:32 PM Lawrence Kearney <
hangarbait@gmail.com>
wrote:
SSSD team, A curious issue after walking through the implementation of the socket activated responders.
System is a new RHEL 7.7 host with SSSD v1.16.4-21 using the AD
providers.
Essentially user resolution (NSS), user login (PAM) and sssctl (IFP) worked when specifying the responders in the SSSD.conf file.
[root@darkvixen241 ~]# id msteele uid=1727401116(msteele) gid=1727401151(primary_unix_g)
groups=1727401151(primary_unix_g),1727402106(darkvixen_hpc_admin_g),1727401607(darkvixen_hpc_g),1727402101(darkvixen100_g),1727401603(darkvixen101_g),1727401604(darkvixen102_g),1727401174(darkvixen240_g),1727401175(darkvixen241_g),1727401145(marketing_g),1727402105(bioinf_lab_g),1727400513(domain
users)
[root@darkvixen241 ~]# sssctl user-checks msteele user: msteele action: acct service: system-auth
SSSD nss user lookup result:
- user name: msteele
- user id: 1727401116
- group id: 1727401151
- gecos: Ming Steele
- home directory: /home/dvc.darkvixen.com/msteele
- shell: /bin/bash
SSSD InfoPipe user lookup result:
- name: msteele
- uidNumber: 1727401116
- gidNumber: 1727400513
- gecos: Ming Steele
- homeDirectory: /home/msteele
- loginShell: /bin/bash
testing pam_acct_mgmt
pam_acct_mgmt: Success
PAM Environment:
- no env -
After implementing the desired socket activated responders I cannot
login
as users via SSH, but can su as them from a root session. User
resolution
and sssctl still work.
[root@darkvixen241 ~]# systemctl list-units -a -t socket | grep sssd- sssd-autofs.socket loaded active listening SSSD AutoFS Service responder socket sssd-kcm.socket loaded active listening SSSD Kerberos Cache Manager responder socket sssd-nss.socket loaded active running SSSD NSS
Service
responder socket sssd-pac.socket loaded active listening SSSD PAC
Service
responder socket sssd-pam-priv.socket loaded active listening SSSD PAM
Service
responder private socket sssd-pam.socket loaded active listening SSSD PAM
Service
responder socket sssd-secrets.socket loaded active listening SSSD Secrets Service responder socket sssd-ssh.socket loaded active listening SSSD SSH
Service
responder socket sssd-sudo.socket loaded active listening SSSD Sudo
Service
responder socket
[root@darkvixen241 ~]# id msteele uid=1727401116(msteele) gid=1727401151(primary_unix_g)
groups=1727401151(primary_unix_g),1727402106(darkvixen_hpc_admin_g),1727401607(darkvixen_hpc_g),1727402101(darkvixen100_g),1727401603(darkvixen101_g),1727401604(darkvixen102_g),1727401174(darkvixen240_g),1727401175(darkvixen241_g),1727401145(marketing_g),1727402105(bioinf_lab_g),1727400513(domain
users)
[root@darkvixen241 ~]# sssctl user-checks msteele user: msteele action: acct service: system-auth
SSSD nss user lookup result:
- user name: msteele
- user id: 1727401116
- group id: 1727401151
- gecos: Ming Steele
- home directory: /home/dvc.darkvixen.com/msteele
- shell: /bin/bash
SSSD InfoPipe user lookup result:
- name: msteele
- uidNumber: 1727401116
- gidNumber: 1727400513
- gecos: Ming Steele
- homeDirectory: /home/msteele
- loginShell: /bin/bash
testing pam_acct_mgmt
pam_acct_mgmt: Authentication service cannot retrieve authentication
info
PAM Environment:
- no env -
My sssd.conf is provided below:
[sssd] config_file_version = 2 # services = nss,pam,pac,ssh,autofs,sudo domains = dvc.darkvixen.com
[nss] filter_users =
root,bin,daemon,adm,lp,sync,shutdown,halt,mail,operator,games,ftp,nobody,systemd-network,dbus,polkitd,sshd,postfix,chrony,sssd,apache,rpc,rpcuser,nfsnobody
filter_groups =
root,bin,daemon,sys,adm,tty,disk,lp,mem,kmem,wheel,cdrom,mail,man,dialout,floppy,games,tape,video,ftp,lock,audio,nobody,users,utmp,utempter,input,systemd-journal,systemd-network,dbus,polkitd,ssh_keys,sshd,postdrop,postfix,chrony,printadmin,cgred,sssd,apache,rpc,rpcuser,nfsnobody
[pam] pam_account_expired_message = "Account expired, please contact help
desk."
pam_account_locked_message = "Account locked, please contact help
desk."
pam_verbosity = 3
[pac]
[ssh]
[autofs]
[sudo]
[ifp]
[domain/dvc.darkvixen.com] id_provider = ad access_provider = ad
cache_credentials = true
override_homedir = /home/%d/%u override_shell = /bin/bash override_gid = 1727401151
ad_access_filter = DOM:DVC.DARKVIXEN.COM:
(|(memberOf=CN=DARKVIXEN241_G,OU=LDAP,OU=SVS,DC=dvc,DC=darkvixen,DC=com)(memberOf=CN=DARKVIXEN_HPC_ADMIN_G,OU=CLUSTERS,OU=SVS,DC=dvc,DC=darkvixen,DC=com))
Nothing remarkable shows up in the logs after issuing "sssctl
debug-level
7" and curiously there are no sssd_pam or sssd_pac log files created.
Any assistance would be appreciated,
-- lawrence
-- Lawrence Kearney
w: www.lawrencekearney.com l: www.linkedin.com/in/lawrencekearney
-- Lawrence Kearney
e: lawrence.kearney@earthlink.net t: +001 706.951.6257 w: www.lawrencekearney.com l: www.linkedin.com/in/lawrencekearney
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o... _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
On (15/11/19 05:23), Lawrence Kearney wrote:
SSSD team, Just checking in on this post. Any thoughts why the socket based responders would be crashing? Is there any additional info I could provide that would be useful?
Thank you as always!
sssd on rhel7 has hardcoded unprivileged user "sssd" for responders. And mixing privileged sssd and unprivileged users is not a good idea.
sh# rpm -q sssd-common sssd-common-1.16.4-21.el7_7.1.x86_64
sh# systemctl cat sssd-pam.service # /usr/lib/systemd/system/sssd-pam.service [Unit] Description=SSSD PAM Service responder Documentation=man:sssd.conf(5) After=sssd.service BindsTo=sssd.service RefuseManualStart=true
[Install] Also=sssd-pam.socket sssd-pam-priv.socket
[Service] Environment=DEBUG_LOGGER=--logger=files EnvironmentFile=-/etc/sysconfig/sssd ExecStartPre=-/bin/chown sssd:sssd /var/log/sssd/sssd_pam.log ^^^^^^^^^ here ExecStart=/usr/libexec/sssd/sssd_pam ${DEBUG_LOGGER} --socket-activated Restart=on-failure User=sssd Group=sssd ^^^^^ and here PermissionsStartOnly=true
It works well when sssd is running fully in unprivileged mode. "user = sssd" in "sssd" section of sssd.conf
Other option would be to override service files for responder in /etc/systmd/system
But I would like to ask why do you want to use socket activated responders on rhel7?
LS
Lukas et al., Thank you for the suggestion. I'll test that as soon as convenient. I'm currently attending SC19 so spinning up labs is something best managed in the mornings with coffee :-) .
Curiously I did have to change the ownership of the socket, and a few service, unit files to sssd:root to get them to start. I would like to test the daemon to running as an unprivileged user as much as possible. I did not consider digging into the files themselves to check configured runtime users, I should've.
As to your question I currently have no real use case for the socket based responders other than their potential for system level optimisation in large enterprise deployments and kicking the tyres on the SSSD feature set to both experiment with it and document the assessment, results, and configuration nuances and requirements.
I often share these results in attempts to help others deploying the daemon and advocate for its use. Similar to this community :-) .
Thank you again and I'll test asap and report what I find,
-- lawrence
On Wed, Nov 20, 2019 at 11:16 AM Lukas Slebodnik lslebodn@redhat.com wrote:
On (15/11/19 05:23), Lawrence Kearney wrote:
SSSD team, Just checking in on this post. Any thoughts why the socket based
responders
would be crashing? Is there any additional info I could provide that would be useful?
Thank you as always!
sssd on rhel7 has hardcoded unprivileged user "sssd" for responders. And mixing privileged sssd and unprivileged users is not a good idea.
sh# rpm -q sssd-common sssd-common-1.16.4-21.el7_7.1.x86_64
sh# systemctl cat sssd-pam.service # /usr/lib/systemd/system/sssd-pam.service [Unit] Description=SSSD PAM Service responder Documentation=man:sssd.conf(5) After=sssd.service BindsTo=sssd.service RefuseManualStart=true
[Install] Also=sssd-pam.socket sssd-pam-priv.socket
[Service] Environment=DEBUG_LOGGER=--logger=files EnvironmentFile=-/etc/sysconfig/sssd ExecStartPre=-/bin/chown sssd:sssd /var/log/sssd/sssd_pam.log ^^^^^^^^^ here ExecStart=/usr/libexec/sssd/sssd_pam ${DEBUG_LOGGER} --socket-activated Restart=on-failure User=sssd Group=sssd ^^^^^ and here PermissionsStartOnly=true
It works well when sssd is running fully in unprivileged mode. "user = sssd" in "sssd" section of sssd.conf
Other option would be to override service files for responder in /etc/systmd/system
But I would like to ask why do you want to use socket activated responders on rhel7?
LS _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
On (20/11/19 11:57), Lawrence Kearney wrote:
Lukas et al., Thank you for the suggestion. I'll test that as soon as convenient. I'm currently attending SC19 so spinning up labs is something best managed in the mornings with coffee :-) .
Curiously I did have to change the ownership of the socket, and a few service, unit files to sssd:root to get them to start. I would like to test the daemon to running as an unprivileged user as much as possible. I did not consider digging into the files themselves to check configured runtime users, I should've.
Using "hybrid" sssd:root is not a good idea. You should either remove sssd user/group from service files or run sssd as completely unprivileged user.
As to your question I currently have no real use case for the socket based responders other than their potential for system level optimisation in large enterprise deployments and kicking the tyres on the SSSD feature set to both experiment with it and document the assessment, results, and configuration nuances and requirements.
And I an exactly interested in that real use-case :-) Could you share a little bit more even thought you did not test it?
Because there might be other solution to the problem you would like to solve.
LS
Lukas et al., Firstly reverting the ownership of the sssd service and socket files in the "/usr/lib/systemd/system" and "/var/lib/sss" directories to sssd:sssd and adding the "user = sssd" to the sssd.conf file did resolve the responder issue.This file ownership model was what I thought should be in place, but rhel did not install them consistently this way. I implemented the sssd:root ownerships to resolve some issues with services starting. Interestingly even after changing the ownerships of the same files to sssd:sssd the responder still crashed without the user = sssd directive present in the sssd.conf. I would have thought the daemon on this platform would not require it.
That said, my experience on other platforms is the daemon runs as root, so this is useful to know for additional testing with other distributions, so thank you.
As to the use case discussion, most of my experience and assistance in deployments are direct integration models. Not that I have a technical issue with the indirect approach, but most organisations I encounter prefer the reduced complexity of the direct model. As long as it works reliably. There are feature trade offs using this method but most are okay given those choices are communicated.
That said, when you stand up sssd as a client against a large, mature, complex directory service any thing you can do to reduce the load on the clients and the directory service is a good step. Filtering search results across purposefully configured hosts and reducing load on the client and the directory service are key design components of this proposition.
So, I'm curious if the socket based responders can play a meaningful part in optimisation.
An addition question that may help me. What are your thoughts on the use case(s) for the socket based responders?
Thank you!
-- lawrence
On Thu, Nov 21, 2019 at 5:16 AM Lukas Slebodnik lslebodn@redhat.com wrote:
On (20/11/19 11:57), Lawrence Kearney wrote:
Lukas et al., Thank you for the suggestion. I'll test that as soon as convenient. I'm currently attending SC19 so spinning up labs is something best managed in the mornings with coffee :-) .
Curiously I did have to change the ownership of the socket, and a few service, unit files to sssd:root to get them to start. I would like to
test
the daemon to running as an unprivileged user as much as possible. I did not consider digging into the files themselves to check configured runtime users, I should've.
Using "hybrid" sssd:root is not a good idea. You should either remove sssd user/group from service files or run sssd as completely unprivileged user.
As to your question I currently have no real use case for the socket based responders other than their potential for system level optimisation in large enterprise deployments and kicking the tyres on the SSSD feature set to both experiment with it and document the assessment, results, and configuration nuances and requirements.
And I an exactly interested in that real use-case :-) Could you share a little bit more even thought you did not test it?
Because there might be other solution to the problem you would like to solve.
LS _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
On (21/11/19 09:14), Lawrence Kearney wrote:
Lukas et al., Firstly reverting the ownership of the sssd service and socket files in the "/usr/lib/systemd/system" and "/var/lib/sss" directories to sssd:sssd and adding the "user = sssd" to the sssd.conf file did resolve the responder issue.This file ownership model was what I thought should be in place, but rhel did not install them consistently this way. I implemented the sssd:root ownerships to resolve some issues with services starting. Interestingly even after changing the ownerships of the same files to sssd:sssd the responder still crashed without the user = sssd directive present in the sssd.conf. I would have thought the daemon on this platform would not require it.
Sorry If I was not clear. I did not suggest to change owner/permissions of directories or files
Just to remove "sssd" user and group from systemd service files for sssd responders
cp /usr/lib/systemd/system/sssd-pam.service /etc/systemd/system/sssd-pam.service
#modify file /etc/systemd/system/sssd-pam.service e.g. [Unit] Description=SSSD PAM Service responder Documentation=man:sssd.conf(5) After=sssd.service BindsTo=sssd.service RefuseManualStart=true
[Install] Also=sssd-pam.socket sssd-pam-priv.socket
[Service] Environment=DEBUG_LOGGER=--logger=files EnvironmentFile=-/etc/sysconfig/sssd ExecStartPre=-/bin/chown root:root /var/log/sssd/sssd_pam.log ExecStart=/usr/libexec/sssd/sssd_pam ${DEBUG_LOGGER} --socket-activated Restart=on-failure User=root Group=root PermissionsStartOnly=true
systemctl daemon-reload
That said, my experience on other platforms is the daemon runs as root, so this is useful to know for additional testing with other distributions, so thank you.
Different distributions build packages with different flags.
As to the use case discussion, most of my experience and assistance in deployments are direct integration models. Not that I have a technical issue with the indirect approach, but most organisations I encounter prefer the reduced complexity of the direct model. As long as it works reliably. There are feature trade offs using this method but most are okay given those choices are communicated.
I am still not sure how socket activated responders would help here.
That said, when you stand up sssd as a client against a large, mature, complex directory service any thing you can do to reduce the load on the clients and the directory service is a good step. Filtering search results across purposefully configured hosts and reducing load on the client and the directory service are key design components of this proposition.
You still need to provide sssd.conf for each host. (and whether there is a line with "services" is a minimal change)
So, I'm curious if the socket based responders can play a meaningful part in optimisation.
An addition question that may help me. What are your thoughts on the use case(s) for the socket based responders?
I would say it in this way. If distributions though that socket activated responders are tested enough hey would enable it by default.
LS
... that is a good point :-) .
-- lawrence
On Thu, Nov 21, 2019, 7:56 AM Lukas Slebodnik lslebodn@redhat.com wrote:
On (21/11/19 09:14), Lawrence Kearney wrote:
Lukas et al., Firstly reverting the ownership of the sssd service and socket files in
the
"/usr/lib/systemd/system" and "/var/lib/sss" directories to sssd:sssd and adding the "user = sssd" to the sssd.conf file did resolve the responder issue.This file ownership model was what I thought should be in place, but rhel did not install them consistently this way. I implemented the sssd:root ownerships to resolve some issues with services starting. Interestingly even after changing the ownerships of the same files to sssd:sssd the responder still crashed without the user = sssd directive present in the sssd.conf. I would have thought the daemon on this platform would not require it.
Sorry If I was not clear. I did not suggest to change owner/permissions of directories or files
Just to remove "sssd" user and group from systemd service files for sssd responders
cp /usr/lib/systemd/system/sssd-pam.service /etc/systemd/system/sssd-pam.service
#modify file /etc/systemd/system/sssd-pam.service e.g. [Unit] Description=SSSD PAM Service responder Documentation=man:sssd.conf(5) After=sssd.service BindsTo=sssd.service RefuseManualStart=true
[Install] Also=sssd-pam.socket sssd-pam-priv.socket
[Service] Environment=DEBUG_LOGGER=--logger=files EnvironmentFile=-/etc/sysconfig/sssd ExecStartPre=-/bin/chown root:root /var/log/sssd/sssd_pam.log ExecStart=/usr/libexec/sssd/sssd_pam ${DEBUG_LOGGER} --socket-activated Restart=on-failure User=root Group=root PermissionsStartOnly=true
systemctl daemon-reload
That said, my experience on other platforms is the daemon runs as root, so this is useful to know for additional testing with other distributions, so thank you.
Different distributions build packages with different flags.
As to the use case discussion, most of my experience and assistance in deployments are direct integration models. Not that I have a technical issue with the indirect approach, but most organisations I encounter
prefer
the reduced complexity of the direct model. As long as it works reliably. There are feature trade offs using this method but most are okay given those choices are communicated.
I am still not sure how socket activated responders would help here.
That said, when you stand up sssd as a client against a large, mature, complex directory service any thing you can do to reduce the load on the clients and the directory service is a good step. Filtering search results across purposefully configured hosts and reducing load on the client and the directory service are key design components of this proposition.
You still need to provide sssd.conf for each host. (and whether there is a line with "services" is a minimal change)
So, I'm curious if the socket based responders can play a meaningful part in optimisation.
An addition question that may help me. What are your thoughts on the use case(s) for the socket based responders?
I would say it in this way. If distributions though that socket activated responders are tested enough hey would enable it by default.
LS _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
sssd-users@lists.fedorahosted.org
-
Lawrence Kearney -
Lukas Slebodnik -
Sumit Bose