This section describes problems related to user ownership and permissions. Symptoms include error messages with operative clauses such as:
"Unable to stat NIS+ directory name"
"Security exception on LOCAL system"
"Insufficient permission to . . ."
"You do not have secure RPC credentials"
Another symptom is a user or root user who cannot perform any namespace task.
The most common permission problem is the simplest: you have not been granted permission to perform some task that you try to do. Use niscat -o on the object in question to determine what permissions you have. If you need additional permission, you, the owner of the object, or the system administrator can either change the permission requirements of the object (as described in Administering NIS+ Access Rights) or add you to a group that does have the required permissions (as described in Administering NIS+ Groups).
Without proper credentials for you and your machine, many operations fail. Use nismatch on your home domain's cred table to make sure you have the right credentials. See Corrupted Credentials for more on credentials-related problems.
A server running at security level 0 does not create or maintain credentials for NIS+ principals.
If you try to use nispasswd on a server that is running at security level 0, you receive the error message: You name do not have secure RPC credentials in NIS+ domain name.
Security level 0 is only to be used by administrators for initial namespace setup and testing purposes. Level 0 should not be used in any environment where ordinary users are active.
A user cannot have the same login ID as a machine name. When a machine is given the same name as a user (or vice versa), the first principal can no longer perform operations requiring secure permissions because the second principal's key has overwritten the first principal's key in the cred table. In addition, the second principal now has whatever permissions were granted to the first principal.
For example, suppose a user with the login name of pine is granted namespace read-only permissions. Then a machine named pine is added to the domain. The user pine will no longer be able to perform any namespace operations requiring any sort of permission, and the root user of the machine pine will only have read-only permission in the namespace.
Symptoms include:
Note: When running nisclient or nisaddcred, if the message Changing Key is displayed rather than Adding Key, there is a duplicate user or host name already in existence in that domain.
Run nismatch to find the host and user in the hosts and passwd tables to see if there are identical host names and user names in the respective tables:
nismatch username passwd.org_dir
Then run nismatch on the domain's cred table to see what type of credentials are provided for the duplicate host or user name. If there are both local and DES credentials, the cred table entry is for the user; if there is only a DES credential, the entry is for the machine.
Change the machine name. (It is better to change the machine name than to change the user name.) Then delete the machine's entry from the cred table and use nisclient to reinitialize the machine as an NIS+ client. (If you wish, you can use nistbladm to create an alias for the machine's old name in the hosts tables.) If necessary, replace the user's credentials in the cred table.