It did not. It wasn’t even part of a group. They use it the account as a service account
on other systems but it has no sudoers permissions.
-Kevin
> On Dec 1, 2022, at 9:30 AM, Pavel Březina <pbrezina(a)redhat.com> wrote:
>
> On 12/1/22 16:28, Pavel Březina wrote:
>>> On 11/30/22 20:57, Kevin Vasko wrote:
>>> 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?
>
> Also did the ipa user had any sudo rules defined in ipa? Those might have been
deleted/disabled when you removed the 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
>