Designing NetWare 4.x Security

Articles and Tips: article

PAULA MOREIRA
Senior Technical Instructor
Novell Education

01 Nov 1993

Since the introduction of NetWare Directory Services in NetWare 4.x, a sense of mystique and fear has surrounded the complexity of administering security on this new operating system. This AppNote demystifies the implementation of NetWare 4.x security and demonstrates that the operating system itself handles many default rights assignments, allowing the network administrator to administer additional security with minimal effort.

Introduction
Security Concepts Review
NDS Security
Designing Security for a Complex Network
Assigning Additional NDS Rights
Assigning Additional File System Rights
Where to Assign Rights
Troubleshooting Rights
Summary

Introduction

NetWare 4.x 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 enables users to run application programs and access their data files. The NetWare 4.x file system security is essentially the same as file system security in NetWare 3.11. A few attributes have been added and some terminology has been changed, but the functionality remains the same: to provide users with 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.11, they also included such tasks as assigning trustee rights and creating a workgroup manager or a console operator.

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

Figure 1: 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.x is the ability to separate file system administration from NDS administration. The user who administers the NDS tree and its objects does not need to have any file system rights and 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.x 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 wouldn't 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 better serve their needs than the Dusseldorf administrator can.

With the flexibility in NetWare 4.x security, you do not have to have separate file system and NDS administrators, or even different administrators for different sites. If you prefer, you can continue to administer your NetWare 4.x network in a NetWare 3.x-like fashion, with one central Admin account with omnipotent power over both NDS and the file system. For this type of administration, this AppNote will help you understand how rights have been assigned and how to implement rights for your other users.

In this AppNote we will:

Review security concepts which affect file system and NDS security.
Review file system security and note the differences in implementation in NetWare 4.x.
Introduce NDS security.
Discuss the default security assignments NetWare 4.x makes for certain events like file 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 distributionof 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 we delve into NDS security per se, we need to review the following concepts which affect both file system and NDS security in NetWare 4.x:

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.x, 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 doesn't seem practical - a printer being made a trustee of a Volume object doesn't make sense, but it can be done.

It is impractical to have to assign each user rights to every network resource, file, or NDS object. For that reason, NetWare 4.x 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 subsequent child containers until they are reassigned or filtered.

We can prevent the inheritance of rights down a directory structure or 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.

A user may gain rights to files and the NDS tree through security equivalence to other objects. The user is also assigned rights to its own user object, group objects it may be a member of, and organizational role objects it may be an occupant of.

When User A is security equivalent to another user, User A receives rights to any objects or files the other user has explicit trustee assignments to. NetWare 4.x considers all security equivalences of the user from 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.

File System Security Changes

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

The Inherited Rights Mask (IRM) is now referred to as the Inherited Rights Filter (IRF), but it behaves the same way as the IRM.
Additional attributes have been added to accommodate the new data migration and file compression features of NetWare 4.x (see Figure 2).
Rights assigned to user home directories at user creation time now include the Supervisory file right as well as all other rights.

Figure 2: New attributes in NetWare 4.x.

Attribute	Abbrev.	Definition
Compress	Co	Status attributethat indicates the file is compressed.
Can't compress	Cc	Status attributethat indicates the file cannot be compressedbecause of limited space savings.
Don't Compress	Dc	Added to adirectory, this attribute keeps all fileswithin the directory from being compressed.This attribute can also be added to a specificfile.
Immediate Compress	Ic	Added to directoriesor files, this attribute alerts the filesystem to compress a file as soon as theoperating system can handle the action.
Migrated	M	This statusattribute indicates that the file has been migrated.
Don't Migrate	Dm	Added to adirectory, this attribute will not allowfiles within the directory to be migratedto secondary storage. This attribute canalso be added to a specific file.

Determining File System Effective Rights

The method for determining file system effective rights is the same as determining them in NetWare 3.11. 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 revoked by an IRF or reassigned.
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 File System Rights

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

On the Volume object
As trustee of the root directory
On directories
As trustee of a directory
Through User, Group, Organizational Role, or container objects
As rights to the file system property

The following utilities can be used:

The NWAdmin GUI utility
The NETADMIN text-based utility
The FILER menu utility
The RIGHTS command line utility:
```
RIGHTS [path] [+|-] rights[NAME|GROUP]=
```

NDS Security

NDS security affects how users see, use, and manage such network resources as printers, users, and groups. There are two levels of NDS security: object rights and property rights.

