The first level of providing good logical security is to protect administrative accounts. This might seem fairly obvious as a need, but the how-to aspect is something that many administrators do not give thought to.

Protecting administrative accounts is quite easy to do. First, you should try to limit the number of partitions that contain administrative accounts and make sure the replicas that hold those objects are on servers that have an extra degree of physical and console security. As discussed earlier in this chapter, if someone can gain access to a server console, he or she can grab the DIB files and attack them offline.

Second, containers where there are administrative accounts should have intruder detection turned on. You can turn this on in NetWare Administrator, for example, by selecting the details of the container and then selecting the Intruder Detection tab. By default, this feature is turned off, and when it’s turned off, someone trying to break into your system can try as many passwords as he or she wants in an online brute-force attack. Figure 15.4 shows how to set up this feature.

FIGURE 15.4 Enabling intruder detection through NetWare Administrator.

Third, you want to limit the number of workstations the administrative accounts can log in at simultaneously. You may elect to enable administrators to only log in from certain workstations; you can also do this by using a network address restriction. As shown in Figure 15.5, you can enable network address restrictions based on IPX or IP addresses. Although Figure 15.5 also show a number of other address types—Ethernet/Token Ring, AppleTalk, and so on, these entries may be used by custom-developed applications, but they are not used by the Novell Client software to restrict user logins.

FIGURE 15.5 Specifying network address restrictions.

Novell Client software prefers to use IP instead of IPX to connect to NetWare 5.x or higher servers. Therefore, if you have an address restriction set only for IPX, it will not allow the IP connectivity, and this results in the user not being able to log in.

In DS, it is possible to block Supervisor rights to an object or a branch of the tree. The only caveat is that Supervisor rights must be explicitly assigned to at least one user object that is being protected with an Inherited Rights Filter (IRF). Otherwise, you will end up with an unmanageable object.

Figure 15.6 shows the Inherited Rights Filter dialog box in its default state. To block a particular right, you simply uncheck it. The arrow next to the check box reflects the state of the filter; when blocked, the arrow icon changes to indicate that a right is blocked. For protecting an administrative account, we recommend blocking all object rights except Browse rights and all property rights except Read and Compare. This prevents someone from deleting the account and re-creating it without the IRF, and it also prevents people from making other changes to the account.

FIGURE 15.6 The Inherited Rights Filter dialog box in NetWare Administrator.

With the Property Rights portion of the Inherited Rights Filter dialog box, you can block rights to specific attributes, such as password management, or to all attributes. The default is to set up the IRF for all properties. By selecting a specific attribute, though, you can be very granular in what you revoke rights to, just as you can when granting rights.

When you’re protecting an administrative account, we recommend that in addition to giving a user explicit Supervisor rights to his or her own object, you give another user or group of users rights as well. For example, in Figure 15.3 we have a group called RootAdmins located in the Groups.IS_Admins container that would be ideal for this type of role. The idea behind doing this is that if an administrative user gets locked out of his or her account, somebody else should be able to unlock the account or change the password. Remember that by applying an IRF to an object, you remove some degree of administrative access to that object.

You might wonder why a special group called RootAdmins exists in this example. After all, Admin has explicit rights to [Root], and the discussion thus far has suggested granting explicit rights to [Root] for objects that need Admin equivalence. In a large environment, it might make sense to use a group to house administrative accounts other than Admin and possibly one other account; that way, at least one person can get back in if something happens to both the Admin user and the RootAdmins group. Using a group membership is somewhat easier to manage if you have a few people with that level of access.

It is also strongly recommended that administrative users change their passwords on a regular basis (perhaps more frequently than the typical end users); it is very easy for administrators to make exceptions for themselves with their own administrative accounts and remove otherwise standard password restrictions and length limitations. If anything, administrative accounts should have their passwords changed more frequently, have longer minimum password lengths than standard user accounts, and be used only for performing administrative tasks. Any other work the administrator does should be performed through a separate account set up as a typical user account.

Also suggested in our tree structure example is a special group called OU_Admins. As the name implies, this group is used for granting rights to all organizational unit (OU) objects and all objects under those containers. The only exception to this is the IS_Admins container itself; only Admin and members of RootAdmins should have rights to the IS_Admins container because these users determine what administrative groups should exist, what rights these groups should have within the tree, and who the group members are.

