Losing Admin Group

What happens if you do this

dscl . read /Groups/admin GroupMembership

or

dscl . list /Groups | grep "admin"

I have never heard of this or seen this before. What are the last
packages you installed, or last scripts you have ran before this
happened? Also, do your end users have admin rights to these machines?

-Tom

I saw this with 10.5.6 Machines a few months ago. In our case the the admin group existed, but it was corrupt. We could not use terminal to delete it, or recreate it, as it would say that it already existed. You had to log in as root, go to the /var/db/dslocal/nodes/Default/groups directory and remove the admin.plist file first. I posted here about it and one person also had seen the issue. I was never able to figure out what caused the issue, as it happened on a total of 7 machines over 3 months. We could not find a common cause, no file push or policy was run on these machines that would not have been on the rest of our computers. Not to mention we test everything before we push it to users. I did contact Apple about it but they were not much help, the only thing they would offer was a archive an install to fix the problem.

Sean

--
Sean Gallagher
Sr. Platform Engineer
The Children's Hospital of Philadelphia
100 Penn Square East 7th Flr.
Phila, PA. 19107
267-426-2607

I was just told by Tom Anderson that McAfee was causing this. I'm going to get this added to the exclusions list: /var/db/dslocal

Are there any other exclusions that anyone sets to make sure McAfee isn't causing issues or slowing systems down?

Thanks,
Noah

Apologies, I meant to reply to the group.

We also suspect this caused a problem where our Macs could no longer login against AD. And one additional point, our AppleCare rep said they've seen these problems caused by antivirus software, so I don't think it's unique to McAfee.

Thanks,
Tom

Sorry forgot to change the subject...

Hi Noah,

I know it is a bit late to respond...

I had this issue on 2 or 3 Macs in the past and this fixed it for me.

rm /var/db/dslocal/nodes/Default/groups/admin.plist && dseditgroup -o
create -i 80 admin && dscl . append /groups/admin GroupMembership myuser

After that I could elevate users to admin again.

Cem

I've been seeing this on a few more machines. In this case the admin.plist file was still intact but corrupt and unreadable.

True I can use Cem's recommendation for this however there's a roadblock. Our Machines are PGP encrypted and cannot boot to single user mode to fix these changes. Since there is no admin accounts, I can't use Terminal to make these changes.

The only other resolution is to boot the affected machine into target mode and use another machine (with pgp) to mount the disk then make the changes.

That being said, has anyone nailed the cause of this issue?

Thanks,
Noah

Bringing this back from the dead.

I have had this happen to ~ 10 machines with a total population of about 400 Macs. It is good to be pointed in the right direction at AV software, but does anyone else have any clue why this is happening?

Forgot to add the Machines are 10.9.5, JSS is 9.63, McAfee Endpoint Protection.

What version of McAfee? Ran into this problem at multiple clients, adding /var/db/dslocal seems to stop it from happening. Have also seen McAfee deleting the localhost.plist in /var/db/dslocal, breaking Kerberos (and thus, 802.1X authentication).

File a bug report with McAfee while you are at it.

Wow, never saw this particular thread before, probably because of its age, but we've been having this happen on some of our Macs randomly over the last year or more. Not in large numbers, but enough that we had to script a repair process for our techs to run. Prior to developing that we were just reimaging them which is a hassle for such a stupid issue. We also use McAfee Endpoint Protection on our Macs. I'm not in the least surprised that it may be linked to CrapAfee McAfee. The number of issues we've had to troubleshoot and get fixes for related to McAfee over the last couple of years are miles long.
Thanks for the tip on adding /var/db/dslocal to the exclusion list @RobertHammen. I will be talking to our AV guy about this come Monday.

Thanks for the tip @RobertHammen. Will give that a shot as well.

@mm2270, what was your repair process?
Currently we are reimaging as well if this happens. Curious what the fix would be, as that would save some time. Anything I've tried to do to get the group back would not work as the mgmt account could not do anything without elevated rights.

