Yup, “files” was first in nsswitch.conf. But now I can’t reproduce it
because after removing the user1 user from FreeIPA and adding it back,
it’s working as expected. :-/.
Is it possible that the IPA user had different UID before and now has
the same UID as the local user?
I'm still going to emphases my original answer: name collisions are not
supported. There may be some workarounds to solve particular situations,
but it is never a good idea to have name collisions.
For your particular situation with sudo, you don't have to have local
user in order to setup sudo rules in /etc/sudoers.
-Kevin
> On Nov 30, 2022, at 11:11 AM, Alexey Tikhonov <atikhono(a)redhat.com> wrote:
>
>
>
> You need to have 'files' first in all nsswitch.conf databases.
> If 'sudo' doesn't respect this then this is a bug in 'sudo.
>
> On Wed, Nov 30, 2022 at 5:59 PM Kevin Vasko <kvasko(a)gmail.com
> <mailto:kvasko@gmail.com>> wrote:
>
> So for example.
>
> machine1 enrolled in FreeIPA also has userid:
> user1 - locally (e.g. useradd)
> user1 on machine1 has a defined sudoers of NOPASSWD
>
> FreeIPA also has user1 defined in it.
>
> machine2 enrolled in FreeIPA:
> does not have any local accounts.
> if user1 logs in, machine2 uses sssd to allow it from freeIPA.
>
> What I want is on machine1 I want it to use _all_ locally
> configured settings for user1. I effectively want machine1 to
> ignore FreeIPA for user1.
>
> With that being said, I think this is a bug or some weird caching
> is happening.
>
> This is a series of even that happened:
>
> * user1 was on machine1 prior to freeIPA and being enrolled into
> FreeIPA.
> * user1 is a local account and has a NOPASSWD defined for it locally.
> * 1 year passes
> * freeIPA implemented, user1 account created in FreeIPA
> * machine1 enrolled into domain
> * user1 and NOPASSWD still working on machine1
> * Upgrade Ubuntu from 18.04 to 20.04
> * user1 no longer respects local sudoers file NOPASSWD on machine1
> and falls back to IPA
> * user1 account deleted from FreeIPA
> * user1 starts respects sudoers NOPASSWD file on machine1
> * user1 account added back to FreeIPA
> * user1 still respects sudoers NOPASSWD file on machine1.
>
> So it was working, upgraded to 20.04, stops working, removed
> account from FreeIPA, starts working, added account back to
> FreeIPA (expecting it to start failing again) but it’s still
> working as to how it did prior to 20.04 upgrade.
>
> -Kevin
>
> > On Nov 30, 2022, at 8:34 AM, Pavel Březina <pbrezina(a)redhat.com
> <mailto:pbrezina@redhat.com>> wrote:
> >
> > On 11/29/22 15:43, Kevin Vasko wrote:
> >> passwd: compat systemd sss
> >> group: compat systemd sss
> >> I changed it to be
> >> passwd: files compat systemd sss
> >> group: files compat systemd sss
> >> and still had the same problem.
> >> id_provider=ipa
> >> Yes Ubuntu.
> >> sssd 2.2.3-3ubuntu0.9
> >> This same named user that was created local is also in our IPA
> server but want this local account and settings on this machine to
> override that.
> >> -Kevin
> >>>> On Nov 29, 2022, at 3:03 AM, Alexey Tikhonov
> <atikhono(a)redhat.com <mailto:atikhono@redhat.com>> wrote:
> >>>
> >>>
> >>> Hi,
> >>>
> >>>> On Tue, Nov 29, 2022 at 1:10 AM Kevin Vasko
<kvasko(a)gmail.com
> <mailto:kvasko@gmail.com> <mailto:kvasko@gmail.com
> <mailto:kvasko@gmail.com>>> wrote:
> >>>
> >>> We have a local user that has an entry in sudoers for a
> “NOPASSWD”.
> >>>
> >>> In /etc/nsswitch.conf we have:
> >>>
> >>> sudoers: files sss
> >>>
> >>>
> >>> What is in 'passwd:' and 'group:'?
> >>> Do you use 'id_provider=files' in 'sssd.conf'?
> >>>
> >>>
> >>> For some reason sssd is falling back to sssd even though we
> have
> >>> the “files” entry first and is checking our FreeIPA
> instance and
> >>> rejecting it and prompts for password.
> >>>
> >>> if I make it
> >>>
> >>> sudoers: files
> >>>
> >>> It works.
> >>>
> >>> This was working without issue on 18.04, we upgraded to
> 20.04 and
> >>> now see the problem.
> >>>
> >>>
> >>> I guess this is Ubuntu version?
> >>> Could you please specify SSSD package versions?
> >>>
> >>>
> >>> Is there a way to make it prioritize the local sudoers and stop
> >>> looking on sssd?
> >
> > In general, SSSD does not support name collisions. You should
> make the ipa domain to require fully qualified names.
> >
> > Depending on the problem, there might be a way to solve it.
> However, I must admit, I do not fully understand your issue. Can
> you be more descriptive and provide some examples?
> >
> > Thank you,
> > Pavel
> >
> >
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> <mailto:sssd-users@lists.fedorahosted.org>
> To unsubscribe send an email to
> sssd-users-leave(a)lists.fedorahosted.org
> <mailto:sssd-users-leave@lists.fedorahosted.org>
> Fedora Code of Conduct:
>
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> <
https://docs.fedoraproject.org/en-US/project/code-of-conduct/>
> List Guidelines:
>
https://fedoraproject.org/wiki/Mailing_list_guidelines
> <
https://fedoraproject.org/wiki/Mailing_list_guidelines>
> List Archives:
>
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...
<
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...
> Do not reply to spam, report it:
>
https://pagure.io/fedora-infrastructure/new_issue
> <
https://pagure.io/fedora-infrastructure/new_issue>
>
> _______________________________________________
> 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