Unable to change management password with dollar sign ($) in password

[stevewood]

Not sure if anyone else has seen this or not, and I have not filed a support request with JAMF yet. We use a policy to spin the management account password to something we set. We generate this password every 90 days at a different office.

The latest password has a dollar sign in it. When using a policy to spin the password, the policy completes normally, but the password is not changed. This is occurring on version 9.63 of the JSS.

Anyone else seen this behavior?

[Sonic84]

how are you applying the password? A script attached to a policy or a run unix command? The dollar sign has special meaning in Bash and needs to be preceded with a "" or single quoted ' ' to tell bash to not expand it during execution.

I have a similar management account on all workstations, however password rotation is required every two weeks. The workflow my team uses is to use an old copy of Recon 8.32 to create a quickadd package. We then then extract the account creation command from the resulting PKG's postflight script. This results in a bash command that creates the management account, or replaced the password if it already exists. It command is then added to a policy as a run unix command. Because the actual password is encoded in a predictable format and in a format the JAMF binary understands, there is no chance of a special character like a dollar sign throwing off the execution. This method has some obvious security/scaling issues, but meets the requirement of the current password not being in plain text, repeatable, and reliable.

[stevewood]

I should have been more clear in my post. @Sonic84 I'm using the options in a policy under Management Account "tab" to "Specify New Password". This is how I've done it in the past. And I don't think I can encapsulate the password in slashes or quotes (single or double) via the policy tabs.

I know I can use a script or QuickAdd to do this, but I've alway done it using the policy method. It's nice and simple and just requires changing the password in the policy and flushing the logs. Easy peasy lemon squeezy. :-)

[stevewood]

And one more thing. I believe this was working in 9.62, because I have a few machines that the password change took effect on, and those were ones that ran before I upgraded to 9.63.

[Brad_G]

That's interesting.

I have a bug report in with our acct mgr on something similar. We noticed a Quick Add package with Recon that had a $ in the password would also cause issues. 9.62 didn't seem to have issues. I haven't updated our test environment yet to see how 9.64 behaves. Looks like tomorrows project.

[joecurrin]

Haha I remember yelling at a few employees over this a few years back. I defer to the rule don't use "$" in passwords. They don't play nice. My suggestion is to script it or change the password. I scripted it with just use the backslash before the $.

[alexjdale]

Ugh, yes, we just upgraded to 9.63 over the weekend, and I am seeing this issue too. It was working fine in 9.61, hopefully it's fixed in 9.64 so I can do an emergency upgrade.

I can verify this because we just changed a password that is managed by this feature about a month ago, and it contains a $ (not the management account password, a local account). Passwords that have already been set are OK, but the feature simply is failing to change the password now.

[nkalister]

Just FYI, I've got a ticket open with JAMF support about an issue with changing management passwords in 9.63- if the policy is set to create a password of the maximum length, it ALSO fails to change the password.
For now, we've switched over to generating a random password using openssl.

[stevewood]

I heard back from support this morning, and this is a known issue with an open defect (D-008512). I'm going to get around it using a QA package since that will update the JSS with the appropriate info and is nice and easy to complete.

[ericjboyd]

This is also in play if you have a policy to randomly generate new passwords. If the random password has a $ character in it, connecting via casper remote will fail.
I confirmed this bug with the support staff yesterday. Their recommendation was to switch from a random password to a static password without a $.