Novell is now a part of Micro Focus

Chapter Three:Implementing and Administering NetWare 4 Security

Articles and Tips: article

01 Apr 1994


Implementing and Administering NetWare 4 Security

This chapter provides guidelines for setting up network security. It begins by providing the actions required to meet the baseline for each of the security models introduced in Chapter 1. We recommend that your implementations surpass these baselines based upon your specific needs.

This chapter also contains information on setting up proper security for NetWare Directory Services and for the file system. These are important, but often overlooked items when defining and implementing network security.

NetWare 4 Security Model Implementation

There are certain actions that are required to achieve a baseline level of each of the NetWare 4 security models. After defining network security needs, implement the corresponding security model. Again, these are minimum baselines.

In the NetWare 4 Security Model Actions in Figure 1, the requirements for each security model are listed. As you progress to the next higher level of security, remember that each higher level requires the implementation of all of the lower level security models as well. This means that if you implement the basic model, you must implement all the actions for the simple model in addition to the actions required for the basic model.

Figure 1: NetWare 4 security model actions.

NetWare 4 Security

NetWare 4 has two distinct levels of security: file system security and NetWare Directory Services (NDS) security.

File system security affects access to files and directories located on the various volumes. This type of security provides control of the application programs and their data files. The NetWare 4 file system security is essentially the same as file system security in NetWare 3.1x. A few attributes have been added for the new data compression and data migration features, and some terminology has been changed, but the functionality remains the same: to provide users with control and access to file system directories and files.

NetWare Directory Services security affects management of the NDS database and its objects. It is used strictly for managing the objects and their properties. The functions of NDS security are similar to those Supervisor functions not related to the file system in previous versions of NetWare. Examples of these functions are creating users, editing login scripts, and creating printers and print servers. In NetWare 3.1x, they also included such tasks as assigning trustee rights and creating a workgroup manager or a console operator.

As shown in Figure 2, these tasks have been separated from the general "Supervisor" account and can be distributed to various users on the network. In NetWare 4, the default account that receives these rights initially is the ADMIN account (the first user account created when the first NetWare 4 server is installed).

Figure 2: Comparison of the SUPERVISOR account and the Admin account.

Generally, file system and NDS security do not affect each other and are independent of one another. In fact, one of the features of NetWare 4 is the ability to separate file system administration from NDS administration. The user who administers the NDS tree and its objects can be separate from the file system administrator. You can also have different administrators for different parts of the tree, different volumes, directories, or files.

NetWare 4 security is extremely flexible in the subdivision of administration. This is necessary since we are now dealing with global networks that need multiple administrators. For example, imagine a network with offices in New York and Dusseldorf. You would not want the Dusseldorf administrator to have to manage the entire network over a wide area link. In addition, the New York administrator probably knows his environment and users better and thus can serve their needs better than the Dusseldorf administrator.

With the flexibility in NetWare 4 security, you have the ability of creating many different types of administration structures. These could range from local to centralized global administration. This section will help you understand what the features are and how you can setup a trusted working environment.

In the sections that follow, we will:

  • Review security concepts which affect file system and NDS security.

  • Review file system security and note the differences in implementationin NetWare 4.

  • Introduce NDS security.

  • Discuss the default security assignments NetWare 4 makes for certain events like server installation and user creation.

  • Discuss what additional file system security assignments are needed for a functional network.

  • Discuss what additional NDS security assignments are needed including:

    - Proper distribution of Directory tree administration (including how to prevent cutting off administration from branches)

    - Creating special purpose users

    - How and to what types of objects these assignments can be made

Security Concepts Review

Before delving into NDS security per se, we need to review the following concepts which affect both file system and NDS security in NetWare 4:

  • Trustee Assignments

  • Inherited Rights

  • Inherited Rights Filter

  • Security Equivalence

  • Effective Rights

On a network, users must be granted rights in order to use resources. Users never automatically "get" rights. They cannot access resources like files and directories unless they have been granted a trustee assignment. Trustee assignments can be made to such resources as files and directories, User objects, Server objects, Volume objects, and so on.

In NetWare 3.x and below, the "trustee" (the object granted the rights) was typically a user or a group. In NetWare 4, besides User and Group objects, trustees may be Organizational Role objects, the [Public] trustee (to be discussed in depth later on), other leaf objects, or container objects. Essentially, any object can be made a trustee of another object even if this does not seem practical - a printer being made a trustee of a Volume object does not make sense, but it can be done and definitely should be avoided.

It is impractical to have to assign each user rights to every network resource, file, or NDS object. For that reason, NetWare 4 makes it easy by allowing for the downward "flow of rights." This flow of rights is known as inheritance. Rights assigned to a directory in the file system continue to flow down the directory structure until they are reassigned. In NDS security, rights assigned to a container flow down to subordinate containers and leaf objects until they are reassigned or filtered.

We can prevent the inheritance - or flow - of rights down a file system directory structure or NDS Directory tree through the use of an inherited rights filter (IRF). An IRF revokes allowable rights and affects all users. Only users with explicit trustee assignments at the level where an IRF is invoked may access that level.

