Novell manager accounts

Early in the Monash NDS design process, the need to be able to locally control some aspects of the Novell rights was identified. This local control was never autonomous. There was a need to create a hierarchy that allowed a more senior administrator to step in when a local administrator was absent.

Who was to administer a particular part of the NDS was likely to change over time. The method devised had to be able to readily decouple the physical administrator and put a new one in their place without loss or reissuing of rights.

Manager accounts (MGR accounts) and managerroles

Monash has used two NDS object types to distribute and manage supervisory rights to the Staff and Student NDS trees. These are the faculty authorized manager accounts or MGR accounts and the NDS container manager roles.

The MGR account is used to login when doing administration tasks. The MGR accounts have no rights, but can be made an occupant of the container manager roles. The manager roles have the rights to administer. The manager roles can not login. Since the rights are passed in only one direction, this allows both the "one-to-many" and the "many-to-one" relationship to work without interaction.

The manager account structure was NOT designed for administrators to be continually logged in, and doing their personal productivity tasks. Administrators have their usual or ordinary user account for those tasks and are protected to some extent from accidentally retransmiting or propagating viruses, trojans, worms or policies.

Novell manager account attributes:

• Novell user account object
• easily identified by their prefix of "MGR-"
• suffix is the CRUX id of the authorized user
• only one MGR per authorized user
• user authorized by faculty administration (paper copy)
• not represented in CRUX
• created manually by EWS staff
• do not have a home directory
• do not receive or send mail
• have no NDS trustee rights
• have no volume, directory or file rights
• only obtain rights by container manager role occupancy
• may be a role occupant of many container manager roles
• anywhere on the same NDS tree depending of faculty authorizations
• Manager accounts in the Staff Novell system may not login from workstations that are on Student subnets.

By themselves, MGR accounts have no useful rights, apart from the ability to login to the NDS tree. When the MGR account is made an occupant of a manager role, rights are granted automatically by security equivalence to the role. The rights are removed when the account is no longer an occupant of the role.

An MGR account gets S rights to the objects it created by use of a C right granted by the role. It does not have sufficient rights to give the role S rights to the created object. This does lead to problems in the "many-to-one" role occupancy, but can be fixed by EWS staff.

Novell manager organizational role attributes:

• Novell organization role object
• one per container
• created as part of the CRUX/container preparation
• always given S right to CRUX created objects
• may be given C right to subordinate containers
• always given S rights to faculty global, shared and home directories
• always given S rights to SYS:MAIL subdirectories of their users (not the SYS:MAIL directory itself)
• does not get S right to objects created by occupants of the role

Safe usage procedures

There are some things an MGR account has the rights to do that simply should not be done. It is not easy to block most of these things while the role has S rights to user objects or C rights to a container. This first group of things here is for consistency across all platforms with accounts created by CRUX.

DON'Ts

User account manipulation

Do not use the MGR account for ANYTHING that can be done via CRUX (Account creation, account deletion, account name changes, users full name changes, moves from one container to another, group membership, disk quota, profile script) The only exception to the above is also main reason why S right is issued at all. Novell Passwords can be changed and the intruder detect lockout after multiple password attempt failures can be reset. Using CRUX to fix these is preferred as the password change can be co-ordinated across
all the services the user has access to. Changing the password to Novell access will not help them remember it for other services.

Profile is a special case. Since a user can only have one profile, it was decided to use this as an account "state" indicator. This is things such as Pending_Suspend.

The %SEE_ALSO property is used in some containers to point to a directory map of the users shared V: drive and must be empty or point to a valid directory map object.

Properties of user accounts an MGR must not touch for operational issues.

• Profile - may leave the account state unknown
• Account Balance - reported as an anomaly in audit logs

NDS Objects in general

Do not create volumes, servers, containers, users, groups or organizational units. Do not attempt to modify the NDS schema.

Do not use an MGR account for any unattended automated process. Particularly beware of running software than may act differently with manager rights. Some Novell aware utilities may ask you if you want to modify the schema. Answer No.

Manager roles are not given access to their own container login script or those of the users they administer. If any login script modification is required, a login script file is usually left on the faculty T: drive and the container login modified to INCLUDE T:\LISTS\LOGIN.SCR which the manager role should have access to.

DOs

Use the MGR accounts for:

• Setting passwords in an emergency
• Resetting Intruder detection
• Creation of Directory Map objects (for use with %SEE_ALSO)
• Changing the %SEE_ALSO of a user
• Creation of Profiles (so their scripts can be included in individual user login scripts)
• Modifying user login scripts
• Creation of shared subdirectories
• Examining user directories and files to resolve problems
• Granting directory and file rights to groups
• Setting quotas on shared subdirectories
• Adding groups to Print Queue users or operators
• Installing components of shared applications