Local account override IPA account

[Kevin Vasko]

I know this is probably stupid but we have a server with a local account (let’s call this local user “user1”). This server and its install predated our IPA install. This local user also has sudoers exception for this account for a “NOPASSWD” locally on this machine and this machine alone.

After some period of time (it’s been like this for years), we added this “user1” account to FreeIPA so we could use it on other select machine. We kept using the local account as if nothing changed.

This server with the local “user1” account was on Ubuntu 18.04 and with this set up was working fine. We upgraded it to Ubuntu 20.04 and it broke the sudoers “NOPASSWD”. This local account can no longer execute commands without a password as it seems sssd is overriding the “local account” and going back to IPA and asking for its authentication (user1 on this box is local and has a uid of 1000, the freeipa user1 had the random freeIPA generated 123456789 UID).

In my nsswitch.conf

For passwd, group, sudoers all of them have “files” listed first which should instruct sssd to prioritize local account information first, correct?

If I remove “sss” from the nsswitch sudoers line it works as expected.

Is this a regression in sssd or something else Im missing?

-Kevin

[Jochen Kellner]

Hello Kevin,

Kevin Vasko via FreeIPA-users 
writes:
> I know this is probably stupid but we have a server with a local
> account (let’s call this local user “user1”). This server and its
> install predated our IPA install. This local user also has sudoers
> exception for this account for a “NOPASSWD” locally on this machine
> and this machine alone.
>
> After some period of time (it’s been like this for years), we added
> this “user1” account to FreeIPA so we could use it on other select
> machine. We kept using the local account as if nothing changed.

...
> If I remove “sss” from the nsswitch sudoers line it works as expected.
>
> Is this a regression in sssd or something else Im missing?

I don't think it's a pure regression. I think the supported way to
"migrate" a former local user to IPA with another uid or others is to
define an id view for user1 on the ubuntu host and use uid 1000 there.
I'd hope that deleting the local user just changes the password to the
IPA one and sudo starts working.

If you want to debug your install further, you'd probably need to enable
tracing in sssd and look for clues,

Jochen