The user may also have rights assigned to his own User object, Group objects he may be a member of, and Organizational Role objects he may be an occupant of. A user may gain rights to files and the NDS tree through security equivalence to other objects.

When User A is security equivalent to another user, User A receives rights only to the objects or files the other user has explicit trustee assignments to. NetWare 4 evaluates most of the possible sources of rights as security equivalences. For users these include groups they belong to, Organizational Roles they are occupants of, explicit security equivalences, parent containers up the tree to the [Root], and the [Public] trustee.

NDS Security Concepts and Features

A well laid out NDS design facilitates network use and administration in the same way that a well designed file system directory structure facilitates efficient file access. In order to exploit the capabilities of NDS, the network administrator must understand NDS objects, object and property rights associated with the NDS objects, and the best way to use these objects to implement both NDS and file system rights. This section will explore these topics.

NDS Objects

The NDS database is similar to the NetWare 3 bindery in many respects. NDS still has objects, properties, and values. However, NetWare 4 has twenty standard objects. NDS objects are either container or leaf objects. The four container objects are [Root], Country, Organization, and Organizational Unit. They are called container objects because, as the name implies, they can contain other objects.

NDS container objects provide for the hierarchical structure of the NDS database. The general model is similar to the file system directory structure. An NDS directory tree is composed of one [Root] object, usually several levels of the other container objects, and many leaf objects. Similarly, the tree outside your window has roots (NDS [Root] object), several different-sized branches (NDS container objects), and many leaves (NDS leaf objects). NDS contains sixteen standard leaf objects. These standard leaf objects include Users, Groups, Print Servers, and Print Queues, as well as the twelve additional leaf objects listed below:

  • AFP Server

  • Alias

  • Computer

  • Directory Map

  • NetWare Server

  • Organizational Role

  • Printer

  • Profile

  • Volume

  • Unknown

  • Bindery Object

  • Bindery Queue

Each NDS object (both container and leaf) has a specific set of properties associated with it. More than 120 separate properties are defined within the Directory Services Schema.

The particular subset of these properties associated with a given object class define how that object can operate within the NetWare 4 network. For example, the Login Script property is defined for the object's Organization, Organizational Unit, Profile, and User. Only these objects have login scripts. Some properties, such as the ACL (Access Control List), apply to all objects. You can find a table containing all of the NDS objects and their associated properties in Appendix A of the NetWare 4 Utilities Reference Manual.

In this chapter, we examine the User object in detail, but the general principles involved apply to every other object as well. The NetWare 4 User object has 59 user-accessible properties defined for it. They are listed below:

Properties of the NDS User object

Account Balance Account Locked Account Reset Time Allow Unlimited Credit Allow User to Change Password Back Link Bindery Property City Common Name Day Between Forced Changes Default Profile Default Server Description E-Mail Address Fax Number Full Name Group Membership Higher Privileges Home Directory Incorrect Login Attempts Intruder Address Language Last Login Time Last Name Limit Grace Logins Location Login Disabled Login Expiration Date and Time Login Script Login Time Login Time Restrictions Mailing Label Information Maximum Connections Minimum Account Balance Minimum Password Length Network Address Restriction Network Addresses Object Class Object Trustees (ACL) Organizational Unit (Department) Password Expiration Date and Time Postal (Zip) Code Postal Office Box Print Job Configuration Printer Control Public Key Remaining Grace Logins Require a Password Require a Unique Password Revision Security Equivalences See Also Server Holds State or Province Street Telephone Title Type Creator Map UID (User ID)

NDS Object and Property Rights

The NDS database allows for as many levels of access as you want to create and manage. These access levels are controlled through object and property rights. NDS object rights are used to control who can perform administrative functions such as creating, deleting, or renaming an object. NDS property rights are used to control who can examine, use, or change the values of the various properties of an object. The five object rights are listed in Figure 3.

Figure 3: NDS object rights.


Right
Description

Supervisor (S)

Grants all access privileges

Browse (B)

Grants theright to see the object in the Directory tree

Create (C)

Grants theright to create new objects below this objectin the Directory tree (this right can onlybe assigned to a container object)

Delete (D)

Grants theright to delete the object from the Directory tree

Rename (R)

Grants theright to change the name of the object

The Browse right is the only NDS object right that is generally granted to users. The other object rights are used to manage the objects in the tree. The Supervisor object right implicitly grants the other four object rights as well as the Supervisor property right to "All Properties" (this is explained later). It should also be noted that deletion of an object requires the Write property right to "All Properties" in addition to the Delete object right.

As stated above, property rights are used to control how a trustee object can access the values of the various properties of an object. They are listed in Figure 4.

Figure 4: NDS property rights.


Right
Description

Supervisor (S)

Grants all rights to the property

Compare (C)

Grants theright to compare any value to a value ofthe property. With the Compare right, anoperation can return True or False, but youcannot see the value of the property.

Read (R)

Grants theright to read values of the property. TheRead right includes the Compare right.

Write (W)

