Home > Articles

The Directory Information Base

This chapter is from the book

Just as you don't really need to know how a combustion engine works in order to drive a car, it is not necessary for you to have an intricate knowledge of the directory services (DS) database file structure in order to use, manage, and troubleshoot eDirectory. On the other hand, knowing that the eDirectory database is made up of a number of files and knowing what components make up the eDirectory database can make troubleshooting easier. Although this chapter is by no means an in-depth technical view of the DS database files, it gives you an idea of what the files are named, where they are located, and what the purpose of each is.

The set of DS database files is officially known as the Directory Information Base (DIB). Oftentimes, these files are simply referred to as NDS files; however, in a number of Novell utilities, such as DSRepair, the term DIB is used.

Because there are still many NetWare 4 and NetWare 5 servers being used around the world, this chapter covers the DIB sets used in NDS 6, 7, and NDS 8/eDirectory.


The main DIB set used by NDS 6 is composed of four files:





Each of these files is examined individually in the sections that follow.


The PARTITIO.NDS file contains information specific to partitions that are stored on the file's server. This data is server-centric because it has no correlation with the data in the PARTITIO.NDS file on another server. The file contains the following fields to help DS replicate and synchronize data between servers:

  • Partition ID—This is the hexadecimal number assigned to a replica (by NetWare) when it is created. This number is used to associate an object with its partition. It is also referred to as the replica ID in DSRepair and the root entry ID in DSBrowse.

  • Partition root object—This is the hexadecimal object ID number of the object that is the root of the partition. This is also known as the replica root object.

  • Replica type—This is the type of replica (such as Master or Read/Write).

  • Replica state—This is the state of the replica (such as On or Split).

  • Replica flags—The replica flags are used by the NDS synchronization processes. They are also referred to as partition flags.

  • Next timestamp—This is the minimum value of the next timestamp the server issues to an object in the partition.

You can look up this information by using DSREPAIR.NLM in the following way: From the main menu, select Advanced Options, Replica and Partition Operations. Then you select any one of the partitions from the displayed list and choose Display Replica Information. The resulting log file shows the data from the PARTITIO.NDS file in a readable format, as shown in Figure 3.1. You can obtain similar information by using DSBrowse, as illustrated in Figure 3.2.

Figure 3.1Figure 3.1 A sample DSREPAIR.NLM log file, showing information about the SLCDEV partition.

Figure 3.2Figure 3.2 DSBrowse, showing information about a partition.


All objects stored on the server are located within the ENTRY.NDS file. Each object has a record entry in the file, and each record contains the following fields:

  • Object Name—This is the typed relative distinguished name of the object (for example, CN=Tasha).

  • Partition ID—This is the hexadecimal ID of the partition in which the object exists. This corresponds to the records in the PARTITIO.NDS file.

  • Base Object Class—This is a pointer to the record within the ENTRY.NDS file that contains the schema definition (such as User), which is used as the object's base object class.

  • Creation Time—This is the timestamp of when the object was created.

  • Parent Object—This is a pointer to the record within the ENTRY.NDS file that contains the object that is the parent of the current object. For example, if the current object's full name is CN=Tasha.OU= North_America.O=Testing, this field points to OU=North_America.O=Testing, which is the parent of the CN=Tasha object.

  • Sibling Object—This is a pointer to the record within the ENTRY.NDS file for the object that is a sibling object.

  • NOTE

    A sibling object is an object that has the same parent object (or name context) as another object. For example, CN=Tasha.OU=North_America.O=Testing is a sibling object to CN=Chelsea.OU=North_America.O=Testing because both objects have the same parent object, OU=North_America.O=Testing.

  • First Child Object—This is a pointer to the record within the ENTRY.NDS file for the object that is the first child object. If the current object is a leaf object, such as a user, then there is no child object.

  • Last Child Object—This is a pointer to the record within the ENTRY.NDS file for the object that is the last child object. If the current object is a leaf object, such as a user, then there is no child object.

  • First NDS Attribute—This is a pointer to the record within the VALUE.NDS file that contains the object's first attribute.

  • Subordinate Count—This is the number of records that are subordinate to (that is, reference) the current object. In essence, this is the number of child objects the object has. For example, if the current object is a container and has four User objects and two organizational units (OUs), the subordinate count is six.

  • Object Flags—This is a set of flags that identifies the characteristics of the object. The following are the possible flag values:

    • Alias indicates that the object is an alias to another object.

    • Backlinked indicates that the object is an external reference that has established a backlink.

    • NOTE

      An external reference is a placeholder used to store information about an object that is not contained in a partition held by the server. See Chapter 6, "Understanding Common eDirectory Processes," for more information about external references and backlinks.

    • Partition or Partition Root indicates that the object is a partition root object.

    • Present indicates that the object is present in the DS tree.

    • Not Present indicates that the object is no longer considered by DS to exist within the tree, but its record still exists in the DIB because the Janitor process hasn't purged it yet. See the "Delete Object" and "Obituaries" sections in Chapter 6 for more information about the Janitor process.

Figure 3.3 shows a sample entry record for the User object Tasha, located in OU=North_America.O=Testing.

Figure 3.3Figure 3.3 Viewing DS entry record information by using DSBrowse.