Having Supervisor rights to the [Root] object grants you another special right: the capability to make changes in the schema partition on all servers. Extending the schema is one of the things that make NDS and eDirectory so versatile. At the same time, you need to control changes to the schema, or you might run into problems due to schema definition clashes. This is a real danger if you have programmers who write programs using the Novell Developer Kit for eDirectory. In most cases, extensions added to the schema can be very difficult to remove, and in some cases, they cannot be removed after they’re added.

ConsoleOne includes the Schema Manager (accessed from the Tools pull-down menu; see Figure 15.7) that has the capability of adding extensions to a schema. Administrators who are learning may have a tendency to play with this feature and create new object classes and attribute definitions. If you or another part of the administrative staff want to experiment with this functionality, it is best to test it on a nonproduction tree. For this reason, we recommend using a group for rights at [Root] (the RootAdmins group in the preceding example) and a second group that has rights to all objects under [Root] (the OU_Admins group).

FIGURE 15.7 Creating new class and attribute definitions with Schema Manager.

Limiting the access to [Root] also limits the possibility of someone who is trying to break into your system causing damage. If the administrative accounts are few and are relatively difficult to locate, and if the accounts that are found do not have rights to [Root], the ability for a would-be hacker to extend the schema and create a special class object to be a backdoor into the system is limited.

Another aspect of DS that should be closely controlled is the capability to modify login scripts. Refer to Figure 15.3, where another special group is called Script_Admins. The idea behind the Script_Admins group is that only members of the Script_Admins group can change the majority of login scripts.

One large company has implemented this on a rather large scale. Each of the OUs in the tree contains a subcontainer called Scripts. The Scripts container contains profile objects that make up the login scripts for that container. The container script itself contains only one line:

The main script indicated in the INCLUDE statement contains all the standard script components—validation of network address for dial-up accounts (to abort the script and not run programs in the script over a dial-up connection) and execution of an operating system–specific login script.

The operating system–specific script is called with the following line:

The client performing the login request fills in the %OS portion of the command with the name of the operating system. The Scripts container then contains the following scripts to be included:

These are all created as profile objects and contain commands specific to the operating system in question. The reason this is done is because as the Novell Client has evolved, its login script interpreter has come to include capabilities that are not supported in the old LOGIN.EXE DOS program.

On 32-bit Windows platforms, the @ command executes an external program and immediately continues the script. It is very similar to the # command (which these interpreters also support), except for the fact that it does not wait for the program that was run to return control back to the interpreter.

Unfortunately, the LOGIN.EXE script interpreter does not understand the @ command, and even if you attempt to check for the operating system in the login script as shown here, the script interpreter still interprets the line and returns an error:

You might notice that the list of different script names includes three DOS names and both WIN95 and WIN98. This is because the %OS variable actually returns these values, depending on the workstation’s operating system. In the case of DOS workstations, however, the scripts for MSDOS, PCDOS, and DRDOS are really the same. Rather than copy the script and have to maintain three copies, you can simply work with one (MSDOS is what we use) and then include that script in the others, using the login script INCLUDE command. The same holds true for Windows 98, which is frequently considered by software to be an upgraded Windows 95—the client is the same, the environment is the same, so the script probably should be the same as well.

Protecting login scripts really serves two purposes:

When a script change is made and causes problems, it can be difficult to determine what change was made and who made the change. By limiting editing access to the login scripts, you reduce the number of people who might have caused the problem. A good side effect of this is that you can more easily create an environment where script changes are thought out and discussed before implementation.

To limit access to edit the scripts, you need to secure the container. First, you grant Admin and the Script_Admins group explicit Supervisor rights to the Scripts container, as shown in Figure 15.8.

FIGURE 15.8 Granting Supervisor rights to the Scripts container.

Next, you block all rights to the container except for Browse object rights and Read and Compare rights to all properties.

In some environments where tree administration is decentralized, it may be necessary to set up regional administration—possibly even site-level administration. If you have administrative groups in Salt Lake City and Toronto, for example, you may not want the administrative group in Toronto to be able to make changes to the users in the Salt Lake City container.

Setting up administrative authority to do this is easy. Using the base model shown in Figure 15.3, you add two groups to the Groups.Admin container—one called TorontoAdmins and another called SaltLakeAdmins. For the high-level container in the tree for Salt Lake City, you grant the SaltLakeAdmins group Supervisor object rights. Similarly, for the Toronto high-level container, you grant the TorontoAdmins group Supervisor object rights.

