Security Issues

     

Although there are many different categories of NDS/eDirectory- related security issues, in our experience, the following rank as the top three:

• Users getting excessive file system rights

• Maximum concurrent login limit reached

• Hidden or stealth objects in the tree

Excessive File System Rights

NetWare implements fairly tight file system security. In order for users to access the files and directories on network volumes , they must have the appropriate file system security access rights. The default NetWare file system security is such that users have no access to any files and directories on NetWare volumes except to their own home directories (whether those were set up) and to SYS:PUBLIC and SYS:LOGIN .

A user can receive file system rights in many different ways, such as from direct trustee assignments, groups belonged to, and even DS containers. Therefore, it is not always easy to determine or troubleshoot a scenario in which a user has full file system rights where he or she is not supposed to. The following are the steps you can take in order:

To track down the cause, at the root of the volume where the user has excessive rights, you type RIGHTS /T to see whether there was an explicit rights assignment granted to the user or to any group or DS container the user is a member of. If so, revoke that assignment and see whether that resolves the problem.

NOTE

RIGHTS.EXE is a 16-bit DOS application that is shipped with all versions of NetWare, including NetWare 6.5. It is located in the SYS:PUBLIC directory.

If no explicit assignment exists, the user has most likely inherited the rights from DS. This means that somewhere in the DS tree, the user, one of the groups the user is a member of, or the container (or one of its parent containers) the User object is in has the Supervisor right to the file server's Object Trustee ( ACL ) attribute. This can happen through one or more of the following assignments:

• Having Supervisor object rights to the NCP Server object

• Having Supervisor or Write rights to the ACL attribute of the NCP Server object

• Having Supervisor or Write rights to All Properties

One way to figure out which of these assignments took place is by using ConsoleOne. To do so, you select Trustees of This Object for the [Root] object and then select Effective Rights to see what the user's effective rights are. If the user has excessive rights, you can find the object that was granted the excessive rights in the Trustees of This Object list. Then you do the same thing for each container between [Root] and the NCP Server object, including the NCP Server object itself. At some point you should find that the user's effective right is more than the default (only Browse object rights and Read and Compare All Property rights). It is at this level in the tree that the excessive rights assignment was made.

Consider the sample tree shown in Figure 11.4, where Lisa has full rights to the SYS volume, even though she was given an explicit file system trustee assignment of Read and File Scan to the root of SYS . The following steps illustrate how you can use ConsoleOne to track down and fix the problem of Lisa having full rights to the SYS volume:

1. In ConsoleOne right-click [Root] and select Trustees of This Object. (By default, the only trustees that are here should be [Public] and Admin.)
   
   

   NOTE

   NDS 7 and later introduced a Tree Root ( T= ) class to the schema. The T= object's name is the same as the name of the tree. As a result, ConsoleOne does not display the [Root] object for NDS 7 and later trees. Instead, it shows the tree name as the top of the tree. However, in the documentation, the term [Root] is still used.

2. Click the Effective Rights button.
   
   
3. Click the Browse icon that is to the right of the For Trustee field. Browse the tree and select the User object Lisa (located under O=XYZCorp ).
   
   
4. Highlight each of [All Attribute Rights] , [Entry Rights] , and ACL in turn to see what the rights are. Normally a user has only Browse entry rights (see Figure 11.5) and no assigned [All Attribute Rights] and ACL rights.
   
   

   Figure 11.5. Only Browse object rights to [Root] exist for Lisa.

   

   
   
5. Close the dialog boxes because Lisa didn't gain her rights here.
   
   
6. Repeat steps 1 “4 for O=Systems . This time, when you select Effective Rights for Lisa , you see that she has full rights to every attribute listed, including [Entry Rights] , as shown in Figure 11.6.
   
   

   Figure 11.6. Lisa has full rights.

   
   
7. Close the Effective Rights dialog box and return to the Properties of Systems dialog.
   
   
8. Examine each of the trustee assignments (by first highlighting the entry and then clicking Assigned Rights) that are in some way related to the user Lisa (for instance, O=XYZCorp , where the User object is located, and O=Systems , where some of the groups she belongs are). In this case, you find that O=XYZCorp was granted Supervisor rights to [Entry Rights] (see Figure 11.7). This is the source of Lisa 's excessive rights.
   
   

   Figure 11.7. O=XYZCorp with Supervisor object rights to O=Systems .

   

   
   