The VALUE.NDS file contains attribute values associated with records in the ENTRY.NDS file. The structure of the VALUE.NDS file is similar to that of ENTRY.NDS. The following fields are stored in the VALUE.NDS file:

  • Object Name—This is a pointer to the object record in the ENTRY.NDS file to which this attribute is associated.

  • Attribute—This is a pointer to the record within the ENTRY.NDS file that contains the schema attribute definition (such as Surname) for this attribute.

  • Next Value—This is a pointer to the record within the VALUE.NDS file that contains the attribute's next value if the attribute is multivalued.

  • Next Attribute—This is a pointer to the record within the VALUE.NDS file that contains the next attribute assigned to the object.

  • First Block—Each VALUE.NDS record can hold up to 16 bytes of data (such as the number of days before a password expires). If the data for an attribute's value doesn't fit in a single VALUE.NDS record, the extra data is stored in a record in the BLOCK.NDS file. The First Block field is a pointer to a record in this file that holds the first block of overflow data.

  • Modification Time stamp—This field contains the time stamp when the attribute value was created or last modified.

  • Attribute Value—This is the data associated with the attribute. If the attribute's data type or syntax is stream (SYN_STREAM), the filename containing the stream data is recorded instead.

  • NOTE

    All stream data, such as login scripts, is stored in individual files, where the filename is an eight-digit hexadecimal number and the file extension is .000. The hexadecimal number in the filename has no direct relationship to the hexadecimal object ID of the DS object to which the file is associated. For example, the container login script for OU=North_America (whose object ID is 0x01000124) is stored in a stream file named 0004B3C0.000, and the print job configuration information associated with the same container is stored in a stream file called 0031B000.000. You can look up the filenames by using DSBrowse, as illustrated in Figure 3.4. DSBrowse on NetWare does not provide that information. However, you can use MONITOR to see the filename that is opened when you are editing the login script and print job configuration.

    Figure 3.4Figure 3.4 Looking up the name of a stream file for the login script.

  • Attribute Flags—This is a set of flags that identify the characteristics of the attribute. The following are the possible flag values:

    • Base Object Class indicates that the value in the record is the value used as the base object class for the object that this attribute is associated with.

    • Naming indicates that the value in the record is used as the relative distinguished name of the object that this attribute is associated with.

    • Present indicates that the object is present in the DS tree.

    • Not Present indicates that the object is no longer considered by NDS to exist within the tree, but its record still exists in the DIB because the Janitor process hasn't purged it yet. See the "Delete Object" and "Obituaries" sections in Chapter 6 for more information.


The BLOCK.NDS file is used to store the value of an object's attribute that exceeds 16 bytes in size. Each record in BLOCK.NDS consists of the following fields:

  • Attribute Name—This is a pointer to the attribute record in the VALUE.NDS file to which this data block is associated.

  • Value—This is the value or data for the attribute. Each record in BLOCK.NDS can hold up to 108 bytes of data.

  • Next Block—If the data is larger than 124 bytes (16 bytes in the VALUE.NDS file and 108 bytes in the first block of BLOCK.NDS), additional records in the BLOCK.NDS file are used for the excess data. The next block points to the next record within the BLOCK.NDS file that contains data for the attribute.

NDS and Transaction Tracking System

If you are familiar with database structures, you'll readily recognize that the DIB set is implemented as a set of linked lists. The link generally starts in the ENTRY.NDS file and is then linked to VALUE.NDS and then to BLOCK.NDS. By using linked lists, NDS can easily insert data into the DIB by simply adjusting the pointers accordingly. Any nodes (that is, elements in the list) that are deleted can be easily reused; therefore, there is generally no need to repack the DIB unless you have deleted a large number of objects. Even then, you might not see much of a size reduction of the DIB because only empty nodes at the end of the lists are deleted.

To reduce the chance of pointer corruption and data integrity, DS transactions are protected by NetWare Transaction Tracking System (TTS); therefore, if for some reason the server's TTS mechanism is disabled, DS.NLM automatically shuts down the DIB. Because TTS uses disk space on the SYS: volume to create transaction log files, it is essential that you ensure that the SYS: volume always has sufficient free disk space; otherwise, you risk shutting down NDS.


eDirectory does not depend on TTS because it is a cross-platform product and TTS is available only on NetWare. However, eDirectory also keeps its roll-forward log (RFL) files on the same disk on which the DIB is installed. Therefore, it is also essential that you ensure that sufficient free disk space is available; otherwise, you risk eDirectory shutting down unexpectedly.

On NetWare 4 servers, you can easily look up the object and attribute information by using Novell's DSView NetWare Loadable Module (NLM). This NLM is not included with NetWare but can generally be found included with the DS.NLM updates. For NetWare 5 and higher, the corresponding utility is the DSBrowse NLM that is included with NetWare; a DSBrowse module is included for the other platforms that eDirectory runs on. The DSView screen in Figure 3.5shows the information related to the Login Intruder Limit attribute, such as timestamp and syntax.

Figure 3.5Figure 3.5 Examining the NDS 6 DIB by using DSView on a NetWare 4 server.


By default, DSRepair saves the old DIB files after a repair operation. The four files in the main DIB set used by DS 6 are renamed with a .OLD extension. Because of the backup DIB files, you essentially double your DIB size after you run DSRepair. Keep this in mind if you're low on disk space on the SYS: volume.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020