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 <[email protected]>
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 -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
_______________________________________________
sssd-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
