Implementation of a new user policy
Use the guidelines in this scenario to implement policy profiles in the specification of new user IDs.
The previous sections describe the profiles that are used in the decision process for the user ID and the place in the RACF® group hierarchy. These profiles allow great flexibility in specification of the user IDs that a terminal user is allowed to create. Use the following scenario to describe the steps that are required to implement a new user policy:
- Central administrators can define all users.
- De-centralized administrators can define users only for their own department.
- Departments can be recognized by the RACF group structure (ownership).
- All user profiles must be owned by a RACF group, according to the departmental structure.
- A user ID naming convention is used where the first 3 characters of the userid are the same as the first 3 characters of the department name.
For the preceding organization, the following profiles can be implemented:
- c4r.user.id.* uacc(none) sysadmin(update)
- This profile ensures that only system administrators are allowed to define new user profiles outside the regular naming conventions.
- c4r.user.id.=racuid(3) uacc(update)
- This profile allows all decentralized administrators
to define new users that have as first 3 characters the same characters
as the decentralized administrator. Only those decentralized administrators
who have CLAUTH(USER) and the group-SPECIAL attribute
are allowed to define new users. Note: The implementation of this policy through the =RACGPID(3) profile is not as effective. All the groups of the terminal user are used as naming convention. It is not guaranteed that the terminal user is not connected to a functional group of another department, which has a different prefix.
- c4r.user.delete.** uacc(none) sysadmin(update)
- This profile ensures that only the central system administrators are allowed to delete existing users.
- c4r.user.=dfltgrp.** uacc(update) sysadmin(control) appldata('=myowner')
- This profile specifies that independent of what any decentralized administrator specifies, the newly defined userid is always connected to the GROUP that owns the decentralized administrator. Central system administrators must specify a DFLTGRP because this control does not apply to them. However, see the next profile.
- c4r.user./dfltgrp.** uacc(none) sysadmin(update) appldata('USERS')
- If the central system administrator does not specify a DFLTGRP for new users, the user is assigned to the group called USERS.
- c4r.user.=owner.** uacc(update) sysadmin(control) appldata('=myowner')
- This profile ensures that the OWNER of the new user ID profile is the same as the OWNER of the decentralized administrator. Again, this control does not apply to the central system administrators. The next profile is especially defined for their usage.
- c4r.user./owner.** uacc(none) sysadmin(update) appldata('=dfltgrp')
- The use of =DFLTGRP as the APPLDATA value ensures that if no value is specified for the OWNER, the OWNER is completed by zSecure™ Command Verifier to be the same as the DFLTGRP for the new user ID.