Object Rights

Object rights control how a user can manage an object. They allow a user to see, create, rename, or delete objects in a container. The object rights are shown 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 (can only be assignedto 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

In order to see what resources are available on a network, users need the Browse right. The Browse right is assigned automatically during file server installation to allow users to see the Directory tree. Users do not need object rights to themselves in order to login. The Create, Delete, and Rename object rights are generally assigned only to users who will be managing part of the Directory tree.

Property Rights

Property rights affect how a user can access information about an object. Property rights allow users to see, search for, or change the values of such properties as Other Names, Fax Number, Mailing Address, Phone Number, or Email Address. Property rights may be assigned to all of an object's properties collectively through the "All Properties" option. This is similar to assigning rights to a file system directory - all files within that directory receive the same rights.

Property rights may also be assigned selectively - different rights to different properties. For example, a user may be assigned [ RC ]to Title, but [ R W ] to their Login Script property. Property rights assigned through the "Selected Properties" option override those assigned through the "All Properties" option for that property only.

The property rights are shown 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 includes Add 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.

The 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 who has been made an explicit trustee of an object and which rights they have been assigned. The ACL lists who has access to the particular object or properties, not what the object might have rights to.

One of the most confusing aspects of NDS rights is that there are more rights than we know what to do with. For instance, you can assign the Add Self property right to the Login Script property. While doing this may not make sense, it is important to know that NetWare 4.x will allow you to do such things. You also need to understand what rights are needed in order to perform various tasks. The last part of this AppNote will help you determine additional rights that may be required.

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 the objects other than those for whom explicit trustee assignments have been made, minus any rights revoked by the IRF.

NDS Security Examples

To help you understand NDS security so far, following are some practical examples of how rights and trustee assignments work.

Explicit Trustee Assignments Explicit trustee assignments continue to flow down the directory tree until they are reassigned (see Figure 5).

Figure 5: Reassignment of explicit rights.

Explicit Trustee Assignments plus Security Equivalent Trustee Assignments. Explicit trustee assignments for Groups, Organizational Roles, and the [Public] trustee are added to those of the User object (see Figure 6).

Figure 6: Effective rights equal user's explicit assignments plus security equivalent assignments.

Even though the explicit trustee assignments for Groups, Organizational Roles, and the [Public] trustee are added to those of the User, they flow down the directory tree independently (see Figure 7).

Figure 7: Rights flow independently.

Inheritance

Besides a user's ability to inherit rights to child containers they have been assigned to, there are additional considerations with NDS rights inheritance:

Only object rights and property rights assigned using the "All Properties" rights are inherited.
Rights assigned to "Selected Properties" override those assigned by "All Properties". This is similar to how rights assigned to individual files in a file system directory override those assigned to the directory the file is contained in (see Figure 8).

Figure 8: NetWare Administrator "trustees of this object" dialog box.

Inherited Rights Filter

The Inherited Rights Filter (IRF) is used to block inherited rights from flowing down the Directory tree. For example, the IRF can be used to restrict access to a sensitive area of the Directory tree. When this is done, only users with explicit trustee assignments may access that part of the Directory tree (see Figure 9).

Figure 9: Inherited rights filter.

Containers as Trustees

A new concept in NetWare 4.x 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.

To simplify understanding of this concept, think of containers as "natural groups" since their members do not have to be added to the group membership list, but they can't 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. Users receive these trustee "rights" as if they were their own.

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.

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 10).

Figure 10: 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 11).

Figure 11: Using 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=Mktg will receive the same rights. Lisa's rights to OU=Mktg are therefore [ B ], as seen in Figure 12.

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

Now consider what happens if an IRF is added to the picture. Thus, if an IRF is placed on any object below OU=Mktg, for instance at CN=FS1, the rules of inheritance then apply (see Figure 13).

Figure 13: 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. It is not necessary to login to receive these trustee assignments. 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 Auditing.

It is preferable to remove [Public] as a trustee and use other objects as trustees. Also, [Public] should not be used for the assignment of file system rights. For this reason, DSREPAIR removes any [Public] trustee assignments.

Effects of NDS Rights on File System Rights

Under normal circumstances, NDS rights are independent of the file system rights. For instance, Browse to a Volume object is not the equivalent of the File Scan right to the volume's files. Also, users do not need any NDS rights in order to use the file system.

