Error: The Managed Account Password could not be reset

[jondowd]

After our helpful discussion from earlier today, I have attempted to create a policy that will spin a new Management Account Password once a day. I went to Management > Policies > Create policy manually > General - named it, Category=No Category, Triggered By=The Every 15 Trigger, Execution Frequency=Once every day. Accounts - Change Management Account Password, Randomly Generated Passwords, Number of characters-12. Then I pushed that out to one test machine and got the error in the subject line above. Did I leave something out?

[mm2270 · Accepted solution]

Are you still running into this problem?

I just ran a quick test on my JSS, using the same settings as you have above, scoped to one Mac and forced it to run using the every15 trigger and it was successful. If its not working for you, have you attempted to run it against other Macs? I suspect something may be up with your management account.

The other thing is, give us a run down on your JSS, i.e, OS its running on, version of the JSS, etc. And are you using certificate based communication?

EDIT: Something else just occurred to me. When you say you "pushed that out" do you mean you tried this through Casper Remote, or were you doing a 'sudo jamf policy -trigger every15' on the Mac itself? If you haven't tried it on the Mac with the above, give that a shot to see if it works.

[jondowd]

When I said I 'pushed this out' I meant I created a policy with a scope of one machine. Since I had several iterations of QuickAdd packages since we began testing, I was unsure of just exactly how the computer in question was collected, so I thought to run a fresh QuickAdd package once again and then re-run the policy. This time I was successful. Thank you for your helpful reply. I appreciate this forum very much.

[mm2270]

Great, glad to hear its working now. Hopefully that helps you out when talking to your boss about the management account.

[yellow]

This has re-appeared for me suddenly after updating the Casper 9.8 on multiple devices in multiple locations.

[yellow]

Executing Policy Security: Change admin password...

There is a problem with your syntax.

     Error: The operation couldn’t be completed. (com.jamfsoftware.core.errors error 36.)

Type "jamf help" for more information.

    Error: The Managed Account Password could not be reset.

So I just started getting this for an unknown reason. This is a very simple policy that simply that only does:

Reset Password for Management Account to Specified Password

But for some reason it stopped working on some devices and it's not clear why. Failed on (some 30 clients now):

10.10.5
10.9.5
10.7.5

All running the 9.8 client. Burt it's worked on 10.9.5 and 10.10.5 and 10.11, etc.

However it works on many of them.. the majority of them. Tried creating a new policy as this one was inherited from 8.* era Casper. Still no dice.

EDIT I think I know why it's doing that.. when trying it manually our password contains 2 bangs and I think the shell is interpreting it as a 'previous command', as normal. Pretty sure this is the issue. In trying to manually do the command "jamf resetPassword" etc... I see the shell interpreting the !!s from our passwords as previous commands and filling that in. The error I see as an output int he shell exactly matches the errors I see in /var/log/jamf.log.

As such I've opened a support ticket with JAMF since this is quite strange, especially since MacA with 10.10.5 might work fine and MacB with 10.10.5 does not.

[bollman]

Just chiming in that we see this too. Randomly, computers cannot reset the password. We have a policy running every month to randomize the password, but ever so often it fails.
Before 9.8 it was the odd one that probably closed the lid in the midst of the policy running, but since 9.8 it's more or less 50-50 if the policy fails or not.
Could it be the randomization that uses "wrong" characters?

[bollman]

A little more research gives this:
On a computer where the reset works, it always works, and on computers where it fails, it always fails no matter how many time you try.
Running jamf policy -verbose on a non-working computer gives this:

Executing Policy name_of_policy...

There is a problem with your syntax.

Error: The operation couldn’t be completed. (com.jamfsoftware.core.errors error 51.)

Type "jamf help" for more information.

Error: The Managed Account Password could not be reset.
Submitting log to https://jss.example.com:8443/

To me, it looks like the randomization part of the policy puts wrong characters into the password and store it in the database and whenever the policy tries to set the password it fails due to non-escaped characters. Strange though that it does not help to run the policy again, it should generate a new password?

[lkrasno]

Seeing this also after upgrading to 9.81, and we're just rotating a fixed password

bash-3.2# jamf policy -id 2 -verbose
verbose: JAMF binary already symlinked
verbose: JAMF agent already symlinked
verbose: Checking for an existing instance of this application...
Checking for policy ID 2...
verbose: Checking for active ethernet connection...
verbose: Active ethernet connection found...
verbose: The Management Framework Settings are up to date.
verbose: Found 1 matching policies.
verbose: Removing any cached policies for this trigger.
verbose: Parsing servers...
verbose: Parsing Policy Rotate Managment Password (2)...
verbose: Parsing Policy Rotate Managment Password (2)...
Executing Policy Rotate Managment Password...
There is a problem with your syntax.
Error: The operation couldn’t be completed. (com.jamfsoftware.core.errors error 51.)
Type "jamf help" for more information.

[yellow]

So I put a bug into JAMF with this error and they're working on getting it fixed (D-009757).

It's something in the Keychain folder of your (our) management user. To date, I've not really figured out which.

One some clients it's the login.keychin. On some clients it's the hex-named-folder (Local Items junk, I think?).
On one client, it was the hidden .fl####### file. At least, that's all I removed.

So, at this point I go with the nuclear option and just removed all the contents of this folder, since they don't really matter to me. After removing this, flush failed the account update policy and the next time it runs, it should succeed.

[ktappe]

This problem suddenly started happening to us too, within an hour of updating from 9.72 to 9.81. Casper Remote still works, which indicates the management password is stored correctly in the JSS and is retrievable. That points to it being a bug with the 9.81 binary.

Using clues from this thread, we made a package containing the 9.72 binary with do_not_upgrade_jamf set to TRUE in /Library/Preferences/com.jamfsoftware.jamf.plist. We removed the 9.81 binary and deployed this to our clients, and the problem went away.

I'm not necessarily advocating running an older binary with the newer JSS. But in our case our company's security policy requires we regularly enact password randomization, but we also had to keep 9.81 so we could start deploying El Capitan*. YMMV.

* Yes, we'll have to use the 9.81 binary & no password change policies for any 10.11 Macs...

[tangerinehuge]

I'm seeing this problem too. Any updates on the bug?

[yellow]

Nope.
I added a policy to do a "rm -f /private/var/our_management_account/Library/Keychains/." that appears to be helping as well.

[tangerinehuge]

Our systems don't appear to have the Keychains directory.

[yellow]

The directory must be there for your management account...
When logged into the management account, what is in ~/Library/Keychains/ ?

[tangerinehuge]

We never login using our management account. It has a randomly assigned rotated password and is only used by the JSS.

[steveevans]

I have this problem as well I'm noticing. v9.81. 61 managed computers, I have 4 seeing this issue.

When running the policy manually I see:

verbose: JAMF binary already symlinked verbose: JAMF agent already symlinked verbose: Checking for an existing instance of this application...
Checking for policies triggered by "recurring check-in"... verbose: Checking for active ethernet connection... verbose: Active ethernet connection found... verbose: The Management Framework Settings are up to date. verbose: Found 1 matching policies. verbose: Removing any cached policies for this trigger. verbose: Parsing servers... verbose: Parsing Policy Randomize Management Account Password (122)... verbose: Parsing Policy Randomize Management Account Password (122)...
Executing Policy Randomize Management Account Password...

There is a problem with your syntax.

Error: Credentials could not be verified, username or password is invalid.

Type "jamf help" for more information.

Error: The Managed Account Password could not be reset.

Policy running fine everywhere else, also on machines enrolled at the same time as problematic machines.

[steveevans]

Well.....i got this to work, but had to do the following:
- Remove machine from JSS
- Removed JAMF framework
- deleted management account via terminal
- enroll machine again via web enrollment
- add machine to proper departments/buildings/etc.

[yellow]

For us, our management account at the time ended with 2 bangs (!!). As most of you know, in the unix world, that means 'last command'. So when I would get the error "There is a problem with your syntax" and would try it manually using "jamf resetPassword", I would see that our password would get mangled and the !! would be interpreted by the shell as the previous command, which is what prompted me to open a ticket with JAMF in the first place. Luckily, the number of devices that were effected like this were sub-25. All the others just had failures for login.keychain reasons (so far). I did the same thing for the 25 as @steveevans did, though I left the management account (with no issues).. but I did it as a script.

This is based on/forked from @rtrouton's (always) fine work. Effectively, I host a current QuickAdd.pkg on an accessible web server, I login on the effective device remotely using the management account, I escalate myself to root status, and then run this script that I've pre-staged on all devices within the management account's home directory:

#!/bin/bash

qaURL="http://website.ourlocation.edu/QuickAdd.pkg.zip"

if /sbin/ping -oq jss.ourlocation.edu &> /dev/null

    then

    /bin/echo "grabbing package"
    /usr/bin/curl --silent --output QuickAdd.pkg.zip "$qaURL"

    /bin/echo "unzipping package"
    sudo unzip QuickAdd.pkg.zip -d .;sudo rm -rf __MACOSX

    /bin/echo "updating time"
    sudo ntpdate -u $(systemsetup -getnetworktimeserver|awk '{print $4}')

    /bin/echo "removing jamf framework"
    sudo jamf removeFramework -verbose

    /bin/echo "installing QuickAdd package"
    sudo installer -dumplog -verbose -pkg QuickAdd.pkg -target /

    /bin/echo "running a(nother) recon"
    sudo /usr/local/bin/jamf recon -verbose

    /bin/echo "installing CasperCheck"
    sudo /usr/local/bin/jamf policy -trigger installCasperCheck

    /bin/echo "flushing policy history"
    sudo /usr/local/bin/jamf flushPolicyHistory

    /bin/echo "running policy"
    sudo /usr/local/bin/jamf policy -verbose

else

/bin/echo "Can't reach Casper.  Quitting."

fi

exit 0

