S 2.149 Secure operation of Novell Netware  4.x networks

Initiation responsibility: Head of IT Section, IT Security Management

Implementation responsibility: Administrators

The items described in the following must be observed to allow secure operation of a Novell Netware  4.x network.

Allocation of access rights to directories, files, NDS objects and NDS object properties

The security of a Novell Netware  4.x network and its data can be guaranteed by allocating access rights (trustee assignments) to NDS objects, NDS object properties, directories and files in the network. NDS objects such as users or groups which have been assigned rights to access various NDS objects, NDS object properties, files or directories are termed trustees.

In Netware 4.11, three types of access rights exist. The first two are based on the NDS object rights and the NDS object property rights. The third is based on files or directories.

• Object rights

Menu diagram: Netware Administrator Container zenk_gmbh "Trustee of this Object..."

Object rights control access by trustees to objects, i.e. users, groups, printers and Netware servers. As can be seen in the above figure, the following object rights are available:

• Supervisor

• Browse

• Rename

A user with these rights over another NDS object, for example another user, is able to sequentially browse, create, delete or rename user accounts. The Supervisor right includes all of the other four rights. The Browse, Create, Delete and Rename rights do not include any object property rights or file rights. One exception to this in this special case is the Supervisor right to an object. This right also incorporates Supervisor rights to the object properties.

• Object property rights

Object property rights control access by trustees to stored details concerning an object, i.e. the object properties. No object rights are required for this. With the exception of the object right Supervisor, rights to object properties cannot be obtained with object rights. As can be seen in the above figure, the object property rights are as follows:

• Supervisor

• Compare

• Read
• Write

• Add Self

The object property rights consist of the main rights Write and Read. The right Read contains the right Compare and the right Write contains the right Add Self. The supervisor right is the combination of these four rights and does not have any other effects. With the right Read, object properties such as the user's properties surname or even the log-in script can be read. In order to make changes, the right Write is required. The right Compare allows queries to be made to the NDS, such as if the surname of user XY is Mustermann. The answer is then either "true" or "false". The right Add Self is only useful for objects with which users are able to enter themselves in a list, as is the case for a group. As an object often has numerous properties, there are two ways of allocating object properties. In principle, it is possible to allocate the same right for all properties. To do this, the option All Properties must be selected in the area Property Rights. On the other hand, it is also possible to allocate specific rights for particular object properties. This is done using the option Selected Properties. It must be noted that when the function Selected Properties is used, the rights that were allocated with the option All Properties are overwritten.

Rights in the NDS must be allocated even more carefully than rights in the file system. In the file system, an NDS object receives rights to a file or a directory. In the NDS, however, an NDS object receives rights to another NDS object. In the process, it must be carefully checked who is actually to receive the right to who. For example, it may well happen that a user object is supposed to receive rights to a container object, but the container object is given rights to a user object.

• File and directory rights

Menu diagram: Netware administrator directory PUBLIC "Details: Trustee of this Directory"

File and directory rights control the operations which a trustee, in this case the user RZenk, can perform in a file or directory. Just as object rights are independent from object property rights, file and directory rights are completely independent from the two NDS rights. The following file and directory rights exist:

• Supervisor

• Read

• Write

• Create

• Erase

• Modify

• File Scan

• Access Control

With the rights Read, Write, Create and Erase, a trustee can read, change, create and delete files or directories. Modify is not intended for changing files, but for renaming files and directories. In addition, the right Modify can be used to change the attributes of files or directories. The right File Scan allows users to view files or directories, for example with the command NDIR or even DIR. With the right Access Control, other NDS objects can be granted file and directory rights, with the exception of the supervisor right.

Unlike the object rights, where the right Create is only available at container level, the Create right in the file system can also be allocated for files, not just for directories. In the case of files, this right allows a deleted file to be restored through the Salvage mechanism. In the NDS, objects cannot be restored once they have been deleted. This means that the right Create is only useful at container level.

