After enabling debugging level 10 I spent several hours reading through the extremely verbose logs. Turns out a previous error that I didn't think mattered much was the culprit. I had an error stating that a specific Group Policy Object was unreadable:

[ad_gpo_missing_or_unreadable_attr] (0x0020): Group Policy Container with DN [cn={5D25
...},cn=policies,cn=system,DC=xyz,DC=mydomain,DC=com] is unreadable or has unreadable or missing attributes. In order to fix this make sure that this AD object has following attributes readable: nTSecurityDescriptor, cn, gPCFileSysPath, gPCMachineExtensionNames, gPCFunctionalityVersion, flags. Alternatively if you do not have access to the server or can not change permissions on this object, you can use option ad_gpo_ignore_unreadable = True which will skip this GPO.See 'man ad_gpo_ignore_unreadable for details.'

Since GPOs apply to Windows, I thought I could ignore that error. Incorrect. The solution was to add "ad_gpo_ignore_unreadable = True" to the domain-specific section of sssd.conf. I did check the permissions on that GPO and they did not match any of the above attributes, however compared to other GPOs it looked fine. But maybe there's a better way to resolve this.

After adding the above to sssd.conf I bounced the service and cleared the cache and was able to log in:

systemctl stop sssd && rm -f /var/lib/sss/db/* && systemctl start sssd


From: Lukas Slebodnik <lslebodn@redhat.com>
Sent: Friday, April 5, 2019 6:10 PM
To: End-user discussions about the System Security Services Daemon
Subject: [SSSD-users] Re: Fedora 29, one successful login, then no more
 
On (05/04/19 21:47), Mike Hughes wrote:
>I used realm join and experienced one successful graphical login but then updated the system to the latest version and now cannot login. I can su to the account, run id user on the account so AD lookups seem to be working, but getent passwd returns only local accounts (not sure if that’s a symptom of a problem or not).
>
>This is what I see in journalctl:
>
>journalctl -q _TRANSPORT=audit | grep "mike\""
>Apr 05 11:53:41 my-hostname.internal.domain.com audit[3352]: USER_AUTH pid=3352 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:authentication grantors=pam_succeed_if,pam_succeed_if,pam_sss,pam_gnome_keyring acct="mike" exe="/usr/libexec/gdm-session-worker" hostname=my-hostname.internal.domain.com addr=? terminal=/dev/tty1 res=success'
>Apr 05 11:53:41 my-hostname.internal.domain.com audit[3352]: USER_ACCT pid=3352 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:accounting grantors=? acct="mike" exe="/usr/libexec/gdm-session-worker" hostname=my-hostname.internal.domain.com addr=? terminal=/dev/tty1 res=failed'
>

Access control failed here.
You should find more info in sssd.log files after increasing debug_level
in domain section of ssd.conf
https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html#troubleshooting-general-authentication-problems

LS
_______________________________________________
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.org