To the best I'm able to determine, Mac OS X Server's cron does not recognize crontabs of users who exist in LDAP, nor the flat files (e.g., /etc/passwd). This is because cron starts prior to LDAP, and thus sees the crontabs of such users as "orphans." If you log in and re-establish the crontab, all is well ... but a simple reboot shouldn't cause crontabs to become disabled.
The system cron is a launchd service, and so it's quite difficult to control the order in which it launches. One can make the argument that it's cron's fault that it doesn't check for LDAP when it starts, but I think that the blame is really Apple's to bear. I spent hours today trying to figure out a graceful way to delay cron's launch without installing a new cron or hacking things up too badly, all in vain.
I gave up and just installed the hackery below; the script waits for LDAP to respond, then kills cron, which automatically restarts.
Create the following in /Library/LaunchDaemons/local.cron.plist:
<?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>local.cron</string>
<key>Program</key>
<string>/bin/sh</string>
<key>ProgramArguments</key>
<array>
<string>sh</string>
<string>/local/sbin/restart_cron</string>
</array>
<key>RunAtLoad</key>
<true/>
<key>LaunchOnlyOnce</key>
<true/>
</dict>
</plist>#!/bin/sh
PATH=/bin:/usr/bin
LDAP_MASTER=127.0.0.1
#DEBUG=1
DEBUG_FILE=/tmp/local.out
if [ "$DEBUG" ]; then
exec >$DEBUG_FILE 2>&1
else
exec >/dev/null 2>&1
fi
while ! dscl "/LDAPv3/$LDAP_MASTER" -list /Users; do
echo "Sleeping 5 seconds...."
sleep 5
done
sleep 10
echo "Killing cron"
kill `ps ax | grep '/usr/sbin/[c]ron' | awk '{print $1}'`Mac OS X Hints
http://hints.macworld.com/article.php?story=20090119164250363