appropriate to both the user and the system in question. Just because users
need *SECOFR authority on one system does not mean that they need that
same authority on

all

machines.
UID Mapping Examples
In the TULAB, an engineering graduate student named Bill has a UID of 136 on
TULAB1 and a UID of 142 on AS/400 TULAB2. If Bill wants to mount or otherwise
access a file on TULAB1, his UID of 136 will be transmitted to that server.TULAB1
will then run an authority check on him as 136 before it lets him access the object
he requested. Even if Bill is the administrator of TULAB2, if his TULAB1 UID maps
to a profile that lacks proper authority, he will
not
be able to access the object he
has requested.
It is important, therefore, to make sure that all your users have properly mapped
UIDs. In this case, a user was unable to access data he felt he had authority to
access, but improper UID mapping can also have worse effects.
A new undergraduate engineering student named Jennifer has the exact opposite
UIDs of Bill: 142 on TULAB1 and 136 on TULAB2. When Jennifer makes a request
from TULAB1 to TULAB2, her UID and associated authority is transmitted over to
the server. Because she and Bill have the same UID,AS/400 TULAB2 will assume
that she

is

Bill. TULAB2 will allow her access to all objects and actions that Bill
normally has access to.
In this case, a user with little to no authority on one server unknowingly created
chaos on another server simply because of poor UID mapping. It is of utmost
importance to pay attention to the big picture of the namespace when assigning
UIDs and their associated authorities. Give users access only to what they will need
and make sure that none of the UIDs overlap. The result will be a much more
secure namespace.
For example, Chris Admin can correct this situation by making sure that Bill has a
UID of 136 on both systems. He can also ensure that Jennifer has a UID of 142 on
both machines. Furthermore, Chris Admin can erase the UID of 142 on a system if
Jennifer does not need access and, therefore, a user profile there.
In the above example, a user unwittingly assumed the UID of another user.
Sometimes, however, users will knowingly impersonate the UIDs of other users.
Users might attempt this to gain excess authorities and permissions to file systems
or objects that were previously out of reach or to cause mischief. Either way, a
smart system administrator can stop this from happening.
For example, on TULAB1 and TULAB2, there exists a user named Ray.Ray has a
UID of 2700 on TULAB1, where he holds *SECADM authority.He also has a UID of
150 on TULAB2, where he is a regular user.
Another user named Joe also has regular user access to TULAB2, where his UID is
170. Aproblem can exist if Ray accesses Joe’s user profile and discovers Joe’s
UID. Ray can then set up a FOOL=170 UID on TULAB1 and make requests to
TULAB2. When the server checks Ray’s FOOL UID, it will assume that FOOL is the
same as Joe. TULAB1 will then grant Ray access to Joe’s home directory and any
objects that he owns. Ray then has the authority to completely delete Joe’s home
directory, remove Joe’s access to the system, and generally perform any other act
that Joe was capable of.
Chapter9. Network File System Security Considerations 85