There was a time when the mention of the term local area networking meant Novell to most IT managers. In the early 1980s, Novell introduced an operating system that allowed users of personal computers to communicate with each other and share files and printers. By today’s standards, this may not seem like much, but at the time when it was first introduced, the ability to share files and expensive resources, such as printers, amongst multiple users was revolutionary. It provided the means by which workers could collaborate and managers could leverage existing investments, which included different operating systems.
The use of a file server to centrally store data also made it very easy to implement security and management policies. Instead of having to back up or secure multiple user workstations to protect sensitive, important data, the organization could focus its management and security efforts on a few key computers. It is this element of Novell networking that will be addressed in this chapter.
NetWare, Novell’s operating system, uses the concept of a file server—a robust and powerful server that is used to store files. Today, most desktop operating systems have the ability to share files, but this does not make them file servers in the context of NetWare.
NetWare has undergone some major changes over the years, but the basic concept of having a powerful and reliable server providing networking services to multiple client workstations has remained constant over the years. The current version of NetWare (version 6) is significantly different from the original, which evolved from NetWare 68 or S-Net (1983) made for a Motorola 68000 into NetWare 86 for an Intel 8086 or 8088. NetWare 286 was written for an Intel 80286 and existed in various versions that were later merged to NetWare 2.2. NetWare 386 was written for the 386 platform and was later renamed to NetWare 3.x.
NetWare now supports the TCP/IP protocol in addition to Novell’s own proprietary protocol, Internetwork Packet Exchange (IPX). IPX was the only protocol supported for many years, and while TCP/IP has been available as an add-on since version 3.11, it was never the core protocol. Novell has since rewritten NetWare to use pure TCP/IP and has even made it the default network protocol, dethroning Novell’s own IPX. Native IP support was introduced in NetWare version 5, when the core operating system was changed to be able to run on top of IP. The use of IP prior to this change was basically the encapsulation of IPX within IP datagrams, because the core operating system could only communicate using IPX.
Other significant changes include the introduction of Novell Directory Services (NDS), which is well known for its strong security features. NDS introduced the concept of logging in to the network, instead of logging in to a specific server, and it also introduced an entirely new layer of security features.
Novell has always been known for its strong security features. From the very first product, it provided the means to implement passwords for access and the ability to protect network resources by limiting access to approved users, with each user having different privileges.
In its most current form, NetWare 6 has improved and expanded on these capabilities. A single sign-on gives the user access to all networked servers, regardless of operating system. Policies can be used to control the resources a user, or group of users, can access. Many previously separate Novell products and features have been weaved into NetWare, and are marketed as an integrated solution. This includes the ability to implement a Novell Certificate Server, which is a public-key cryptography server that creates, manages, and issues digital certificates, and to use Novell BorderManager, a very powerful security management suite that incorporates features such as firewalls and virtual private networking tools.
As has been mentioned, the earlier versions of NetWare all used a proprietary Novell protocol called IPX. This protocol formed the basis by which clients and file servers communicated. If a workstation wanted to communicate with a Novell file server, or if there was a need for server-to-server communication, IPX had to be implemented on the computers.
Beginning with NetWare 5, Novell made a major shift in strategy—IPX was no longer a requirement to operate a Novell NetWare network. Users of this and subsequent NetWare versions have had a choice of implementing IP or IPX or a combination of both. In the versions prior to NetWare 5, TCP/IP was an optional protocol but the operating system still relied on IPX for its core functions. Today, the TCP/IP protocol suite is the de facto standard for local and wide area networking, and it is also the default protocol for current Novell systems. IPX is now an optional protocol instead of being the core protocol it once was.
This poses a challenge. Traditionally, IPX users only had to be concerned with implementing security policies that addressed the unique challenges that an IPX network presented. It was a fairly safe assumption that an attack on the network would not originate from an IP-based workstation, because an IP workstation did not understand IPX packets, and computers running IPX did not understand IP. The security challenges of the Internet, therefore, were never an issue.
NetWare 5 changed all that, and its ability to use either or both protocols opened up the network to the security threats of IP, and there are many. As a general rule, a Novell network will perform better and will be less vulnerable if it uses the IPX protocol in an all NetWare environment. It may be wisest, therefore, to implement IP only if there is a real need. If you are not running any IP-based services on a NetWare server, there is little reason to implement IP as a server protocol. By sticking with IPX as the only protocol, no one can attack your network from the Internet.
However, life may not be that simple. In fact, many of the new services of NetWare 6 are designed to function over IP only, so you may not have a choice. If this is the case, approach your security policies from the viewpoint of an IP user or an enterprise that is exposed to the Internet. Do not limit your policies to those suggested in this chapter only. Be sure to explore the other chapters of this book that address TCP/IP.
The NetWare Core Protocol (NCP) is a set of procedures that the operating system of a NetWare server uses to service workstation requests. One way NetWare could be attacked is by forging a workstation NCP request. By forging such a request, an intruder could trick the server into believing that the request originated from a valid workstation, thereby gaining access to the network and its resources.
To address this, NetWare uses NCP Packet Signature, an enhanced security feature that protects the server and the workstation against packet forgery. NCP Packet Signature prevents this forgery by requiring both the server and the workstation to sign each NCP packet with a packet signature that changes with every packet. NCP packets with the incorrect signature are dropped without breaking the connection to the workstation.
Packets with an invalid signature are tracked and, each time one is received, an alert is generated and logged to an error log and to the server console. Alert messages contain the login name and the station address of the affected workstation. NCP Packet Signature will be explored in greater detail in the “Tips and Best Practices for Securing NetWare” section, later in this chapter.
Prior to NetWare 4, Novell networks were file server–centric. This means that the file server was the center of the local area network universe. To get access to a network resource, a file or printer, for instance, the user had to log in to the server that owned that resource. This also meant that if the user wanted access to another resource owned by another server, they would have to log in separately to that server, which may or may not have the same username and access profile defined for that user.
Novell Directory Services, introduced in NetWare 4, changed the focus from the file server to the network. In this new network-centric environment, the user effectively logs in to the network, and by doing so can access any resource within that network, regardless of its owning server or location.
NDS is one of the most important aspects of NetWare security, so much of this chapter will be devoted to NDS and the enhanced security features that were introduced along with it. But before we delve into these security features, it is necessary to introduce some key NDS concepts and terminology.
NDS is a distributed, object-oriented database that organizes network resources into a hierarchical tree structure. Instead of storing information about an object on a single server, NDS information can be distributed over a global database that can be accessed by all servers. Users can access any network service without knowing the physical location of the server that hosts the service.
Because NDS is distributed across the network instead of being stored on a specific server, users are able to log in to the network instead of having to log in to a particular server. As a user attempts to use resources, background processes check to make sure the user is authorized to use the resource or perform the specific function by checking the user’s rights to the resource.
NDS is also object oriented, and each object can be assigned multiple attributes. An object represents a physical or logical entity—a printer is an example of an object, as is a user, or a group of users (a group being a different object from a single user). A benefit of using an object-oriented approach is that an object—a device, for example—can be moved from one location to another without changing the object’s definition. Another benefit is that an object can be assigned multiple properties or attributes. For example, properties of a user object would be a user’s full name, password, a telephone number, and other personal information.
The rights that are assigned to the NDS object determine whether a user can have access to the network or can use a particular object on the network, such as a printer.
NDS organizes objects into a hierarchical tree structure, and each object within the tree structure is given an object class of [Root], container, or leaf. Figure 21-1, shows the logical structures of an NDS tree and the way in which the tree is normally depicted.
FIGURE 21-1 NDS tree structure
The remainder of this chapter makes reference to specific NDS names and terminology that follow the X.500 directory service standards. It is therefore necessary to understand the terminology and abbreviations. Table 21-1 lists common object types, their classes and abbreviations.
TABLE 21-1 NDS Object Classes and Common Object Types and Abbreviations
The [Root] object is the highest object class in the NDS tree. In effect, it is a placeholder and contains no information. It is different from a container object in that it cannot be moved, deleted, renamed, or created except during the install process of the first server in the network. It is always depicted with the square brackets.
The container object is used to hold leaf objects and other container objects. Types of container objects include organization (O), organization unit (OU), and country (C) objects. The organization object is a required object and exists in [Root] or in a country object. An organization unit is optional and exists in an organization or another organization unit. It is typically used to organize groups of subunits that provide similar functions.
Finally, the leaf object defines the actual network resources. Leaf objects are objects that do not contain other objects. They represent the actual network resources, such as computers, printers, users, groups of users, servers, and so on.
In summary, NDS can be viewed as a logical layer that exists above the physical layout of the network. It is used to group the network resources and users into logical groupings that are aligned with the way in which the enterprise actually functions, rather than being based on the objects’ physical locations. Using this approach, servers and users in different locations that provide similar functions, such as marketing or engineering, can be managed by placing the user and directory objects that represent the actual resources into organizational objects called “marketing” or “engineering.” Figure 21-2 illustrates how the concept works.
FIGURE 21-2 NDS is not dependent on the physical location of the resources.
In the figure, a user belonging to the Marketing OU typically accesses files on servers Rome and Paris. Prior to using NDS, the user would have had to log in to each server separately. With NDS, the user is able to access both by simply accessing the network. In this example, the volumes on Rome and Paris have both been defined as being part of the Marketing OU, to which Brenda also belongs. Files on both servers are accessible to her. The printer on the Paris server, has been defined to the Sales OU; it is still accessible to Brenda, but she would have to specify the printer by name using a syntax that references the location of the printer relative to its location in the tree.
The way in which an NDS object is referenced is very similar to the way a file is referenced in a file system. When referencing a file, a syntax such as \Documents\Data\ Help.txt, indicates that the file Help.txt is in a directory called Data, which is in a directory called Documents, which in turn is located off the root of the file system. NDS uses a similar structure, the main difference being that the reference begins with the leaf object and progresses toward the root, whereas, the preceding file reference began with the root and progressed toward the file.
The fully distinguished NDS name for the user Brenda from Figure 21-1 would be CN= Brenda.OU=Marketing.OU=BrandMgmt.O=CartyCorp. Using this fully distinguished name, any user on the network can locate the user object called Brenda.
So why is the hierarchical tree structure so important? Having a good understanding of the concepts of NDS and how its hierarchical structure works is very important in implementing security. Since network resources are presented to the user through the NDS tree, managing the NDS objects properly can control the security of the resource. The security rights that are assigned to an OU object have the potential to affect the resources that reside within that OU, regardless of where they physically reside. User accounts and network resources spread across many servers can be managed through the policies defined for a single OU.
Herein lies the convenience and power of NDS. In the versions of NetWare that predated NDS (NetWare 3.x and lower), the security policies governing these same resources would have had to be implemented on each owning server for each user account defined on that server.
Prior to the introduction of NDS, Novell used a bindery. The foundation of NetWare 3.x security was based on three hidden system files in the SYS:SYSTEM directory called the bindery. These files contained information about users, groups, and the associated rights to all network resources, including printers, print queues, files, directories, and so on.
Understanding that bindery-based security was based on the content of these hidden files further explains why NetWare 3.x is server-centric in its approach. Each file server had its own bindery that defined all its resources. This limited view of the network explains the need to log in to each server separately to gain access to its resources. In bindery mode, the user needed to be defined to each server before they were allowed access.
The bindery was replaced when NDS was introduced. Instead of using those three hidden files, NDS security uses a distributed object-oriented model as previously discussed. NDS also supports a bindery-emulation mode, in order to ensure backward compatibility between bindery-based and NDS-based systems.
NDS security consists of two parts: file-system security and object security. File-system security provides access controls to files and directories; object security provides access controls to objects, their properties, and the functions that they perform.
Not much has changed between NetWare versions in the way file security is handled. File-system security is implemented by assigning users different combinations of access rights for various directories and files. In this context, the users of the file system are also known as trustees, which is why the term file system trustee rights is also used to describe the rights that each user is assigned for a file or a directory.
There are eight trustee rights in NetWare file-system security. These rights are Supervisor, Read, Write, Create, Erase, Modify, File Scan, and Access Control. Each right grants a specific set of capabilities for a directory or a file, and the capabilities may vary slightly depending whether they are applied against a directory or a file. The explanation of each right, and what it does in the context of a directory or file, is explained in Table 21-2.
TABLE 21-2 File System and Directory Trustee Rights
When a new user is created, they are given the [RWCEFMA] trustee rights to their home directory by default. They are granted all possible rights with the exception of Supervisor.
Users that are created in the same container as the SYS volume object receive the [RF] rights to the SYS volume. This ensures that they can log in to the volume.
File-system rights flow downward through the directory structure. This means that a user with a set of rights for a directory will have the same set of rights for any subdirectories that are created below that directory. This will always be the case unless measures are implemented to block specific (or all) rights from flowing down to lower subdirectories. Figure 21-3 illustrates this concept.
FIGURE 21-3 Inherited and explicit rights assignments
In this figure, the TopDir directory is given the rights [RWCEFMA]. The three subdirectories, Dir-A, Dir-B, and Dir-C, inherit the rights given to TopDir by default, because file-system rights flow downward through the directory tree.
Note, however, that while Dir-A has indeed inherited the same rights as TopDir, Dir-B and Dir-C did not. The rights for Dir-C changed (it did not inherit all the rights of TopDir) because an Inherited Rights Filter (IRF) was defined to filter certain rights from being inherited.
The Write, Create, and Erase rights were blocked from being inherited by the IRF (they were not included in the IRF). The rights that are assigned to an IRF are the rights that can be inherited. It is important to note the only exception to this rule—the Supervisor right can never be blocked by an IRF.
NOTE In file-system security, the Supervisor right cannot be blocked by an IRF.
Dir-B demonstrates the more common way of changing the rights of a subdirectory, which is to explicitly define the rights for that subdirectory or file. Explicitly defining rights overrides any rights that would have been inherited. These explicitly defined rights will also flow down to any subdirectory or file below Dir-B.
Finally, it is important to remember that an IRF does not grant rights; it is used to revoke rights that would otherwise be inherited.
Directory and file attributes are used to assign properties to individual directories or files. When used in conjunction with file-system trustee rights, file attributes provide an additional level of security and control.
The FLAG or NetWare Administrator utilities can be used to change file and directory attributes. Table 21-3 lists the file and directory attributes that can be used to further enhance file-system security.
TABLE 21-3 File and Directory Attributes
Keep in mind that attributes assigned to a file or directory affect all users, regardless of the rights that were assigned to those users. For example, if a file is assigned the Delete Inhibit attribute, no one, including a user with the Supervisor right, will be able to delete it. However, the Supervisor or any user with the Modify right could change the attribute to allow deletion.
At first glance, this may seem somewhat counterproductive or of little value, but when used wisely, attributes are a very useful security tool. Consider the case where you wish to grant a user access to a directory and enable them to read, write, and erase files at will, with the exception of one file that should never be erased. By setting this file’s Delete Inhibit attribute, the user will not be able to erase the file. You achieve your objective of allowing the user the ability to erase everything else in the directory except for this lone file. Furthermore, by not granting this user Supervisor or Modify trustee rights, you prevent them from changing the attribute of the file you wish to protect. Only the administrator or another user with the appropriate rights will be able to override the file attribute.
An effective security policy is one that is based on allowing users the minimum level of access necessary to get their jobs done. Allow any more access, and you create the potential for accidents or loopholes that can be exploited. For instance, if a user should only be able to view files in a directory, the trustee right required to do this is the Read right. If your security policy did not limit the trustee right to the minimum right required but included other rights, such as Erase, the policy would open the door to a possible accident or mischief. The user could delete the file by accident or by choice.
It would be great if there were a one-to-one relationship between each right and the functions that users perform, but unfortunately, life is not so simple. To enable your users to perform the jobs they are meant to do, they must be provided with the appropriate rights to different files and directories. Sometimes it is a simple matter of assigning them the Read right, allowing them to view a file, but more often than not, they need the ability to perform much more complex tasks that require combinations of rights. Table 21-4 lists common tasks and the minimum rights required to accomplish those tasks.
TABLE 21-4 Common Tasks and the Minimum Rights Required
The second part of NDS security is object security. Because file-system security has seen few changes between NetWare versions, the term NDS security has come to mean object security to many NetWare users. NDS object security defines different rights for an object and its properties. These rights are permissions that are assigned to an object and its properties.
As with file-system security, object security also has its own associated set of rights. When NDS was first introduced, it defined five different object rights: Supervisor, Browse, Create, Delete, and Rename. A sixth right—Inheritable—was later introduced in NetWare 5.
The Supervisor object right grants all access privileges. A trustee that has been granted the Supervisor object right also has unrestricted access to all of the object’s properties. Unlike the Supervisor right in file-system security, the Supervisor object right can be blocked by an IRF. This is a major difference between file and object security, and it should be noted because of its potential impact on the security of your network if it were not considered.
The Browse object right grants the right to see the object in the directory tree. Trustees that have been granted this right can search the tree in NWAdmin and through the NLIST and CX commands.
The Create object right grants the right to create a new subordinate object in the Directory tree in and below the object to which the Create right is granted. The implication of this is that only container objects can have this right, because non-container objects (leaf objects) cannot have subordinates.
The Delete object right grants the right to delete the object from the tree. Note that objects that have subordinates, such as a container object with contents, cannot be deleted until the subordinates are deleted.
The Rename object right grants the right to rename the object. In effect, this changes the naming property. Prior to NetWare 5, this and the preceding four rights were the only valid rights for an object. As of NetWare 5, the following additional right was introduced.
By default, object rights flow down the tree (just as they do in file-system security). In NetWare 5 and later versions, the ability to control whether or not rights flow down the tree was made possible through the introduction of the Inheritable Object Right property. This property, once removed, prevents the rights from being inherited, and rights to subordinates have to be explicitly defined.
In addition to the object being granted rights, the properties of the object are also assigned their own rights. As discussed earlier in this chapter, each object, such as a user object, can be assigned multiple properties or attributes. For instance, the user object has properties such as Full Name, Phone Number, and Password.
Unlike file-system security, where the file and directory rights both had the same names but slightly different functions, NDS object security defines a separate set of rights for an object’s properties. These property rights—Supervisor, Compare, Read, Write, Add or Delete Self, and Inheritable—are described in Table 21-5.
TABLE 21-5 NDS Property Rights
To know the default values is to understand the price of inaction. Table 21-6, lists the NDS trustee rights that are granted by default.
TABLE 21-6 Default NDS Trustee Assignments
Special attention should be paid to the ADMIN user object. As shown in the table, this object is given the Supervisor rights to [Root] by default, so the ADMIN user object effectively has Supervisor rights to the NDS tree. This is how the logic works: The ADMIN user object is assigned the Supervisor right to [Root]. ADMIN, as a result of this assignment, also has the Supervisor rights to the NDS tree. Remember that [Root] is a placeholder that represents the top of the directory tree, and rights flow down the tree. Because the server object is placed in the NDS tree, the ADMIN user object also has Supervisor rights to the server object. By having Supervisor rights to the server object, the ADMIN user object also has Supervisor rights to the NetWare file system on the server.
NOTE The ADMIN user object has supervisor rights to the file system by default, because of the Supervisor object right that it was given to [Root]. This is the only instance in NetWare NDS security where object rights have an impact on file-system rights.
The concepts of NDS object security should sound familiar, as they are very similar to those we discussed earlier for file-system security. However, in some instances there are subtle differences between the two. And while the differences may be subtle, they can have far-reaching effects. The Supervisor right is one such example. In file-system security, the Supervisor right cannot be blocked from being inherited, but in NDS object security it can. This small shift in the rule can have a major impact on security.
NOTE In NDS object security, the Supervisor right can be blocked by an IRF. This is in contrast to file-system security, where it cannot.
Figure 21-4 provides a visual representation of the key concepts of NDS object security and how they interact.
FIGURE 21-4 NDS object security concepts and how they relate
A trustee assignment describes the rights that are granted to an object for a specific directory, file, object, or property. In NDS, security always begins with a trustee assignment, which is an explicit or direct assignment of rights to an object. An object that has been granted the rights to manage another object is said to be a trustee of that object. As you can see in Table 21-6, by default the ADMIN user object is a trustee of the NDS tree, because ADMIN has been assigned the Supervisor rights to [Root].
The following rules govern trustee assignments:
• Trustee assignments for an object flow down the tree.
• An IRF can be used to block trustee assignments from being inherited.
• Explicit trustee assignments can be made anywhere in the tree. When rights have been explicitly assigned, the new set of rights override any rights that may have been inherited.
• When a user is first created, the user object receives the Read property to all of its own properties through the All Property rights. The All Properties is a category that is visible by selecting rights to other objects when using the NWADMIN or NETADMIN utility. When a right to an object’s property has been assigned through the All Properties category, it may be overridden by selectively assigning a new right using the Selected Properties category.
• Trustee assignments to an object are stored in the object’s access control list (ACL) property.
As the name implies, security equivalence means that two objects have equivalent rights. This is the most common way of assigning rights to an object. For instance, if the goal is to create a user object that has the same rights as the ADMIN user object, the network administrator can simply create the user object and state that it has the security equivalence of the ADMIN user object. This is a lot more convenient than having to define every right that the ADMIN user object has.
The convenience of security equivalence is multiplied when assigning the same rights to multiple users. If the goal is to give multiple users the same rights as the ADMIN user object, the network administrator can choose to create a group object and define those users as members of that group. The group can then be given the security equivalence of the ADMIN user object.
The following rules govern security equivalence:
• An object is security-equivalent to all objects listed in its Security Equals property.
• Every user object is security-equivalent to the [Public] object. This equivalence allows the user the ability to browse the NDS tree before logging on to the network.
• Once the user has logged on to the network, they are security-equivalent to [Root].
• If an object has been assigned a security equivalence, this assignment cannot be blocked by an IRF.
• Every object is security-equivalent to all container objects that are part of its fully distinguished name. The fully distinguished name of the user Brenda, from Figure 21-1, is CN=Brenda.OU=Marketing.OU=BrandMgmt.O=CartyCorp, and this would signify that the user object Brenda is security-equivalent to the Marketing, BrandMgmt, and CartyCorp containers. If the BrandMgmt container were given rights to a particular object, the Brenda object would also receive those rights through security equivalence.
Rights flow down the NDS tree. The rights that are assigned at a given level within a tree will be inherited by subordinate levels within the same tree. These rights are said to be inherited rights because they are not explicitly defined but are instead inherited by virtue of what was assigned at a higher level in the tree.
The following rules govern inheritance:
• Inherited rights can be blocked by an IRF.
• Only rights that are assigned for all properties can be inherited. Rights assigned to selected properties cannot be inherited.
The Inherited Rights Filter (IRF) is a filter that is used to block rights that would otherwise be inherited.
The following rules govern IRF:
• The Supervisor object right can be blocked by an IRF (this is not the case in file-system security, where the Supervisor right cannot be blocked by an IRF).
• By default, an IRF allows every right to be inherited from the parent directory. In other words, an IRF by default permits all rights to flow down.
• An IRF defines the rights that are allowed to be inherited; to allow a right, the right must exist in the parent container and in the IRF.
• An IRF does not grant rights; it is used to revoke previously granted rights. To revoke a right, the right must exist in the parent container and be removed from the IRF.
• An IRF can be applied to object rights, the All Properties category, and the Selected Properties category.
• The IRF is ignored whenever a trustee has an explicit assignment to the object.
As previously mentioned, the IRF of an object and its properties can block the Supervisor object right in NDS object security. It should be noted, however, that NetWare utilities do not allow you to block the Supervisor object right unless there is another object (including itself) that is also granted the Supervisor right. This helps ensure that no part of the directory tree is cut off from Supervisor-level access. This is a useful feature, but there are still dangers when blocking the Supervisor right. An object may have another object defined as a trustee with Supervisor rights, but if the trustee is not a user object, that object could still be cut off from management, because you can only log in as a user object.
Effective rights are not defined or granted—they are calculated. Effective rights are what an object can actually do after all security factors are considered. These rights are calculated each time an object attempts an action.
To derive the effective rights and determine what an object can effectively do to another, the following factors are considered:
• The contents of an object’s access control list
• The object’s explicit assignments
• The object’s security equivalence
• Inherited rights
Using Figure 21-5 as an example, the user object Brenda’s effective rights to access the SalesPtr printer can be derived from
FIGURE 21-5 The user object Brenda’s effective rights to another object are calculated from many different factors.
• An explicit trustee assignment on SalesPtr that lists the user Brenda.
• A trustee assignment to any group object of which Brenda is a member. However, this is only true when the object requesting rights is a user object.
• A trustee assignment on SalesPtr that lists the Sales container. In this case, Brenda inherits the rights from the container object.
• A trustee assignment on the Sales container that lists Brenda. In this case, the rights to SalesPtr are inherited from the object’s container, but the right must pass through any IRFs that may have been defined for SalesPtr.
• A trustee assignment on the Sales container that lists the Marketing container. In this example, Brenda inherits the rights from the object’s and the trustee’s container. The rights must pass through any SalesPtr IRF.
• A trustee assignment to any object listed in Brenda’s Security Equal To property. This is only valid when the object requesting the right is a user object.
The following rules govern effective rights:
• If an object has a trustee assignment on a container, and on an object within the container, the trustee assignment on the subordinate object overrides the trustee assignment on the object’s container. For example, again referring to Figure 21-5, if Brenda has a trustee assignment on the Sales container and SalesPtr, the trustee assignment on SalesPtr supersedes those defined on the Sales container.
• Trustee assignments to groups do not override other rights; instead they are added to the previous trustee assignments for user objects. In this scenario, rights assignments are additive. Instead of overriding the rights that were previously assigned to members of the group, the rights that are assigned to the group are added to those that the members already possessed.
NOTE Trustee assignments to groups do not override other rights; instead they are added to the previous trustee assignments for user objects.
An effective security strategy begins with the tools that are available to implement the strategy. It does not end there, however. In fact, the will to implement and to adhere to a strong security policy can be even more important than the tools. Much can be accomplished if there is a strong commitment to adhere to an established policy, even if the tools are somewhat limited. Understanding NDS security is only the beginning; the real test of your strategy will be in the policies you choose to implement and your commitment to enforce them. The remainder of this chapter will offer some practical advice on how to improve security in a Novell network.
The server is where your most valuable network assets reside: data files, applications, login scripts, and profiles, to name just a few. It is also the place where commands can be entered, so it has the potential to impact the network at large. With access to the file server, an attacker can issue commands to shut down the server or remove NDS from the server. It follows, therefore, that a robust security policy must include measures to secure access to the server.
Access to the server should be limited to authorized personnel only. Keep the server in a locked room, and restrict access to authorized persons. If you are unable to lock the server in a separate room, remove the keyboard and the monitor. The server should be able to function normally without a keyboard and monitor attached.
The MONITOR utility can be used to view server use and statistics, to set server parameter values, and to print server parameters to a file. In earlier versions of NetWare (version 4.x and earlier), the MONITOR utility also included a screensaver and server-console locking features. These features were removed from the MONITOR utility in version 5 and are now incorporated in the screensaver utility, SCRSAVER.NLM.
The SCRSAVER utility incorporates more robust security features that use the security features of NDS to limit access to the server. To unlock the server, a valid username and password must be entered. SCRSAVER then verifies that the user object has the correct rights (the Write right) to the ACL attribute for that server. Implementing a password is optional, but it is highly recommended. However, a word of caution is necessary. The SCRSAVER utility relies on NDS to authenticate the user and password used for unlocking the server, so if NDS becomes unavailable, as is the case when the DSREPAIR utility is being used, you will not be able to unlock the console. To avoid this situation, the NO PASSWORD option indicates that the console can be unlocked without a password in the event NDS is unavailable. A password would still be necessary when NDS is running.
Table 21-7 lists the options that are available for the screensaver utility.
TABLE 21-7 The SCRSAVER Utility Options
Using remote console, the RCONSOLE utility, is a convenient way of remotely accessing and controlling a NetWare server, but its use is fraught with security risks. The best policy is to eliminate its use altogether, but this may not be practical.
At the very least, try to limit its use and assign a unique encrypted password. Always remember that the remote console authentication may be encrypted, but the session is not. This means that passwords that are transmitted during an active session are transmitted in the clear.
If RCONSOLE must be used, implement NCP Packet Signature at its highest level for that workstation.
Using the Secure Console utility is not the same as locking the console. Secure Console is used to help secure the server by doing the following:
• Preventing loadable modules from being loaded from any directory other than the SYS:SYSTEM directory. Loading from a floppy or another location is inhibited.
• Preventing keyboard entry into the operating system debugger.
• Protecting the server date and time from change.
• Removing DOS from the server and sending it to disk cache.
NDS provides a much more secure environment than NetWare 3.x. Upgrading to a version of NetWare that supports NDS (version 4 and higher) is highly recommended. Keep the operating system up to date with the latest software patches and field updates; they are usually used to patch known security holes.
In addition to securing the server, workstations should also be secured. The following are tips for workstation security:
• Implement screensavers with passwords. NDS-enabled screensavers can be found at www.netwarefiles.com/scrsaver.htm.
• Use Windows NT or Windows 2000 instead of Windows 95 or 98.
• Implement NCP Packet Signature, which is explained in the next section.
Novell recommends the use of NCP Packet Signature in environments that may have the following security risks:
• An untrustworthy user of your network
• Network physical wiring that cannot be secured
• An unattended, publicly accessible workstation
Novell further recommends that NCP Packet Signature may not be necessary for a file server that is used to host executable files exclusively or if the data is not sensitive, and loss or corruption of the data would not impact the business. Networks consisting of known and trusted users are also listed as potentially safe and so may not need NCP Packet Signature.
While this is good advice, especially in light of the fact that the feature impacts performance, NCP Packet Signature should be implemented as far as possible. It can impact the network, but the potential benefits far exceed any adverse effects it may have on performance. Also, by implementing NCP Packet Signature across the board, you do not need to keep track of where it is implemented. Having to track where it is deployed increases administrative overhead and increases the chance of forgetting to deploy it in a place where it is really needed.
NCP Packet Signature comes in four different levels, 0 through 3, and not all levels have the same impact on CPU and performance. NCP Packet Signature must be implemented on both the workstation and the server for it to be of any use, but they do not need to implement the same levels on each for NCP Packet Signature to work.
Table 21-8 shows the four levels of NCP Packet Signature, along with a brief explanation of what they mean for the server and the workstation.
TABLE 21-8 NCP Packet Signature Levels for Servers and Workstations
Figure 21-6 further illustrates the relationships between these levels and how the server setting interacts with that of the workstation.
FIGURE 21-6 Interaction of NCP Packet Signature levels on server and workstation
To check the current NCP Packet Signature level for a server, type the following on the server console:
To set the NCP Packet Signature level for a server, type the following on the server console:
where number is 0, 1, 2, or 3; the default value is 1.
The appropriate SET command should be added to your STARTUP.NCF file to ensure that the server NCP Packet Signature is set each time the server is brought up.
Login security controls the access to the network and the content of the network. To log in to the network, a user must know the username and password of an existing user object. A number of steps can be taken to ensure that unauthorized people cannot access the network.
Remove all unused user accounts, including the Guest user object. Maintain a list of valid users, and ensure that they are given just the minimum rights required to perform their jobs.
The ADMIN user account, and any other user account that has security equivalence, should never be left unattended while logged in to the server. In fact, it is always a good idea to use these types of user accounts only when necessary. System administrators should use less privileged user accounts for day-to-day, non-administrative activities and reserve the use of the more powerful account for times when they are performing administrative functions that require a higher privilege level.
Administrator user accounts should employ a much more stringent password policy than is in place for general users. At minimum, a 12-character password is suggested.
Implementing a password on a Novell network is optional, but is strongly recommended to secure the network and its resources. A password should be difficult to guess, and to achieve this, NetWare provides many password attributes that are designed to achieve varying degrees of security. The complexity of the password is determined by the number of attributes that are implemented, and how each attribute is implemented.
Implementing a strong password policy is a balancing act between user convenience and the level of security that you hope to achieve. Users will find many of the password security features to be an outright nuisance, and they can, in fact, hinder productivity. Careful consideration should therefore be given to your password policy.
To help your users create passwords that are easy to remember, but potentially hard to guess, you could suggest that they use phrases and substitute letters with numbers or numbers with letters. An example of this would be the phrase “Call Me Before yoU GO,” which could translate into a password such as CMB4UG0. Note that “fore” in “Before” became the numeral 4, and “GO” became “GO” (with a zero). Using this method does lead to passwords that are easier to remember and harder to guess, but it does not make them harder to crack.
At a minimum, the following password options are available and should be implemented:
• Require a minimum length The default password length is five characters, and the longer the password, the more difficult it is to guess. A minimum length of 6 characters is recommended.
• Periodically change passwords Frequently changing passwords ensures that hackers have less time to break any particular password, and if the password has been compromised, it limits the remaining time before the next change. The default for this value is 90 days, and that may be too long. The key is to ensure that the feature is enabled.
• Require unique passwords With this option enabled, the server tracks all the passwords that have been used for a day or longer, and limits the user from reusing the last eight most recently used passwords. This option is off by default.
• Require user passwords Ensure that all user objects require a password.
The preceding list should be considered a minimum. For a more robust password policy, the following features are also recommended:
• Limit login attempts Limit the number of attempts a user can make at signing on with an invalid password before access to the network is revoked. The default value is 6 times, a value of 3 or 4 is recommended.
• Enable encrypted passwords Without encryption, passwords are transmitted in the clear. If a packet decoder, such as a sniffer, is placed on the network, the passwords can be intercepted. By turning encryption on, the passwords are encrypted before they are sent.
• Set expiry dates Expiration dates should be set on temporary passwords, such as those created for contractors.
• Require special characters Passwords should have at least one non-alphanumeric character.
If the policy for choosing a password is left up to the user, without any external influence, shorter passwords will typically be selected. Increasing a password by one extra character exponentially increases the possible combinations it would take to crack the password, as shown in Table 21-9. The table also demonstrates the effect of adding numbers to the password combination.
TABLE 21-9 Increasing Complexity of Passwords Using Different Character Combinations
Compare the difference between using a password of five characters and one that uses six. The number of possible combinations using only the characters A–Z increases from less than 12 million to over 308 million. If numbers are introduced into the password, those six characters can generate over 2 billion possible passwords. Using passwords of at least six characters with at least one non-alphanumeric character is recommended. By requiring the use of at least one special character (any character other than non-alphanumeric), the possibilities for a six character password greatly increases beyond 2 billion possibilities.
The standard Novell password restrictions allow the administrator to define the basic options, including minimum password length, whether or not a password is required, whether it has to be unique or can be reused, the period before a change is forced, an expiration date, and whether grace logins should be limited.
In addition to these standard and somewhat limited options, there are also other enhancements to Novell password restrictions that can be applied through the use of add-in utilities. The LGNPWCFG utility (also from Novell) writes the password policy to the local workstation registry, which means that password policies can be enforced through the use of data stored locally. When the user logs in and a password change is requested, a dynamic-link library (LGNPWW32.DLL) checks the local registry to see if the password complies with the configured policies. The following additional features are embodied in this utility:
• Option to apply the rules only on initial login
• Option to require a minimum number of digits
• Option to require a minimum number of alphabetic characters
• Options to restrict the number of aphabetic, numeric or special characters which may follow each other, also known as the maximum consecutive rule
• Options to limit the how many times a character can be repeated
It should be noted, however, that while these improve on the standard password options, this utility also has its weaknesses, mainly in the fact that the information is stored locally.
Connectotel’s Password Policy Manager (PPM) is an add-in that is also available. It has many improved features over LGNPWCFG, such as control over how many punctuation characters are needed within a password, the maximum instances of any character, and a comparison feature that compares the new password with an old password. With the comparison feature, the administrator sets a similarity threshold based on a percentage value that represents how similar the new password is allowed to be when compared to the old.
All these are great features, but an even stronger feature is the fact that PPM is NDS-aware. Implementing PPM creates a new object type, called the Password Policy Object in the NDS tree. Once PPM creates a password policy within a container within the NDS tree, it is associated with the user, or groups of users, against which the policies are enforced. When a user enters their password, it is checked against the password policy. Information on Connectotel’s PPM can be found at www.connectotel.com/ppm/index.html.
For even greater security, security tokens can be used in conjunction with Novell’s BorderManager VPN Client, BorderManager Proxy, and BorderManager Authentication Services.
It is important to remember that Novell approaches security from the perspective of layers. The core NetWare products provide a basic, and to a degree, a robust layer of security, which has been the subject of discussion in this chapter. To most small companies, the security provided in NetWare is sufficient to do the job. To many larger institutions or those who have a need to employ a more robust security strategy, however, Novell provides additional products to meet most, if not all, requirements. If Novell doesn’t have an appropriate product, there are third-party products that will do the job.
The Novell Modular Authentication Service (NMAS) uses NDS to provide a single point of administration and management for an expanded set of authentication methods. The enhanced features of NMAS can be obtained by purchasing a product that has NMAS bundled with it, or by purchasing the stand-alone version called NMAS Enterprise Edition.
NMAS uses three different methods, or login factors as they are called by Novell, for logging into the network:
• Password Authentication Uses a method that depends on something being known
• Physical Device Authentication Uses a method that depends on something being owned
• Biometric Authentication Uses a method that depends on something that you are
These three different login factors describe different ways, items, or qualities that can be used to authenticate to the network.
With the Password Authentication login factor, NMAS provides different methods for using a password to authenticate to the network. These methods include the standard NDS method for password authentication, as well as methods using the SHA-1 and MD5 hash algorithms. Also included is a plaintext method that transmits the password over the wire in an unencrypted form. When using plaintext, no authentication is performed; this is included as an option to provide interoperability with other systems that use plaintext authentication, native Telnet being one such example.
The standard NDS method for authentication uses a two-process mutual authentication method called password challenge-response. In this two-process scheme, the password is sent, along with identifiers that are used only once, called a nonce. The nonce values are generated by both the client and the server and are hashed twice using two different hash algorithms and then encrypted using an RSA encryption algorithm. The second process in the two-process scheme consists of a background authentication to an NDS server.
The Physical Device Authentication login factor uses something that the user carries around with them, like a smart card or a token. The concept is similar to carrying a driver’s license that is unique to an individual and proves that the individual is who they claim to be (though, of course, fraud is always a threat). Tokens and smart cards operate in conjunction with other products to authenticate the user. The Novell Certificate Server that ships with NMAS or Novell BorderManager can be used in conjunction with smart cards and tokens to perform authentication. An NDS authentication module is also available from RSA Security. With this module, an RSA SecurID card can also be used in conjunction with an RSA ACE/ Server security server to authenticate users.
The Biometric Authentication login factor uses technology that authenticates based on your human characteristics. These characteristics include, but are not limited to, fingerprints, eye retina, facial features, voice, and handwriting. Identicator, a division of Identix and Safelink Corp. is one company that provides NMAS biometric login solutions.
NMAS has many additional features that are intended to make the network more secure and the ability to hack progressively more difficult. To get the details of all the features, see www.novell.com/documentation/lg/nmas21/index.html.
In the realm of auditing, Novell provides a utility called AUDITCON. However, it is somewhat limited in its application. If NDS eDirectory is being run on a platform other than NetWare, Windows 2000 for instance, you will not be able to use AUDITCON.
BindView (www.bindview.com) provides the ability to audit and enforce password security. It can generate reports on security exposures and change attributes across the entire network.
Login scripts are batch files that customize the network environment when a user logs on. Functions that can be performed in these scripts include initializing environment variables, mapping drives, and executing commands.
Ensure that login scripts exist for every user, even if they only contain the EXIT command. Also ensure that the last entry in each script is the EXIT command. Up to three login scripts can be used at login, and they are executed in the following order:
• The login script of the user’s immediate container
• The login script in a profile object specified for that user
• The user’s individual login script, which is stored in the user’s mail directory
A user has the ability to create their own login script in their mail directory, and this is a potential security exposure. To make matters worse, a user could create a login script for another user. For example, if a privileged user account (one with a high security clearance and access to sensitive system and data files) does not have a login script, another user could copy a login script to the privileged user’s mail directory. The next time the privileged user logs on, it would execute the contents of the login script and could potentially execute sensitive commands without the privileged user knowing it.
The best way to counter this threat is to ensure that all users have a login script and that all scripts end with an EXIT command. The EXIT causes the script to stop executing at the point at which it is entered into the script. All commands after the EXIT command are ignored. This means that if a user somehow managed to append some destructive instructions at the end of a script, the script would ignore everything entered after the EXIT command.
The following are general ideas for implementing NDS security. These are simple concepts that are easy to implement and will pay big dividends.
• Implement a policy that facilitates auditing of activities. An effective way of doing this is to limit the use of the ADMIN user object. Create another user object instead, and make it security-equivalent to ADMIN. By doing so, you have the potential to track who made changes. The alternative, which is a fairly common practice, is to have multiple users use the ADMIN user object, but this limits your ability to track who actually makes what changes. The ability to track changes, and being accountable for those changes, is a key element in enforcing a strong security policy.
• Enable intrusion detection, which is off by default, in every OU. Intrusion detection must be turned on for each container and is based on restrictions that are set on each server account. The network administrator can restrict any account on a server to a specific number of login attempts in order to protect the account from unauthorized use.
• Remove the bindery context after upgrading to NDS. Many NetWare hacks are based on bindery access to the server. These hacks, which have been around since version 3.x, can be prevented by moving to NDS authentication.
• User objects that are equivalent to ADMIN should have a password policy that requires at least 12 characters. The rules for this password should also be a lot more stringent than those used for daily routine access.
• Implement connection limits for users. This prevents a user from logging on from different places concurrently.
• Limit the number of users that are security-equivalent to, and know the password for, the ADMIN user object. No more than two or three people should know this password. Of course, the size of the organization plays a big part in deciding how many people should have this access. Suggesting that two or three people may know the password is not in any way condoning that the ADMIN object should be used to implement changes. As previously stated, the user’s own object (security-equivalent to ADMIN) should be used when making changes. The purpose of knowing the ADMIN password is to ensure that someone knows how to access the ADMIN object itself if necessary.
• Periodically review server logs, especially the SYS$LOGG.ERR and CONSOLE.LOG files. Table 21-10 lists the locations and descriptions of these files.
TABLE 21-10 NDS Log File Locations
The SYS:LOGIN directory is viewable by anyone who connects to the network, regardless of whether or not they are logged in to the network. In other words, a user does not need to be authenticated and signed in to the network to see the contents of the SYS:LOGIN directory. For this reason, limit the number of files in this directory to only those that will not harm your network or divulge sensitive information.
If you are using NetWare 4.x, it is recommended that you move the NLIST utility from the SYS:LOGIN directory to some other directory. The NLIST utility allows a user to view information about objects such as users, volumes, servers, and the like. It also allows the user to search on objects and object properties. These are all activities that should be limited to approved users of the network, and not just casual browsers.
In NetWare 5, the NLIST utility was moved to the SYS:PUBLIC directory so that it can only be used by authenticated users. You may consider doing the same if your particular installation still has it stored in the SYS:LOGIN directory.
NetWare always had a good track record for security, and NDS builds on this record by adding stronger authentication as well as object and property rights. The more current versions of NetWare have added even more layers of security by introducing a Novell Certificate Server that provides public key cryptography, which creates, manages, and issues digital certificates. Other security options include Novell BorderManager, a very powerful Internet security management suite that incorporates features such as firewalls and virtual private networking tools, as well as content control. These products tap into the advancements made in security for IP networks, such as digital certificates, SecureID tokens, and encryption.
The tools that you have at your disposal are important, but even if the tools are somewhat limited, much can be accomplished if there is a strong commitment to adhere to an established security policy. Understanding NDS security and the tools that are available is only the beginning; the real test of your strategy will be in the policies you choose to implement and your commitment to enforce them.
• Novell Network Security Self Assessment www.stanford.edu/dept/Internal-Audit/docs/novell_appc.shtml
• An Architectural Rationale for a Security Infrastructure http://developer.novell.com/research/appnotes/1997/november/07/04.htm
• Traditional File Services Administration Guide www.novell.com/documentation/lg/nw51/trad_enu/data/h158rfoc.html
• NDS Tree Design www.nwconnection.com/jul.96/ndstre76/
• The importance of file security, control and reliability www.novell.com/products/netware/nw6_w_importance.html
