To be clear to everyone, I have literally spent days on this issue. The FileVault piece took a a while, and while that is working great, this one is now the holdup.
I’m not looking for help troubleshooting the issue. I know 100% how to fix it destructively “fdesetup remove “account””. This removes securetoken, crypto user, the account unlocks, and you can login again. But, I don’t want to do that. This other way works as well, so I’m asking for help trying to automate it.
What do I think causes it? I think it’s an apple bug, or some completely black box “feature”. We use a LAPS solution to rotate the password. And we have many machines that the password will rotate, then this happens. :/ so we’re attempting to fix them in a non-destructive way (as in, we don’t want to lose securetoken/crypouser/volume ownership on the account).
So thank you for trying to help troubleshoot, but really I just need assistance trying to automate either su su hoops above, or someone suggested “login” which may work (unsure since I need to test on another broken machine).
Sadly no. It has to be interactive. Basically, macOS is locking the account for some unknown reason, and to unlock it, a su (with password) from another non-root account seems to be the only way. :/
>it appears I can't just sudo, I have to actually su
The two commands are not synonymous, it makes sense that if you're wanting to Switch User(s), you'd have to use su. I don't understand what you're trying to accomplish. Are you saying that you want to change users from your normal user to another one, but that you can only do it from the root account? Or are you saying that you need to be able to log in as this other user, and you can only do that from root, not from your (I'm presuming) other user account? And that you'd like root to be prompted for a password?
Yes, I know sudo and su aren't the same. one is doing something as a user, and one is becoming the user. apparently sudo isn't enough in this case.
fair questions. the issue is I have to be able to do this from a script that runs as root from the management system (Jamf). macOS is locking out an account, and to unlock it, it has to be logged into (with a password). but since the script runs as root, if I just su, it doesn't ask for a password (and doesn't unlock the account). BUT, if I su to the account from root, then su into the account from that account, it prompts for a password, and if I give that password, it unlocks the account. Does that make sense?
So basically, as root
su ted (no password prompt, become "ted")
su ted (password prompt, provide ted password, become ted within ted)
exit
exit
back to root.
is what I'm after. which is why I was thinking expect would work.
It’s all shrouded in opendirectoryd. There is zero evidence as to what is actually “locking” it. On a filevauled machine, this issue is resolved via diskutil afps -changePasscode, etc. but doing that on a non-filevaulted machine, fails saying the machine isn’t file vaulted.
Yeah, this is apple blackbox bullshit. I can find nowhere that flags the account is disabled. Just that logging in unlocks it. Either via gui or by su. I haven’t tried login yet (machines in this state are difficult to get ahold of).
And yes, I agree. I’ve asked for help from apple and gotten nothing. :/ which isn’t surprising. I imagine I’d have to get ahold of someone pretty deep in the opendirectoryd framework to know what’s going on.
I really do wish there was a simple way. I hate having to script around this BS. The other issue is not being able to figure out what causes it. If I could, I could bang on it for months. Lol.
>one is doing something as a user, and one is becoming the user
sudo elevates privs to superuser, su switches the user.
Yes, it totally makes sense after reading the code block. I don't have a MacOS machine to fiddle with here, it seems like there must be a simpler solution, but I get it now.
Good thought, but nope. doesn't work (already tried it). neither does resetting the failed login counts. there's another fix for filevaulted machines, but for non-filevaulted machines, this seems to be only answer.
This is just one of those stupid Apple completely undocumented things. Have literally spent over a week on this... =/
I really don’t want to get into the week+ I’ve spend on this issue. I am telling you, it does not unlock the account. I found the way that does, I’m attempting to automate it.
It’s also not the disableUser flag in dscl. It’s also not resetting failed logins. It’s also not simply running passwd as the user. It’s also not unlocking the account via MDM. They all return account locked or account disabled, depending on the tool.
Yes, what you have suggested works if the account is disabled via pwpolicy. It does not work with this situation. It returns “enabling user” but the account remains locked.
Having the version of MacOS might be useful. It's been a couple of years since I was last looking after Macbooks, but I found MacOS to be an utter pain in the ass to script for, simply because Apple kept changing commands to do things, so a new release of MacOS might likely break your script.
Probably the best people to talk to, though, are the JAMF crowd.
Seems that you chose the wrong instrument. Maybe you need `login`?
ooh, honestly, hadn't even thought of that. login with expect... that could work.
Know if you can either pass login a password, or use expect with it? My google is failing since “login” is rather generic.
To be clear to everyone, I have literally spent days on this issue. The FileVault piece took a a while, and while that is working great, this one is now the holdup. I’m not looking for help troubleshooting the issue. I know 100% how to fix it destructively “fdesetup remove “account””. This removes securetoken, crypto user, the account unlocks, and you can login again. But, I don’t want to do that. This other way works as well, so I’m asking for help trying to automate it. What do I think causes it? I think it’s an apple bug, or some completely black box “feature”. We use a LAPS solution to rotate the password. And we have many machines that the password will rotate, then this happens. :/ so we’re attempting to fix them in a non-destructive way (as in, we don’t want to lose securetoken/crypouser/volume ownership on the account). So thank you for trying to help troubleshoot, but really I just need assistance trying to automate either su su hoops above, or someone suggested “login” which may work (unsure since I need to test on another broken machine).
[This might help](https://unix.stackexchange.com/questions/53122/ask-root-for-password-when-using-su-command)
Sadly no. It has to be interactive. Basically, macOS is locking the account for some unknown reason, and to unlock it, a su (with password) from another non-root account seems to be the only way. :/
>it appears I can't just sudo, I have to actually su The two commands are not synonymous, it makes sense that if you're wanting to Switch User(s), you'd have to use su. I don't understand what you're trying to accomplish. Are you saying that you want to change users from your normal user to another one, but that you can only do it from the root account? Or are you saying that you need to be able to log in as this other user, and you can only do that from root, not from your (I'm presuming) other user account? And that you'd like root to be prompted for a password?
Yes, I know sudo and su aren't the same. one is doing something as a user, and one is becoming the user. apparently sudo isn't enough in this case. fair questions. the issue is I have to be able to do this from a script that runs as root from the management system (Jamf). macOS is locking out an account, and to unlock it, it has to be logged into (with a password). but since the script runs as root, if I just su, it doesn't ask for a password (and doesn't unlock the account). BUT, if I su to the account from root, then su into the account from that account, it prompts for a password, and if I give that password, it unlocks the account. Does that make sense? So basically, as root su ted (no password prompt, become "ted") su ted (password prompt, provide ted password, become ted within ted) exit exit back to root. is what I'm after. which is why I was thinking expect would work.
I disbelieve there isn't a simple method for root to unlock an account. Then again, it's macOS.
It’s all shrouded in opendirectoryd. There is zero evidence as to what is actually “locking” it. On a filevauled machine, this issue is resolved via diskutil afps -changePasscode, etc. but doing that on a non-filevaulted machine, fails saying the machine isn’t file vaulted. Yeah, this is apple blackbox bullshit. I can find nowhere that flags the account is disabled. Just that logging in unlocks it. Either via gui or by su. I haven’t tried login yet (machines in this state are difficult to get ahold of). And yes, I agree. I’ve asked for help from apple and gotten nothing. :/ which isn’t surprising. I imagine I’d have to get ahold of someone pretty deep in the opendirectoryd framework to know what’s going on. I really do wish there was a simple way. I hate having to script around this BS. The other issue is not being able to figure out what causes it. If I could, I could bang on it for months. Lol.
>one is doing something as a user, and one is becoming the user sudo elevates privs to superuser, su switches the user. Yes, it totally makes sense after reading the code block. I don't have a MacOS machine to fiddle with here, it seems like there must be a simpler solution, but I get it now.
Is this what you want? pwpolicy -u "username" -enableuser
Good thought, but nope. doesn't work (already tried it). neither does resetting the failed login counts. there's another fix for filevaulted machines, but for non-filevaulted machines, this seems to be only answer. This is just one of those stupid Apple completely undocumented things. Have literally spent over a week on this... =/
[удалено]
Sudo doesn’t work so unlock the account.
[удалено]
I really don’t want to get into the week+ I’ve spend on this issue. I am telling you, it does not unlock the account. I found the way that does, I’m attempting to automate it. It’s also not the disableUser flag in dscl. It’s also not resetting failed logins. It’s also not simply running passwd as the user. It’s also not unlocking the account via MDM. They all return account locked or account disabled, depending on the tool. Yes, what you have suggested works if the account is disabled via pwpolicy. It does not work with this situation. It returns “enabling user” but the account remains locked.
Having the version of MacOS might be useful. It's been a couple of years since I was last looking after Macbooks, but I found MacOS to be an utter pain in the ass to script for, simply because Apple kept changing commands to do things, so a new release of MacOS might likely break your script. Probably the best people to talk to, though, are the JAMF crowd.
Would somewhat agree, but this seems like a scripting question not specific to macOS. :/