[SSSD-users] Re: logins fail after socket activated responders implemented.
... that is a good point :-) .
-- lawrence
On Thu, Nov 21, 2019, 7:56 AM Lukas Slebodnik 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-le...@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-le...@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] Re: logins fail after socket activated responders implemented.
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-le...@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] Re: logins fail after socket activated responders implemented.
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 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-le...@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-le...@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] Re: logins fail after socket activated responders implemented.
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-le...@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] Re: logins fail after socket activated responders implemented.
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
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-le...@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-le...@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] Re: logins fail after socket activated responders implemented.
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-le...@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] Re: logins fail after socket activated responders implemented.
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 failedSSSD 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 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 > > > 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 failedSSSD 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 > > > > > > >
[SSSD-users] Re: logins fail after socket activated responders implemented.
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 failedSSSD 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 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 > > 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 failedSSSD 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 < > hangarb...@gmail.com> > > > wrote: > > > > > >> SSSD team, > > >> A curious issue after walking through the
[SSSD-users] Re: logins fail after socket activated responders implemented.
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 > 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 failedSSSD 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 > > 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) > >>
[SSSD-users] Re: logins fail after socket activated responders implemented.
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 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 failedSSSD 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 > 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
[SSSD-users] Re: logins fail after socket activated responders implemented.
... 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 failedSSSD 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 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 = >
