The answer here is firmware password.

What is your issue with management of the password?

You might want to look at this link text. This is an old post but it should still work. I would also recommend using a firmware password, unless there is a really good reason for people to boot to another OS.

Without a firmware password you will be chasing your tail. You could start with chflags to lock the file though.

Also consider setting up a launchd item to kill the erroneous admin users. Perhaps a test against the admin group. You know who the admins should be, so remove any that shouldn't be there. Something based on the below. Change the echo command to what you would like to consider should be done.

You could of course remove the admin rights, remove the user or my preference make the machine useless to them so they have to come back to you. Kill the loginwindow and then do your worst.

#!/bin/bash

declare -a AdminList=("root" "myadmin")

function RemoveAdmins
{
        while [ $# -gt 0 ]
        do
                if [[ ! "${AdminList[@]}" =~ $1 ]]
                then
                        echo $1
                fi
                shift
        done
}

current_admins=`dscl . read /Groups/admin GroupMembership | cut -d " " -f 2-`
RemoveAdmins $current_admins

exit 0

Perhaps once an unknown admin is found, you could have a LaunchAgent to check the ownership of /dev/console and if it isn't root kill the loginwindow, essentially killing all logins.

killall -HUP loginwindow

You could also provide a message using iHook, Cocoadialog, Pashua, Big Honking Text, etc. to overlay the loginwindow with a message. "You will are required to buy the IT team cake!"

If these are shared machines and you don't know who is doing it, you could take a picture with the camera.

There are other ways to achieve the same results, but essentially the idea is rather than playing with the .AppleSetupDone file, monitor the admins/user accounts and then react.

I have got around this by creating a LaunchDaemon to touch the .AppleSetupDone file.
That way it will always be created on startup even if the user deleted the file in Single User mode

Here is my LaunchDaemon

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict> <key>Label</key> <string>com.setupassist</string> <key>ProgramArguments</key> <array> <string>touch /var/db/.AppleSetupDone</string> </array> <key>RunAtLoad</key> <true/>
</dict>
</plist>

@WANEWS

Hmm so a user starts up a machine in single user mode, removes the .AppleSetupDone file and reboots

Does the setup assistant not show up? Does your LaunchAgent run before Setup Assistant checks for the presence of the file?

If the user is able to boot into single user mode, and they know about the presence of the .AppleSetupDone file. It would be trivial for them to also remove the LaunchAgent

The Apple Setup wizard will not show up if the user deletes the .AppleSetupDone file as it is a LaunchDaemon and runs before the loginwindow is invoked, LaunchAgents run when the user logs in.

Yes the user could delete the launchdaemon in single user mode but how would they know of its existence?

Without a firmware password they could delete basically any file they wanted to in single user mode so without acutally setting a firmware password I have used this method and it has been successful in preventing users gaining admin access.