@stevefair I'd suggest looking at the policy logs for the Macs exhibiting the problem and looking for something that was installed on all of them. Especially if you have any installer packages that were created by having Composer watch a system for changes while installing something. It's not uncommon for that process to grab files that you don't really want included when you deploy the package.

I'm seeing a similar thing on my Macs. I'm still testing, but it looks like it's affecting Macs who have installed the security update:

* Security Update -10.14.6 Security Update (10.14.6), 1568930K [recommended] [restart]

I found a machine that still needed the update, and sudo worked just fine. After I did the installation, I started seeing the error. Is anyone else seeing this same thing?

Seeing this from Jamf Remote client log and on the Mac when using sudo.

On some test machines, I found that updating to Catalina or reinstalling Mojave both seemed to clear up the issue, though both are slow processes. For Catalina, I used a Profile to push out a package with the new OS installer to the machine (profiles work with this bug) and then ran the installer from the Mac (installer authentications also work with this bug). For Mojave, I rebooted holding down Cmd+R and installed in-place over the old OS and did updates from there. Hopefully there are easier fixes, but these appear to work.

@ukcasey With both updates you reference to, the /etc/sudoers files is overwritten.
I would advise to take a look at this file (and the 'included' files) on affected mac's. (You must be very carefully to edit this file, see man visudo).
Maybe resetting this file (or the 'included' files) solves your issues.

Thanks, @maurits. The only issue is that when you're stuck that way, you can't easily access the sudoers file. sudo, visudo, and even dsenableroot don't work from the command line. sudoers is owned and only readable by root. That being said, I've found that policies do work, and they're executed with root privileges, so it's possible I can examine the contents in a policy (or write it to another file or something like that). That's something worth trying. Possibly (admittedly, this could cause its own problems), if the sudoers file is messed up, maybe I could package up the file from a "good" machine through Composer and push it out via policy to a "broken" one to let sudo work again. It would be easier than a full OS reinstall.

Your approach to replace the file with a policy may work. (Test-test-tast again)
Personally I prefer to create a pkg using tools like munkipkg over Composer, since that may include additonal files if used incorrectly. Let us know

@ukcasey Taking a shot in the dark with this, but, have you confirmed that the local admin group still exists on these affected Macs? This would be done with something like dscl . list /Groups A group named "admin" should be one of the items that shows up in the list. If it's there, check the contents of the admin group with dscl . read /Groups/admin
Normally the admin group would look something similar to this on almost all Macs:

dsAttrTypeNative:record_daemon_version: 4850000
AppleMetaNodeLocation: /Local/Default
GeneratedUID: ABCDEFAB-CDEF-ABCD-EFAB-CDEF00000050
GroupMembers: FFFFEEEE-DDDD-CCCC-BBBB-AAAA00000000 42F9AA5B-127F-45E7-BF5D-9C7F2582F273 E355528F-B714-4FC5-9851-9F0C5A7F0603
GroupMembership: <list of usernames here>
Password: *
PrimaryGroupID: 80
RealName: Administrators
RecordName: admin BUILTINAdministrators
RecordType: dsRecTypeStandard:Groups
SMBSID: S-1-5-32-544

I ask all this because some years ago I had to deal with a situation where the local admin group was being deleted because of a faulty installer, or maybe it was McAfee, I can't recall exactly now. Whatever it was, it caused any account that was not specifically "root" to stop being able to do any sudo commands. This is because all admin accounts end up in the admin group, from which they inherit their admin permissions. Root isn't effected by a missing admin group, so it will continue to work. This also explains why normal policies, at least the ones that run by a check-in (using a LaunchDaemon) continue to work. These get run as root, not as another user elevated to root.

If you checked this already, then just ignore what I'm saying. But if you didn't look into that yet, I would check it, just to make sure that isn't the main cause of the problem you're seeing. In case it helps, it is possible to recreate the admin group. It can be done with a policy. That's actually what we ended up doing to get things fixed on those broken Macs.

@mm2270 Good idea to check that. The affected machines I checked have the admin group in there.

An unfortunate follow-up: When I examined the /etc/sudoers file of a broken machine, it was identical to the same file on a working machine, and neither had anything in the include (/private/etc/sudoers.d) directory, so it appears to be a deeper problem than just the one file. The update/reinstall has been working as a fix (Who has two thumbs an installed Catalina on a hundred machines over a weekend? This guy!), but as I said before, it's slow. Still if there's someone else running into this, you have some kind of answer.

Just a +1.
We're seeing this on all our 10.14.6 machines with the latest security update installed. Unfortunately it breaks the functionality of some of our scripts. Fingers crossed we'll have a fix from Apple soon.

I just SSHed (as a local account 'administrator') into the handful of Mojave MacBooks that have upgraded to the 2020-01 Security update (18G3020) and was able to 'sudo jamf policy' on all of them. Must be something else in the mix.

The invalid value of 4294967295 - might it indicate the user ID from an LDAP source like AD? Our Macs are bound to AD.

I just SSHed in to one of the Macs with my own credentials and was able to sudo.

