dscl delete + Mojave

[zinkotheclown]

Does anyone know if dscl -delete still works in 10.14 (Mojave)? I have a script that converts a local user to a mobile one and it requires the local account be deleted so i script a "dscl . -delete /Users/username" but all I get is "delete: Invalid Path" and "<dscl_cmd>DS Error: -14009 (eDSUnknownNodeName)".

However I have found that "sysadminctl -deleteUser username -keepHome" does work in 10.14 except for the last user with a securetoken.

[jmariani]

Just as a test...try granting /usr/sbin/cfprefsd full disk access in the new Privacy settings and then try running your scripts again.

[sshort · Accepted solution]

I've avoided dscl in Mojave and High Sierra, as it seems to strip secureToken from users that already have it when resetting a pw with that command. This has been working for me in Mojave:

sudo sysadminctl -adminUser AdminUserHere -adminPassword AdminPasswordHere -deleteUser UserToBeDeletedHere -keepHome

[Lotusshaney]

Dscl under Mojave has changed.

Deletes don’t work for everything. You cans update a UID or home location.

[dstranathan]

I agree with @Lotusshaney - The main reason I run dscl is to edit a user's homedir location and UID.

[alexjdale]

Just to add to this (it was sorta mentioned in the first post), there are limitations on some user actions, designed to address the "what happens if no user has a Secure Token?" issue. In later versions of 10.14, you cannot do anything that would leave the system without a Secure Token user. That includes deleting the last Secure Token user or forcing a password change for that user. It was a half-hearted effort to solve the problem, without actually solving it.

I'm curious what would happen in a DEP scenario where the only Secure Token user is the primary user, who happens to be a mobile user, if that user changed their password at the directory and tried to log in with it. Would they be able to log in, but not sync their local password? Or would they just be unable to log in at all?