Ah yes - I can't believe I didn't do that first before messing with debugging and
posting to the list. Absolutely fixed my issue.
I wasn't fully clear on the note about removing support of handling local users so I
dug up commit 3e94b64 and have it on my list of things to read through.
Like so many important things, Ubuntu lags pretty hard on SSSD in comparison to RHEL, but
I have to assume we'll see the removal down the line sooner or later.
Thanks again for all the help, I'm down to one final SSSD related problem to
investigate. If I relent I'll probably post a question about socket activated vs
service based responders for pac and nss.
- Kodiak
Sent with [Proton Mail](https://proton.me/) secure email.
On Wednesday, January 31st, 2024 at 3:27 AM, Alexey Tikhonov <atikhono(a)redhat.com>
wrote:
Hi,
On Tue, Jan 30, 2024 at 11:22 PM Kodiak Firesmith <firesmith(a)protonmail.com>
wrote:
> Hello,
> I've begun to see the oddest thing within our AD environment on Linux clients
(Ubuntu 20, 22).
>
> During logins I see "groups: cannot find name for group ID".
>
> Then during various operations (eg when installing a package that has scripts that
create local users, such as postgresql) I see a few of the same userIDs listed as terminal
output like this:
>
> Couldn't invalidate user jim.bob(a)domain.college.edu
> Couldn't invalidate user sally.sue(a)domain.college.edu
> Couldn't invalidate user joe.nobody(a)domain.college.edu
>
> Reading through what little comes up in Google for 'Couldn't invalidate
user' + sssd, I found old bugs about not being able to invalidate groups in the
sss_cache. That got me far enough to have a repeatable action to force this output:
>
> # sss_cache -UG
> Couldn't invalidate user jim.bob(a)domain.college.edu
> Couldn't invalidate user sally.sue(a)domain.college.edu
> Couldn't invalidate user joe.nobody(a)domain.college.edu
Looks like the cache got into an inconsistent state.
Try to delete cache altogether: stop SSSD; rm -rf /var/lib/sss/db/* (or make a backup if
you'd like to); start SSSD
Btw, SSSD shipped in recent Fedora is built without support of handling local users and
for this reason shadow-utils doesn't execute 'sss_cache' when manipulating
local users. Ubuntu should do the same.
> I've tried ramping up debugging on my AD domain entry in sssd.conf to 9 but
I'm not seeing anything that jumps out.
>
> Any ideas?
>
> 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...
> Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue