NDS 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:

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 that the following examples use the nwcm(1Mipx) command line utility to set bindery contexts. You can also use the scoadmin(1M) NetWare Setup utility (see ``NetWare Setup'').

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

On the ACCT_SRV1 server, the bindery context is set with the following command:
```
nwcm -s ds_bindery_context="ACCT.HQ.ACME"
```
On the HQ_SRV1 server, the bindery context is set with the following command:
```
nwcm -s ds_bindery_context="HQ.MFG.ACME"
```

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.