Note the "installing CasperCheck" portion (also @rtrouton's, and on which this is based, and a very useful piece of gear!) as an added sanity check. Link to this tool: https://github.com/rtrouton/CasperCheck

It grabs the package, unzips, updates the current time so there's no skew, removes the JAMF framework (de-enrolling it), installs the QuickAdd (re-enrolling it), recons, flushes any policies, and then runs all policies again.

This has been VERY useful for me to quickly de-enroll/re-enroll devices that aren't 'healthy'.

[steveevans]

NICE WORK @yellow I will be following your method for my remaining machines. Automation is our friend ;-)

[yellow]

Notice the change between "sudo jamf removeFramework -verbose" & later declarations of the full (new) path of the jamf binary. I found this was necessary on older devices where the jamf binary may not have yet been moved. Other missing path declarations are pure oversight/laziness on my part. :)

[donparfet]

I am experiencing this problem where the management account password rotation fails, and I have found that the solution is to:
1. delete the managment account
2. uninstall jamf framework
3. install a new quickadd package (tweaking @yellow script for my environment)

I have around 40 machines that are failing, and I am wondering it anyone has a suggestion how to create a smart group based on the policy failure log? So far in my searching in jamfnation I have come upon a feature request but nothing else so far...

[aamjohns]

This is becoming a prevalent issue for us. We've always used a randomized password for the management account. I am now seeing a number of machine that will not let us use Casper Remote due to authentication error. So I will trigger a policy to reset the password for the management account (usually the first thing I try). This always errors now. I get the error:

Credentials could not be verified, username or password is invalid. Error: The Managed Account Password could not be reset.

So I decided to do some troubleshooting along with Googling. I've scripted a procedure that creates a new management account, and deletes the old one. That works, and the account seems ok. Remoting will work. But since the script sets a known password, I decided to add the triggering of another policy to randomize the management account password. That fails. Verbose output says:

Error resetting password for <account>: the operation couldn't be completed. (com.jamfsoftware.core.errors error 51.) Error: The Managed Account Password could not be reset. Policy error code: 750

In this particular case the machine's OS is 10.11.3 and JAMF binary is 9.82

Policy works. This issue is not limited to machines with upgraded OS. Both clean or upgraded are exhibiting this behavior. I never had an issue with resetting the management account password until relatively recently, although I cannot say specifically when this started.

Also, I tried a policy where I set a known password rather than randomized. I am getting the same error with it also.

I have tried about everything I have found in the forum. In the end, I always end up with this error when attempting to send out a password change. I am just wondering if others have gone from 'just works' to this?

Thanks,
AJ.

-BTW - I just tried another policy used to reset a non-hidden administrator account on the Macs - it is the only local admin account other than the management that we create - and it worked.

[donparfet]

@aamjohns My experience was similar to yours. I have had best success with
- delete the management account
- uninstall jamf framework
- reinstall a new quickadd package which includes the management acocunt
I tweaked @yellow 's script for our environment to accomplish this

[aamjohns]

@donparfet ,
Hi, thank you for the response. I appreciate your instructions. I will give your suggestion a try. Thanks, AJ.

[benducklow]

Did any of you check to see if the password was actually changed? I was getting this same error

Error: The Managed Account Password could not be reset

message (when using the the Management Account payload and using a static new password), however I discovered that the password actually did change and does work! This was on v9.82.

UPDATE/ADDITIONAL INFO: I also confirmed that I can use Casper Remote without an issue. Seeing its a staticly assigned Management Account password, the JSS 'knows' what it should be. This looks to be a case of 'false positive' failures.

[aamjohns]

@benducklow,
I tested it and yes the password was changed. Since I went from a random password to a known password, I could test it.

[pmullins]

I've been banging my head against this one, off and on, for months. I have found some solutions, but nothing that works in every instance.
Here's what I have found/done so far, roughly in order from least to most intrusive:
NOTE: Each of these, or a combination thereof, has resolved the issue on at least one machine.

1. Verify the local account password for <admin account>. I do this via SSH.
   As has been mentioned, the password has usually been changed, even with the error returned.

2. If the password has not been changed, manually change the password for <admin account>.

3. Verify the password for <admin account> in Casper. On at least one machine, the password in Casper was still the old one. Changing it to the new one (after verifying the local PW) resolved the issue.

4. Re-enroll the machine
   Hey, worth a shot, right? Worked on a couple of machines.

5. Delete <admin account>/Library/Keychains/login.keychain
   Worked on a few machines. On another machine the Keychains folder didn't exist.

6. Delete and recreate <admin account>.

7. Delete and recreate <admin account>, making sure to delete the previous <admin account> User folder before recreating the account.

8. Remove machine from Casper. Delete and recreate <admin account>, making sure to delete the <admin account> User folder as well. Re-enroll. Cross fingers.

Obviously, I'm going to keep poking it with a stick. Hopefully this information will help others, and possibly enable someone to come up with a comprehensive solution.

[adolfsson]

@pmullins Bumping an old thread but we found a solution for this. You can delete the management account and then re-enroll but there is a better way:

Set a new password for the management account on the computer. Use sudo jamf recon with special flags to report the account password and name to the JSS. Now the accounts are linked and you can change the password with a policy.

Described more in detail here: https://www.jamf.com/jamf-nation/discussions/29518/managed-account-password-could-not-be-changed#res...