Grants theright to add, change, or remove any valuesof the property. The Write right includesAdd Self.

Add/Remove Self (A)

Grants a trusteethe right to add or remove itself as a valueof the property. This right is only meaningfulfor properties that contain object namesas values, such as group membership listsand mailing lists.

Note: The Supervisor object right automatically allows the Supervisor property right for All Properties.

Rights can be granted to every property by using an "All Properties" assignment. Rights can also be granted to individual properties by using a "Selected Properties" assignment. Rights granted to a "Selected Property" will override any rights granted to "All Properties". The default rights granted to a user for her own User object are:

  • Browse object right to itself

  • Read property right to all properties

  • Read and Write to Login Script and Print Job Configuration properties

These rights allow a user to see herself in the NDS tree, read the value of every property, and change the values of the Login Script and Print Job Configuration properties. You must grant both R and W because an individual property right assignment overrides the All Properties assignment. If you wanted to give a user the ability to manage other properties, you would grant the RW rights for these properties. This might be reasonable for the telephone or address related properties. If you do not want a user to be able to change their login script or print job configuration, simply remove the selected properties assignment for that property and the rights will revert to those granted to all properties.

The Group Membership, Object Trustees (ACL), and Security Equivalences properties should be closely monitored because they are directly related to both NDS and file system security. Only object supervisors should possess the RW rights to these properties.

Access Control List

The Access Control List is to NDS what the Directory Entry Tables are to the file system. Whereas file system trustee assignments are stored in the Directory Entry Tables, NDS trustee assignments are stored in a property every object in the Directory tree contains, known as the Access Control List (ACL) property. The ACL is a property just like the Email Address or Telephone Number are properties. The ACL indicates which objects have been made an explicit trustee of an object and which rights they have been granted. The ACL lists who has access to a particular object or properties, not what the object might have rights to.

The ACL also contains the IRF for the object. The Write property right to the ACL of any object allows for complete control of the access to that object and is the highest level of right that can be granted to an object. Thus, this right should be carefully monitored.

Objects as Trustees

Any object can be a trustee of itself or of any other object in the Directory tree. Typical trustee objects are the four container objects - [Root], Country, Organization, and Organizational Unit - and the leaf objects - User, Group, and Organizational Role.

Unless you have particular need for elaborate security, there is no need to develop an elaborate NDS security structure. A few simple settings should be adequate to enable users and administrators to fully exploit the capabilities of NetWare 4. Because there are more ways to grant or acquire rights within NDS and within the file system, people perceive NetWare 4 as difficult to learn and to administer. Do not be intimidated by the variety of ways in which NDS and file system rights can be granted. The default rights assigned by the operating system will usually prove sufficient. The few exceptions to this rule are discussed below.

Containers as Trustees

A new concept in NetWare 4 security is the ability to assign both file system and NDS rights to containers. When rights are assigned to a specific container, all subcontainers and objects within that container receive these rights. In effect, if a container is listed in an object's complete NDS name, then is automatically acquires any file system or NDS rights that have been granted to that container.

To simplify understanding of this concept, think of containers as "natural groups" since their members do not have to be added to a group membership list, but they cannot be excluded either. Objects within a container receive an "implied" security equivalence to that container. Trustee assignments of the container are treated by the operating system just like trustee assignments of groups.

This has been called "ancestral inheritance" which is a misnomer because it has nothing to do with inheritance in NetWare terms. Inheritance - in NetWare terms - means that rights can be blocked by an IRF. You cannot place an IRF on the user to prevent receiving the rights from containers they belong to. A better term to describe this might be tree-positional rights. These are rights which are received by virtue of an object's position in the Directory tree.

In the following example, the OU=Acctg receives an explicit trustee assignment to SYS:APPS\ACCTG. All users in OU=Acctg and below also receive this assignment. This would be similar to creating a group called Acctg, making everyone a member, and then assigning the group the same file system rights (see Figure 5).

Figure 5: Using containers to assign files rights.

Granting rights to containers is generally done to assign file system rights. However, there are situations when NDS rights are assigned as well. An example of this is a container receiving the [ R ] property right to its Login Script property. This enables all users within that container to run the container login script because they have rights to it (see Figure 6).

Figure 6: Using a container to assign NDS rights.

Let's look at another example that may help clarify the assignment of container object rights. Say that the OU=Acctg is assigned [ B ] to OU=Mktg. All users within OU=Acctg will receive the same rights. Lisa's rights to OU=Mktg are therefore [ B ], as seen in Figure 7.

Figure 7: Objects below a container inherit the container's rights.

Now consider what happens if an IRF is added to the picture. If, for instance, an IRF is placed on any object below OU=Mktg, such as at CN=FS1, the rules of inheritance then apply (see Figure 8),because rights are being filtered out which have been granted at a higher level.

Figure 8: An IRF blocks inherited rights.

The [Public] Trustee. The [Public] trustee is a unique trustee. It is not an object, but a trustee assignment whose assignments are received by anyone requesting authentication to the network - even prior to logging in.