9. Uncheck the Supervisor rights assignment from [Entry Rights] and click OK to save the change.
   
   
10. Check the effective rights again and verify that Lisa does not have excessive rights to the file system anymore.
    
    
11. Have Lisa log in to the network and verify that she no longer has excessive effective rights.
    
    

Figure 11.4. A sample DS tree for the excessive file system rights example.

In this example, you can stop at this point because Lisa no longer has full rights to the SYS volume. If you didn't find anything at O=Systems , however, you would also need to check the other trustee assignments (such as the NCP Server object) in case the User object was made SE to one of those objects.

TIP

When checking objects that have been granted rights, you need to follow the rules for acquiring rights. You should check all containers above the User object, [Root] , [Public] , all groups the user is a member of, and any objects the user is SE to (which includes any organizational roles).

The following are some questions you can ask to help determine the location within DS where the user's excessive rights may come from:

• Is the user SE to Admin?

• Is the user a trustee or a member of a group that is a trustee with Supervisor rights to the Write right to the ACL attribute of the NCP Server object?

• Is the user a trustee or a member of a group that is a trustee of a container above the NCP Server object with Supervisor rights to the Write right to the ACL attribute of the object?

• Is the user a trustee or a member of a group that is a trustee of [Root] with Supervisor rights to the NCP Server object?

• Is the user under a container that is a trustee with Supervisor rights to the [Root] object?

• Is [Root] a trustee with Supervisor rights to a container that is over the NCP Server object?

• Has [Public] been added as a trustee with Supervisor rights to a container that is over the NCP Server object or to the NCP Server object itself?

Maximum Concurrent Logins Limit Reached

One of the most common problems encountered since the initial release of NDS in 1993 is a problem involving maximum concurrent logins. The first instance of this problem you'll probably hear of involves a user calling you or your help desk and saying that he or she is receiving a message indicating that the maximum concurrent logins have been reached but that he or she is not logged in on any other computer on the network.

When a user logs in to the network, the login process compares the current number of values in the Network Address attribute of the User object to the value of the Login Maximum Simultaneous attribute. If the number of network addresses is less than the maximum logins allowed, the login is allowed to proceed; otherwise , the server returns the error code -217 ( ERR_MAXIMUM_LOGINS_EXCEEDED ) to the client, which then displays the appropriate error message to the user.

The issue here is that there are circumstances in which old network addresses are never removed from the Network Address property for the user. This most commonly occurs when a workstation the user is logged on to ends its session with the server abnormally. In a NetWare 3.x environment, this is not a problem because the User object has separate authentication credentials for each server. In a NetWare 4 or higher environment, however, the credentials are valid for all servers the client is connected to, and the servers do not communicate with each other a loss of communication with the client. During a normal shutdown, the client logout results in the address being properly cleaned up because the client disconnects from all servers. In an abnormal shutdown, however, none of the servers is told that the disconnect occurred ”each uses the watchdog process to clear connections that are terminated abnormally.

You can clean up this type of problem in a few different ways:

• Increase the maximum concurrent logins allowed

• Remove the concurrent login restriction

• Use DSRepair to expire network addresses on the User objects that are no longer valid

The first two of these options are easy to implement but may not be desirable for security reasons. If the first two options are not viable for your environment, you will have to use the DSRepair option.

DSRepair automatically purges Network Address attribute values that are older than 60 days (based on the Creation TimeStamp [CTS] value) during an unattended repair or during repair of the local database from the Advanced Options menu. However, you can control the time period in which to purge unused network address values by using the -N switch for DSRepair. To do this on a NetWare server, you load DSRepair as follows :

 LOAD DSREPAIR -N<  number of days  > 

After DSRepair is loaded, you execute either an unattended repair or a repair on the local database. During the repair, the value < number of days > is used instead of 60. The main drawback to this solution is that it requires a database repair be run. Running the repair locks the database on the server the repair is being run on. This may not be a desirable side effect (because a locked DIB prevents users from authenticating to that server) for correcting a problem that some administrators consider to be nothing more than a nuisance.

