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 <[email protected]> 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 <[email protected]> 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 <[email protected] >>>> <mailto:[email protected]>> 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 <[email protected] >>>> <mailto:[email protected]>> 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 >>>> <[email protected] <mailto:[email protected]>> wrote: >>>> >>> >>>> >>> >>>> >>> Hi, >>>> >>> >>>> >>>> On Tue, Nov 29, 2022 at 1:10 AM Kevin Vasko <[email protected] >>>> <mailto:[email protected]> <mailto:[email protected] >>>> <mailto:[email protected]>>> 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 -- [email protected] >>>> <mailto:[email protected]> >>>> To unsubscribe send an email to >>>> [email protected] >>>> <mailto:[email protected]> >>>> 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/[email protected] >>>> >>>> <https://lists.fedorahosted.org/archives/list/[email protected]> >>>> 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 -- [email protected] >>>> To unsubscribe send an email to [email protected] >>>> 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/[email protected] >>>> Do not reply to spam, report it: >>>> https://pagure.io/fedora-infrastructure/new_issue > _______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