The only exception to this rule is the Writer property right to the ACL property of a Server object. Normally this right is implied through the assignment of the Supervisor object right. The Write property right provides the trustee with Supervisor file system rights to all volumes on that server. If you would like to separate these assignments but still allow a user to manage the Server objects, assign them all object rights except Supervisor, All Properties rights of [ RCWA], and Selected Property rights [ RC ] to the ACL property.

Designing Security for a Complex Network

Because of the complexity of its levels of security, NetWare 4.x implements some default rights when objects are installed. This is done to help the Admin in administering rights. In order to implement additional rights as needed without duplication of effort, it is important to understand which rights are assigned by default.

Even though NDS rights are independent of file system rights, NetWare 4.x may automatically assign both NDS rights and file system rights during the creation of certain objects. During network installation certain default rights are established.

Default Rights Assignments

The following are default rights assignments that are assigned at certain events.

Event: Installation of NDS

Trustee	NDS Rights	FileSystem Rights
Admin	[S ]object rights to [Root]
[Public]	[ B ]object rights to [Root]

Admin receives the Supervisor object right to the [Root], which allows it to initially administer the Directory Tree. Later on, this trustee assignment may be removed and subtree administrators created.

Any trustee assignments made to the [Public] trustee are available to users before they log in. Assigning the [Public] trustee the Browse right allows users to "look" through the tree using the CX command prior to logging in. This allows a user to find his or her correct context with which to log in. This trustee assignment may also be removed after installation for network security.

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 later on assign [Root] the Browse object right.

Event:Installation of a file server

Trustee	NDS Rights	File System Rights
Creator	[S ]object rights toServer object
[Root]	[ R ]property rights toeach Volume object'sHostServer Name property andHost Volume Nameproperty
[Public]	[ R ]propertyrights to Server'sNetwork Address property
Container	[ R ]propertyrightsto the Login Script property of that container
Containervolumesareinstalled into		[ 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 removing the trustee assignment and reassigning only [ BCDR]object rights and [ CRWA]object rights.

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.x CBT. If these are selected during file server installation, file system rights are automatically assigned to the container the file server is installed in.

Event:Creation of a user

Trustee	NDS Rights	File System Rights
[Root]	[ B ]objectrights toUser object [ R ]propertyrights toNetwork Address [ R ]property rights toGroup Membership
User	[ B ]objectright to itself [ R ]toAll Property Rights [ RW ]propertyrights toLogin Script property [RW ]property rights toPrintJob Configuration property	[SRWCEFMA]to its home directory if one was selectedat creation time
[Public]	[ R ]propertyrights toDefault Server property

When the user is created, it receives enough rights to modify its login script and its print job configurations. If you don't want your users to modify their login scripts, you must revoke that right.

Assigning Additional NDS Rights

As you can see, many of the default rights assignments are handled by NetWare 4.x. Using NetWare 4.x'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
Establishing special types of users such as mailing list administrators
Assigning profile login scripts
Creating directory map objects
Allowing users to login as aliases in containers other than where their original object is stored.

Dividing Subtree Administration

There are two general ways of dividing subtree administration: using only one administrator per branch, or using a "workgroup" type of assistant administrator. The manner you prefer will depend on the security 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. This is a typical government requirement. If this is the case, it may be necessary to cut off any rights inherited by the original Admin user. To do so, follow these steps.

Assign user Tom an explicit trustee assignment to OU=ENG of:

[SBCDR]object rights and [SRCWA] property rights

Make sure you assign allrights, not just [S ], to ensure that total administration of a branch is still possible even if [S ]is filtered by an IRF.
Revoke inherited rights so the original Admin does not inherit rights to OU=ENG.

Set the IRF 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.
Remove any trustee assignments to OU=ENG for the original Admin user.
Ensure that Tom has [S ] object rights to himself, and then remove any trustee assignments to CN=Tom for the original Admin so he may not restrict Tom's rights.

Figure 14: A 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.

Workgroup Manager. Your organization may have security needs that require central administration but also allow for workgroup or departmental management. As seen in the previous 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, perform the following steps.

Assign user Tom an explicit trustee assignment to OU=ENG of:

[ BCDR]object rights and [ RCWA] All Properties rights

[ RC ]ACL Property rights

Reassignment of the ACL property rights override the rights assigned to All Properties rights, preventing CN=Tom from changing the trustee assignments to OU=ENG and thus preventing him from deleting himself or anyone else from the ACL.
Ensure Admin has explicit trustee assignment to OU=ENG by assigning:

CN=Admin to OU=ENG [SBCDR]object rights[SRCWA] All Properties rights
Assign Admin an explicit trustee assignment to CN=Tom.

CN=Admin to CN=Tom [SBCDR]object rights[SRCWA] All Properties rights
Revoke all inherited rights except B to object CN=Tom so that Tom does not inheritrights to manage himself.

IRF [ B ]object rights only
Reassign Tom's rights to himself so that he cannot assign himself more rights.

CN=Tom to CN=Tom [ B ]object rights[ R W ] Login script property[ R W ]Print job configuration [ RC ]ACL property

Figure 15: Workgroup manager.

What makes this scenario work is Tom's inability to change trustee assignments to OU=ENG through restricted access to this container's ACL property.

Assignment of Profile Login Scripts. Profile login scripts are used when multiple users in different containers need common working environments. 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 assignment of profile login scripts when the profile and the user objects are in the same container does not require additional rights. Under normal circumstances, the users needing a common profile script will not be in the same container and so those users will need to be assigned additional rights to the profile object. Assign these rights by completing the following steps:

Create the profile object.
Fill in the profile login script property.
For each user who will run the profile login script, assign the profile as their profile login script.
Make each user who will run the script a trustee with the[ B ] object right and the [ R ]Login script propertyright.

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. When using Directory Map objects, you must ensure that the user has the [ R ] All Properties rights to the Directory Map object.

Alias Logins. 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.

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]