If multiple sites within a location have their own administration, you can take this a step further. In Salt Lake City, you may have a regional office but also several branch offices with their own IT staff, in Murray, Provo, and Logan. Assuming that these containers are listed under Salt Lake City’s container, you would create a container in Groups.Admin called Salt Lake City and under that container create the groups MurrayAdmins, ProvoAdmins, and LoganAdmins.

The reason for this setup is that you might want to design a hierarchy for adding people to these groups. Putting the branch office administrators in a container named after the region means that you can grant the regional Admins groups Supervisor rights to the container. The regional Admins groups can add people to those groups, but without having the capability to add people to the regional group.

This type of design is very scalable and easy to manage, and at the same time, it provides a foundation for smaller organizations that will not have to change as the organization grows.

You should do security equivalence checks from time to time. It never hurts to make sure security is set up the way you think it is.

The first thing you need to understand is how security equivalence works. Figure 15.9 shows three users—AmyP, JimH, and PeterK—and how security equivalence works.

FIGURE 15.9 Security equivalences between three users.

In this figure, JimH is assigned a security equivalence to PeterK, and AmyP is assigned a security equivalence to JimH. In some environments, the result might be that AmyP receives security equivalence to PeterK, but in DS or the bindery, that is not the case. Security equivalences are not transitive—they are evaluated only to a single level. This makes the evaluation of security equivalence much simpler.

NetWare 5 introduced a new feature called an Inheritable Access Control List value. As you will see in the section “Setting Up eDirectory Security Access for a Help Desk,” later in this chapter, the capability to set this up simplifies administration greatly, but it introduces an additional complexity to evaluating security equivalence—also commonly referred to as the effective rights of an object.

Fortunately, NetWare Administrator and ConsoleOne have the capability to perform the evaluation for you, even with the changes that became effective with NetWare 5. Figure 15.10 shows the Effective Rights window in NetWare Administrator.

FIGURE 15.10 Using NetWare Administrator to evaluate effective rights.

The evaluation of one object’s effective rights to another object’s attributes includes several checks:

You might notice that group membership is not one of the things tested. Group membership itself does not grant rights to another object. However, because members of a Group object are also security equivalents to the Group object, each member will have whatever rights the Group object has.

Starting with the release of NetWare 4, Novell has included a feature for providing an audit trail. The original auditing in NetWare 4.0, and even as late as NetWare 4.10, was not very easy to use. The utility used for manipulating auditing, AUDITCON.EXE, was fairly cryptic, and its reports contained too much information to determine who was doing what. In short, it was difficult to find specific information you might look for because the reports were so difficult to read.

In NetWare 4.11, the Auditcon utility became more robust. Gone were the auditing passwords, and in their place was an object placed in the tree to control access to various features of auditing. Auditing in NetWare 5.x is still handled through Auditcon, shown in Figure 15.11. The utility still maintains its somewhat cryptic interface, but the tool has been greatly improved. Because this is a largely unfamiliar utility for administrators, we examine it in some detail. A brief discussion about Novell Nsure Audit (NNA) is presented after the discussion of Auditcon.

FIGURE 15.11 The Auditcon main menu.

Auditing is a good way to keep track of what changes are made on a network and who makes them. Auditing can be a very powerful tool, but if it is overused, Auditcon data can become burdensome to maintain and evaluate. Auditing all events is generally not a good idea because of the space needed on all servers and because of the amount of information returned. As you can see, there are many events that can be audited, and many of those events happen very frequently.

You should use auditing when you want to figure out why something is happening. For example, you might want to audit the container objects, but you only see changes in the access control list; this would indicate that someone is granting rights or removing rights in a way that you do not want them to. You might also want to audit changes to passwords or resets of intruder lockouts. In conjunction with a help-desk setup, this is a way to provide checks to verify that only the people you want to be able to make the changes are actually the ones making the changes.

Another use for auditing is to record changes in the DS partitioning and replication scheme. In the Directory Services Auditing dialog box events, there are items to audit partition split/join operations as well as replica additions, deletions, and changes of replica types.

Because an object in the DS tree controls auditing, you can block access to even see the object, thus making the auditing operation transparent to the users and other administrators on the system.

When you have Auditcon running, you can select Audit Directory Services and then select a container to audit by pressing F10. If the container does not have auditing enabled, you see a menu like the one in Figure 15.12.

FIGURE 15.12 Enabling container auditing with Auditcon.

When auditing is enabled, the menu in Figure 15.13 is displayed.