@jrserapio - The root account still has full rights to do anything even when in this state since it doesn't rely on the local admin group for its privileges. You would need to be able to log into the Mac under a root account or somehow open a root shell. One way might be to boot into Recovery HD and run some commands to enable root, or even run the commands from Terminal that recreate the group. Only possible issue is that Recovery HD is a very limited environment. I recently discovered that 'nano' and a few other tools for example don't exist while booted into Recovery HD.

In my case, I examined several Macs in this state and several unaffected Macs and was able to get a script together that can be run by the root account that recreates the local admin account. Its somewhat tricky mind you, and I'm not even sure the script I have put together would work in any other environment since the group UID and other items might be different.

single user mode if no FV2 or firmware password. May have to start directory services manually first, though...

We had this problem some years ago but no longer see it now that we've added the exclusion. I was able to dig up an old wiki article in Evernote from when we were having this issue that had the steps we used to fix it (being a packrat pays off now and then). Keep in mind this was from 10.5 and 10.6 days (a LONG time ago) so take it for what it's worth.

------------------------------

Old instructions (use with caution, test, test, test, etc.)

1. Boot off of a Leopard install Disc, this could be the disc that comes with the MacBook, or an external firewire drive.

2. When it boots up, select continue. Then at the top there is a MENU thats called UTILITIES, select that and choose CHANGE PASSWORD UTILITY.

3. Choose from the drop down menu “Systems Administrator (root)”, and change the password to something you can remember.

4. Restart the Machine and log in as root.

5. Open Terminal and run this command: dscl . read /groups/admin

If you get this error, then you need to run one more command <dscl_cmd> DS Error: -14136 (eDSRecordNotFound)

1. Run the following command from Terminal: cp /System/Library/DirectoryServices/DefaultLocalDB/Default/groups/ admin.plist /private/var/db/dslocal/nodes/Default/groups/admin.plist

2. After this is done, restart the computer, and log back in as ROOT one more time.

3. You should be able to make the local user an administrator now, from System Preferences - Accounts. After that restart and allow user to log in and confirm.

Then disable root.

---------------------------------

Again, old notes but may be useful for some.

Posting to confirm similar issue, environment and related issue.
We weren't not seeing high frequency of missing admin(80) group, but it sure was annoying...

Missing admin(80) group:
We use McAfee Endpoint Protection for Mac v2.1.0 (w/ Anti-malware v9.6.0) and we had our security team add exclusions for /private/var/db/dslocal/nodes/Default/.* in ePO in order to prevent groups and users from getting corrupted during various local scans (per @noah_swanson OP). We could've been more specific, e.g. ./groups, ./users, but wanted to prevent McAfee from affecting other entries. This seems to have prevented the issue from occurring, as we haven't seen the issue since implemented.

If damage is already done:
@tanderson post still applies; Basically, check whether admin(80) group exists and restore copy from template, if missing. Note: instead of booting into single-user mode, etc you maybe able to use ARD "Send UNIX Command" (as root user) to perform copy template tasks, etc.

A related McAfee note re: UID 499...
We discovered the McAfee installer may conflict w/ accts using UID 499 (common for hidden local admin accounts). In these cases, the admin(80) group still exists, but your local admin acct is missing from membership. To avoid this, use a different sub 501 UID—other than 499, since McAfee won't likely change their installer, etc.

Hope this helps someone

Here's a tip for recreating the admin group remotely if the Mac is still communicating with JSS.

Using suggestions from here and @rtrouton, I created a new policy scoped only to my problem Mac, checked everything for triggers, with this combo-command in ​Files and Processes:

cp /System/Library/DirectoryServices/DefaultLocalDB/Default/groups/admin.plist /private/var/db/dslocal/nodes/Default/groups/admin.plist && dseditgroup -o edit -a localadminaccount admin

That recreates a fresh admin group and adds localadminaccount back into the admin group.

You can wait for the next check-in or have the user disconnect/reconnect network to initiate the policy.

@SmithersJr Thanks for this suggestion was able to use it to correct a system which no accounts could authenticate as admins. Was much simpler then trying to boot into single user mode and trip the new user setup wizard