Description of problem: Since bug #1727236 was fixed, 'usermod -G' now fails if the user is a member of any remote groups. This breaks accountsservice's org.freedesktop.Accounts.User.SetAccountType method.
Version-Release number of selected component (if applicable): shadow-utils-2:4.6-12.el8
How reproducible: Always
Steps to Reproduce:
1. Somehow add user to remote group (either by enrolling with IPA server or with Active Directory)... this is hard, don't ask me how :)
2. Try to change user's account type from standard to administrator or vice-versa in gnome-control-center. Or do it manually via D-Bus.
$ gdbus call --system --dest org.freedesktop.Accounts --object-path /org/freedesktop/Accounts/User1636600000 --method org.freedesktop.Accounts.User.SetAccountType 1
Error: GDBus.Error:org.freedesktop.Accounts.Error.Failed: running '/usr/sbin/usermod' failed: Child process exited with code 6
Expected results: There should be no error!
Additional info: See https://github.com/shadow-maint/shadow/issues/338 for upstream discussion. The problem is the patch added in bug #1727236 doesn't just prevent adding users to remote groups, it also prevents *not removing* users from remote groups, i.e. it prevents us from keeping remote group membership unchanged. In order to add the user to a new local group, we now have to remove all the user's remote group memberships, since that's the only way to prevent usermod from claiming the groups don't exist.
As a solution the patch provided to fix bug #1727236 will be reverted
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory (shadow-utils bug fix and enhancement update), and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.