Hallo Rolegat,
We had the same problem, seems like the problem was a xcode finalize script that does slmething with the auth.db file.
So check if that client has Xocde installed if so make a policy with a force restart and the option
Files and Process
mv /var/db/auth.db /var/db/auth.db.
Hallo Rolegat,
We had the same problem, seems like the problem was a xcode finalize script that does slmething with the auth.db file.
So check if that client has Xocde installed if so make a policy with a force restart and the option
Files and Process
mv /var/db/auth.db /var/db/auth.db.
Did you mean to copy it to itself or create a backup of it? Like:
mv /var/db/auth.db /var/db/auth.db.bak
yeah my bad
That did the trick....anyway to find out how the auth.db got corrupt?
In our case i was using a script to finalise our Xcode installation for our users that aren’t admin users by default. The script that we used in the past was this one:
https://github.com/franton/Xcode-Scripts/blob/master/finalise.sh
Looks like line 42 is breaking the shutdown/restart option for macos.
what did is created an EA to detect which machines were affected after that i created a policy with a force restart.
#!/bin/sh
# Check for "root-or-entitled-admin-or-authenticate-admin" in authorizationdb.
AuthDbSetting=$(security authorizationdb read system.install.apple-software | grep "root-or-entitled-admin-or-authenticate-admin")
#echo "$AuthDbSetting"
# If the $AuthDbSetting variable does not contain "root-or-entitled-admin-or-authenticate-admin" then the variable will have a string length of zero.
# If the $AuthDbSetting variable has a string length of zero, output "AuthDB setting is wrong".
# If the $AuthDbSetting does not have a string length of zero, output "AuthDB setting is AuthDB setting is correct".
if f -z $AuthDbSetting ]]; then
echo "<result>AuthDB setting is wrong</result>"
else
echo "<result>AuthDB setting is correct</result>"
fi
This is the EA we are using to detect if a Mac needs there auth.db fixed
We then created a policy with the Files and Processes mv /var/db/auth.db /var/db/auth.db.old
We also added an option with the restart option to restart immediatly and added this in the SelfService scoped to the smart group
hope this information helps out?
Awesome info! We use a similar Xcode script in our environment. We've been working with apple and our vendors to try to figure out what has been causing this for a long time now and you've moved us to the goal post. Appreciate the info and the EA. Will test the EA in our environment as well to help find the machines in condition
In our case i was using a script to finalise our Xcode installation for our users that aren’t admin users by default. The script that we used in the past was this one:
https://github.com/franton/Xcode-Scripts/blob/master/finalise.sh
Looks like line 42 is breaking the shutdown/restart option for macos.
what did is created an EA to detect which machines were affected after that i created a policy with a force restart.
#!/bin/sh
# Check for "root-or-entitled-admin-or-authenticate-admin" in authorizationdb.
AuthDbSetting=$(security authorizationdb read system.install.apple-software | grep "root-or-entitled-admin-or-authenticate-admin")
#echo "$AuthDbSetting"
# If the $AuthDbSetting variable does not contain "root-or-entitled-admin-or-authenticate-admin" then the variable will have a string length of zero.
# If the $AuthDbSetting variable has a string length of zero, output "AuthDB setting is wrong".
# If the $AuthDbSetting does not have a string length of zero, output "AuthDB setting is AuthDB setting is correct".
if f -z $AuthDbSetting ]]; then
echo "<result>AuthDB setting is wrong</result>"
else
echo "<result>AuthDB setting is correct</result>"
fi
This is the EA we are using to detect if a Mac needs there auth.db fixed
We then created a policy with the Files and Processes mv /var/db/auth.db /var/db/auth.db.old
We also added an option with the restart option to restart immediatly and added this in the SelfService scoped to the smart group
hope this information helps out?
Got some tidbit for you that might help. Running the command:
sudo security authorizationdb reset
Resets the auth.db. So after backing it up you can run that command and the next time the user reboots it'll work fine. No need for hard reboot via command line.
Got some tidbit for you that might help. Running the command:
sudo security authorizationdb reset
Resets the auth.db. So after backing it up you can run that command and the next time the user reboots it'll work fine. No need for hard reboot via command line.
I was playing with the security authorizationdb reset command some off the machines are returning the following error: Authorization Database reset failed: -1
how did you solve this?
I was playing with the security authorizationdb reset command some off the machines are returning the following error: Authorization Database reset failed: -1
how did you solve this?
Here's what I'm doing:
#!/bin/bash
##backing up original auth.db
cp /var/db/auth.db /var/db/auth.db.bck
##resettting auth.db
/usr/bin/security authorizationdb reset
##sleeping to allow time to reset
sleep 5
##reconing to update extension attribute
/usr/local/bin/jamf reconSo instead of moving the database to backup, we're copying it. So the reset has the database to reset. I found it needs a little delay before you do any other command so I gave it 5 seconds. Then I give it a recon to update the EA. So far this has worked great. Tested on around 10 machines at this point.