FIGURE 15.13 Menu choices that are available when container auditing is enabled.

The first option in the menu, Change Replica, enables you to select the replica you want to view. DS auditing is stored along with the directory itself and is a part of the partition. Therefore, its information is replicated along with the rest of the partition.

When you’re setting up auditing, the menu item you want next is Auditing Configuration. The menu that appears when you select this item, shown in Figure 15.14, is where you select what you want to audit and which objects in the tree you want auditing enabled for.

FIGURE 15.14 The Auditing Configuration menu in Auditcon.

The first item on this menu, Audit by DS Events, enables you to toggle specific events by highlighting the event and pressing F10 (see Figure 15.15). When you have auditing enabled and have selected the events and users you want to audit, you can extract the auditing information from the audit logs. Selecting the Auditing Reports option from the Available Audit Options menu shown in Figure 15.13 brings up the Auditing Reports menu, shown in Figure 15.16.

FIGURE 15.15 Selecting which DS events to audit.

FIGURE 15.16 The Auditing Reports menu.

There are several options in the Auditing Reports menu; these options create a readable file that can be browsed offline. If you have few events enabled, browsing offline can be a fast way to see what has been happening on the system. The second type of report is viewed onscreen; this is similar to the report options, except that the information is displayed directly to the screen.

The most useful of the different reporting methods is the database report. This creates a comma-delimited file that can be imported into a database or spreadsheet for more detailed analysis. This file format does not lend itself to easy visual examination, but if you are attempting to keep a history of old audit files to establish trends in certain events, this is the best format to use.

The Auditing Reports menu contains the option Edit Report Filters. You can edit these filters either from the menu or after selecting a reporting method. Figure 15.17 shows the options available for creating reporting filters.

FIGURE 15.17 Edit Report Filter menu options.

In addition to performing DS auditing, you can audit a number of other services. By returning to the main Auditcon menu and enabling volume auditing, you can select the other types of events that can be audited. The information recorded for all the volume-specific auditing events is stored on the volume being audited in the _NETWARE directory on that volume.

All the different types of auditing include the capability to control the configuration of auditing. We mentioned earlier in this chapter that auditing can cause disk space problems if you are not careful with how you use it. The Audit Configuration menu, shown in Figure 15.18, enables you to limit the use of disk space and define what should happen when the audit log is full.

FIGURE 15.18 Audit Configuration menu options.

The Audit Configuration menu options are set on a per-volume or per-container basis. Another configuration option is the capability to audit not-logged-in users or to enable auditing of specified users as opposed to all users. The User Restriction menu options are shown in Figure 15.19.

FIGURE 15.19 Special user restriction configuration options.

The other option on the User Restriction menu, also called User restriction, allows you to specify whether all users are audited (value set to NO) or just the specified users selected from the Audit Configuration menu (value set to YES). This is useful if you have containers with a large number of users in them and do not want to have to enable auditing for every user manually or figure out when users are created so you can enable auditing for them.

Because managing auditing requires a fair amount of time and energy, you should not turn on auditing frivolously. Rather, you should use it as a preventive tool. There are two differing philosophies when using auditing:

There are advantages to both options. With the first option, people know you are watching what is happening on the network and know that they will be held accountable for the changes they make. This tends to make people think more before they make a change because they know you will find out if something goes wrong.

On the other hand, by not telling people you are using auditing, they do not feel that Big Brother is watching everything they do. Used in this way, auditing can be a tool for helping you learn what shortcomings other administrators have in their education, and you can teach them how to properly do things.

With the second option, if you are not careful, people will find out that you are watching every move they make. It is important when dealing with people that they be at ease and not fearful that you are going to make life difficult for them when they make mistakes. A big part of successfully implementing auditing without letting people know you are auditing them is making sure they cannot see the Audit:File objects in the DS tree. If those objects are not blocked, people will likely know that something is up, particularly if they are familiar with how auditing works.

While no method is completely effective for keeping people from knowing auditing is going on, it is possible to make it more difficult to detect. Using an IRF to block rights to the object is a starting place.

NetWare 6.0 shipped with NAAS, but NAAS is no longer supported as of January 1, 2004. NNA, included with NetWare 6.5, supercedes NAAS. NNA is a centralized, cross-platform, client/server-based auditing service. It can collect event data from multiple applications across multiple platforms; it writes the data to a single data store, using a common data structure; and it includes tools for reporting the logged data. It also provides real-time event information for notification and monitoring.

