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(a)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#troubleshoot...
LS
_______________________________________________
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:
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...