Use caution when assigning [Public] trustee assignments, as the [Public] trustee's rights are given to all network users as soon as they are attached to the network. Because it is not necessary to login to receive these trustee assignments, you should make no assignments to the [Public] trustee other than the defaults provide by NetWare 4 during the installation process. Initially, [Public] is granted the Browse right at the [Root] of the Directory tree. This enables everyone to use the Change Context (CX) command to move around the tree to find their correct context for logging in.

Avoid assigning excessive rights to the [Public] trustee because any actions performed by a user using only the [Public] access will not be recorded by the NetWare 4 Auditing Utility (AUDITCON).

Determining Effective Rights for NDS

For every NDS object, a user's effective rights to that object are determined by all of the following:

  • Explicit trustee assignments made to the object for that user

    plus

  • Any explicit trustee assignments made to any of the user's security equivalents (Groups, Organizational Roles, [Public], and containers it belongs to including [Root])

    plus

  • Any inherited rights from trustee assignments for source objects other than those for whom explicit trustee assignments have been made, minus any rights revoked by the IRF.

Default NDS Rights

An acceptable NDS security structure is easily implemented because most of the necessary rights are automatically assigned as the objects are created. The table below lists the rights assigned as each object is created and the rational behind that assignment.

Figure 9: NDS installation defaults.


Event-Object
Rights Assigned
Reason

Admin

[ S ] object to [Root]

Allows theuser Admin to administer every object inthe tree. This user will have Supervisorobject rights to every object in the treethrough inheritance unless that right isblocked at a lower level.

[Public]

[ B ] object to [Root]

Rights assignedto [Public] are passed to every object inthe tree, whether authenticated or not. Thismeans that every person who has establisheda connection to the tree can see every objectin the tree unless an IRF intervenes.

It should not be necessary to grant additional object rights to the user beyond the Browse right. This Browse right only allows a user to see the object in the Directory tree. An administrator may not want anyone to see which objects exist in a Directory tree before a user is logged in. In this case, the administrator may reassign [Root] the Browse object right instead of [Public].

Figure 10: NDS defaults for installation of a server.


Trustee
NDS Rights
File System Rights

Creator

[S ] objectrights to Server object

[Root]

[ R ] propertyrights to each Volume object's Host ServerName property and Host Volume Name property

[Public]

[ R ] propertyrights to Server's Network Address property

Container volumesare installed into

[ R ] propertyrights to Login Script property of that container

[ R F ] to SYS:PUBLIC

[ R F ] to SYS:DOC (optional)

[ RWCE F ] to SYS:NOVINI (optional)

The creator of a server automatically receives the Supervisor object right. This right also allows him or her to administer the file system because [S ] to a Server object implies [S ] to the file system. This administrative control over the file system and NDS can be separated by assigning the Supervisor object right for the Server object to the file system administrator and assigning only [ BR ] object rights and [ R ] property rights to the NDS administrator.

NDS needs to identify which server the volumes belong to, so it assigns [Root] the Read property right to the Host Server Name property. Because a volume's NDS name can be different from the name assigned to it during volume creation, it also assigns Read to [Root] for the Host Volume Name property.

Enough file system rights are automatically assigned to the container the volumes were installed into so that users within that container can login and map drives properly. The optional file system assignments refer to the installation of ElectroText and the NetWare 4 computer-based tutorial (CBT). If these are selected during server installation, file system rights are automatically assigned to the container the server is installed in.

Figure 11: NDS defaults upon creation of a user.


Trustee
NDS Rights
File SystemRights

[Root]

[ B ] objectrights to User object (only assigned if IRF has blocked the right)

[ R ] property rights to Network Address

[ R ] property rights to Group Membership

User

[ BR ] objectrights to itself

[ R ] to All Property Rights

[ RW ] property rights to Login Script property

[ RW ] property rights to Print Job Configuration property

[SRWCEFMA]to its home directory if one was selected at creation time

[Public]

[ R ] propertyrights to Default Server property

When the user is created, he receives enough rights to modify his login script and his print job configurations. If you do not want your users to modify their login scripts, you must revoke that right. The rights assigned to [Root] and [Public] enable all users to have read-only access to those properties.

Assigning Additional NDS Rights

Using NetWare 4's default NDS rights assignments allows users created in the same container as the server to login and use other system resources defined in the same container (such as print queues). The default installation is typical for organizations where the users will be in the same container as their most frequently accessed server. However, there may be scenarios where an administrator needs to assign additional NDS rights. Typical examples of this include the following:

  • Dividing the tree's administration

  • Assigning profile login scripts

  • Creating Directory Map objects

  • Allowing users to login as aliases in containers other than where their original object is stored.

  • Establishing special types of users such as mailing list administrators

Dividing Subtree Administration

Because the NDS database is a global database (that is, it contains the information for the entire network), it may have containers representing geographically diverse organizations. It is usually more convenient to use local NDS and file system administrators than to have only one central administrative authority. There are three general ways of dividing subtree administration: using one administrator per branch, using multiple administrators per branch, or using a "workgroup" type assistant administrator. The manner you prefer will depend on the needs of your organization.

Single Administrator. Depending on the security requirements of your organization, you may require only one user to have administrative rights to a particular branch. If this is the case, it may be necessary to cut off any rights inherited by the original Admin user. To do so, complete the following steps.

  1. Assign the subtree administrator as an explicittrustee of the container to be administered:

    [SBCDR] object rights and [SRCWA] property rights

    Make sure you assign all rights, not just [S ], to ensure that total administration of a branch is still possible even if [S ] is filtered by an IRF.

  2. Revoke inherited rights so the original Admindoes not inherit rights to the container.

    Set the IRF for the container to [ B ] object rights and [ R ] property rights.

    Do not revoke the Browse object right as you may still want to allow other users to see that part of the tree.

  3. Remove any trustee assignments to the container for the original Admin user.

  4. Ensure that the subtree administrator has [S ] object rights to himself, and then remove any trustee assignments for the original Admin so he may not restrict the subtree administrator's rights.

Figure 12: single administrator.

It is imperative that you assign explicit trustee assignments which include [S ] before revoking the [S ] right using the IRF. If you attempt to revoke the [S ] right without any explicit trustee assignments, the utilities will prevent you from doing so. However, it is still possible to lose total control over a branch of the tree if the only user with the [S ] explicit trustee assignment is deleted.

Note: There is a procedure in place that allows network Admin's to regain control over a branch, but it requires the intervention of Novell technical support (calling 1-800-NETWARE at a cost of $150 per incident).

Multiple Administrators. If your organizational needs call for multiple administrators per branch, then you will need to grant each administrator the appropriate rights to the container. Do this by completing the following steps:

  1. Assign each subtree administrator as an explicit trustee of the container to be administered:

    [SBCDR] object rights and [SRCWA] property rights

    Make sure you assign all rights, not just [S ], to ensure that total administration of a branch is still possible even if [S ] is filtered by an IRF.

  2. If the original Admin is not going to administer this branch, then revoke inherited rights so the original Admin does not inherit rights to the container.

    Set the IRF for the container to [ B ] object rights and [ R ] property rights.

    Do not revoke the Browse object right because you may still want to allow other users to see that part of the tree.

  3. If the original Admin is not going to administer this branch, then remove any trustee assignments to the container for the original Admin user.

  4. If the subtree administrators need to be independent of each other (i.e. they cannot manage each other), then ensure that each sub-tree administrator has [S ] object rights to himself, and then remove any other user's trustee assignments for each subtree administrator and block inherited rights by setting the IRF of each independent subtree administrator to [ B ] object rights and [ R ] property rights.

Workgroup Manager. Your organization may have security needs that require central administration but also allow for workgroup or departmental management. As seen in the first example, it is possible to cut off administrative control to a branch of the tree. It is therefore imperative to set up security so that if the administrator of a branch leaves the company under unfavorable circumstances, the resources in that branch can still be administered.

To prevent cutting off administrative control from a branch of the tree, complete the following steps:

  1. Assign the workgroup manager as an explicit trustee of the container to be administered:

    [ BCDR] object rights and [ RCWA] All Properties rights [ CR ] ACL Property rights

    Reassignment of the ACL property rights override the rights assigned to All Properties rights, preventing the workgroup manager from changing trustee assignments to the container.

  2. Ensure Admin has explicit trustee assignment to the container by assigning:

    [SBCDR] object rights [SRCWA] All Properties rights

  3. Assign Admin an explicit trustee assignment to the workgroup manager.

    [SBCDR] object rights [SRCWA] All Properties rights

  4. Revoke all inherited rights except B to the workgroup manager so that the workgroup manager does not inherit rights to manage himself.

    IRF [ B ] object rights only

  5. Reassign the workgroup manager's rights to himself so that he cannot assign himself more rights. This gives the workgroup manager the same rights to manage himself that a user has by default.

    [ B ] object rights [ R ] All properties [ RW ] Login script property [ RW ] Print job configuration [ CR ] ACL property

Figure 13: Workgroup manager.

What makes this scenario work is the workgroup manager's inability to change trustee assignments for a container through restricted access to this container's ACL property.

Assignment of Profile Login Scripts

Profile login scripts are used when groups of users need common working environments. These users may be in different containers. The profile login script allows them to share a login script. In order to run a profile login script, users who have it assigned to them need to be able to read the login script property of the Profile object. The Profile object can have file system rights assigned to it. These rights do not pass to the user. They are there so that the Profile object can execute the INCLUDE and DISPLAY commands of a login script which require reference to a file.

There are no default rights assigned to a Profile object upon its creation. Assign these rights by completing the following steps:

  1. Create the Profile object.

  2. Fill in the profile login script property.

  3. For each user who will run the profile login script, assign the profile as their profile login script.

  4. Make each user who will run the script a trustee with the [ B ] object right and the [ R ] Login script property right. It is usually easier to assign these rights to the container in which the users are located or to a Group object.

Directory Map Objects

Directory Map objects are used for mapping to a pointer to a directory rather than a directory itself. When using Directory Map objects, users must be able to read the properties that point to the actual directory. You must ensure that the user has the [ R ] All Properties rights to the Directory Map object. Since there are no default rights assigned to a Directory Map object upon its creation, these rights will need to be explicitly assigned. Again, for Directory Map Objects it usually easier to assign these rights at the container or group level.

The Directory Map object can also have file system rights assigned to it. These rights are not automatically passed to the user. However, if users are assigned as security equivalent to a Directory Map object the system administrator can easily relocate an application as well as reassign the file system rights of those users by simply changing the values of the Directory Map object.

Alias Logins

In NetWare 4.01, a user may have an Alias object created for it. When a user logs in as an Alias object, the user runs the system login script belonging to the container the Alias is in. If you create a user Alias in a different container than an original object, you need to assign the Alias object rights to run the new container's login script. To do so, assign the Alias object [ R ] to the container's Login Script property. In a future version of NetWare 4, this will change so that an Alias of a user will execute the container login script of the original user.

Special Users: Mailing List Administrator

The mailing list administrator role is repetitive to set up. Since the user will be managing properties of individual User objects, assignment must be made to individual users. You are unable to assign the administrator to a group of users because then he or she would be managing the properties of the Group object rather than the User objects. You also may not assign rights to the mailing list administrator using the All Properties rights selection because that would include too many rights (including the ACL property).

Following is a list of rights that the mailing list administrator would typically assign for each User object he or she is responsible for:

Email address [ R W] Phone number [ R W] Fax number [ R W] Address [ R W]

It is important to understand the implications of assigning the [RW] right through the All Properties option. Remember that "All Properties" includes the object ACL property. The [ W ] right to an object's ACL property controls who can change trustee assignments to that object. As we discussed earlier, this is the most powerful right that an object trustee can have. Someone with the [ W ] right to the ACL property can also assign others rights to the directory. If we were to make this assignment, the mailing list administrator would have more rights than were originally intended.

Effects of NDS Rights on File System Rights

NDS rights do not "flow" into the file system. The only exception to this rule involves the Server object. Anyone with the Supervisor object right or Write property right for the ACL property will automatically have the Supervisor file system right to every volume attached to that server.

NDS Rights Needed for Printing

NetWare 4 printing is managed similarly to NetWare 3.1x printing. Management is done through users and operators. No NDS rights are required. To manage a print server, you need to be a print server operator. To manage print queues, you need to be a print queue operator. To print to a printer or print queue, you need to be a print queue user.

By default, the container the queue is created in is made a print queue user. All users within that container can therefore print to the queues in their own containers.

File System Security

File system security in NetWare 4 is essentially the same as it was with NetWare 3.1x. There are three minor changes:

  1. The Inherited Rights Mask (IRM) is now referred to as the Inherited Rights Filter (IRF), but it behaves the sameway as the IRM.

  2. Additional attributes (marked by an asterisk in Figures 16 and 17) and attribute status flags (see Figure 18) have been added to accommodate the new data migration and file compression features of NetWare 4.

  3. Rights assigned to user home directories at user creation time now include the Supervisory file right as well as all other rights.

Figure 14: File system directory rights for NetWare.


Right Name
Abbreviation
Meaning

Supervisor

S

Grants allrights to the directory, its files, and itssubdirectories. The Supervisor right overridesany restrictions placed on subdirectoriesor files with an Inherited Rights Filter.Users who have this right in a directorycan grant other users Supervisor rights tothe directory, its files, and its subdirectories.

Read

R

Allows thedirectory to be opened and read.

Write

W

Allows usersto open and write files. Displaying existingfiles is not possible without Read authorization.

Create

C

Allows usersto create directories and files. Write authorizationis required in order to write data to anycreated file. If the user has Write and Createauthorization, he can create a file and writedata into this file. As soon as the filehas been closed, it can no longer be reador modified without Read authorization.

Erase

E

Allows usersto delete a directory, its files, and subdirectories.

Modify

M

Allows usersto change directory and file attributes (withFile Scan). This also grants the right torename the directory,its files, and its subdirectories.This does not grant the right to modify anyfile's contents.

File Scan

F

Allows users to see files.

Access Control

A

Allows usersto change directory trustee assignments andthe Inherited Rights Masks for directories.This also allows users to modify file trusteeassignments. Users can grant any right (exceptSupervisory) to any other user, includingrights that they themselves have not been granted.

Figure 15: File system file rights.


Right Name
Abbreviation
Meaning

Supervisor

S

Grantsall rights to the file. Users who have thisright can grant any file right to anotheruser and can modify all the rights in thefile's Inherited Rights Mask.

Read

R

Allowsthe file to be opened and read.

Write

W

Allowsthe file to be opened and written to.

Create

C

Allowsthe file to be salvaged, after the file has been deleted.

Erase

E

Allowsthe file to be deleted.

Modify

M

Allowsthe file's attributes to be changed, andthe file to be renamed. This does not allowthe contents of the file to be modified.

File Scan

F

Allowsthe file to be seen when viewing the contents of the directory.

Access Control

A

Allowsthe file's trustee assignments and InheritedRights Mask to be modified. Users who havethis right can grant any right (except Supervisory)to any other user, including rights thatthey themselves have not been granted.

Figure 16: File system directory attributes.


Attribute
Abbreviation
Meaning

*Don't Compress

Dc

Addedto a directory, this attribute keeps allfiles within the directory from being compressed.

Delete Inhibit

Di

Preventsusers from erasing directories even whenthey have been granted the Erase trusteeright. If the user has been granted the Modifytrustee right, he can remove this attributefrom the directory.

*Don't Migrate

Dm

Addedto a directory, this attribute will not allowfiles within the directory to be migratedto secondary storage.

Hidden

H

Hidesdirectories from DOS DIR scans. NetWare'sNDIR program will display these directoriesif the user has appropriate File Scan rights.

*Immediate Compress

Ic

Addedto directories, this attribute alerts thefile system to compress a file as soon asthe operating system can handle the action.

Normal

N

Normalflags a directory as Read/Write and nonshareable.It removes most other flags.

Purge

P

Whenthis attribute is assigned to a directory,NetWare will automatically purge all filesin the directory after they have been deleted.

Rename Inhibit

Ri

Preventsusers from renaming directories even whenthey have been granted the Modify trusteeright. However, if the user has been grantedthe Modify trustee right, he can remove thisattribute from the directory in order torename the directory.

System

Sy

Hidesdirectories from DOS DIR scans and preventsthem from being deleted or copied. NetWare'sNDIR program will display these directoriesas System if the user has appropriate FileScan rights.

Figure 17: File system file attributes.


Attribute
Abbreviation
Meaning

Archive Needed

A

Identifiesfiles modified after last backup. NetWareassigns this bit automatically. This is DOS's Archive bit.

Copy Inhibit

Ci

Restricts thecopy rights of only users logged in fromMacintosh workstations. Even if these usershave been granted Read and File Scan trusteerights at the directory or file level, theywill not be able to copy the file. If theuser has the Modify right, he can then modifythis file attribute to allow copying.

*Don't Compress

Dc

Keeps datafrom being compressed. This attribute overridessettings for automatic compression of filesnot accessed within a specified number of days.

Delete Inhibit

Di

Restricts thedelete rights of only users logged in fromMacintosh workstations. Even if these usershave been granted the Erase trustee rightat the directory or file level, they willnot be able to copy the file. If the userhas the Modify right, he can then modifythis file attribute to allow deleting.

*Don't Migrate

Dm

Prevents filesfrom being migrated from the server's harddisk to another storage medium.

Hidden

H

Hides filesso they can't be seen using the DIR command.They can be seen if a user with File Scanrights uses the NDIR command.

Index

I

This indicatesto the NetWare operating system that thisfile's FAT entries are to be indexed in servermemory for faster file access. NetWare 4will automatically index any file with morethan 64 File Allocation Table (FAT) entries.

*Immediate Compress

Ic

Sets data tobe compressed as soon as a file is closed.

Normal

N

While thereis not an N attribute bit for file attributes,if you flag a file as N(ormal) this willflag the file as Read/Write (see Read/Writebelow). This is the default setting for files.

Purge

P

When this attributeis assigned to a file, NetWare will automaticallypurge the file after it has been deleted.

Rename Inhibit

Ri

Prevents thefile name from being modified.

Read Only

Ro

Prevents afile from being modified. This attributeautomatically sets Delete Inhibit and RenameInhibit.

Read Write

Rw

Allows youto write to a file. All files are created with this attribute.

Shareable

S

Allows severalusers to access a file simultaneously. Thisattribute is normally used with the ReadOnly attribute, so that a file being usedby other multiple users cannot be modified.

System File

Sy

Hides thesefiles from DOS DIR scans and prevents themfrom being deleted or copied. NetWare's NDIRprogram will display these directories asSystem if the user has appropriate File Scan rights.

Transactional

T

Allows a fileto be tracked and protected by the Transaction Tracking System (TTS).

Execute Only

X

Prevents thefile from being copied, modified, or backedup. This attribute cannot be removed unlessthe file is deleted. Used for program filessuch as .EXE or .COM files.

Figure 18: New file attribute status flags in NetWare 4.


Attribute
Abbreviation
Definition

Compress

Co

Status flagthat indicates the file is compressed.

Can't Compress

Cc

Status flagthat indicates the file cannot be compressedbecause of limited space savings.

Migrated

M

This statusflag indicates that the file has been migrated.

Determining File System Effective Rights

The method for determining file system effective rights is the same as determining them in NetWare 3.1x. The only additional considerations are who can be a trustee. For file system rights, a user's effective rights to a directory are determined by:

  • The Supervisory right to a directory, which allows all rights to a directory and all subsequent subdirectories and files below that directory. The Supervisory right cannot be reassigned nor can it be revoked by an IRF.

  • Any explicit user trustee assignments to a directory.

  • Any explicit user trustee assignments made for a group or organizational role the user is a member of, security equivalent to, or container it is a member of.

  • Any inherited rights from trustee assignments for the objects other than those for whom explicit trustee assignments have been made, minus any rights revoked by the IRF for that directory.