NOTE

NNA’s installation extends the eDirectory schema and includes Novell iManager 2.0 plug-ins for administration and management. You can configure and manage the various NNA components—including Logging Applications but not Platform Agents—by using Novell iManager or, in environments where eDirectory is not present, by using Novell WebAdmin (see Figure 15.20).

FIGURE 15.20 Managing NNA components using WebAdmin.

NNA is composed of four primary components (see Figure 15.21):

FIGURE 15.21 NNA architecture overview.

Logging applications, also called reporting applications, are software that reports events to platform agents, using the NNA SDK. Novell has already instrumented many of its systems to log to NNA, including all currently supported versions of NDS and eDirectory; NetWare 4.2, 5.1, and 6.x; BorderManager 3.8; and NetMail 3.5. You can add the instrumentation (that is, event reporting) to your own applications by using the NNA SDK that is freely downloadable from Novell DeveloperNet (http://developer.novell.com).

A platform agent is a shared library that collects events from all logging applications on the platform on which it runs and forwards the data to the logging server. One platform agent must reside on every platform that has one or more logging applications. When the platform agent cannot communicate with a secure logging server—due to a downed link, for instance—the collected events are sent to the secure logging cache module, which stores them in a local disconnected mode cache file(s). When the link is reestablished, the contents of these files are transmitted. Similarly, if the platform agent receives a flood of events that might cause network congestion if immediately transmitted, it buffers the events in the secure logging module and trickles the data flow until the traffic lightens.

The communication links between platform agents and the secure logging server can be encrypted using SSL/TLS to ensure the privacy of the events. In addition, platform agents employ two methods—event signing and event chaining—to ensure that the logged events are not otherwise modified by any intervening third parties. In event signing, the platform agent (or the logging application, in some cases) embeds a digital signature to each event before the platform agent forwards the event data to the secure logging server. This signature enables the secure logging server to verify the integrity of the event data it receives, ensuring that the data has not been modified.

In event chaining, the platform agent establishes a sequential, tamper-evident link of all events. The platform agent (or the logging application, in some cases) includes with each new event from a given logging application a hash of the previous event from the same logging application. The platform agent signs the hash, along with the data from the current event, before sending it on to the secure logging server. The hash enables you to inspect logs to ensure that all events that have occurred are contained in the log in the sequence in which they occurred and that no events are missing.

The secure logging server is a centralized and secure server that aggregates the logging entries received from the various platform agents that it serves. The secure logging server event manager receives the data and forwards it immediately to the logging, notification, and monitoring services provided by the secure logging server. The logging service records the events in the data store. The notification service alerts the appropriate people or systems of particular events or absence of events via one or more of the defined means, such as SNMP and SMTP. The monitoring service sends values in realtime to monitoring applications.

The secure logging server records all events in a centralized data store, using a format that is similar to the syslog packet format. The data store can be kept in a number of different database formats, such as MySQL or Oracle, depending on your selection during NNA installation; if MySQL or Oracle is not already installed, a flat-file database is used instead. NNA is also capable of creating filtered data stores. Based on criteria you define, NNA captures specific types of events and writes those events to secondary data stores. You can query the data stores by using included custom reports and log drivers that support MySQL database, Oracle database, flat-file database, and syslog. Novell has planned support for other databases, including DB2 and Sybase. You can also develop your own custom log drivers by using the NNA SDK.

The NDS/eDirectory Instrumentation application (or agent) for NNA, called auditDS, allows NNA to log eDirectory events. To log replicated eDirectory events (such as object creation and deletion) on NetWare, Windows, and Linux/Unix systems, auditDS should be loaded on one server per DS replica. To log nonreplicated events (such as those associated with DirXML), it must be installed on each individual server for which you want to log nonreplicated events.

The following are two excerpts from the NNA eDirectory event log (in flat-file format)—with the timestamps removed—showing the events associated with Admin logging in and the creation of a new Group object:

As you can see, each event generates a fair number of entries in the log. Therefore, you need to spend some time considering, deciding, and selecting the types of events to track.

You may be wondering why you need to bother with the manual process of setting up security when you can simply use Role-Based Services (RBS). Let’s quickly overview RBS. With the introduction of iManager as the direction for a Web-based management tool, a functionality called RBS was introduced. The concept behind RBS is that you have the ability to assign specific responsibilities to users (say, your help desk) and to present them with only the tools (and the accompanying DS rights) necessary to perform those sets of responsibilities and those sets only. For instance, the Help Desk role allows the user to only reset intruder lockouts, create users, reset passwords, and nothing more.

RBS allows you to focus the user on a specified set of functions (such as reset intruder lockouts and reset passwords), called tasks. One or more tasks can be grouped together and form a role (such as Help Desk). What a user sees then when he or she accesses iManager is based on his or her role assignments stored in eDirectory. Only the tasks assigned to that user are displayed (see Figures 15.26 and 15.27). The iManager plug-in for that task presents the necessary tools and interface to perform the task. You can assign multiple roles to a single user. You can also assign the same role to multiple users.

FIGURE 15.26 Giving Admin access to all roles and tasks.

FIGURE 15.27 Giving Users access to only the roles and tasks you have assigned to them.

You can either use the existing roles or define additional custom RBS roles based on your organization’s needs. After you have created the desired roles, you can assign members to each role. In doing so, you also specify the scope (the starting NDS container or context) in which each member can exercise the functions of the role. A user can be assigned to a role in one or more of the following ways:

Therefore, instead of having to go through the steps presented earlier to assign individual rights necessary for a user to perform a specific task, you just use the following simple steps to accomplish the same result by creating role associations and scope assignments:

1.   In iManager, click the Configure button (see Figure 15.28).

FIGURE 15.28 Modifying iManager role assignments.

2.   Click Modify iManager Roles under Role Configuration.

3.   Click the Modify Members button to the left of the role you want to modify.

4.   To add an association to the role, specify the full distinguished name of the object (which can be a user, a group, an organizational role, or a container) in the Name field; you can use the Browse button to the right of the field to locate the object. Fill in the Scope field with a container name; you can also use the Browse button for this.

5.   Click Add and then click OK.

To remove a role association, you check the box to the left of the listed name(s), click Remove, and then click OK.

On the surface, RBS seems to be the ultimate solution to a security nightmare—giving help desk users only what they need and not too much, with just a few simple clicks. By defining custom roles and tasks, you can present the exact list of tasks for your help desk users to utilize. However, there is a security loophole that is often overlooked.

When you associate a user to a RBS role, the user is granted the necessary DS rights to perform the tasks even when he or she is not logged in to iManager! Here is what happens when you add a user to an RBS role, using the example shown in Figure 15.28:

   User Helpdesk.DreamLAN is added to the Help Desk role with the scope set to O=XYZCorp.

   An rbsScope2 object called XYZCorp is created under the Help Desk Management.Role Based Service 2 container.

   The rbsScope2 object is made a trustee of the scope container (O=XZYCorp in this case) and granted the necessary rights for the various tasks defined for the Help Desk role (see Figure 15.29).

FIGURE 15.29 DS rights assigned by the Help Desk RBS role.

   The user Helpdesk.DreamLAN is made an rbsMember object of the rbsScope2 object and is made the security equivalent to the rbsScope2 object.

All this happens at the eDirectory level, and the assignments are static. This means that Helpdesk.DreamLAN has all these DS rights, even when not using iManager. Therefore, the user can use other management utilities, such as ConsoleOne, to perform additional tasks that are allowed by his or her DS rights but not when using iManager—not because he or she doesn’t have the necessary rights but because iManager didn’t have these additional capabilities listed as available tasks.

Consider this scenario: The default Help Desk RBS role allows the associated users to create users but not delete users. However, as you recall from the discussion about default ACL templates in Chapter 2, “eDirectory Basics,” because of the default ACL template defined for the Top class, the object that creates another object has full control (Supervisor rights) over the created object. This means that although the Help Desk role users will not be able to delete users they created using iManager (because it does not give them the option), they can delete these User objects by using another tool, such as ConsoleOne. Consequently, you must take care when using RBS roles to delegate network management responsibilities.

Because RBS role assignments are based on scopes (DS contexts), you should place your administrative users in containers that are not managed by your typical help desk roles to ensure that these users do not get modified accidentally. You should take the precautions and steps outlined earlier to protect your administrative users.

RBS is an excellent tool when used with the right expectation and maintenance. Because it is a Web-based application, its performance and functioning are heavily dependent on a number of factors:

If any one of these components required by iManager fails, iManager will stop functioning. Therefore, you should not rely on iManager as your sole management platform, and you should have your staff also trained in using other tools, such as ConsoleOne.