Skip to main content
Question

Lost ability to use sudo command


Forum|alt.badge.img+1

A random number of Macs in my environment have lost the ability to use sudo from a terminal. I have tried local admin user, ARD send Unix command as root, and JAMF Remote. I am trying a simple jamf recon and the result is:
sudo: 4294967295: invalid value.

Google turns up a few articles:
https://www.sudo.ws/alerts/minus_1_uid.html
https://news.ycombinator.com/item?id=21366177
I am not a Unix or Linux expert to understand why this is occurring or how to fix it. I do know that I have not edited the sudoers file, I can log into a local admin account and run normally if I don't use terminal requiring sudo, I can log in as an AD admin and get the same error message sending terminal commands using sudo, and logging in as a standard AD user I can su to a local admin account, but can't run commands using sudo.

These are computers that were installed with a fresh 10.14. OS and apps from our JAMF server and worked normally until I noticed sudo failing Wednesday. They were not imaged, they all work as expected with this exception.

I looked at permissions of the sudoers file on a working Mac. Admin and wheel are read only, everyone is no access. On the non working Macs, Fetching is in place of admin, wheel is read only, and everyone is no access. My conclusion is that the permissions are wrong and that's why sudo fails, but I know nothing of why this has happened or if this is the only anomaly regarding these permissions and how to repair it.

Sorry for the long winded post, but no one in my organization knows what to do. Thanks.

34 replies

sdagley
Forum|alt.badge.img+25
  • Jamf Heroes
  • 3540 replies
  • January 31, 2020

@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.


Forum|alt.badge.img+2
  • New Contributor
  • 5 replies
  • February 5, 2020

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?


thomasC
Forum|alt.badge.img+10
  • Contributor
  • 57 replies
  • February 5, 2020

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


Forum|alt.badge.img+2
  • New Contributor
  • 5 replies
  • February 6, 2020

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.


Forum|alt.badge.img+8
  • Contributor
  • 58 replies
  • February 7, 2020

@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.


Forum|alt.badge.img+2
  • New Contributor
  • 5 replies
  • February 7, 2020

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.


Forum|alt.badge.img+8
  • Contributor
  • 58 replies
  • February 7, 2020

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


mm2270
Forum|alt.badge.img+16
  • Legendary Contributor
  • 7880 replies
  • February 7, 2020

@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.


Forum|alt.badge.img+2
  • New Contributor
  • 5 replies
  • February 11, 2020

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


Forum|alt.badge.img+2
  • New Contributor
  • 5 replies
  • February 11, 2020

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.


Forum|alt.badge.img+7
  • Contributor
  • 35 replies
  • February 12, 2020

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.


Forum|alt.badge.img+14
  • Honored Contributor
  • 862 replies
  • February 12, 2020

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.


Forum|alt.badge.img+7
  • Contributor
  • 35 replies
  • February 13, 2020
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.


Forum|alt.badge.img+8
  • Contributor
  • 50 replies
  • February 13, 2020

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


Forum|alt.badge.img+12
  • Valued Contributor
  • 359 replies
  • February 13, 2020

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?


Forum|alt.badge.img+8
  • Contributor
  • 50 replies
  • February 13, 2020

@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

Forum|alt.badge.img+5
  • Contributor
  • 13 replies
  • February 13, 2020

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


Forum|alt.badge.img+7
  • Contributor
  • 35 replies
  • February 14, 2020

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.


Forum|alt.badge.img+12
  • Valued Contributor
  • 359 replies
  • February 14, 2020

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.


Forum|alt.badge.img+3

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!


jartron3030
Forum|alt.badge.img+6
  • New Contributor
  • 15 replies
  • June 12, 2020

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?


sdagley
Forum|alt.badge.img+25
  • Jamf Heroes
  • 3540 replies
  • June 13, 2020

@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


Forum|alt.badge.img+13
  • Honored Contributor
  • 253 replies
  • August 31, 2020

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!!


Forum|alt.badge.img+8
  • Valued Contributor
  • 126 replies
  • August 31, 2020

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.


Forum|alt.badge.img+16

@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!


Reply


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings