The +NISGroup account in the local UNIX /etc/passwd file originally contains no UID or GID entries. After creating a standard user account and updating a password for a standard user account, the UNIX ETC agent added a UID and GID of 60001 to all NetGroup entries (the /etc/passwd file were modified).
The UID 60001 is assigned to the account "nobody" and the GID 60001 assigned to group "nobody".
Examples of /etc/passwd after installing the UNIX ETC Agent and creating a standard user account, and updating a password for a standard user account:
+@SA-ADMINS:x:60001:60001:::
+@PARCH:x:60001:60001:::
+@NETWORK:x:60001:60001:::
+@TIVOLI:x:60001:60001:::
UNIX Agent version r12CR07 (CES 53088).
UNIX hosts are NIS clients with standard UNIX accounts and NIS accounts.
What triggered the "nobody" creation?
The UID and GID were added when the remote agent updated the /etc/passwd file.
When scanning the file the remote agent would have found that no ID was present in the ID fields, and therefore adds the nobody ID.
Why was that specific UID / GID chosen?
The nobody ID is used as a security measure to limit the access a user can have to the system.
The number given to the nobody UID/GID is Operating System dependant.
As an example: it might be 60001 on Solaris and 65534 on RedHat.
Is this standard best practice?
Yes, at the time when the agent was designed and implemented this was considered best practice.
The CA Agent for NIS/UNIX identifies the userID that has no UID or GID.
The Agent then adds the "nobody" UID and "nobody" GID accordingly. This is done as a security measure to limit the access that a user may have if a user is able to logon locally to the userID with no UID.
The number given to the nobody UID/GID is Operating System dependant; e.g. might be 60001 on Solaris and 65534 on Redhat.