Remove password of user on OSX

Question

What's the purpose of having a business vault when we can apply business rules while building information marts?

Solution 1

I think the problem you're having with @Daniel Beck's answer is that the password isn't stored in the user record's Password attribute, but as a shadow hash file in /var/db/shadow/hash/USERGUID, and the AuthenticationAuthority attribute still points to that. This seems to work for me:

sudo dscl . -delete /Users/buildbot AuthenticationAuthority
buildbotGUID=$(dscl . -read /Users/buildbot GeneratedUID | awk '{print $2}')
sudo rm "/var/db/shadow/hash/$buildbotGUID" "/var/db/shadow/hash/$buildbotGUID.state"

Ideally, you should also remove the account's Kerberos principal (OS X clients run their own "local" Kerberos realm, and it occasionally gets underfoot). But that's a bit more complicated, and I think depends a fair bit on which version of OS X you're using.

BTW, if the above doesn't completely do the trick, try this:

sudo dscl . -create /Users/buildbot AuthenticationAuthority ";DisabledUser;"

Solution 2

You need to set the password to a single * character (asterisk, star) using dscl.

sudo dscl . -create /Users/buildbot Password '*'

Be sure to escape or quote (as shown) it so it doesn't get interpreted by your shell.

This will (when read) not be displayed as ******** like any other password, but as *, which just means "no password".

Comments

[Canadian Luke]

I'm confused: you want them to not have a password, but not have a blank password?

[nlucaroni]

yeah. I guess the same affect may be having a blank password and locking the account? (from looking around,unix.stackexchange.com/questions/7283/…). Would this be correct?

[Canadian Luke]

That looks right, but I didn't quite understand your question based on wording alone. I would recommend editing it to say so, and if that is the answer, paste what was said and give credit as an answer

[nlucaroni]

No it's not right for OSX; passwd -l is for location not lock. I edited the question accordingly. Does it need further clarification? I thought I was being pretty precise.

[Canadian Luke]

My confusion came from your second sentance, that's all. And the OSX part is what drew me in, but I don't use dscl to make users, I use the GUI part

[HikeMike]

What version of OS X is this? Can you reproduce this behavior of being unable to delete the Password entry with a new account created using System Preferences?

[HikeMike]

Are you ignoring dscl program output? That last command, change, has a different syntax. The page of error output should tell you...

[nlucaroni]

I'm sorry, I mistyped, it should have been create.

[HikeMike]

Just curious, what's the output of dscl . -read /Users/username for a user that was entirely created using the GUI?

[HikeMike]

Can you reproduce the behavior with a new user account just created using System Preferences?

[nlucaroni]

As much as I would like to figure out the problem, at this point too much time has been invested in deleting a stupid key when I already had a solution (the command line creation) that works. I'm going to delete the user and run the commands that I need. It would still be wonderful to have an answer, but I don't think that is going to happen.

[nlucaroni]

This did not update the password; after executing the command I can still use the old password. is it possible that it should be -change instead of -create?

[HikeMike]

@nlucaroni Did you -delete /Users/buildbot Password before executing that line? My reference starting point was the code in your question, which didn't mention creation of a password.

[nlucaroni]

No, I did not delete anything; I thought you were referring to my earlier made accounts. Do I have to do this to the newly created account through the command line? It appears to be doing what I want without setting that key at all.

[HikeMike]

@nlucaroni Now I understand what you mean. It's difficult with multiple questions combined into one. Run dscl with the arguments in my earlier comment first to delete the old password, then set the new one to '*'. -change might work, I haven't tested it myself though. What do you mean by without setting that key at all? What's the output of dscl . -read /Users/buildbot Password?

[nlucaroni]

I deleted the key, and then created one as you prescribed on the machines with accounts that already had passwords, but I can still log in with the old account password. I am guessing I'll have to restart the box? (I cannot do it now to test this). "without setting the key" was referring to my account created via the command line by the commands I listed above, that one seems to be working fine without setting a key or needing to set it to '*'.

[HikeMike]

@nlucaroni Cannot reproduce. If I set the password through System Preferences (it's an account created through the GUI), I can e.g. su to that account using the password I set. Then I just sudo dscl . -create /Users/name Password '*' and su fails. How are you logging into that account after removing the password? Remember that root can su into any account, and e.g. SSH keys will still work to authenticate SSH clients.

[nlucaroni]

Delete isn't deleting the key. when I read the value on the machine that never had a password set I get the expected, no such key. but when I run the command on the other box, after a delete, i get '*****'.

[nlucaroni]

I open a new terminal (to avoid sudo permissions still active) and using su

[HikeMike]

@nlucaroni su doesn't use sudo, they are completely independent. su asks for the target account's password, sudo for your own. Don't use sudo su, just run su buildbot to get queried for buildbot's password.

[nlucaroni]

yeah i know what the difference is and I didn't use sudo su. I meant, since sudo was used to change the keys, the terminal still was unlocked. I guess it doesn't matter since I didn't use sudo anyway in the command, I was just being 100% sure since I'm not a usual OSX user.

[nlucaroni]

Disabling the account is functionally equivalent to locking it?

[Gordon Davisson]

Mostly; there are probably some subtle differences. Note that the "disabled" setting is in the AuthenticationAuthority attribute, so generally it only disables authentication, not other account functions. I don't know enough about buildbot to know this will interfere with it.

[Fictional]

Thanks a lot, @tobi6.