Active Directory Database: Structure, Access and Tools
This section of the SelfADSI Tutorial describes the technical design of the Active Directorydatabse and its access. Following topics are available:
| Structure of the Active Directory database: Partitions / Naming Contexts |
| LDAP Access to Active Directory |
| GUID based Tools for the AD Access : ADSIEdit, LDP and LEX |
| Commandline tools for the AD Access: LDIFDE, CSVDE and DS Commands |
| Technology, Files und File Paths of the Active DirectoryDatabase |
| Database Maintenance |
Structure of the Active Directory Database: Partitions / Naming Contexts
The Active Directory Database is normally divided into several section.
As a basic principle, these sections are called Partitions or Naming Contextes
or Name Contextes too. The domain controller are so to speak those server
on which single entities of these partitions are saved.
There are three different types of standard partitions:
 |
Schema Partition |
The design of the Active Directorydatabase is determined in the schema, i.e. definitions of object classes (e.g. user, contact, group etc.) and their attributes (e.g. displayName, streetAddress, mailNickName etc.). These definitions can be customized for additional tasks: The so-called schema extension. The schema partition has to be identical on all domain controllers in the entire forest. The LDAP pathname of the schema partition in an Active Directory is always: cn=Schema,cn=Configuration,dc=<root domain of the forest>,dc=<toplevel domain of the root> |
|
|
Configuration Partition |
This part of the database contains important information about the structure of the Active Directory forest itself. E.g. AD sites and their site links are determined here. Other systems, like e.g. Exchange or PKI store information about their configuration here, too. The configuration partition is given to all DCs of the whole forests. The LDAP pathname of the schema partition in an Active Directory is always: cn=Configuration,dc=<root domain of the forest>,dc=<toplevel domain of the Root> |
|
|
Domain Name Context |
The 'normal' objects of a domain are stored here, e.g: User, contacts,
groups, printer objects, organisational units et. |
Additionaly, there are "Application Naming Contexts" (or "Application Partitions"), which can be configured for any purpose. You can store LDAP content in these, which is not related to Active Directory itself, for example if you need LDAP access to objects for a special application (DNS data, meta directories, telephone number directories, address lists, etc.)
The application partitions aren't used by Windows or Active Directory but can benefit from the powerful storage engine and multimaster replication on the directory servers. So if you want to store data decentrally and replicated which can be accessed by the LDAP protocol, you can accomplish all this by creating an application partition.
The good thing about application partitions is that you can decide which servers store an application partition: so you can configure exactly where the data of these partitions is replicated. The LDAP access can be implemented right there where it is needed - based on the infrastructure of the AD replication mechanisms. Hereby the application naming contexts are stored either as additional partitions on normal domain controllers or their are implemented on dedicated servers for application partitions.
You have to install an additional Microsoft service module on these servers: Active Directory Application Mode (ADAM). For Windows Server 2008 and later versions ADAM was renamed to Active Directory Ligthweight Directory Services (ADLDS) .
LDAP access to Active Directory
The local and remote access to the Active Directory database is done with the LDAP protocol (Lightweight Directory Access Protocol). On an domain controller, the process LSASS implements the LDAP server for this purpose. This server supports the LDAP version v3 according to RFC 2251.
The LSASS (Local Security Authority SubSystem) implements some other important services for Active Directory, among others Kerberos. You can read more details about LDAP here in the SelfADSI tutorial in the following topic: LDAP - The Lightweight Directory Access Protocol.
GUI based Tools for the Active Directory Access
There are several tools available which allow the access to the Active Directory database. Talking about GUI based tools, we have to mention two programs which are included in the Windows Support Tools: ADSIEdit and LDP. ADSIEdit comes with a bit more comfortable user interface, whereas LDAP allows you to control the pure LDAP communication and can be used for all kinds of LDAP servers.
Even more comfortable than ADSIEdit and faster than LDP is "LEX - The LDAP Explorer", the commercial LDAP browser and admin tool which is developped by the author of this tutorial.
Apart from ADSIEdit, LDAP and LEX, there are some other commercial and non-commercial tools for LDAP access:
LUMA (OpenSource)
Softerra LDAP Administrator
LDAPAdmin (OpenSource)
LDAP Browser / Editor (OpenSource)
LEX - The LDAP Explorer
LEX - The LDAP Explorer can browse, search and edit any LDAP directory. The look and feel is very similar to the windows explorer. By evaluating the directory schema, all attributes of an object are found by LEX - even the system or operational attributes can be displayed. The tool can display any attribute values directly in list columns. Sorting is no problem - this works even for more complex or constructed data types like Active Directory 64Bit-Timestamps (e.g. "lastLogon"):
ADSIEdit
ADSI-Edit is an MMC snapin tool from the Windows Support Tools (free add-on software on the Windows server CDROM in the directory \Support\Tools). ADSIEdit was mode especially for the access to Active Directory LDAP services. To launch the tool, you have to install the support tools, than start the Microsoft Management Console (MMC.EXE), then load ADSIEdit from the list of the available snap-ins.
First of all, you have to make a connection to some AD partition to see something in the ADSIEdit object browser. Choose "Connect to..." from the context menu of the tool entry. Then you can choose domain, configuration or schema partition with the "Select a well known Naming Context" option:
In addition to the three main Active Directory partitions you can also connect to application partitions or you can read the RootDSE entry. With the dialog option "Advanced" you can use other credentials or choose another TCP port to connect to the directory (for example for a connection to the global catalog). Later on you can access the objects and their attributes with the context menu option "Properties" or with the hotkey "ALT-ENTER":
LDP
LDP is an LDAP browser tool from the Windows Support Tools (free add-on software on the Windows server CDROM in the directory \Support\Tools). With LDP you can access any LDAP directory (for example OpenLDAP, Novell eDirectory and so on). To launch the program you have to start directly LDP.EXE after you installed the support tools.
First of all, you have to connect to an LDAP server. You have to use the option "Connection -> Connect..." for this. For this connection you can configure the TCP port to use (for example 3268 for a global catalog) and other parameters. Normally the default values allow a connection to an Active Directory domain controller without any problems.
When the connection is established, the content of the RootDSE object is shown in the data window on the right side. After the connect an LDAP client has to authenticate itself to the server, this procedure is also called Bind and is implemented with the menu option "Connection -> Bind...". If you want to bind to a non-AD LDAP server, you should deactivate the option "Domain":
When the logon to the server succeeded without errors, the output on the right side should list an "Authenticated as" at the end. The next step is the configuration of the search base for the objects which LDP should display in the object hierarchy. For this setting you have to use the menu option "View->Tree". In this option you have to fill in the LDAP pathname of the partition you want to browse.
After that, you see the hierarchical structure of the choosen partition in the left window pane. You can access all objects and their attributes (visible in the right window pane). If there should be some protocol errors in the LDAP communication, then they are displayed directly in the right window pane:
Commandline Tools for the AD Access - LDIFDE
LDIFDE is an abbreviation for LDIF Directory Exchange. With this
command, you can export directory objects and their properties into an
ASCII text file. This file is structured according to the standardized
LDAP Data Interchange Format (LDIF). This format is defined in RFC
2849. The objects will be listed here with a blank line to
separate them, for each attribute there will be text line like this: <attribute
name>:<value>". An example:
dn:
CN=Philipp Foeckeler,OU=Consultants,OU=Employees,DC=cerrotorre,DC=de |
Exactly with this format you can also create new objects in the AD or change object attributes. For this operation you have to use the meta attribute "changeype" in the LDIF import file, for example this way:
dn:
CN=Sandra Biermann,OU=Consultants,OU=Employees,DC=cerrotorre,DC=de |
Examples for the use of LDIFDE from the Microsoft Knowledge Base:
Q555637: LDIFDE - Export / Import data from Active Directory - LDIFDE commands 2
Commandline Tools for the AD Access - CSVDE
The use of this command and the parameters are basically identical to LDIFDE, only the syntax of the import/export file is CSV: Every object is listed in one text line, all attributes are there separated by a semicolon.
Commandline Tools for the AD Access - The DS Commands
DSADD
Adds new objects to the directory. However, you are bound here
to the standard object classes "user",
"contact", "group", "computer" and
"quota",
DSMOVE
Moves objects inside the directory from one container to another.
Is also used for renaming objects. This is restricted again to the object
classes mentioned above.
DSMOD
Modifies attribute values of directory objects. This is restricted again to the object classes mentioned above.
DSGET
Reads and displays attribute values. But this is restricted to
the object classes mentioned above and also restricted to some important
attributes.
DSRM
Deletes directory objects.
DSQUERY
Searches the directory for objects. This command returns only
objects and no attributes. Interesting: The return values are always LDAP
Distinguished Names. With command pipelining, these Distinguished Names
can be the input for other DS commands. An example:
This removes all computer accounts which wasn't active for the last 4 weeks.
Technology, Files und File Paths of the Active Directory Database
The Active Directory database is stored on a Windows domain controller as an Extensible Storage Engine (ESE) database. This database technology is also used for example for mail databases in Exchange servers. In addition to the database, the files for the transaction protocols pla an important role. This protocol helps to keep the databse always in a consistent state, even in case of system breakdowns.
The default file path of the AD database is %SYSTEMROOT%\NTDS. In this directory several transaction log files are stored together with the actual database: NTDS.DIT. "DIT" is here an abreviation of Directory Information Tree.
Database Maintenance
Maintenance of the AD database means operations like moving the database files or the offline defragmentation. This is done with the commandline utility NTDSUtil.