Setting a Bindery Context

In a Single-Level Directory Tree

If the Directory tree contains only one container level (that is, if the Directory structure is flat), there is only one possible bindery context. For example, the following figure shows a Directory tree with only one level.

Figure 4-2 Bindery Context in a Flat Directory Tree

In effect, this structure is like a bindery and is not fully utilizing NDS. Because there is only one container object, you can set the bindery context on each server to O=ACME. You can do this using either of these methods:

Because the User objects are also located within the O=ACME object, those users can log in to either server under bindery services.

In a Multiple-Level Directory Tree

If the Directory tree contains more than one level, the bindery context has a more noticeable effect on a user's ability to access bindery services. For example, consider the Directory tree shown in the following figure.

Figure 4-3 Two Different Bindery Contexts in a Directory Tree

This Directory tree has seven container objects, each designated by the name type O (Organization) or OU (Organizational Unit).

	NOTE: The following examples use the nwcm command line utility to set bindery contexts. You can also use the System Administration Manager (SAM) utility (see "SAM" in chapter 9).

Suppose the ACME Corporation requires bindery services and sets bindery contexts as follows:

This enables bindery services access to objects in the ACCT.HQ.ACME and HQ.MFG.ACME container objects. Specifically, users in the ACCT.HQ.ACME container can log in as bindery objects and access objects in the ACCT.HQ.ACME container, and users in the HQ.MFG.ACME container can log in as bindery objects and access objects in the HQ.MFG.ACME container.

Now suppose that users in the ACCT.HQ.ACME container no longer need bindery services, but that ESAYERS now requires bindery access to ACCT_SRV1. The bindery context for ACCT_SRV1 can now be set with the following command:

nwcm -s ds_bindery_context="HQ.MFG.ACME"

This requires that a writable replica of the MFG partition be stored on the ACCT_SRV1 server. Also, rather than change the bindery context for the ACCT_SRV1 server, you might choose to place an Alias object for the ESAYERS User object into the ACCT.HQ.ACME container.

For a Specific Server

A server's bindery context can be set to any OU or O that is present in a replica on that server.

For example, given the partitions defined in Figure 4-4, you could set the bindery context of ACCT_SRV1 to any one of the following containers:

Figure 4-4 Bindery Contexts for a Specific Server

This Directory tree represents three partitions of the ACMECORP tree. If there were only one partition, the bindery context could be set to any OU, O, or set of OU and O in the tree. But because multiple partitions exist, any context you set in a different partition must include the path all the way to the [Root] of the tree.

Nevertheless, the bindery context must specify the containers that hold the users that want to log in to that server under bindery services.

For example, suppose you want to set the bindery context for the server PROD1_SRV2 in this tree to OU=HQ so that user ESAYERS can log in to that server with a bindery login. Using nwcm you would type

nwcm -s ds_bindery='HQ.MFG.ACME'

This command sets the bindery context to the OU=HQ container and provides the path NDS uses to find that container. In this case, the command specifies that the bindery context OU=HQ is contained in OU=MFG.O=ACME.

	CAUTION: Be careful when changing a server's bindery context. Removing a container from that server's bindery context prevents all users in that container from using bindery services.

For Multiple Servers in the Same Bindery Context

If a user needs access to several servers, you could use the same container in the bindery context for all of those servers; however, Server objects do not need to be located in their bindery context.

The following figure illustrates how to locate each Server object within the same container as the User object.

Figure 4-5 Multiple Servers in the Same Bindery Contexts

For Objects in Different Bindery Contexts

Ideally, all objects a user wants to access under bindery services should be located in the same bindery context. However, this is not always possible or practical.

You can set multiple bindery contexts for users who need to access objects outside of their own bindery contexts. For example, consider the Directory tree in the following figure.

Figure 4-6 Multiple Bindery Contexts in the Same Directory Tree

To set bindery contexts on the servers HQ_SRV1 and HQ_SRV2 in this figure, you could use nwcm utility to type

nwcm -s ds_bindery_context="ACCT.HQ.ACME;PROD1. 
DETROIT.MFG.ACME;TEST.DETROIT.MFG.ACME";

To set multiple bindery contexts, you must set the contexts to include the path all the way to the [Root] of the tree. You can set up to 16 contexts per server.

	WARNING! Do not change a server's bindery context once you set it. Changing a server's bindery context prevents all bindery services users (from the original context) who need to log in to that server from accessing bindery services. Changing the server's bindery context can also disable access to print queues.