TIP

You can schedule DSRepair to automatically run during off-hours. For example, you can use the CRON.NLM file that is shipped with NetWare and have it execute the following command every night to clear out all network address values at a predetermined time:

 LOAD DSREPAIR -N0 -U 

The DSRepair option clears out the Network Address attributes for all users who are in the partitions hosted by the server. Novell offers a utility called REMADDR.EXE that can also remove Network Address attribute values for a specific user in IPX environments. Refer to TID #2950374 for details.

TIP

The DSRepair option works only on NetWare because the other implementations do no support the -N option. A more flexible, but workstation-based, option is Deladdr from JRB Software (see www.jrbsoftware.com ). It works in both IP and IPX environments.

Dealing with Stealth Objects

Chapter 8, "eDirectory Data Recovery Tools," discusses how you can handle hidden objects. This section describes another possible solution that uses existing tools ”DSView on NetWare 4.x servers and DSBrowse on later servers ”that you can readily obtain for free without having to call Novell or use a third-party utility.

In a distributed management environment, a network administrator may lock out a branch of a DS tree from administration by other network administrators. This is done by granting one or more users Supervisor object rights to the topmost container of the tree branch and revoking the inheritance of rights from higher in the tree by using inherited rights filters (IRFs). This branch of the DS tree becomes invisible or unmanageable if none of the trustees of the container are available at a later time or have forgotten their passwords.

NOTE

As long as the users know their User object names and the contexts, they can still log in, even if they cannot browse the tree to see the objects.

In such a situation, where there are trustees to the topmost container, you can make use of Bindery Services to change the password of one of the administrators. Here are the steps to accomplish this:

1. Find a user who has explicit rights to the container in question. If you don't know what containers are invisible or hidden, the Hidden Object Locator NLM (see Chapters 8 and 13, "eDirectory Health Checks") can assist you in locating them in a NetWare environment; otherwise, you can use DSBrowse as described next . If the users having rights to the containers in question are also unknown, you can use DSBrowse:
   
   

   1. Run DSBrowse on a server that has a replica of the partition containing the blocked container.
   
   

   2. Browse the tree until you locate the blocked container object.
   
   

   3. Browse through the values of this object's ACL attribute until you find a User object that has Supervisor object rights. Figure 11.8 shows that a user called NewAdmin has full rights to the hidden container.
   
   

   Figure 11.8. Locating a user who has Supervisor rights.

   
   

   4. Although the User object's context is not shown in the data, you can use its object ID to locate the object in the tree. In this example, the object ID is 0x00008172. With DSBROWSE.NLM , simply enter the value into the ID field (you can leave out any leading zeros) in the Object Search menu and then press F10. With the Windows version, switch DSBrowse into DIB Browser mode, highlight Entries, and right-click. Then select the Go to Record ID option from the context menu and enter the ID value (again, you can leave out any leading zeros). The resulting screen looks similar to what is shown in Figure 11.9. This provides you with the context information of the User object.
   
   

   Figure 11.9. Locating the user NewAdmin in the tree.

   
   

   NOTE

   You cannot use NDS iMonitor or iManager for this step because what these utilities can see in the DIB are based on the rights of the authenticated user.

2. After you locate a user who has Supervisor rights to the blocked container, on a server that holds a writable replica (Master or Read/Write) of the partition, set the server's bindery context to the location of the user who has rights.
   
   
3. Log in to the server from step 2 as Supervisor (in Bindery mode). If that server is running eDirectory 8.7.3 or higher, you need to also include the partition where Admin is in the bindery context and log in as Admin instead.
   
   
4. Change the password of the administrator user ( NewAdmin in this example) by using SYSCON.
   
   
5. Log in with the revived user and either grant other users rights or remove the IRFs from the container so that it can be administered again.
   
   

You can apply this same procedure to blocked objects.

NOTE

This procedure assumes that there is at least one trustee with Supervisor rights to the blocked object. If there are no trustees or if the amount of time to track down a trustee is long, you should consider trying the solutions outlined in Chapter 8 .