Environment
Novell NFS Services
Novell NetWare 6.5
Situation
When a NetWare 6.5 server is installed into a tree, it creates (or verifies the existence of) a NFAUUser object in the server's context (or bindery context). This user object is used by services such as Native File Access for Unix (NFS Server), NFS Gateway, FTP Server, etc., for searching and modifying eDirectory.
The user object can also be manually created with SCHINST.NLM (which is the same method used automatically during an install).
However, in some cases, it has been observed that this object is getting removed immediately after creation. In such cases, the SYS:\ETC\SCHINST.LOG will show:
Info:98:<date stamp> <time stamp> : Added the object: .CN=NFAUUser.<context>
Warning:100:<date stamp> <time stamp> : Removing the object : .CN=NFAUUser.<context>
Resolution
This situation can occur when a Universal Password policy is in effect in the container where the user is being created. A password is randomly created for the user, and if it does not meet the password policy created for its container, the process cannot be completed properly, so SCHINST.NLM removes the object as a precaution.
The workaround is to disable (temporarily, at least) the policy in place for the container (mentioned in the log warning), so this object can be created and its password can be generated and assigned.
Even after returning policies into effect, it is not recommended that a policy be set to monitor this user ("existing users") for password compliance, as that kind of policy could cause this user to be disabled later. Existing NFAUUser objects should be treated as exceptions to administrator-defined policies. Or, alternatively, a special policy (with no special restrictions defined) could be created and assigned specifically to the various NFAUUsers that exist in the tree, so no other policies can effect them.
NOTE: In NetWare 6.5 SP8, SCHINST.NLM was modified so it's randomly generated password is more likely to meet some of the common password policies that are in use. This could prevent the issue from occurring with servers installed directly from SP8 overlay media, or when manually using SCHINST.NLM on a SP8 server. However, it is not feasible that the randomly generated can meet all possible policies, so even when using SP8, this issue could occur.