When a principal (user or machine) has a corrupt credential, that principal is unable to perform any namespace operations or tasks, not even nisls. This is because a corrupt credential provides no permissions at all, not even the permissions granted to the nobody class.
Corrupted keys or a corrupt, out-of-date, or otherwise incorrect /etc/.rootkey file.
Or, if the principal is listed, log in as the principal and try to run an NIS+ command on an object for which you are sure that the principal has proper authorization. For example, in most cases an object grants read authorization to the nobody class. Thus, the nisls object command should work for any principal listed in the cred table. If the command fails with a “permission denied” error, then the principal's credential is likely corrupted.
Ordinary user. Perform a keylogout and then a keylogin for that principal.
Root or superuser. Run keylogout -f followed by keylogin -r.