An unauthenticated user is one whose DCE identity has not been verified by the DCE Security Service. For example, a user can access DCE without being authenticated by logging into the local machine without logging into DCE. In this case, the user is said to be unauthenticated because DCE cannot verify the user's identity. An authenticated user whose DCE credentials have expired is also considered an unauthenticated user.
When a user attempts to access an object, DFS first determines whether the user is authenticated. For access to an object in a DCE LFS fileset, an authenticated user acquires the permissions associated with the user's authenticated identity according to the normal ACL evaluation routine. (See ACL Evaluation for a description of ACL evaluation.) An unauthenticated user's permissions are determined as follows:
1. DFS uses the identity nobody as the identity of the user; it treats the identity as an authenticated user from a nonexistent foreign cell.
DFS assigns the identity nobody to all unauthenticated users, treating the identity as an authenticated user from an unknown foreign cell, regardless of the cell from which an unauthenticated user requests access to an object. DFS uses a fictitious cell as the local cell of the identity nobody; an entry for the fabricated cell cannot be created on an ACL. The primary group of the identity nobody is the group nogroup. The user ID of the identity nobody and the group ID of the group nogroup are both typically -2. However, these IDs can vary between File Server machines.
2. DCE LFS grants the user the permissions associated with the any_other entry.
Because the user nobody is treated as a user from a nonexistent foreign cell, the user cannot match any foreign_ entries (foreign_user, foreign_group, or foreign_other). The user is therefore granted the permissions associated with the any_other entry. If an any_other entry is not present on the ACL, the user has no permissions. To prevent unauthenticated users from acquiring permissions for an object, do not include an any_other entry on the object's ACL.
For access to objects in non-LFS filesets, unauthenticated users (regardless of their cells) and all foreign users (authenticated or unauthenticated) are treated as the user nobody. As a result, such users are granted the permissions associated with the other UNIX mode bits. Note that authenticated users from foreign cells are granted the permissions associated with their authenticated foreign identities when they access objects in DCE LFS filesets.
Note: DCE ACLs used with objects for other DCE components include an additional unauthenticated entry type that masks the permissions that can be granted to unauthenticated users. Prior to DCE Version 1.1, DCE LFS allowed unauthenticated entries to be included on the ACLs of DCE LFS objects, but it ignored the entries when determining users' permissions.
As of DCE Version 1.1, DCE LFS no longer allows unauthenticated entries to be included on the ACLs of DCE LFS objects. It is possible for the ACLs of existing objects to include unauthenticated entries added with earlier versions of DCE LFS. DCE LFS continues to ignore existing unauthenticated entries when determining permissions.
However, an ACL that includes an unauthenticated entry cannot be modified until the entry is removed from the ACL. An attempt to make any other change to the ACL fails until the entry is removed. You can use the dcecp acl modify command with the -remove option to remove an unauthenticated entry from an ACL.
To prevent potential failures, you may want to remove unauthenticated entries from the ACLs of all DCE LFS objects. Moving or restoring a DCE LFS fileset to a File Server machine that is running DCE Version 1.1 or a later version of DCE automatically removes unauthenticated entries from the ACLs of all objects in the fileset. You can also write a script that removes the entries from the ACLs of all DCE LFS objects in your cell.