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(a)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(a)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(a)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(a)earthlink.net
> > > t: +001 706.951.6257
> > > w:
www.lawrencekearney.com
> > > l:
www.linkedin.com/in/lawrencekearney
> > >
> > >
>
> > _______________________________________________
> > 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://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.fedorahoste...
> _______________________________________________
> 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://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.fedorahoste...
>