GROUP THINK II, THE ADMINISTRATOR STRIKES BACK

by Wayne M. Krakau - Chicago Computer Guide, September 1992

Last month we covered reasons to avoid the indiscriminate use of Personal Login Scripts as part of a network management strategy that I call "Group Think". This month we will deal with the other half of this grouping approach, rights management.

Rights are the characteristics that govern who has access to directories and files and just how much can they do. The usual way to manage rights is to give a trustee assignment covering a particular directory (or file in Netware 3.0 and above) to a group or an individual. Experienced systems administrators also will encounter rights masks (maximum in Netware 2.2 and below - inherited in 3.0 and above), but they are not important to a discussion of the benefits of group management.

The most frequent situation that I encounter involves an ad hoc approach to trustee assignments. People are given individual trustee assignments as applications are installed or upgraded. As new employees come on board or existing employees have changes in responsibilities, more individual trustee assignments are handed out. Existing assignments that are no longer appropriate or even completely obsolete are often left behind.

This rights "hash" (analogous to the login script "gumbo" of last month's column) eventually reaches the breaking point when the management load of making these constant trustee assignment changes ties up too much of the system administrator's time. That's when the decision to reorganize is made.

Reorganization requires a painstakingly detailed examination of the ingredients of the hash. This task is even more difficult when the impetus is the departure of the system administrator. The only documentation often exists only in the gray matter (that's brain cells) of the system administrator. The new (often shanghaied) administrator has to try to reverse engineer the pattern of trustee assignments, usually without any prior knowledge of the underlying logic.

The solution here, as in the previous discussion of login scripts, is to plan from the beginning to use grouping as the key element. The groups can be organized by functional area. The group ACCT could be created for the Accounting Department. It could be given a trustee assignment to the accounting program directory (and by implication, its subdirectories) that allowed seeing and executing the accounting programs (R and F for Read and File Scan in Netware 3.11 terminology). The assignment for the accounting data directory (and subdirectories) could allow changing, creating, renaming, and deleting files (depending on the requirements accounting software) files (RWCEMF for Read, Write, Create, Erase, Modify, and File Scan).

An underlying concept to remember is to assign the least amount of rights that the application requires. If the accounting system doesn't create and delete temporary or report files, then don't give the corresponding rights. If it needs those capabilities only in a particular subdirectory, just give those rights explicitly in that subdirectory.

The groups also can be organized by application. All users needing access to the main wordprocessor could be put in a group called WP. This group could be assigned rights to see and execute the programs in the wordprocessing program directory (RF for Read and File Scan). The same rights could apply to a directory set aside for boilerplate (common reusable) documents.

In many companies, a combination of the two techniques (department and application organization) is suitable. Usually it is useful to create groups for even the smallest number of people rather than giving individual assignments. If frequent transfers or employee turnover is an issue, groups of one (used, for instance, to give a manager additional rights for applications associated with his or her department), become practical.

Usually it is easier to process a transfer or a new employee by simply adding and subtracting group memberships from an individual's characteristics in Netware's SYSCON utility than it is to make additional trustee assignments for every directory affected by the personnel change.

Even the documentation overhead (You ARE documenting your network, aren't you?) is lower with the grouping method. One document would list groups with their respective trustee assignments. A second would list directories and their respective trustees (a group or individual having a trustee assignment). A third would list groups with their respective members. A fourth would list individuals and their groups. A final document would contain any exceptions where an individual was given a trustee assignment. These documents are much shorter with grouping than with the more typical individual-based method.

One additional benefit of this organization method is the reduction in the security risk to the network. It is much easier to leave behind an inappropriate trustee assignment when assigning by individual. These leftover assignments can come back to haunt you if they result in files being viewed or altered by those who have no business accessing them.

Grouping is a way to save both internal and external costs. Remember, not only is a system administer's time worth money, but, if the network is disorganized enough to call in outside help, the cost can be budget-busting.

RANDOM NOTES

Most people have discovered that Netware 2.2 and below is an 80286 specific operating system that will run perfectly well on a 386 machine. That's why they don't call it Netware 286 anymore. Some people have noticed that Netware 3.11 is a 386 specific operating system that changes to a 486 specific system (it loads 486 commands) when it detects a 486 chip. That's why they don't call it Netware 386 anymore.

Now as we anxiously await Netware 4.0 (originally announced as Netware 3.2), I've discovered that it follows Novell's tradition of utilizing the most advanced instruction set available. When it detects a P5 chip (the code name of Intel's as yet unreleased 80586 chip), it becomes an 80586 specific operating system. When rumors of errors in the original sample set of P5 chips circulated, it turns out that it was Novell who discovered the problems. Since Netware 4.0 is currently the only 80586 specific software available, it was the only thorough test bed.

So much for the constant complaints of hardware always advancing faster than software.