IBM AS/400E manual UID Mapping Examples

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 ®le 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 pro®le that lacks proper authority, he willnot 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 pro®le 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 ®le 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.A problem can exist if Ray accesses Joe's user pro®le 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.

Chapter 9. Network File System Security Considerations 85