Bindery Services “ related Issues Although NDS and eDirectory are backward-compatible with the bindery, you need to be aware of a number of common issues when dealing with bindery-based applications in a DS environment. NetWare bindery information is server-centric; therefore, when you use Bindery Services in a DS environment, the bindery data that you see is also server-centric. From our experience, there are four general areas of concern when using Bindery Services: You can use the procedures outlined in Table 11.1 to verify whether you have Bindery Services enabled. Table 11.1. Verifying That Bindery Services Is Enabled | OPERATING SYSTEM | PROCEDURE | | NetWare | On the server console, enter either the command SET BINDERY CONTEXT or CONFIG . Alternatively, check the SYS:\SYSTEM\AUTOEXEC.NCF file for the line SET BINDERY CONTEXT= (which is generally located near the beginning of the file). If a bindery context is set, the default is to set it to the container where the NCP Server object is located. | | Windows | From NDSCon, highlight ds.dlm , click the Configure button, and then select the Bindery Emulation tab. By default, no bindery context is set. | | Linux/Unix | Examine the /etc/nds.conf file and look for the n4u.nds.bindery-context= line. If the line is not present or the value is , Bindery Services is not enabled. By default, no bindery context is set. |
The Bindery Supervisor User The bindery Supervisor user is an odd creature. It is both a DS object and a non-object. It is a bindery object in that it exists on each and every NetWare 4 and higher server and on non-NetWare eDirectory servers, regardless of whether Bindery Services is enabled on that server or not. Similarly to the [Public] pseudo object, the bindery Supervisor User object doesn't physically show up when you browse the DS tree using standard management tools such as ConsoleOne or iManager, but it is recognized and acted upon by DS servers. You should be aware of the issues discussed in the following paragraphs. The bindery Supervisor is created as a pseudo-DS object whose rights are restricted to a specific bindery context and only to that context. Supervisor does not have Admin-like rights in the whole DS tree. It does, however, have full rights over the objects that are in the same bindery context and full file system rights to the servers that provide the bindery emulation service. Within the bindery context, Supervisor can perform all administrative operations, such as changing a user's password and creating new users, regardless of DS inheritance right filters. Although you can't see Supervisor via the traditional management tools ”except via bindery-based utilities such as SYSCON.EXE ”you can see it using DSBrowse because there is actually an entry record in the Directory Information Base (DIB) for this object. When you use the Windows version of DSBrowse, you need to switch to the DIB view, as shown in Figure 11.1. With DSBROWSE.NLM , you need to use the Object Search option from the main menu and specify an object ID of 1 (see Figure 11.2). Unfortunately, because there is no DSBrowse implementation for Linux/Unix, you cannot readily check this on those platforms. Figure 11.1. Database view, showing the bindery Supervisor object. 
Figure 11.2. Searching for the bindery Supervisor object. 
NOTE If no bindery context is set, Supervisor has no access to any resources within the DS tree.
Depending on how you migrated the user information from a bindery server into NDS/eDirectory, you might have a security backdoor that you're not readily aware of. Any user who was security equivalent (SE) to Supervisor in the bindery will be made SE to the NCP Server object (and thus will have full rights to all volumes associated with that server object) on the server that was used to import the bindery data. This means that all users who were SE to bindery Supervisor on the old server now have full rights to the new server. One of the most confusing issues associated with Supervisor is its password. The initial Supervisor password is the same as that of Admin or that of the user used to authenticate the installation utility. When you install the first server into the DS tree, the passwords of Admin and the bindery Supervisor user are set to be the same. Subsequent changes of the Admin password in NDS/eDirectory are not synchronized with the bindery Supervisor password and vice versa. To change the Supervisor password, you need a bindery utility such as SETPASS.EXE (which is shipped with NetWare 4 and NetWare 5). You can also use SYSCON.EXE , which you can still download from Novell's knowledge base (see TID #1003215) or use third-party bindery tools such as JRB Utilities, from www.jrbsoftware.com, or BinPass, from ftp://ftp.dreamlan.com/Freeware/binpass.zip. It is important to keep in mind that the Supervisor password is not synchronized between servers; therefore, when you change the Supervisor password, the change applies only to the one server you are logged in to at the moment of change. WARNING NDS 8 and eDirectory handle Supervisor differently than do the legacy versions of NDS . Under eDirectory, you are able to log in as Supervisor but are unable to see the user by using any of the bindery-based tools, even with SYSCON. Figure 11.3 shows that although SYSCON reports that one is logged in as Supervisor, the user list does not indicate that Supervisor exists. Figure 11.3. SYSCON, not showing that Supervisor exists.  This situation leads to a potential security risk if Bindery Services is enabled because you cannot change Supervisor's password (because the utilities cannot "see" it). Anyone who knows that original password can log in to the server as Supervisor and has full file system access. This potential security issue is partially addressed in eDirectory 8.7.3, where bindery Supervisor is explicitly prevented from logging in, even though there exists an entry record for it in the DIB , as shown in Figure 11.1 .
In NetWare 5 and higher, the screen saver and console-locking function have been removed from MONITOR.NLM and placed into a separate NetWare Loadable Module (NLM), SCRSAVER.NLM . In addition, DS User objects are used to unlock the console. For NetWare 4 servers, however, if you don't know the password that was used to lock MONITOR.NLM or if the console was locked by pressing Enter twice at the Lock File Server Console option, you need the bindery Supervisor password to unlock MONITOR.NLM . The Admin password does not work unless it happens to be the same as the Supervisor password. NOTE There are some alternatives you can try when you encounter this MONITOR.NLM issue for NetWare 4 servers. Two such examples are using SecureConsole from Protocom and using SSLock for NDS from DreamLAN Network Consulting. Both of these products work on NetWare 4 and higher servers. Refer to the "Console Security" section in Chapter 15, "Effectively Setting Up eDirectory Security," for more information about these products.
Mail Directories and Bindery Queues Mail directories (created under SYS:MAIL ) were an integral part of NetWare prior to version 4; however, they are no longer required for use in the DS environment unless there are users who are still running in bindery emulation mode. These bindery users create the need for mail directories to still exist on NetWare 4 and higher servers. Each mail directory is tied to its user through the user's hexadecimal object ID; the name of the directory (located under the SYS:MAIL directory) is the hexadecimal number. There are times, however ” especially during a restoration ”when the ID of the user object is changed and thus the link to the mail directory is broken. As a result, bindery users lose access to their personal login scripts, and any email applications that make use of these directories fail to function correctly. TIP Novell used to have a utility called RENMDR.NLM that was used to restore the link between the users and their mail directories. However, it seems to have been removed from Novell's support Web site. You may still be able to find a copy on the Internet. Alternatively, you can use Lscripts ”from JRB Software (see www.jrbsoftware.com ) ”to accomplish the same task.
Queues suffer the same issue as user mail directories. The directory corresponding to a bindery queue is named using the queue object's hexadecimal ID number. Thus, if the object ID of a bindery queue object is changed, the link to its queue directory is broken. In such a case, you need to delete the queue object and re-create it so the proper link can be made. DS queue objects do not fall under this category. Bindery Clients There may be times when you're unable to switch all your client workstations to use DS-aware client software, such as Novell Client for Windows. Or your workstation platform may be such that you're unable to switch ”for example, if you have old Macintosh workstations that can't be upgraded to the latest MacOS version in order to use the DS-aware client without great expense. In such a situation, you need to bear in mind the following differences between a Bindery Services connection and a DS connection: -
There's the matter of what NetWare Core Protocol (NCP) API calls the client can use. A bindery connection can't use any of the DS NCPs. That means you can't run utilities such as NetWare Administrator or ConsoleOne to perform administration of the tree. -
When you log in through Bindery Services, the container and profile login scripts are not read from the tree. The bindery client looks for a NET$LOG.DAT file in the SYS:PUBLIC directory and a login script in the user's mail directory. NOTE The Native File Access Pack (NFAP) enables Macintosh, Windows, and Linux/Unix clients to access storage on NetWare 5.1 and NetWare 6 servers without requiring you to install special client software on each workstation. When communicating with NFAP-enabled NetWare servers, the clients use their own native file protocols ”such as Apple File Protocol for Macintosh (AFP), Network File System (NFS) and Common Internet File System (CIFS) ”instead of NCP calls, thus eliminating the need for Bindery Services. Whereas it is an optional product for NetWare 5.1, NFAP is included as part of NetWare 6.0 and higher. For more information, visit www.novell.com/products/nfa/.
Performance Considerations Frequently, administrators are not aware that NetWare assigns only one service process to service all bindery requests , regardless of the number of bindery connections to the server or the number of currently allocated service processes. Consequently, you'll notice that a server which services many bindery clients (workstations and/or printers) will show a higher CPU utilization than ones servicing NDS clients. As a point of reference, a server servicing 300 bindery connections may show a CPU utilization of 35%, while the same server servicing 300 DS connections (doing the same type of work) may show a CPU utilization of only 10%. | 