WinBatch Tech Support Home

Database Search

If you can't find the information using the categories below, post a question over in our WinBatch Tech Support Forum.

TechHome

Novell Netware
plus
plus
plus
plus
plus
plus
plus
plus
plus
plus

Can't find the information you are looking for here? Then leave a message over on our WinBatch Tech Support Forum.

NDS Relative and Absolute Object dissertation

Keywords:  NDS Relative and Absolute Object dissertation

When you're working with NDS and you are referencing objects in another container that is not a child of the container that you are located in then you need to be very careful about what syntax you use to reference the object's name.

NDS supports both absolute and relative object references, with and without type information.

For an example, look at the following scenario:

NDS Tree Name: "MY_TREE"

My User Object: "choppc"

My User Object's Context: "OU=my_ou.O=my_o"

My User Object's Typed DN: ".CN=choppc.OU=my_ou.O=my_o"

My User Object's Typed CN: "CN=choppc"

My User Object's Untyped DN: ".choppc.my_ou.my_o"

My User Object's Untyped CN: "choppc"
Now, logged in as myself, and trying to reference a print queue named "my_queue" in an OU named "my_ou2" that is a child of the OU named "my_ou", I can do the following assuming that my current context is set to "OU=my_ou.O=my_o":
Queue's Typed Relative DN [or RDN]: "CN=my_queue.OU=my_ou2"

Queue's Untyped Relative DN [or RDN]: "my_queue.my_ou2"

Queue's Typed DN: ".CN=my_queue.OU=my_ou2.OU=my_ou.O=my_o"

Queue's Untyped DN: ".my_queue.my_ou2.my_ou.my_o"
If the queue named "my_queue2" was located in an OU named "my_ou3" which was a child of the organization named "my_o" [and thus a sibling of the OU named "my_ou"], the following applies:
Queue's Typed Relative DN [or RDN]: "CN=my_queue2.OU=my_ou3." [note the trailing dot]

Queue's Untyped Relative DN [or RDN]: "my_queue2.my_ou3." [note the trailing dot]

Queue's Typed DN: ".CN=my_queue2.OU=my_ou3.O=my_o"

Queue's Untyped DN: ".my_queue2.my_ou3.my_o"
Basically, any object name with a leading dot is considered to be a DN value and must contain the full context of the object leading back up to the highest container object in the NDS tree.

Any object name w/o a leading dot and which contains a dot later on is assumed to be in a context relative to the current object. One or more trailing dots means that the RDN is not a child of the current context container but is instead a child of a container higher up in the container hierarchy. Each trailing dot moves back up one level of containment. Thus, a single trailing dot references an object relative the current container's parent container, or in other words, references a sibling of the current container object.

Any object w/o a leading dot or any trailing dots is a CN [common name] value.

Type information is optional as long as the containment hierarchy contains only "OU" and "O" containers at the top of the tree. If there are any "C" [country] or "L" [locality] container objects then type information must be specified. This is necessary because w/o type information, a DN value assumes that the left most component is a CN, while the right hand most component is a O containers and all intervening components are OU containers.

Now, when we get into the Novell Client, and Win32 platforms where the networking components support multiple network providers [e.g. Microsoft File & Print sharing, Novell Client, Banyan Vines, Lantastic, etc...], you need to qualify a network resource [e.g. a share, a volume, a user object, a print queue object, etc...] with a value in the part of a UNC spec that is usually reserved for a server name. In the case of NDS, the Novell Client and Win32 systems, we put the NDS tree name in as the server spec. Thus, all of our object references have "\\MY_TREE\" at the beginning to signify that they are relative to that NDS tree. The multiple network providers installed on a Win32 system will each evaluate the resource name and either process it or pass it on if they cannot identify what it refers to. Thus, the Novell Client will see that the UNC contains a NDS tree name to which the client is authenticated and the Novell Client will step up to the plate and attempt to process whatever request is associated with that UNC spec.

Make sense?


Article ID:   W15213
File Created: 2002:09:05:13:50:36
Last Updated: 2002:09:05:13:50:36