| Earlier in this chapter, we discussed the use of IRFs to block access to certain objects in your tree. Using IRFs in your tree can be beneficial if done properly, but it can be disastrous if the only user object with Supervisor rights to a container or an object is deleted. In addition, you might find that an ex-administrator created a backdoor account in the system and hid the object. Locating hidden objects with excessive authority is not very difficult; the ones that are difficult to find are the ones that are hidden and have no special rights. This type of object is referred to as a zero-footprint hidden object. Tracking down hidden objects with excessive rights is a relatively simple task; however, it can be very repetitive and time-consuming in a large tree. If you have a large network, you might want to look at some of the NDS reporting tools or spend more time learning how to combine NList with awk scripts, as discussed in Chapter 10, "Programming for eDirectory." Locating hidden objects with excessive rights involves looking at the following: -
Objects with administrative rights at [Root] -
Objects with administrative rights at all container levels -
Objects with administrative rights to Admin and related objects -
Objects that are listed in the Security Equals attribute for administrative objects You should also look for objects with administrative rights ( specifically , Supervisor rights to [All Entry Rights] ) to NCP server objects. These rights grant the user full file system Supervisor rights on all volumes associated with that server. After you have looked in these places, you will have a list of objects that potentially have Supervisor access to your tree. You can then search your tree for each of the objects you have found to have administrative rights. Objects that do not have administrative rights but exist in the tree can be a nuisance. For example, if you are attempting to reorganize your tree and need to delete a container, a hidden object or container makes this impossible . Novell Consulting Services created a utility that is capable of locating hidden objects in the tree. You can find the Hidden Object Locator NLM utility ( HOBJLOC.NLM ) at www.novell.com/coolsolutions/tools/1098.html. This tool can be extremely useful when you're trying to determine the cause of problems when attempting to delete a container object. For instance, if NetWare Administrator indicates that a container could not be deleted because there are still subordinate objects, there are two possibilities: NOTE HOBJLOC.NLM stores its log files, created every time the NLM is run, in the SYS:SYSTEM\HOBJLOC directory.
It is easy to use the Hidden Object Locator utility to rule out the second option as the cause of the problems. If the Hidden Object Locator finds an object (see Figure 15.22), there are at least two options: Figure 15.22. Finding hidden objects in your tree by using HOBJLOC.NLM . 
NOTE At this time, all third-party solutions that deal with IRF -blocked objects are NLM based. That means they require a NetWare server to host the writable replica in which the stealth object resides. If you have a pure-Windows or Unix environment, you need to call Novell.
TIP Refer to the "Dealing with Stealth Objects" section in Chapter 11, "Examples from the Real World," for additional information on tracking down hidden objects using Novell-supplied tools such as DSBrowse.
| 