For a clearer overview, easier administration and improved auditing capability, access rights should be assigned primarily to user groups (file and directory rights) and to container objects. A container represents all objects, particularly user objects, which are located below the container object in the NDS. These rights really are assigned to all users, not only those who are located directly in the container.

For NDS rights to objects and object properties, there is the object organisational role (OR). The OR can be compared to a group. Groups pass on any file or directory rights they receive to all their users who are entered as members. In the case of an organisational role, the rights are passed on to members of the organisational role. Here, though, the members are referred to as occupants. This is the term used by Novell. Both for groups and for organisational roles, the rights are transferred to the members or occupants with the help of Security Equal To mechanisms. As in practice far fewer NDS rights are allocated than file rights, the OR is used much less frequently than for groups.

Rights can also be allocated directly to users and by using Security Equal To. However, the clear overview can very easily be lost and these mechanisms should, therefore, seldom be used. To sum it up, the ways in which rights can be allocated are:

• Groups (File and directory rights)

• Organisational role (NDS object and NDS object property rights)

• Containers

• Users

• Security Equal To

To prevent an inadvertent release of directories by users, the system administration should not grant "Supervisor" (S) or "Access Control" (A) rights in the directories and files assigned to the user groups and users.

If certain directories or files are assigned certain attributes - e.g. write-protection (Ro) - with the help of Netware attributes, it must be noted that users who have been granted the "Modify" (M) access right for these directories or files are able to change their attributes. For this reason, the number of users in possession of this access right should be restricted to a minimum.

Inheritance of access rights in the NDS and in the file system

All of the rights dealt with so far are subject to similar mechanisms. This involves important terms such as inheritance of rights, inheritance filters (IRF), effective rights (ER) and access control list (ACL), which are explained in the following.

Inheritance of rights

Rights are usually inherited both in the NDS and in the file system. This means, for example, that a right which is allocated in the root, either in the NDS tree or in the file system, is inherited by all objects, directories and files, which are located below the root. If a right is allocated further down in the tree structure, the rights are inherited from this position in the tree. There is an exception to this: rights which are allocated selectively to object properties (Selected Properties) are not inherited.

Example 1:

SYS: RZenk [Read; File Scan]

PUBLIC

NWADMIN.EXE

NDIR.EXE

If the user RZenk is granted [Read; File Scan] rights to the SYS: volume, these rights are in this case also inherited to the PUBLIC directory and the NWADMIN.EXE and NDIR.EXE files contained in PUBLIC. It is also possible to restrict the inheritance of certain rights. This is done using the Inherited Rights Filters (IRF), which are discussed below. In the basic state, no rights are filtered. There is another mechanism which prevents inheritance. If the same NDS object is assigned the same right again further down in the tree, the original rights that the object received further up in the tree are no longer inherited from this point.

Example 2:

SYS: RZenk [Read; File Scan]

PUBLIC

NWADMIN.EXE RZenk [Write]

NDIR.EXE

In example 2, the user RZenk only has the right [Write] for the file NWADMIN.EXE as the rights [Read; File Scan] of the user RZenk are not inherited to the file NWADMIN.EXE. All other NDS objects which may have received rights to the file NWADMIN.EXE are not affected by this. Even the rights which the user RZenk receives for the file NWADMIN.EXE via other mechanisms, such as groups, containers, etc., are not restricted by this. These rights are, therefore, additive.

Inherited Rights Filters (IRF)

While trustee assignments grant access to an object, an object property, a file or a directory, an IRF prevents rights being inherited from an object, an object property, a file or a directory to other NDS objects, files or directories in the tree. Each object, object property, file and directory in an NDS directory or file system can have a different IRF.

The only difference between the NDS and the file system concerns the right Supervisor. This right can only be filtered in the NDS. In the file system, on the other hand, this right can no longer be filtered once it has been assigned.

Effective rights

The combination of an Inherited Rights Filter, Trustee Assignment and Security Equivalences is called effective rights (ER). The effective rights which an NDS object has to another NDS object or its property, as well as the effective rights which an NDS object has to the file system, can be specified with the program Netware Administrator (see also previous diagrams).

Access Control List (ACL)

The information regarding which users can access an object and its properties and what rights they have is stored in the object itself. For this purpose, every object has a special property: Access Control List (ACL).

The ACL property contains the Trustee Assignments and the Inherited Rights Filter. Every object entered in the ACL can have other Trustee Assignments. In the file system, the ACL and the IRF are stored in the Directory Entry Table (DET).

Allocation of access rights to directories and files

Besides granting access rights to users and groups for files and directories, the allocation of Netware-Attributes to files and directories can increase data security. Attributes are always bound to a file or directory and never to NDS-Objects. These objects are independent of the assigned access rights and are valid for all users including administrators.

Users, who have been granted the "Modify" (M) privilege for the files and directories concerned, can change the Netware-Attributes and thereby carry out every action permitted by their effective privileges.

By installing Netware-Attributes, security takes the form of a subsystem in file and directory security. This means that, although users have the ER to delete a file, they may not be able to do this because the attribute "Delete inhibit" (Di) has been set.

When allocating Netware-Attributes to files and directories, the following properties of Netware-Attributes should be taken into account.

• Directory Attributes:

Delete Inhibit (Di): The directory cannot be deleted.

Hidden (H): The directory will be labelled as hidden; it will not show up in a contents list under DOS, neither can it be copied or deleted.

Purge (P): When deleting, the directory and the files contained therein will immediately be physically deleted. It will not be possible to recover the directory.

Rename Inhibit (Ri): The directory cannot be renamed.

System (Sy): The directory is used by the system; it will not show up in a contents list under DOS, neither can it be copied or deleted.

Don't Migrate (Dm): The directory and the included files are not to be transferred to a secondary data medium (such as a tape drive).

Immediate Compress (Ic): The directory and all files copied into it will be compressed instantly. Files which are already contained in the directory are not affected by this attribute.

Don't Compress (Dc): The directory and all contained files are not to be compressed.

• File Attributes:

Archive needed (A): The contents of files labelled thus by Novell Netware have been changed or reinstalled since the last backup. With a sequential backup, data backup software can recognise that the file must be backed up again.

Execute Only (X): Executable program files (*.exe, *.com) which have been allocated with this attribute may only be executed or deleted. Copying of the file is not possible. It must also be observed that files with this attribute are not saved (e.g. with a full backup)

Read write (Rw): Read and write access to the file is possible.

Read only (Ro): The file may only be read. Write access is not possible. To avoid data loss during simultaneous use, these files should also possess the "Shareable" (S) Attribute.

Executable program files (*.exe, *.com) should be given the "Read only" Attribute to prevent a possible computer-virus attack.

Shareable (Sh): These files can simultaneously be used by many users. Files that have been given the "Shareable" Attribute should also possess the "Read Only" Attribute. The "Shareable" Attribute is only relevant for programs that open files in a non-networkable mode.

Hidden (H): The file will be labelled as hidden; it will not show up in a contents list under DOS, neither can it be copied or deleted. I

System (Sy): This file is used by the network operating system; it will not show up in a contents list under DOS, neither can it be copied or deleted.

Transactional (T): Files with this attribute are subject to transaction control from Novell Netware. Transaction, in this context, means a series of changes in one or more files. Installing this attribute causes only completely executed transactions to be taken over by the data contained in the file. Transactions that have been interrupted before they were completed will be undone by Novell Netware.

Purge (P): Files with the "Purge" Attribute will, when deleted, not only be immediately logically deleted, but also physically. The consequence being that the file cannot be restored. In this context it must be mentioned that a physical deletion of files can not only be achieved by the use of the attribute purge but also with the command "PURGE filename".

Copy Inhibit (Ci): Files of this type cannot be copied. However, this Netware Attribute is only designed for APPLE Macintosh workstations.

Delete Inhibit (Di): The file cannot be deleted.

Rename Inhibit (Ri): The file cannot be renamed.

Don't Migrate (Dm): The file is not to be transferred to a secondary data medium (e.g. tape drive).

Immediate Compress (Ic): The file will immediately be compressed by the operating system and then stored on the volume.

Don't Compress (Dc): The file is not compressed by the operating system, even if compression is enabled for the volume.

Don't Suballocate (Ds): When storing this file no suballocation will be carried out. Even if this feature is enabled on the system.

File Compressed (Co), Can't Compress (Cc), File Migrated (M): With these attribute, corresponding information about a file is stored by the operating system. These attributes can only be changed by the operating system.

Careful allocation of rights

File rights, NDS object rights and NDS object property rights are completely independent. There are two exceptions to this: If users receive supervisor rights to an NDS object, they automatically have supervisor rights to the NDS object properties as well. This phenomenon does not occur the other way round. Supervisor rights for NDS object properties are not equivalent to Supervisor rights for the NDS object itself. In must be borne in mind in this context, however, that the object property Object Trustees (ACL) is a property of each and every NDS object. If users receive supervisor rights for the properties of an NDS object or simply the right WRITE for the property Object Trustees (ACL), they are able to grant themselves or other NDS objects any rights they choose. An important exception is the NDS object Server. If, as in the above example, the user Rzenk receives the right WRITE for the object property Object Trustees (ACL) of the server, this is the same as receiving supervisor rights for the entire file system that is assigned to this server. The property Object Trustees (ACL) of the server is therefore the interface between the NDS and the file system.

Menu diagram: Netware Administrator Server NW4_GT "Trustee of this Object..."

In order to prevent supervisor rights in the file system being obtained through improper allocation of NDS rights, Inherited Rights Filters (IRF) can be activated for every server. This allows the object rights to be separated from the directory rights. The supervisor right must be filtered for NDS objects and NDS object properties and the right WRITE for the property Object Trustees (ACL) must also be filtered. It is of course preferable to be aware of the details of how particular rights take effect.

Restricted usage of accounts with supervisor rights on the file level

The account "Admin" should only be used in an emergency, and not as part of regular administrative activities. Nevertheless, to ensure proper system administration, every user on the Netware security level "Supervisor" should be assigned an account with the same rights as the supervisor object (explicit trustee assignment, see also Protection against a loss of administrative capability) which should usually be used to perform system administration. If administrative tasks are not performed on a full-time basis, additional accounts need to be created specifically for each non-administrative activity.

The account of the administrator or that of the administrator's representative should continue to be used only in workstations defined for this purpose, as the integrity of other workstations could be manipulated.

The account "Admin", which has the sole administrative rights by default, should have its rights removed because it is a target for attack. The necessary supervisor rights should be transferred to another, less conspicuous user account. However, it is possible to simply rename the Admin account, choosing a name that complies with the general regulations for assigning names within the NDS, as laid down in the planning of the NDS for the company.

Protection against a loss of administrative capability

A new function as of Netware Version  4.x allows a decentral administration of Novell Netware networks. This can be achieved by means of certain administrative facilities such as the definition of a separate administrator for each container object. If only one user account has been configured for this purpose and this account is deleted inadvertently, the related container can no longer be managed (refer to T 3.25 Negligent deletion of objects).

To achieve the desired effect, an additional measure is thus required in the form of an explicit trustee assignment for at least one of the user objects of the user administrator. Therefore, the administrator right should not result from the mechanism Security Equal To. This prevents a loss of administrative capability for the container in case the organisational function object is deleted. This applies in particular to the allocation of rights to the central administrators of a Netware  4.x network.

Information on Novell Netware patches

During the development of the Novell Netware network operating system, weak points and shortcomings were discovered, most of which the manufacturer subsequently remedied with the help of patches or service packs for versions  3.x and  4.x. These patches can also be obtained from the manufacturer via the Internet (http://support.novell.com and http://support.novell.de). Shortcomings identified during operation of the network can thus be fixed by obtaining information on the network's functionality and, if necessary, loading the patches which have been made available. In particular, additionally installed software products, e.g. for the purpose of performing data backups, often require a certain patch level of the network operating system. Here though, it must be noted that the offered patches should by no means be loaded "blindly", but only after a thorough research if a concrete requirement for them has arisen ("never change a running system"). As not all patches are error-free, they should first be checked in a test configuration.

Apart from the international discussion forums in the Internet (Usenet) regarding Novell Netware (at present, comp.os.netware.announce, comp.os.netware.misc, comp.os.netware.security, comp.os.netware.connectivity), there exists a german-speaking Novell forum for german users (at present, de.comp.sys.novell). A number of experienced Novell administrators are present, who can help solve even the most complicated problems. In addition, files are available over the Internet to answer the most frequently asked questions (FAQs). The most frequent problems are dealt with and solutions are offered.

Furthermore, patches and information regarding Novell Netware are made available by other service providers such as Compuserve, Fidonet and Mailboxes.

However, no guarantee can be given as to the correctness and comprehensiveness of the respective information in the usenet discussion forums or in the FAQs (Frequently Asked Questions). It should be noted that a complete description of the problems arising, as well as a description of the respective network configuration (Client, Server), is highly advantageous when searching in the Internet (Usenet).

Furthermore, difficulties in network operation can often be remedied by making enquiries with the network operating system salesperson or by exchanging information with colleagues. As before, solving problems will be made considerably easier with a complete description of the configuration.

Testing for Computer-Viruses

Computer viruses harboured by programs and files stored on a Novell Netware server can cause considerable damage in the network.

For this reason, the programs and files on a Novell Netware server should regularly be checked for the presence of computer viruses using a recent virus scanning program.

For this purpose, it is advisable to create a special user account in the Novell Netware  4.x network, which has "Read" (R) and "File Scan" (F) access to all files. A scan for computer viruses should not be performed with supervisor rights or equivalent rights, as a virus scanning program which is itself infected with a virus will transfer it to all programs and files.

Users and user groups, too, should only be granted the "Read" (R) and "File Scan" (F) rights to access directories and files containing executable program code, to prevent them from being infected by viruses which might appear on local computers. In addition, executable programs should be assigned the Netware attribute "Read only" (Ro).

When compression is enabled, all compressed data must be decompressed during a search of the Netware volumes. This is very time-consuming and considerably increases the server's response times.

Regular checks of time synchronisation and NDS replication

To monitor time synchronisation and the comparison of several NDS replications on different Netware  4.x servers, a separate Netware screen can be activated on the console. This is done by entering the following two commands:

• SET TIMESYNC DEBUG = 7 and

• SET NDS TRACE TO SCREEN = ON.

The console then indicates the packets which are transferred between the servers. The comparison of the individual replications of each server can be monitored on this NDS trace screen. Successful comparison is indicated in green lettering, error messages are displayed in red. As this screen is updated regularly, some information might be overlooked. Therefore, it is absolutely necessary to check the console messages on a regular basis. For this purpose, it is advisable to use a network management tool, which allows the status of the network to be ascertained and monitored much more reliably:

In the case of an error, the utility NDS manager (SYS:\PUBLIC\WIN95\ NDSMGR32.EXE - for Windows 95 or Windows NT) is extremely useful. This tool can also be used to monitor the replication.

Regular checks of the utilisation of the system hard disk

To allow trouble-free operation, it must be ensured that the system volume on each Netware server has sufficient free disk space. This is particularly important when compression is enabled. For example, if the generation of temporary files is left uncontrolled and these files are not deleted from time to time, they will eventually fill the system volume. Furthermore, large printer queues could lead to an overflow of the system volume if a large number of users need to print large documents at the same time.

For this reason, a separate volume should be configured for printer queues and other directories in which temporary files are stored. If this is not possible, at least restrictions should be imposed on the size of such directories, so that they do not grow unchecked. This prevents the system volume from being fully occupied, and ensures that enough space is always available for system-specific operations by the Netware server.

Additional controls:

• Have all measures to ensure reliable operation of a Netware  4.x server been implemented?

• Have substitute user accounts been created for protection against a loss of administrative capability, and have these accounts been assigned explicit trustees for accessing the related NDS objects?

• Are the hard-disk utilisation levels and console messages checked regularly?

• Are supervisors' rights to access objects checked regularly?