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.org
_______________________________________________
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.org