File system rights may be assigned at the directory and the file level. Rights assigned to directories are automatically assigned to all files in that directory. Rights assigned to specific files overwrite any rights inherited from the directory level.

Assigning Additional File System Rights

The criteria for assigning additional file system rights in NetWare 4 is very similar to that for previous versions of NetWare. The system administrator will have to assign additional file system rights for:

  • Applications and data files users need access to

  • Users that are not installed in the same context as the server and thus do not acquire file system rights to SYS:PUBLIC

Applications and Data Files

When installing new applications on a server, file system rights must be assigned so that users may access them. In addition, remember that users need a separate area to store data files, which they need access to these as well. This is usually done by assigning a home directory for each user.

Users Not in the Same Context as the Server

By default, the Read and File Scan rights are assigned for SYS:PUBLIC to the container the server is installed in. If users are created outside of this container, they will not inherit these rights. These file system rights must be assigned elsewhere in order for users to execute the drive mappings of the default login script.

The same problem occurs when users attach to a server other than the one installed in their context. When drive mappings in a login script do not specify the server (as is the case of the default login script), drive mappings will be attempted on the server the user attached to when logging in. This may not be the server these mappings are desired on. Thus it is usually a good practice to prevent the default login script from running and to explicitly control the drive mappings involved.

Where to Assign File System Rights

With NetWare 4 you have more choices on where to assign rights. You can assign rights to containers, Groups, Organizational Roles, Users, and the [Public] trustee. Where rights are assigned depends on what your organization needs.

[Root]. In a small network environment where all users may need access to all servers, file system rights to SYS:PUBLIC may be assigned at the [Root] object. In addition, rights to common applications - like WordPerfect or Lotus 1-2-3 - may be assigned to the [Root] object. In this case, all users will acquire these rights.

This is a prime example of tree-positional rights. All users will acquire these rights because of their position in the tree. Rights assigned to a container are implicitly assigned to all objects under that container. In this specific instance, the container is [Root], so all objects in the entire tree will acquire these rights.

Assigning rights at the [Root] eliminates redundancy in making trustee assignments. It also allows users to easily run common applications from different servers if their primary server is down.

On larger networks, assigning file system rights at the [Root] object may be efficient by allowing users that travel from one location to another to map to applications that are running locally rather than having to use their applications over a wide area network (WAN).

However, administrators may not want to assign extensive NDS rights at the [Root] object because these rights will be received by all users. Remember that most NDS rights are management rights and users - other than the administrator - do not require these rights. The most likely NDS right to be assigned at the [Root] is the Browse right so that users may see the other objects in the tree. This done automatically during the server installation when the [Public] trustee receives the Browse right to [Root].

Organization. Assigning rights to an Organization object is similar to assigning them at the [Root] level. Rather than assigning rights network-wide (where the network may be spread around the globe), rights assignments may be segregated by divisions or locations designated by the Organization (O) object. The advantage of assigning rights to an Organization object rather than to the [Root] here would be the unnecessary rights assignment for O=Japan to the servers located in Australia, France, and the U.S.

The same argument described under NDS rights assignments to [Root] applies to NDS rights assigned at the Organization level.

Organizational Unit. The use of Organizational Unit objects starts to provide additional flexibility in rights assignments. File system rights assigned at the OU level are common for servers shared on a departmental basis. Rights to more applications and data files will be assigned at the Ous closer to the User objects.

For example, when accounting applications are shared by both the A/R and A/P departments (each of which has its own OU under the OU=Accounting), the assignments could be made in the parent OU of the two departments.

Try to maximize the amount of rights assigned to containers since all users automatically receive these rights. However, for the same reason, be careful not to assign too many rights to containers.

Group or Organizational Role. When you are unable to assign rights at the container level due to the sensitivity of the data, it may be necessary to create Group and Organizational Role objects for such assignments. File system rights to these objects are also practical for specialized servers, such as an application server or database server where only a subset of all users need access to the file system. Remember to add the necessary users to the Organizational Role or Group.

Directory Maps and Profiles. Even though these have a property called "Rights to the File System," this is not a proper way to assign rights. File system rights granted to Directory Maps and Profiles are not transferred to users mapping to the Directory Map object or to those using the Profile Login Script.

Assigning File System Rights

NetWare file system rights may be assigned in the following ways:

  • On the Volume object

  • As trustee of a root directory

  • As trustee of a subdirectory

  • As trustee of a file

  • Through User, Group, Organizational Role, or container objects

File system rights can be granted by using the following utilities:

  • The NWAdmin GUI utility

  • The NETADMIN text-based utility

  • The FILER menu utility

  • The RIGHTS command line utility:

    RIGHTS [path][+|-] rights[NAME|GROUP]=

* Originally published in Novell AppNotes

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.

© Copyright Micro Focus or one of its affiliates