Skip to main content

What’s the best way to do this. Apple pushed out the fix just now. How can I tell which of my Macs has installed it?

For anyone looking for standalone, it's there, but takes some digging (as in, it's not featured): https://support.apple.com/kb/DL1942?viewlocale=en_US&locale=en_US


FWIW, a 2017 MacBook Touch ID model laptop is showing 17B1003, in case anyone is using build number to determine if the fix is applied.


Has it broken the ability to create an admin account for anyone else?


Yep, it's broken for me as well:


Agree, since installing the second release of the Security Update 2017-001, which results in 10.13.1 build 17B1003, our local admin account can not create standard or admin accounts via System Preferences >> Users & Groups.
Also fails when logging in with a mobile (AD) Admin account and trying the same steps to create an account.

Both types of accounts can be successfully added using Casper Remote (9.101.0).


FWIW I am able to create a new admin account after the patch.


@donmontalvo How come I can never see the build number in my "About This Mac" windows?

@rich.thomas I can't create an admin user through the System Preferences either, but I was able to login with an LDAP account that's in the admin group and it made the account an admin. So it appears to be just something with the GUI.

What are people installing to get 17B1003? I've re-downloaded 2017-001 for 10.13.1 and it still installs 17B1002. The other 2017-001 update only works for 10.13.0 it appears.


@PhillyPhoto you have to click your mouse on the Version number to see the Build number.


@grahamrpugh I learned something new today!

On a side note, the App Store update brings it to 17B1003, but not the dmg download.


To those having issues creating admin accounts (@rich.thomas, @PhillyPhoto, @adhuston), I had the same issue at first but it worked normally after a reboot. Have you tried that already?


It does appear this update required a reboot afterall for the create new accounts to work.


@irobinso The reboot worked for me.


The receipt for the second update is com.apple.pkg.update.os.10.13.1Supplemental.17B1003. I'm not sure if there is a separate update for 10.13 (meaning, if the update installer is unique to 10.13 with a unique receipt name) as I haven't seen a 10.13.0 machine with any comparable receipt listed so far. If someone has a 10.13.0 machine that has gotten a security update and wants to share the receipt name I'm sure that'd help folks out.


From what I can see on my 10.13.0 machines the receipt is com.apple.pkg.update.os.10.13Supplemental.17A501.


Not sure if it's been mentioned elsewhere already, but in case not, the 10.13.x patch (Build 17B1003 for 10.13.1, Build 17A501 for 10.13.0) can be downloaded from here https://support.apple.com/kb/DL1943?viewlocale=en_US&locale=en_US

The pkg itself is labeled "macOSUpd10.13Supplemental.pkg" as opposed to yesterday's earlier version which was "macOSUpd10.13.1Supplemental.pkg"

I'll be testing it out shortly on some 10.13.x systems.


@mm2270 When I run that second package on a 10.13.1 device with 17B1002, I get the following error:

This package runs fine on 10.13.0 but doesn't change the build version at all. It does appear to change the opendirectyd utility as described here: https://support.apple.com/en-gb/HT208315.

I've created an EA (see below) based on the above link to check the version number of opendirectoryd since the inventory doesn't collect this information. I have created a FR for this though.

#!/bin/sh
# note: the " " before PROGRAM below is a tab, not a space.
VERSION=`what /usr/libexec/opendirectoryd | grep " PROGRAM" | awk '{print $2}' | sed 's/PROJECT:opendirectoryd-//g'`

echo "<result>$VERSION</result>"

If you've noticed that you are unable to add admin accounts after this update without a reboot, and you have some kind of support agreement with Apple, or want to file a RADAR, please do. This seems to be news to them based on our interactions and I think more customers reporting the issue will help them get it on their… radar?


So I run the update software policy on a 10.13.1 computer and it updated the computer to build 17B1003. Then had the policy run a couple more times and it acts like the computer is up to date. From what I understand 17B1003 should fix the root issue. But I can still use root sans password to unlock admin rights. Am I missing something here?

Here is a link to my video.

[https://photos.app.goo.gl/TloVSLBHkr2vZIXy2](link URL)


@lpadmin, if you tried out the bug previously, I think it enabled root with a blank password. I don't think the update addresses that, just the bug that allowed it to happen. So you might be testing it now and it works because the root account is active, not because of the escalation bug.


@alexjdale The article for the fix implies the opposite:

"If you require the root user account on your Mac, you will need to re-enable the root user and change the root user's password after this update."


Ah yeah, you are right about that. I'd consider that to be a problem then, but we're pushing root password changes because this can't happen again, ever. Or else it's shame on me.


@PhillyPhoto Thanks for the follow up. It looks like I was mistaken. The "10.13Supplemental" patch seems to be ONLY for 10.13.0 systems and yesterday's "10.13.1Supplemental" is ONLY for 10.13.1 systems, just as the names actually imply. I was under the impression the 10.13 one would work for both, but it does not. I just tried installing it on an un-patched 10.13.1 machine and I get the same error.
Running yesterday's 10.13.1Supplemental patch on it works though.

It updated the Build on my 10.13.1 test Mac to 17B1002. I have to see if I have a 10.13.0 machine I can access to run the patch against to see how the build reflects afterward.

I don't know why Apple wasn't able to issue a single patch to handle both versions of the OS, but oh well. I get the distinct impression this entire thing was seriously rushed out the door.


Happening to me too...<expletive expletive>!!

I've filed a ticket with Enterprise Support to add our names to the list...


UPDATE - Support got back to me right away, saying 1. they're tracking the issue, and 2. You can fix it by rebooting.


Yeah, I can confirm that a reboot is needed to get back the ability to create admin accounts in the GUI. I just get a System Preferences error and it exits out of Sys Prefs otherwise. It's only a GUI issue though. You can still create an admin user using sysadminctl FWIW.