This chapter discusses practical aspects of giving users access to NDS objects that may not be immediately available. The several objectives important to this chapter are listed on page 12-1:
Concepts:The text explains that the NDS tree is used to grant rights to users, based on their location and the location of other resources in the Tree. This use of the Tree affects what users can do and how the network administrator manages user access to objects and resources. Identify How NDS Structure Affects Network AdministrationThree areas to consider are listed on page 12-2:
Identify NDS Planning GuidelinesSensible NDS planning saves the administrator work later. Four results of good planning are listed on page 12-2:
As a rule of thumb, your structure may be based on any of the following considerations (and most likely on a combination of them, leading to a compromise):
Much more information about this is discussed in the NDS Design and Implementation class. Provide Users with Access to ResourcesSetting the context that a user logs in to is discussed on pages 12-7 and 12-8. This is a part of the process that makes it possible to log in. The current context at login can be set in Windows 95 and NT in the Novell Client configuration window (shown on page 12-7). Setting the current context in a login script is shown on page 12-8. Note that the command should contain a distinguished name. Also note, that it need not be typeful. The login context can be set at the time of login in several ways. The way specified on page 12-8 adds the information to a login script. The text points out that this can be done for more than one user at a time, as opposed to other methods which are used on individual workstations. Another way is to specify the context you are logging in by using a distinguished name on the Windows 3.1x, 95, 98, or NT platforms. This may be done by a user, if the user knows the proper context information to enter. To access objects in other contexts, as described on page 12-9, you must supply enough information to the system to find the object. This is why a common name is enough for objects in the current context, and distinguished names are required for objects outside the current context. Compare the notation used for similar operations on pages 12-9 and 12-10. Distinguished names are required for such operations involving objects in other contexts. Configure Shortcuts to Access and Manage ResourcesThe next topic is using shortcuts to objects in other contexts. Four methods are discussed:
Note that the Alias object points to an NDS object, while the Application and Directory Map Objects point to parts of the file system. The Global use of a Group object refers to a fact not stressed before, that a Group may contain users from any part of the NDS tree, not just the container the Group is created in. The choice of where to create the Group object may be decided by what location makes it easier to assign users or to assign rights to the Group. Identify Guidelines for Setting Up Resources in a Multicontainer EnvironmentOn pages 12-17 and 12-18, there are guidelines to the security and creation related issues of this chapter:
Identify the Actions and Rights Needed to Grant Access to NDS ResourcesThe chart on pages 12-19 and 12-20 is important. It shows what action must be taken to grant access to various resources, and the authority that you must have to take the action. This will help you plan the authorities needed by container administrators, and serve as a reference to the actions to take to enable users to use the system. Configure Login Scripts That Identify Resources in Other ContextsFinally, the chapter ends with a discussion of the rules about mapping and capturing in Login Scripts. The basic rule is that a relative name will assume the object being mapped or captured is in the current context, while a distinguished name will remove doubt, and allow you to map or capture in another context. Little mention is made of the CAPTURE command in this book. It is used to enable users to print in non-NDPS systems. |