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(a)redhat.com>
> 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(a)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(a)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
> > (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?
> 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
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
I've tried making the debug_level higher. I got this in sssd.log after
restarting the service
The relevant log file here is sssd_YOUR.DOMAIN.NAME.log.
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.
> > >
> > > Thanks.
> 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://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: