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 <[email protected]> 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 <[email protected]> > > > 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 < > > [email protected]> > > > > 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: [email protected] > > > > t: +001 706.951.6257 > > > > w: www.lawrencekearney.com > > > > l: www.linkedin.com/in/lawrencekearney > > > > > > > > > > > > > _______________________________________________ > > > sssd-users mailing list -- [email protected] > > > To unsubscribe send an email to [email protected] > > > 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/[email protected] > > _______________________________________________ > > sssd-users mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > 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/[email protected] > > > _______________________________________________ > sssd-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] > 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/[email protected] _______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected]