The invalid value of 4294967295 - might it indicate the user ID from an LDAP source like AD? Our Macs are bound to AD.

Maybe? But I'm doubtful since the value is the same across different environments. We're also seeing the same number, 4294967295, and it doesn't match up to any generated UID or GID derived from Active Directory users or groups on our machines.

Edit: As someone pointed out in this thread over on macrumours, 4294967295 is simply the highest number of a 32-bit unsigned integer.

It's odd, I'm having this issue and some of my support staff can't sudo, yet my AD account can; just weird.

Have you tried 'sudo -l' on such a node, using one of the troubled accounts? What is the uid of the troubled account on these nodes? Are you using matched uid's in your AD binding or does the OS select an arbitrary matching?

@mschroder we're mapping UID's to an account attribute. One of the trouble accounts has a UID of 21601719 and mine maps to 81105806. For group mapping I actually add the UID of the group in AD to the NestedGroups attribute of a local group (ex. com.apple.access_ssh) and I've explicitly put his account into that group to rule out nesting issues but still no luck.

Here's the sanitized output:

Matching Defaults entries for {USER} on {DEVICE}:
    env_reset, env_keep+=BLOCKSIZE, env_keep+="COLORFGBG COLORTERM",
    env_keep+=__CF_USER_TEXT_ENCODING, env_keep+="CHARSET LANG LANGUAGE LC_ALL
    LC_COLLATE LC_CTYPE", env_keep+="LC_MESSAGES LC_MONETARY LC_NUMERIC
    LC_TIME", env_keep+="LINES COLUMNS", env_keep+=LSCOLORS,
    env_keep+=SSH_AUTH_SOCK, env_keep+=TZ, env_keep+="DISPLAY XAUTHORIZATION
    XAUTHORITY", env_keep+="EDITOR VISUAL", env_keep+="HOME MAIL",
    lecture_file=/etc/sudo_lecture

User {USER} may run the following commands on {DEVICE}:
    (ALL) ALL
    (ALL) ALL

This post from Mr Macinntosh covers this issue fairly well.
https://mrmacintosh.com/10-15-3-update-breaks-ad-domain-users-admin-sudo-access-fix-inside/
Also in my own testing you can use the old school method of just adding an AD group to the 'admin' group with this command. /usr/sbin/dseditgroup -o edit -a dept-ads-groupname -t group admin

In our environment it seems unrelated to the AD Group admin issue. Our defined AD-groups are still listed under "Allowed admin groups" and the sudo bug also applies to local admin user accounts.

I am surprised that 'sudo -l' works properly, but using it to execute something fails.

Just to give you some more data points:
I use AD accounts with uid and gid mapping, and I don't see this issue neither on 10.14 nor on 10.15. But then again we don't have use AD admins on the Macs, but have added another group as admins via dseditgroup. And I did the binding via a Profile.

Did anyone find the fix to this?
Does 2020-002 fix it? I doubt it as it would only introduce stricter rules
It's obvious the 2020-001 did do something but oddly 60% of the population
Nested groups look fine from one machine to the other.... The same UID is nested.. Makes it odd... I'm stuck on Mojave and high Sierra for a while so if anyone has a better fix than a rebuild or upgrade to Mojave please do let me know... Any help is appreciated

Cheers!

I am also experiencing this issue with our local admin account on all of our of lab machines that are all running 10.14.6. Has anyone been able to find a fix for this?

@jartron3030 Are you by any chance using the Privilege Management for Mac product from Beyond Trust (formerly known as Defendpoint from Avecto)? And have these Macs had Security Update 2020-03 Mojave installed? There is a conflict with PMfM and macOS Catalina 10.15.5 due to an un-documented change Apple made to sudo, and that change may be part of Security Update 2020-03 as well.

If that is what's causing your problem, the workaround posted to the MacAdmins Slack channel for PMfM is to edit defendpoint.plist in /Library/Application Support/Avecto/Defendpoint/ and set the Sudo.Enabled key to false

Good Day

The fix to this issue is to copy a file from a working machine. The file /private/var/db/dslocal/nodes/Default/users/root.plist most likely missing on the machine with the error. I used Composer to create a .dmg of the plist, used a Policy to install said .dmg and reboot machine. Success!!

We did find this as well but found it was related to a FUT, fill user template and FEU fill existing users DMG we pushed out with user settings. THis created a root user in the users folder. When the computer reboots it sees this user in the /Users folder and then the root user gets corrupted. now have a script which checks for that specific root user and removes it at logout. Seems to have fixed the issue for us.
Problem is definately root user issues, whether this is the sudoers file, the root user etc.
if you try to find the root user in dscl does it exist? dscl . read /Users/root
Any device affected we would run startosinstall to install the OS over the top which resolved this.

@BOBW Your theory looks like line up with our situation seeing this in our Labs that have FUT/FEU enabled. What specifically do you run to remove the /Users/root? Simply an rm -rf or something more? Would love to see what you're specifically doing to address this. Thanks for posting it!