Hi.
Some info:
OS: Linux Mint 18 (Ubuntu 16.04)
SSSD version: 1.13.4-1ubuntu1.13 (Downgraded from 1.13.4-1ubuntu1.14 to test is their new update broke something)
AD is on Windows Server (not sure which version).
Everything was working fine until this morning, I'm not aware if anything changed on the Windows server.
Situation:
If I try to login with an AD user: su myuser@domain.com
I see this in log (/var/log/auth.log)
pam_sss(su:auth): authentication success; logname= uid=1005 euid=0 tty=/dev/pts/2 ruser=myuser rhost= user=myuser@domain.com
But the shell just hangs there for about 45 seconds and then spits out "su: Authentication service cannot retrieve authentication info"
I noticed everytime I try this a new line appears in /var/log/sssd/sssd_nss.log:
(Thu May 23 12:02:14 2019) [sssd[nss]] [id_callback] (0x0010): The Monitor returned an error [org.freedesktop.DBus.Error.NoReply]
if I try a wrong password I immediately get an authentication failure.
Any ideas on what I could try to fix this?
Thanks.
On Thu, May 23, 2019 at 12:04:45PM -0400, Jason Pleau wrote:
Hi.
Some info:
OS: Linux Mint 18 (Ubuntu 16.04)
SSSD version: 1.13.4-1ubuntu1.13 (Downgraded from 1.13.4-1ubuntu1.14 to test is their new update broke something)
AD is on Windows Server (not sure which version).
Everything was working fine until this morning, I'm not aware if anything changed on the Windows server.
Situation:
If I try to login with an AD user: su myuser@domain.com
I see this in log (/var/log/auth.log)
pam_sss(su:auth): authentication success; logname= uid=1005 euid=0 tty=/dev/pts/2 ruser=myuser rhost= user=myuser@domain.com
But the shell just hangs there for about 45 seconds and then spits out "su: Authentication service cannot retrieve authentication info"
I noticed everytime I try this a new line appears in /var/log/sssd/sssd_nss.log:
(Thu May 23 12:02:14 2019) [sssd[nss]] [id_callback] (0x0010): The Monitor returned an error [org.freedesktop.DBus.Error.NoReply]
if I try a wrong password I immediately get an authentication failure.
Any ideas on what I could try to fix this?
Hi,
looks like the access control step runs into a timeout most probably because some servers are not reachable.
Which access_provider are you using in sssd.conf?
You can set the debug_level option in the [domain/...] section of sssd.conf to get more details in the logs after restarting SSSD. I would start with e.g '5', '9' is the highest level. See also https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html for more details.
bye, Sumit
Thanks. _______________________________________________ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
On Fri, May 24, 2019 at 2:09 AM Sumit Bose sbose@redhat.com wrote:
On Thu, May 23, 2019 at 12:04:45PM -0400, Jason Pleau wrote:
Hi.
Some info:
OS: Linux Mint 18 (Ubuntu 16.04)
SSSD version: 1.13.4-1ubuntu1.13 (Downgraded from 1.13.4-1ubuntu1.14 to test is their new update broke something)
AD is on Windows Server (not sure which version).
Everything was working fine until this morning, I'm not aware if anything changed on the Windows server.
Situation:
If I try to login with an AD user: su myuser@domain.com
I see this in log (/var/log/auth.log)
pam_sss(su:auth): authentication success; logname= uid=1005 euid=0 tty=/dev/pts/2 ruser=myuser rhost= user=myuser@domain.com
But the shell just hangs there for about 45 seconds and then spits out "su: Authentication service cannot retrieve authentication info"
I noticed everytime I try this a new line appears in /var/log/sssd/sssd_nss.log:
(Thu May 23 12:02:14 2019) [sssd[nss]] [id_callback] (0x0010): The Monitor returned an error [org.freedesktop.DBus.Error.NoReply]
if I try a wrong password I immediately get an authentication failure.
Any ideas on what I could try to fix this?
Hi,
looks like the access control step runs into a timeout most probably because some servers are not reachable.
Which access_provider are you using in sssd.conf?
You can set the debug_level option in the [domain/...] section of sssd.conf to get more details in the logs after restarting SSSD. I would start with e.g '5', '9' is the highest level. See also https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html for more details.
bye, Sumit
Hi
in sssd.conf:
access_provider = ad
I've tried making the debug_level higher. I got this in sssd.log after restarting the service
https://gist.github.com/jpleau/fc23629c95894143a05426dc1fc54b6e
Also if I check journalctl -u sssd, I can see this:
https://gist.github.com/jpleau/286c65306ebbf750d02b72b225140af6
Thanks.
On Fri, May 24, 2019 at 09:00:59AM -0400, Jason Pleau wrote:
On Fri, May 24, 2019 at 2:09 AM Sumit Bose sbose@redhat.com wrote:
On Thu, May 23, 2019 at 12:04:45PM -0400, Jason Pleau wrote:
Hi.
Some info:
OS: Linux Mint 18 (Ubuntu 16.04)
SSSD version: 1.13.4-1ubuntu1.13 (Downgraded from 1.13.4-1ubuntu1.14 to test is their new update broke something)
AD is on Windows Server (not sure which version).
Everything was working fine until this morning, I'm not aware if anything changed on the Windows server.
Situation:
If I try to login with an AD user: su myuser@domain.com
I see this in log (/var/log/auth.log)
pam_sss(su:auth): authentication success; logname= uid=1005 euid=0 tty=/dev/pts/2 ruser=myuser rhost= user=myuser@domain.com
But the shell just hangs there for about 45 seconds and then spits out "su: Authentication service cannot retrieve authentication info"
I noticed everytime I try this a new line appears in /var/log/sssd/sssd_nss.log:
(Thu May 23 12:02:14 2019) [sssd[nss]] [id_callback] (0x0010): The Monitor returned an error [org.freedesktop.DBus.Error.NoReply]
if I try a wrong password I immediately get an authentication failure.
Any ideas on what I could try to fix this?
Hi,
looks like the access control step runs into a timeout most probably because some servers are not reachable.
Which access_provider are you using in sssd.conf?
You can set the debug_level option in the [domain/...] section of sssd.conf to get more details in the logs after restarting SSSD. I would start with e.g '5', '9' is the highest level. See also https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html for more details.
bye, Sumit
Hi
in sssd.conf:
access_provider = ad
This means that the GPO based access control is used, is this what you expected, please see ad_gpo_access_control in man sssd-ad for details.
Can you check if using 'access_provider = permit' helps to make login work?
I've tried making the debug_level higher. I got this in sssd.log after restarting the service
https://gist.github.com/jpleau/fc23629c95894143a05426dc1fc54b6e
The relevant log file here is sssd_YOUR.DOMAIN.NAME.log.
Also if I check journalctl -u sssd, I can see this:
https://gist.github.com/jpleau/286c65306ebbf750d02b72b225140af6
There are hints that the connection to one of the AD DCs might have failed. But details should be available in sssd_YOUR.DOMAIN.NAME.log.
bye, Sumit
Thanks.
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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
On Fri, May 24, 2019 at 11:09 AM Sumit Bose sbose@redhat.com wrote: [snip]
This means that the GPO based access control is used, is this what you expected, please see ad_gpo_access_control in man sssd-ad for details.
Can you check if using 'access_provider = permit' helps to make login work?
access_providere = permit makes it work again!
I asked our sysadmin and he told me he played with those settings a few days ago. That could explain why my setup wasn't working because he didn't do anything for the Linux boxes.
I'm thinking setting back the access_provider to 'ad' and changing ad_gpo_access_control to 'permissive' would also work, I'll reply back once I test it!
Thanks a lot!
I've tried making the debug_level higher. I got this in sssd.log after restarting the service
https://gist.github.com/jpleau/fc23629c95894143a05426dc1fc54b6e
The relevant log file here is sssd_YOUR.DOMAIN.NAME.log.
Also if I check journalctl -u sssd, I can see this:
https://gist.github.com/jpleau/286c65306ebbf750d02b72b225140af6
There are hints that the connection to one of the AD DCs might have failed. But details should be available in sssd_YOUR.DOMAIN.NAME.log.
bye, Sumit
Thanks.
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://getfedora.org/code-of-conduct.html 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://getfedora.org/code-of-conduct.html 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