sssd not using local sudoers file

[Kevin Vasko]

We have a local user that has an entry in sudoers for a “NOPASSWD”.

In /etc/nsswitch.conf we have:

sudoers: files sss

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.

Is there a way to make it prioritize the local sudoers and stop looking on sssd?

-Kevin

[Alexey Tikhonov]

Hi,

On Tue, Nov 29, 2022 at 1:10 AM Kevin Vasko  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?

[Alexey Tikhonov]

Hi,
> sssd is falling back to sssd even though we have the “files” entry first

That's not 'sssd' but 'sudo'.

What is the output of:
(1) `ps aux | grep sss`
(2) `getent passwd $user`
?

On Tue, Nov 29, 2022 at 8:44 PM 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  wrote:
>
> 
> Hi,
>
> On Tue, Nov 29, 2022 at 1:10 AM Kevin Vasko  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?
>
> sssd-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail].o...
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
> sssd-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail].o...
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue

[Pavel Březina]

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  wrote:
> >
> > 
> > Hi,
> >
> > On Tue, Nov 29, 2022 at 1:10 AM Kevin Vasko <[e-mail] 
> > > 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

[Kevin Vasko]

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  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  wrote:
> > >
> > > 
> > > Hi,
> > > > On Tue, Nov 29, 2022 at 1:10 AM Kevin Vasko <[e-mail] > 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

[Alexey Tikhonov]

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  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  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
>
> wrote:
> > > > 
> > > > Hi,
> > > > > On Tue, Nov 29, 2022 at 1:10 AM Kevin Vasko <[e-mail]
>
> > 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail].o...
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue

[Pavel Březina]

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?

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

[Pavel Březina]

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

[Kevin Vasko]

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

[Kevin Vasko]

Appreciate it.

Yup, that’s fair. Once I saw the duplicate name in IPA it kind of made sense. The users were just not wanting to change the names of everything if they could help it (since it was working before). But if it breaks again I’ll be recommending to change the name to avoid the name collision.

Thanks,

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