Comment 7 for bug 27520

We have the same symptom with jaunty (our mirror was last synced ~June 2009) with LDAP providing the non-local users. Restarting cron resolved the issue for us.

After some poking and prodding I found that cron was calling getpwnam for all the user crontabs and getting back NULL for all non-local users. If I understand how the resolver works correctly, when an application first makes a call to resolve something (name, remote host, etc), it checks /etc/nsswitch.conf and attempts to connect to the resolving mechanisms (file, nis/ldap, etc) and then you're stuck with whatever it found then. This means that if you change /etc/nsswitch.conf after you've started a program that needs to resolve hosts, users, groups, services, or whatnot, and it's attempted it's first resolution, your changes will be ignored for the remainder of that process's life cycle.

My guess is that cron is likely coming up before networking is available on the machine and so LDAP (in our case) and winbind (in OP's) is not available initially and is thus ignored by cron until you restart it. I would imagine that nscd may resolve the issue for some if it is already running when cron starts since it will protect cron from this "feature" of libnss.

We've dealt with the issue by adding a cron job to /etc/crontab (or to a snippet in /etc/cron.d) like so:
@reboot root /bin/sleep 45 && /etc/init.d/cron restart

Pretty hackish but it appears to do the trick. Hopefully this is fixed with the move to upstart in karmic and beyond.