Some things to check:
Have the user run 'sudo -l'. This just asks sudo to tell you what permissions you have. If you can't manage this, there's a fundamental issue authenticating that's probably separate from sudo itself.
Compare /etc/pam.d/sudo with other functional systems (or backups).
Compare /etc/pam.d/system-auth with other functional systems (or backups). Subtle changes to this system can introduce gnarly troubleshooting problems.
Look at /etc/pam.d/system-auth and see if the pam_access.so module is in use. If so, you'll want to check whether smithj is allowed in /etc/security/access.conf (unless another file is specified by the pam module). One potentially tricky problem is if the account is allowed access from a remote IP, but not locally; this ends up allowing a remote log in, but local actions like cron jobs and sudo authentications fail.
Is smithj logging in via password? Or via keys? Make sure they can log in with a password to help narrow the problem. If they can't successfully use their password anywhere, start looking at changes against /etc/passwd, /etc/shadow, /etc/nsswitch.conf, and any config files associated with the directory you're using (perhaps none, perhaps LDAP, NIS, AD).
If you have a caching daemon running, perhaps nscd or sssd, restart the daemon ('sudo service nscd restart'). These daemons are notorious for having problems.