Posted on 03-09-2017 12:25 PM
I just wanted to post this here so if the next person runs into this, who is not a MySQL expert (like myself), they won't get stuck for a few hours like I did :-)
So I'm in the process of setting up a brand new JSS environment that will include an application server in the DMZ. Because of this, I'm trying to make sure that things are "more secure", including the step of not using the default jamfsoftware database MySQL password that's been listed in the setup guide for many years.
It turns out that if your MySQL password has special characters in it (we use a random password generator), then some commands that include the password will not execute properly - I guess the password is not passed along properly when it hits the special character(s). This includes some of the commands that are used by the JSS Database Utility. Once I switched to a custom MySQL database password that used just letters and numbers, the issues with issuing certain commands via a script or via the Database Utility disappeared. Once I figured this out, I was able to setup the nightly backups with the Database Utility.
If you have a testing environment, feel free to try this out yourself by changing the database password to something with special characters, and then try configuring the Database Utility to connect. Chances are you'll get some of the following errors:
The two that I saw were:
"Utility Error: Failed to remove backup schedule:"
and
"Unable to connect to database: Warning: Using a password on the command line interface can be insecure.ERROR 1045 (28000): Access denied for the user 'jamfsoftware'@'localhost' (using password: YES)"
Please make sure that the MySQL server is running and that a firewall is not blocking the JSS Database Utility."
As always, your mileage may vary. :-)
-Ted
Posted on 02-26-2019 05:06 AM
Ouch, just come across this and hoping (but not holding breath) that things have changed since. Otherwise, would imply that certain of the applications/scripts including JSS Database Util are not correctly quoting/sanitising password entry and thus have potential for exploitation with SQL injection... little Bobby drop tables;
Comment from JAMF on this please?