You need to understand the implications of assigning the [ R W ] 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. This is similar to having the Access Control file system right to a directory. Someone with this right can assign others rights to the directory. 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.

NDS Rights Needed for Printing

NetWare 4.x printing is managed similarly to NetWare 3.11 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.

Assigning Additional File System Rights

The criteria for when to assign additional file system rights in NetWare 4.x 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 are not installed in the same context as the file server and do not inherit 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.

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 file server is installed in. If users are created outside of this same 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. A typical error message indicating that a user does not have enough file system rights to SYS:PUBLIC is the message "Current drive is not valid>".

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 file server the user attached to when logging in. This may not be the file server these mappings are desired on.

Where to Assign Rights

With NetWare 4.x 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 file 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 inherit 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 should their primary server be 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 file 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 company wide, where the company may be spread out 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 file servers located in Australia, France, and the U.S.

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

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 file 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.

Note: Any file system or NDS rights assigned to a container are automatically inherited by all users in that container.

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

Do not assign file system rights to Directory Map objects and Profile objects. Even though these have a property called "Rights to the File System," this is not a proper way to assign rights. Rights assigned here are not inherited by users mapping to the Directory Map object or to those using the Profile Login Script.

Troubleshooting Rights

Because of these added levels of security, it may be a bit more complicated to figure out misplaced rights assignments. The following are some guidelines to help you in troubleshooting rights. These troubleshooting methods may apply to both NDS and file system security.

Scenario: Too many rights

Check explicit trustee assignments for:

- User object - Groups and Organizational Role the user is a member of - Security Equivalences the user may have - Containers the users is in up the tree to the [Root]
Check the user's inherited rights from explicit trustee assignments from objects in #1.
Check the trustee assignments made to that container or directory, using the indicated utility.

At the container level, check Trustees of this Object with NetAdmin or NWAdmin

For a directory, use FILER or the RIGHTS command
```
RIGHTS  [path] /TRUSTEE
```
Check whether the user is in containers, groups, or security equivalents who have rightsto the container or directory.

Scenario: Not enough rights

To determine why a user may not be receiving rights to a container or directory, you need to ask the following questions:

1.How do you expect theuser to be receivingrights? Through the following:

Group/OrganizationalRole	Has the userbeen made a member/occupant?
Security Equivalence	Has he or she been made a security equivalent?
Container	Has the container been assigned rights?

Also, are you sure everyone in that containershould receive rights?

YES:	Make the assignment at the container level
NO:	Create a group and assign the group rights

In addition, should other users have the same rights?

YES:	Consider assigningthe parent container the necessary rights.
NO:	No action required.

2. Is there an Inherited Rights Filter placedat the container or directory in question?

YES:	Make an explicit trusteeassignment to the container or directory.
NO:	Check the parent containers for IRFs and then make explicit assignments.

Summary

This AppNote has introduced NetWare 4.x file system and NDS security and explained the default rights assignments. It has also detailed cases in which you might need to assign additional security beyond the defaults. This information should help network administrators to take full advantage of the powerful security features in NetWare Directory Services.

* 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.