How Active Directory Application Mode Works

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2, Windows Server 2012, Windows Server 2012 R2

In this section

• ADAM Architecture

• ADAM Protocols

• ADAM Interfaces

• ADAM Physical Structure

• ADAM Logical Structure

• ADAM Security

• ADAM Processes and Interactions

• Network Ports Used by ADAM

• Related Information

Active Directory Application Mode (ADAM) is a new mode of Active Directory that is designed specifically for directory-enabled applications. ADAM is a Lightweight Directory Access Protocol (LDAP) directory service that runs as a user service, rather than as a system service. You can run ADAM on servers and domain controllers running operating systems in the Windows Server 2003 family (except for Windows Server 2003, Web Edition) and also on client computers running Windows XP Professional.

ADAM does not require the deployment of domains or domain controllers. You can run multiple instances of ADAM concurrently on a single computer, with an independently managed schema and independently managed data for each ADAM instance.

The ideal environment for ADAM includes the following:

• A computer running Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; Windows  Server 2003, Datacenter Edition; or Windows  XP Professional and containing hardware that meets the minimum hardware requirements of each respective operating system

• For environments consisting of multiple, replicating ADAM instances, the presence of a fully functioning replication topology

• A regular backup schedule

This section describes the fundamental elements of ADAM, including its architecture, protocols, interfaces, physical structure, logical structure, security concepts, processes and interactions, and network ports.

ADAM Architecture

The ADAM architecture consists of several components that work together to provide directory services. These components include the following:

• Interfaces: LDAP and replication (REPL)and management interface

• Directory System Agent (DSA)

• Database layer

• Extensible Storage Engine (ESE)

• Directory database

The ADAM architecture is illustrated in the following figure.

ADAM Architecture

The following table describes the ADAM components.

ADAM Components

Component	Description
Interfaces (LDAP and REPL)	The data store interfaces provide a way for directory clients and other directory servers to communicate with the data store.
DSA	The DSA, which runs as Adamdsa.dll on each ADAM instance, provides the interfaces through which directory clients and other ADAM instances gain access to the directory database. In addition, the DSA enforces directory semantics, maintains the schema, guarantees object identity, and enforces data types on attributes.
Database layer	The database layer is an application programming interface (API) that resides in Adamdsa.dll and provides an interface between applications and the directory database to protect the database from direct interaction with applications. Calls from applications are never made directly to the database; they go through the database layer. In addition, because the directory database is flat — with no hierarchical namespace — the database layer provides the database with the abstraction of an object hierarchy.
ESE	The ESE, which runs as Esent.dll, manages the tables of records — each with one or more columns — that make up the directory database.
Directory database	The data store stores directory information in a single database file called Adamntds.dit.

DSA

The DSA runs on an ADAM instance as Adamdsa.dll, and it provides access to the directory database. On computers running multiple instances of ADAM, a single, shared copy of Adamdsa.dll supports all ADAM instances.

Note

• Multiple instances of ADAM running on a single computer share all ADAM-related binaries. Therefore, a hotfix that is applied to one ADAM instance affects all ADAM instances running on that computer.

The DSA runs as a user service, in the security context of the service account under which the ADAM instance is running. Clients can use one of the supported interfaces to connect (bind) to the DSA and then search for, read, and write to ADAM objects and their attributes.

An object in the configuration partition of the directory, the NTDS Settings object (with a distinguished name of CN=NTDS Settings,CN=computername$instancename,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,CN={GUID}), represents the DSA. This object contains configuration information about the DSA.

In addition to providing the interfaces through which directory clients gain access to directory data, the DSA provides the following functionality.

Object identification

Every object in ADAM has a permanent globally unique identifier (GUID) and an object name. The object name can be changed; all permanent references to the object are kept in terms of the GUID. The object name is used for hierarchy navigation and display purposes. The DSA maintains the GUID association with an object when the object’s name changes, for example, when the object is moved to a different folder.

Schema enforcement

The DSA ensures that data in the directory adheres to the data definitions that are provided by the directory schema. The schema is the set of rules that determines what kind of data the directory can hold.

Note

• If an update does not produce a conflict with the schema at the originating replica, the update is considered acceptable at all replicas. Therefore, replicated updates do not perform schema checks, and you do not have to wait until the schema replicates before creating instances of a new object or attribute.

Access control enforcement

The DSA reads security IDs (SIDs) on the access token to identify the current user and the user’s group memberships, and it enforces access control based on the identity and group memberships of the user.

Support for replication

The API that is called to initiate replication is implemented in the DSA.

Referrals

The DSA manages directory hierarchy information (referred to as “knowledge”), which it receives from the database layer. The DSA is responsible for cross-references of partition objects.

DSA GUID and Invocation ID

Both the DSA and the ADAM directory database are represented uniquely and have their own respective GUIDS. The DSA GUID is the GUID of the NTDS Settings object (class nTDSDSA). The value of the DSA GUID is stored in the objectGUID attribute of the NTDS Settings object of the ADAM server object, which resides in the Sites container in the configuration directory partition (with a distinguished name of CN=NTDS Settings,CN=computername$instancename,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,CN={GUID}).

The DSA GUID is created when the ADAM instance is initially installed. The DSA GUID is destroyed only if the ADAM instance is uninstalled. The DSA GUID ensures that the DSA remains recognizable when the computer on which ADAM is running is renamed. The DSA GUID is not affected by ADAM backup and restore processes.

The ADAM directory database has its own GUID, which the DSA uses to identify the database instance (the version of the database). The database GUID is stored in the invocationId attribute on the nTDSDSA object. Unlike the DSA GUID, which never changes for the lifetime of the ADAM instance, invocationId changes in two scenarios:

• During the ADAM restore process, to ensure the consistency of the replication process. The change in invocationId enables ADAM to distinguish changes that are made before and after a database restore.

• When an application directory partition is removed from and added back again to the ADAM instance.

Database Layer

The database layer is an API that resides in Adamdsa.dll and provides an object view of the directory database, making the data accessible to the DSA as a set of hierarchical containers. By applying schema semantics to database records, the database layer isolates the upper components of the directory service from the underlying database system. The database layer is an internal interface. No database access calls are made directly to the ESE; instead, all database access goes through the database layer.

In the directory database, each object is identified by its relative distinguished name, which is unique in the object’s parent container. The relative distinguished name and the chain of successive parent object names make up the object’s distinguished name. The database stores the relative distinguished name for each object, as well as a reference to the parent object. The database layer follows these parent references and concatenates the successive relative distinguished names to form distinguished names, thereby defining the object hierarchy.

The database layer is also responsible for the creation, retrieval, and deletion of individual records (objects), attributes within records, and values within attributes. To carry out these functions, the database layer uses the schema cache (an in-memory structure in the DSA) to get information about the attributes that it needs.

ESE

The ESE is a Windows component that is used by ADAM, as well as by several other Windows components, as an interface to the data that is stored in an indexed and sequential access method (ISAM) database. (The ADAM directory database is an ISAM database.) The ESE is responsible for indexing the data in the database file and for transferring the data in and out of the database. The purpose of the ESE is to enable applications to store and retrieve data by using the ISAM. The ESE provides applications with a consistent data state by means of transacted data update and retrieval. A crash recovery mechanism maintains data consistency, even in the event of a system crash. Transactions in the ESE are highly concurrent, making the ESE suitable for server applications. The ESE caches data intelligently to ensure high-performance access to data. In addition, the ESE is resource efficient, which makes it suitable for applications that perform auxiliary roles.

The version of the ESE that is used with ADAM is implemented in Esent.dll. Each ADAM instance running on a computer shares a single a copy of Esent.dll, which is located in windir\ADAM.

The following characteristics of the ESE make it well suited to the storage needs of ADAM. The ESE:

• Supports databases of up to 16 terabytes (TB) in size, and it can hold many millions of objects per instance.

• Supports indexing.

• Supports multivalue attributes.

• Supports update operations that are transacted for stability and integrity across system failures.

• Can be backed up while the ADAM instance is online.

• Handles sparsely populated objects well; that is, space in the database is not reserved for attributes that do not have values.

The ADAM schema defines all the attributes that are required and allowed for a given object. However, the ESE reserves storage only for the space that is used — that is, only for the attributes that have values, not for all possible attributes. For example, if a user object has 50 attributes defined in the schema and you create a user with values for only 4 attributes, storage space is allocated only for those 4 attributes. If more attributes are added later, more storage is allocated for them.

The ESE implements the search and retrieval functionality of the underlying database. Also, the ESE is able to store attributes that can have multiple values. For example, the database can store multiple phone numbers for a single user without requiring a different phone number attribute for each phone number.

The ESE provides transactional views of the database. The cost of providing these views is that any object that is modified in a transaction has to be temporarily copied so that two views of the object can be provided: one to the thread inside that transaction and one to threads in other transactions. This copy must remain as long as any two transactions in the process have different views of the object. The repository that holds these temporary copies is called the version store. Because the version store requires contiguous virtual address space, it has a size limit. If a transaction is open for a long time while changes are being made (either in that transaction or in others), eventually the version store can be exhausted. At this point, no further database updates are possible.

ADAM Protocols

The primary protocol that ADAM uses is LDAP, which runs on top of TCP/IP. In addition, the data store uses remote procedure call (RPC) for replication and management functions.

The following table describes the protocols that are used by ADAM.

ADAM Protocols

Protocol	Description
LDAP	LDAP is a directory service protocol that specifies directory communications. It runs directly over TCP/IP, and it can also run over User Datagram Protocol (UDP) connectionless transports. Clients can use LDAP to query, create, update, and delete information that is stored in a directory service over a TCP connection through the TCP default port 389. Active Directory supports LDAP v2 (Request for Comments (RFC) 1777, “Lightweight Directory Access Protocol”) and LDAP v3 (RFC 2251, “Lightweight Directory Access Protocol v3”). LDAP v3 is an industry standard that can be used with any directory service that implements the LDAP protocol. LDAP is the preferred and most common way of interacting with Active Directory. Historically, LDAP is a simplified (“lightweight”) version of Directory Access Protocol (DAP), which is the original protocol that was used to interact with X.500 directories. X.500 defines an earlier set of standards that was developed by the International Organization for Standardization (ISO). LDAP is simpler than DAP in two key ways: Rather than using its own protocol stack according to the Open Systems Interconnection (OSI) networking model, LDAP communicates over Internet Protocol (IP) by using either UDP or TCP. LDAP syntax is easier to use than DAP syntax. For these reasons, LDAP is widely used and accepted as the standard protocol for directory service access. The following key aspects of LDAP characterize it: The protocol is carried directly over TCP for connection-oriented transport (receipt of data is acknowledged) and over UDP for connectionless transport (sent or received data is not acknowledged). Most protocol data elements can be encoded as ordinary strings, for example, as distinguished names. Referrals to other servers can be returned to the client. Simple Authentication and Security Layer (SASL) mechanisms can be used with LDAP to provide associated security services. Attribute values and distinguished names can be internationalized through the use of the ISO 10646 character set. The protocol can be extended to support new operations, and controls can be used to extend existing operations. The schema is published through an attribute on the directory root object (rootDSE) for use by clients.
RPC	The REPL interface uses RPC for management tasks, including replication and management functions, that are not well suited to the LDAP protocol. RPC is a powerful, robust, efficient, and secure interprocess communication (IPC) mechanism that enables data exchange and invocation of functionality that resides in a different process. That different process can be on the same computer, on the local area network (LAN), or across the Internet.

ADAM Interfaces

As shown in the “ADAM Architecture” figure earlier in this section, network clients and other directory servers obtain access to ADAM through one of the interfaces that are described in the following table.

ADAM Interfaces

Interface	Description
LDAP	The primary interface for ADAM. Directory clients use LDAP v3 or LDAP v2 to connect to the DSA through the LDAP interface. The LDAP interface is part of Wldap32.dll. LDAP v3 is backward compatible with LDAP v2.
REPL	Provides functionality for finding data about ADAM instances, converting the names of network objects between different formats, manipulating service principal names (SPN) and DSAs, and managing replication of ADAM instances.
System.DirectoryServices (ADSI for .NET Framework)	A namespace in the Microsoft .NET Framework that provides simple programming access to LDAP directories, such as ADAM. This API requires the .NET Framework to be installed.
Active Directory Service Interfaces (ADSI) (Ads*.dll)	A set of Component Object Model (COM) interfaces that abstracts the capabilities of directory services from different network providers (such as LDAP) in a distributed computing environment to present a single set of directory service interfaces for managing network resources.
Directory Services Markup Language (DSML)	Provides a means of representing directory structural information and directory operations as an XML document.

ADAM Physical Structure

The ADAM physical structure consists of the following:

• Computers running ADAM (ADAM servers)

• ADAM instances

• Configuration sets

• Sites

Note

• Because ADAM is based on the same code as Active Directory, the service and scalability limits of ADAM are comparable to Active Directory. Therefore, ADAM supports a comparable number of sites as Active Directory.

ADAM Servers

A computer running ADAM is called an ADAM server. ADAM servers can run on any of the following operating systems:

• Windows Server 2003, Standard Edition

• Windows Server 2003, Enterprise Edition

• Windows Server 2003, Datacenter Edition

• Windows XP Professional

When you run ADAM on a computer running Windows XP Professional, certain considerations apply. The following table lists these considerations.

Running ADAM on Windows Server 2003 and on Windows XP Professional

ADAM Feature	Windows Server 2003	Windows XP Professional
Support for multiple processors	Supported.	Not supported. On multiple-processor computers, ADAM uses only one process at a time to prevent resource monopolization.
Maximum cache value	No limit.	Limited to one half of physical RAM.
Data and log file locations	Data and log files can reside on different drives.	Data and log files must reside on the same drive.
Password policies	Supported.	Not supported.
Auditing	Supported. For more information, see “Auditing” later in this section.	Not supported.
ADAM service account requirements	See “Service Account” later in this section.	See “Service Account” later in this section.
Stopping and restarting an ADAM instance	You can stop and then restart an ADAM instance immediately.	If an LDAP client is connected when you shut down the ADAM instance, you may need to wait as long as two minutes before restarting the ADAM instance. This time is required to allow any existing connections to clear.
Backing up ADAM	Multiple ADAM instances running on the same computer can be backed up simultaneously.	For computers running multiple ADAM instances, only one ADAM instance can be backed up at a time.
Full ADSI functionality	No hotfixes are required.	For complete ADSI functionality with Windows XP Professional, you must install hotfix 817583. For more information about this hotfix, see article 817583, “Active Directory Services Does Not Request Secure Authorization Over an SSL Connection,” in the Microsoft Knowledge Base.

Using ADAM on Windows XP Professional as a Personal Data Store

On computers running Windows XP Professional, ADAM has been designed primarily as a personal data store. It is recommended that you run ADAM on Windows Server 2003 if you need scalability to support a growing number of simultaneously connected clients or if you intend to use ADAM on a centralized directory server.

Running ADAM on Windows XP Professional in a Workgroup

When you install ADAM on a computer running Windows XP Professional that is joined to a workgroup, you must set the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\forceguest to 0. (The default is 1.) Otherwise, users connecting to ADAM over the network are forced to a security context of Guest, and binds to ADAM fail.

ADAM Instances

Each time that you install ADAM, you create a unique ADAM instance. Each ADAM instance consists of the following:

• Program files

• Data files

• Registry keys

• Service name

• Service account

• Event log

• Name:port

Program Files

After you install ADAM, the program files and tools of an ADAM instance reside in the windir\ADAM directory. If you install multiple instances of ADAM on a single computer, the program files and tools in the windir\ADAM directory are shared by all ADAM instances running on that computer.

Note

• If you apply a hotfix to one instance of ADAM, all ADAM instances on the same computer are affected.

Data Files

The data files for a given ADAM instance are installed in the directory Program Files\Microsoft ADAM\instancename\Data, where instancename is the name that you provide for the ADAM instance during installation. If you install multiple instances of ADAM on a single computer, each instance that you install has a separate data directory. For example, if you install two ADAM instances named, respectively, instance1 and instance2 on a computer, the computer has the following ADAM data directories:

Program Files\Microsoft ADAM\instance1\Data

Program Files\Microsoft ADAM\instance2\Data

Registry Keys

Registry keys for ADAM are stored in the following location:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ADAM_instancename

For a detailed explanation of the ADAM registry keys, see “Active Directory Application Mode Tools and Settings.”

Service Name

During setup, you assign a name to the ADAM instance, and that name is used in the creation of the file directory structure and registry keys for ADAM. In addition, the name that you assign is used to create the service name, service display name, and service description, as shown in the example in the following table.

ADAM Service Name

Name Supplied During Setup	Service Name	Service Display Name	Service Description
Instance1	ADAM_instance1	Instance1	Blank (no default description provided)

The name that you specify for an ADAM instance during setup must meet the following requirements:

• It must be unique with respect to other ADAM instances running on the same computer.

• It must be no longer than 44 characters.

• It must use characters only from the ranges of a through z, A through Z, or 0 through 9.

• The name “ntds” cannot be used.

The service display name appears in Add or Remove Programs and in the Services snap-in in Microsoft Management Console (MMC). The service description appears in the Services snap-in. You can modify the service display name and the service description anytime after installation by using the sc command-line tool.

Service Account

Each ADAM instance runs as a user service in the security context of the service account that is specified for that instance. The service account for an ADAM instance is specified at installation, and it should be modified only with the dsmgmt command-line tool.

Note

• Change the ADAM service account only with the dsmgmt command-line tool. Changing the ADAM service account with the Services snap-in will cause errors.

The type of ADAM service account that you can choose for an ADAM instance depends on the Windows workgroup or domain environment in which you install the ADAM instance and on whether the ADAM instance participates in a configuration set.

The Active Directory Application Mode Setup Wizard helps you choose a service account for ADAM by only allowing you to choose a service account that is valid for a particular configuration. The following table shows ADAM service accounts that are valid for a given environment.

ADAM Service Accounts

Environment	First ADAM Instance Service Account	Replica ADAM Instances Service Account
Workgroup (that is, no domain or forest)	Network service	Replica ADAM instances not allowed
Workgroup (that is, no domain or forest)	Workstation user	Workstation user
Windows 2000 Server or Windows Server 2003 domain or forest	Network service	Network service or domain user
Windows 2000 Server or Windows Server 2003 domain or forest	Workstation user	Workstation user
Windows 2000 Server or Windows Server 2003 domain or forest	Domain user	Domain user or network service
Windows NT 4.0 domain	Workstation user	Workstation user
Windows NT 4.0 domain	Domain user	Domain user

Note

• When a workstation (local) user account is used on the first ADAM instance in a configuration set, all subsequent ADAM instances in the same configuration set must use an identical local workstation account name and password as the ADAM service account.

Event Log

Each ADAM instance that is installed on a computer writes events to the event log. These events appear in Event Viewer under ADAM (instancename), where instancename is the name that you assigned to the ADAM instance.

Name:Port

For a directory-enabled application to communicate with an ADAM instance, the application must specify the network basic input/output system (NetBIOS) name, Domain Name System (DNS) name, or IP address of the computer on which ADAM is running. In addition, the application must specify the LDAP or Secure Sockets Layer (SSL) communication port that is being used by the ADAM instance. For example, a directory-enabled application that references an ADAM instance running on a computer with a DNS name of ADAMSrv1.microsoft.com — with a NetBIOS name of ADAMSrv and an IP address of 192.168.0.1 and using communication port 389 for LDAP connections — can address the ADAM instance by using one of the following:

• ADAMSrv1.microsoft.com:389

• ADAMSrv:389

• 192.168.0.1:389

Configuration Sets

ADAM instances replicate data based on participation in a configuration set. A configuration set is a group of ADAM instances that replicate a common schema partition and configuration partition. (For more information about partitions, see “Directory Partitions” later in this document.) ADAM instances in a configuration set can also replicate any number of application directory partitions. ADAM instances in a configuration set are not required to replicate all application directory partitions in the configuration set; a single ADAM instance can replicate all — or any subset of — the application directory partitions in its configuration set. An ADAM instance cannot, however, replicate an application directory partition from a different configuration set.

The following figure shows an example of two ADAM configuration sets, each with two ADAM instances. As shown in the figure, a single computer can run multiple ADAM instances, each in a different configuration set.

ADAM Configuration Sets

Creating Configuration Sets

When you install an ADAM instance, you can install a unique instance or you can install a replica of an existing instance, as shown in the following figure, which illustrates the Setup Options page in the Active Directory Application Mode Setup Wizard.

Active Directory Application Mode Setup Wizard Setup Options

The following table describes each of these options as they relate to configuration sets.

Setup Options

Setup Option	Meaning
A unique instance	Choosing this setup option starts a new configuration set.
A replica of an existing instance	Choosing this option causes the ADAM instance being installed to join to an existing configuration set.

Note

• An ADAM instance can be joined to a configuration set only during installation of the instance. After an ADAM instance is created, it cannot be added to or removed from a configuration set.

Sites

Like Active Directory, ADAM uses topology information, which is stored as site objects and site link objects in the configuration directory partition, to build the most efficient replication topology for a configuration set. You can use sites in ADAM to represent the physical structure, or topology, of your network. You can use ADAM ADSI Edit to define site objects and site link objects.

Note

• For specific instructions about creating site objects, site link objects, and setting site link costs, see the ADAM Administrator’s Guide. To view the ADAM Administrator’s Guide, after you install ADAM click Start, point to All Programs, point to ADAM, and then click ADAM Help.

Site Objects

You can create a site object in ADAM to represent each area of your network (typically, a building or a group of buildings) in which all computers are connected by high-speed bandwidth. You can then move the directory objects of ADAM instances that are located in each area of the network into the corresponding site object. By default, the directory objects of each ADAM instance that you create belong to a single default site (CN=Default-First-Site-Name,CN=Sites,CN=Configuration,CN={GUID}).

Site Link Objects

You can use site link objects in the directory to represent low-speed bandwidth connections between the sites on your network. Site link objects help you tune replication on your network; you can use them to determine the relative cost of replication across each site link. By default, the default site (CN=Default-First-Site-Name) belongs to the default site link object (CN=DEFAULTIPSITELINK,CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,CN={GUID}). You can add new sites that you create to the default site link object. You can also create additional site link objects to represent each of the actual site links on your network.

Site Link Costs

Each site link object in the directory has an associated “cost” that represents the relative preference that ADAM gives to one site link compared to another. You can edit the cost attribute on a site link object to specify the relative cost of replication across that site link. ADAM takes into consideration site link costs when it builds the replication topology. ADAM considers a site link with a higher cost to be less desirable than a site link with a lower cost. When multiple paths for replication are available, ADAM uses the site link with the lower cost.

ADAM Logical Structure

The ADAM logical structure consists of the following:

• Directory database

• rootDSE

• Namespaces

• Directory partitions

• Schema

Directory Database

All data that is stored by an ADAM instance is held in the directory database. The ADAM directory database is organized into two or more partitions. ADAM stores directory data in a hierarchical directory store. By default, the directory database for a given ADAM instance is called Adamntds.dit, and it is located in the following directory:

ProgramFiles\Microsoft ADAM\instancename\Data\Adamntds.dit

rootDSE

At the root of the ADAM directory tree is a DSA-specific entry (DSE), which is not part of any directory partition. The rootDSE represents the top of the logical namespace for one ADAM instance. The rootDSE attributes contain information about the ADAM instance, including its capabilities and configuration. The rootDSE is visible, by design, to anonymous users. (The rootDSE is the only object in ADAM that is visible by default to anonymous users.)

Note

• Some non-Microsoft security scanners report an issue regarding the ability of anonymous users to read the rootDSE. However, the rootDSE is visible to anonymous users by design, and it does not represent a security issue.

There is only one root for a given directory instance, but the information that is stored in the root is specific to the ADAM instance to which you connect. Among other things, the attributes of rootDSE identify the directory partitions (the application, schema, and configuration directory partitions) that are specific to one ADAM instance. In this way, the rootDSE provides a “table of contents” for a given ADAM instance.

The rootDSE is always accessible for queries through an anonymous connection.

rootDSE Operational Attributes

The rootDSE publishes information through attributes on the rootDSE object. RFC 2251 and RFC 2252, “Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions,” define a set of seven rootDSE operational attributes that LDAP v3 servers are expected to publish, and these attributes are described in the following table. All LDAP servers recognize these attribute names, but when an attribute corresponds to a feature that the server does not implement, the attribute is absent.

rootDSE Operational Attributes

Attribute	Description
supportedLDAPVersion	LDAP versions that the server implements. Domain controllers running Windows Server 2003 and Windows 2000 Server support LDAP v2 and LDAP v3.
namingContexts	Naming contexts (directory partitions) that this server masters (stores as a writable replica) or shadows (stores as a read-only replica). A client uses this attribute to choose suitable base objects for searching when the client contacts a server.
subschemaSubentry	The name of a subschema entry, which is used to administer information about the schema, in particular, the object classes and attribute types that are supported.
altServer	Uniform Resource Locators (URLs) of other servers that can be contacted when this server becomes unavailable. If the server cannot locate any other servers, this attribute is absent. Clients can cache this information in case their preferred LDAP server becomes unavailable. This attribute is absent by default for Active Directory servers.
supportedExtension	Object identifiers that identify the extended LDAP operations that the server supports. LDAP extensions include such operations as different query types, paging operations, and sorting methods, which each have a different object identifier. This attribute is absent by default for Active Directory servers.
supportedControl	Object identifiers that identify the LDAP controls that the server supports. If the server does not support any controls, this attribute is absent. Server controls extend LDAP functionality; examples include a control to move objects across domains and a control to delete an entire subtree of a container object.
supportedSASLMechanisms	The names of the SASL mechanisms that the server supports. SASL is a standard for negotiating an authentication mechanism and, optionally, an encryption mechanism to provide client authorization for accessing Active Directory. By default, Generic Security Service API (GSSAPI) is supported.

Note

• A new extended LDAP operation on ADAM instances and domain controllers running Windows Server 2003 enables client refresh of a dynamic entry in the directory. Object identifier = 1.3.6.1.4.1.1466.101.119.1 is defined and published in the supportedExtension attribute of the rootDSE object.

rootDSE Informational Attributes

In addition to the previous operational attributes, ADAM also supports the informational attributes in the following table.

rootDSE Informational Attributes

Attribute	Description
configurationNamingContext *	The naming context (directory partition) for the forest Configuration container
currentTime *	The current time in the generalized time format
defaultNamingContext *	The default naming context (directory partition) for a particular ADAM instance as set in the msDS-defaultNamingContext attribute on the NTDSA object at: (CN=NTDS Settings,CN=computername$instancename,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,CN={GUID}) Setting a value for msDS-defaultNamingContext is optional.
dnsHostName *	The DNS name of this ADAM instance
domainControllerFunctionality *	The numeric level of Active Directory functionality for the ADAM instance
dsaVersionString	The version stamp of Adamdsa.dll. This is visible only to administrators.
dsSchemaAttrCount	The total number of attributes that are defined in the schema
dsSchemaClassCount	The total number of classes that are defined in the schema
dsSchemaPrefixCount	The total number of prefixes in the schema
dsServiceName *	The distinguished name of the NTDS settings object that represents this ADAM instance in the configuration directory partition
forestFunctionality *	The Windows forest functional level. With Active Directory: 0 equals Windows 2000 functional level 1 equals Windows Server 2003 interim functional level 2 equals Windows Server 2003 functional level With ADAM, forestFunctionality is set to 2 by default.
highestCommittedUSN *	The highest update sequence number (USN) that is committed to the database on this ADAM instance
isSynchronized *	A Boolean indicator for whether the ADAM instance has completed its initial synchronization with replica partners
msDS-PortLDAP	The LDAP port used by the ADAM instance
msDS-PortSSL	The SSL port used by the ADAM instance
msDS-PrincipalName	The name of the current user. This is visible only to authenticated users.
msDS-ReplAllInboundNeighbors msDS-ReplAllOutboundNeighbors msDS-ReplConnectionFailures msDS-ReplLinkFailures msDS-ReplPendingOps msDS-ReplQueueStatistics	Attributes that make replication information available through LDAP. By using these attributes, you can obtain information with LDAP that otherwise must be obtained with RPC and the DsReplicaGetInfo API. For more information about DsReplicaGetInfo, see DsReplicaGetInfo in the Microsoft Platform SDK on MSDN.
msDS-TopQuotaUsage	A sorted list (highest to lowest) of the top 10 quotas that are used across all directory partitions that are held by the ADAM instance
pendingPropagations	The number of work items in the security descriptor propagator queue
schemaNamingContext *	The naming context (directory partition) for the forest schema
serverName *	The fully qualified distinguished name for this ADAM instance
serviceAccountInfo	Contains details about the service account that is used by this ADAM instance. This service account information is used during replica promotions to detect invalid configurations (configurations for which replication will not work). This is visible only to ADAM administrators.
spnRegistrationResult	The most recent error that relates to service principal name (SPN) registration. This is visible only to ADAM administrators.
supportedCapabilities *	The object identifier values (including 1.2.840.113556.1.4.1851 and 1.2.840.113556.1791) that indicate the additional capabilities of an ADAM instance, such as support for LDAP policies
supportedConfigurableSettings	The list of configurable settings that are supported by the ADAM instance
supportedLDAPPolicies *	Supported LDAP administrative query policies, such as the maximum size of a result set (MaxResultSetSize) and maximum page size (MaxPageSize)
tokenGroups	The current user’s individual and group SIDs
validFSMOs	Operations master roles (also known as flexible single master operations (FSMO) roles) that are held by the ADAM instance. Valid operations master roles for ADAM are the schema operations master role and the domain naming operations master role.

*Default attributes (All other attributes must be explicitly requested.)

Note

• You can retrieve an active users individual and group SIDs by explicitly querying the tokenGroups attribute on the rootDSE.

Namespaces

Each ADAM directory partition has its own unique distinguished name. Unlike Active Directory, which supports only DNS-style (DC=) names for top-level directory partitions, ADAM supports both DNS-style and X.500-style names for top-level directory partitions. However, if you develop an application for ADAM but later intend to migrate the application to Active Directory, use only DC= naming components in directory partition names. Using only DC= naming components helps to prevent compatibility problems when you migrate the application from ADAM to Active Directory.

For directory partition naming, ADAM supports the distinguished name components that are listed in the following table.

ADAM Directory Partition Distinguished Name Components

Distinguished Name Component	Description
C=	Country/region
CN=	Common name
DC=	Domain component
L=	Location
O=	Organization
OU=	Organizational unit

OUs in a Namespace

Organizational Unit containers can be created only in certain types of parent objects. Therefore, if you want to create organizational units (OUs) in a given ADAM directory partition, consider this limitation when you name the directory partition.

OUs can be created only under the following objects:

• OU (OU=)

• Country/region (C=)

• Organization (O=)

• Domain (DC=)

For example, you can create an OU in an application partition named O=Microsoft,C=US, but you cannot create an OU in an application partition named L=Microsoft,C=US.

Directory Partitions

The ADAM directory store is organized into logical directory partitions, or naming contexts. There are three different types of directory partitions: configuration, schema, and application. Each ADAM directory store must contain a single configuration directory partition and a single schema directory partition. The directory store can contain zero or more application directory partitions. The following table describes each directory partition type, its distinguished name, whether it is required or optional, and its contents.

Directory Partition Types

Partition Type	Distinguished Name	Required/Optional	Contents
Configuration	CN=Configuration,CN={GUID}	Required	ADAM configuration information
Schema	CN=Schema,CN=Configuration,CN={GUID}	Required	Class and attribute definitions
Application	(Assigned during partition creation)	Optional	Application data

Note

• The distinguished names of the configuration partition and the schema partition contain the GUID of the ADAM instance as a part of their distinguished names.

Configuration Directory Partition

The configuration directory partition holds information about ADAM replication scheduling and replica sets, information that defines the other partitions in the replication set, information about the users and groups in the replica set, and other information.

The following table describes the default containers in the configuration directory partition.

Default Containers in the Configuration Directory Partition

Container	Purpose
CN=DirectoryUpdates,CN=Configuration,CN={GUID}	Not currently used.
CN=Extended-Rights,CN=Configuration,CN={GUID}	Stores objects of the class controlAccessRight that applications can use to extend standard access control.
CN=ForeignSecurityPrincipals,CN=Configuration,CN={GUID}	Stores proxy objects for security principals that are from Active Directory domains.
CN=LostAndFoundConfig,CN=Configuration,CN={GUID}	Stores configuration directory partition objects that are being created in containers that are being deleted simultaneously on other ADAM instances in the same configuration set. If, before replication, an object is created in or moved to a location that no longer exists after replication, the “lost” object is added to the LostAndFoundConfig container.
CN=NTDS Quotas,CN=Configuration,CN={GUID}	Stores objects of the class msDS-QuotaControl that contain object ownership quota assignments for the configuration directory partition. Quotas limit the number of objects that a user (including inetOrgPerson), group, computer, or service can own in a configuration directory partition or application directory partition.
CN=Partitions,CN=Configuration,CN={GUID}	Stores the cross-references to every directory partition in the configuration set, including the configuration partition, the schema partition, and all application partitions. During LDAP searches, these cross-references to directory partitions make referrals to other domains possible.
CN=Roles,CN=Configuration,CN={GUID}	Stores the default groups for a given partition.
CN=Services,CN=Configuration,CN={GUID}	Stores data for various networking services and applications.
CN=Sites,CN=Configuration,CN={GUID}	Identifies all the sites in the network, the ADAM instances in those sites, and the replication topology. The contents of this container take the form of replication transports, subnets, and the first site and site link that are created, which are called Default-First-Site-Name and Default-First-Site-Link, respectively.

Schema Directory Partition

The schema directory partition contains the definitions for the types of data that the directory database can hold. The definitions in the schema partition maintain data consistency for the ADAM directory service. In addition, applications can refer to the schema partition to determine the types of data that an ADAM instance allows. You can also extend the schema so that ADAM can hold data that is specific to a particular application. For more information about schemas, see the “Active Directory Schema Technical Reference.”

Application Directory Partitions

Application directory partitions hold the data that your applications use. You can create an application partition during ADAM setup or anytime after installation. Depending on your application, you might extend the schema manually or your application might automatically extend the schema for you. Typically, you manage data in a given application directory partition through your application. After the application directory partition is created, ADAM holds the application partition reference objects in CN=Configuration,CN=Partitions.

Note

• With ADAM you can create users in an application directory partition. ADAM differs from Active Directory in this respect, because Active Directory does not allow the creation of users in an application directory partition.

Schema

The ADAM schema uses object classes and attributes to define the kinds of objects and data that can be created and stored in an ADAM directory. Each ADAM configuration set has its own independently manageable schema, which is stored in the schema directory partition. In keeping with the ADAM design concepts of simplicity and flexibility, the base (or default) ADAM schema contains only the classes and attributes that are needed to start an ADAM instance. The schema can be extended with new classes and attributes, either by administrators or by the applications themselves. In addition, unneeded schema classes and attributes can be deactivated. As with all objects in the directory, access control lists (ACLs) protect schema objects so that only authorized users can alter the schema. Every object in an ADAM directory is an instance of an object class that is defined in a schema.

Object Classes

An object class represents a category of objects, such as users, printers, or applications, that share a set of common characteristics. The definition for each object class contains a list of the attributes that can be used to describe instances of the class. For example, the User class has attributes such as givenName, surname, and streetAddress. Attributes for a class are divided into those attributes that an object of that class must contain and additional attributes that the object may contain. The definition of each class also lists the classes whose objects can be parents of the objects of that class.

Attributes

The schema defines each attribute. The definition for each attribute includes unique identifiers for the attribute, the syntax for the attribute, optional range limits for the attribute values, whether the attribute can have only one value or multiple values, and whether the attribute is indexed. The directory schema defines each attribute exactly once. Each attribute can then be referenced by multiple object classes. For example, the description attribute is defined once, and then it is referenced by many object classes.

Single-value and multivalue attributes

Attributes can be single valued or multivalued. An instance of a single-value attribute can contain only a single value. An instance of a multivalue attribute can contain multiple values, which must all use the same syntax. Each value of a multivalue attribute must be unique.

Note

• A multivalue attribute stores its values in random order. Therefore, you should not make any directory decisions — programmatic or manual — based on the order of the values in a multivalue attribute.

Indexed attributes

Indexing attributes helps to improve the performance of queries that are based on the indexed attributes. Both single-value and multivalue attributes can be indexed; however, classes cannot be indexed. Attributes can be marked for indexing through their schema definition. Indexing an attribute makes it possible for users to use wildcard symbols (*) as prefixes and suffixes when they specify a search string.

When you mark an attribute as indexed, all instances of the attribute are added to the index, not just the instances that are members of a particular class. Indexing attributes, particularly multivalue attributes, can negatively affect replication and object creation time, as well as directory database size. Therefore, you should only index commonly used attributes.

For general information about schemas, see “Active Directory Schema Technical Reference.”

Schema Extensions

Like the Active Directory schema, the ADAM schema can be extended through the importing of .ldf files into the schema. The ADAM package contains four .ldf files that can be imported as an option on the Import LDIF Files page of the Active Directory Application Mode Setup Wizard. Together, these files contain several user class schema definitions, along with objects that can be used with Windows Authorization Manager.

The following table describes each of the optional ADAM .ldf files.

ADAM .ldf Files

.ldf file	User Classes	Description
ms-user.ldf	Person Organizational-Person User	Used to create user objects in the ADAM directory.
ms-inetorgperson.ldf	Person Organizational-Person User inetOrgPerson	Used to create user objects in the ADAM directory of the inetOrgPerson class (as defined in RFC 2798, “Definition of the inetOrgPerson LDAP Object Class”).
ms-userproxy.ldf	User-Proxy	Used to create proxy objects in ADAM for use in bind redirection. For more information about proxy objects and bind redirection, see “Bind Redirection for ADAM Proxy Objects” later in this section.
ms-azman.ldf	Not applicable	Used to prepare ADAM for use with Windows Authorization Manager.

These .ldf files are installed to the windir\ADAM directory, and they can be imported anytime after ADAM installation.

Note

• Each of these .ldf files contains within it the command-line instruction for importing the file into the ADAM schema. To import one of these files after ADAM installation:

1. Open the file in a text editor, such as Notepad.

2. Copy the command-line instruction for importing the file from the beginning of the file.

3. Open an ADAM tools command prompt. Click Start, point to All Programs, point to ADAM, and then click ADAM Tools Command Prompt.

4. Paste the copied command into the command prompt.

5. Run the command.

ADAM Security

Because ADAM is based on the same code as Active Directory, security in ADAM works very similarly to security in Active Directory. ADAM uses the same basic set of security concepts as Active Directory: authentication, authorization, users, groups, ACLs, tokens, and so on. This section describes how these security concepts are implemented in ADAM.

Default Groups in ADAM

ADAM uses groups to provide access to directory data. Like Active Directory, ADAM contains its own set of default groups that are created at installation time. After ADAM is installed, a set of default groups exist in each directory partition. In addition, you can create your own custom groups.

ADAM provides three default groups in each configuration and application directory partition. The groups reside in the CN=Roles container of each partition. These default groups include the following:

• Administrators (CN=Administrators,CN=Roles)

• Readers (CN=Readers,CN=Roles)

• Users (CN=Users,CN=Roles)

Note

• The schema partition does not contain any groups.

The following figure illustrates the default ADAM groups for each directory partition.

Default ADAM Groups by Partition

The following group resides only in the configuration directory partition: Instances (CN=Instances,CN=Roles).

Note

• ADAM uses the Instances group for replication. You should not add users to the Instances group.

You can use ADAM ADSI Edit to view the ADAM groups in the CN=Roles container. The following figure shows the groups that are contained in the CN=Roles container in the configuration partition of an ADAM instance.

Groups in the ADAM Configuration Partition

The following table describes the purpose and default members of each of the default ADAM groups.

Partition	Group	Purpose	Default Members
Configuration	Administrators	This group administers the ADAM instance.	The ADAM administrator that is assigned during ADAM setup. The ADAM administrator is always a Windows security principal.
Configuration	Readers	This group has Read access to the configuration partition (including the schema).	None
Configuration	Users	This group is a computed group.	All users that are defined in any application directory partition
Application (0 to n)	Administrators	This group administers the application partition in which the group resides.	Members of the Administrator’s group from the configuration partition
Application (0 to n)	Readers	This group has Read access to the application partition in which the group resides.	None
Application (0 to n)	Users	This is a computed group.	All users from the respective application directory partition

You can create additional groups in any application partition. You cannot create additional groups in the configuration partition.

Partition Membership and ACL Restrictions

This section describes the partition membership and ACL restrictions in ADAM.

ADAM users

Cross-partition memberships are not allowed for ADAM users. In other words, an ADAM user cannot reside in groups in more than one directory partition. In addition, ADAM users can be assigned permissions only on objects in their own directory partition; they cannot be assigned permissions on objects outside their own directory partition.

By default, ADAM users cannot be created in the configuration directory partition, and they cannot be members of a group in the configuration directory partition. However, there is a hotfix for ADAM that you can use to create ADAM users in the configuration directory partition, which allows ADAM users to be administrators of an ADAM instance. For more information about this hotfix, contact Microsoft Product Support Services.

Windows users

Cross-partition memberships are allowed in ADAM for Windows users (both local and domain Windows users). In other words, a Windows user can reside in groups in more than one directory partition, including the configuration directory partition. In addition, Windows users can be assigned permissions on objects outside their own directory partition.

Group Memberships in ADAM

ADAM groups can contain ADAM users (also called ADAM security principals), as well as Windows users (also called Windows security principals), as members. An ADAM user is a user that is created in an ADAM directory partition. A Windows user is a user that exists as a Windows user on the local computer or as a domain member of an Active Directory domain.

An ADAM user or Windows user becomes a member of an ADAM group by being added to the multivalue member attribute on the respective group object. You can use ADAM ADSI Edit to add users to ADAM groups.

Note

• Although ADAM provides a number of default groups, no default users exist in ADAM, except for the Windows security principal that you specify as the ADAM administrator during ADAM setup. The user that you specify as the ADAM administrator becomes a member of the Administrators group in the configuration directory partition.

Restrictions on the Administrators Group

By default, only Windows security principals can be made members of the Administrators group on the configuration directory partition. Therefore, by default only Windows security principals can administer an ADAM instance. However, there is a hotfix for ADAM that you can use to create ADAM users in the configuration directory partition that allows ADAM users to be administrators of an ADAM instance. For more information about this hotfix, contact Microsoft Product Support Services.

Group Scope

The scope of an ADAM group (or of an ADAM user) is restricted to the partition in which the group (or user) is created. In other words, a group that is created in partition A cannot be used to assign permissions on resources in partition B. The exception to this rule is the Administrators group in the configuration directory partition, whose members have full control of all objects in all partitions. In addition, a user in partition B cannot be added to a group in partition A. This includes groups in the configuration directory partition.

Security Principals in ADAM

The term security principal refers to any object (typically, a user) that has a unique SID and that can be assigned permissions to directory objects. In ADAM, security principals can be any of the following:

• ADAM security principals that are created in an ADAM directory partition

• Windows users that are defined on a local computer

• Windows users that are defined in an Active Directory domain

ADAM Security Principals

An ADAM security principal is a user or other bindable object that is created in ADAM. A newly installed ADAM instance does not include any default ADAM users. In fact, the default ADAM schema does not contain any user object classes. However, you can easily import the schema extensions that are provided with ADAM to add several different user object classes to the ADAM schema. These object classes include the User object class (which is very similar to the User object class in Active Directory) and the inetOrgPerson object class (which is derived from the User object class). You can import these object classes through the Active Directory Application Mode Setup Wizard.

In addition, you can make any object class in the ADAM schema a security principal by adding the msDS-bindableobject auxiliary class and the unicodePwd attribute to the schema definition of the object class in the ADAM schema.

Note

• When you create an ADAM security principal, ADAM generates a SID for the security principal automatically.

Windows Security Principals

In addition to supporting ADAM security principals, ADAM supports the use of Windows security principals. In other words, Windows security principals can be assigned permissions on objects in ADAM, and Windows security principals can become members of ADAM groups. ADAM does not authenticate Windows security principals. Instead, Windows security principals are authenticated by Active Directory (for domain-based Windows security principals) or by the Local Security Authority (LSA) on the local computer (for local Windows security principals).

Default ACLs

Just like Active Directory, ADAM uses ACLs to control access to objects in ADAM. However, unlike Active Directory, the majority of ACLs in ADAM are on the partition head objects (the top-level containers of partitions). These ACLs are inherited throughout the entire partition on which they reside.

By default, the ACLs in the following table exist on the partition head objects in ADAM.

ADAM Default Partition Head ACLs

Partition Head	Group: Default ACLs
Configuration	Administrators: Full Control Readers: Read
Schema	Administrators (from the configuration partition): Full Control Readers: Read
Application (0 to n)	Administrators: Full Control Readers: Read Instances: five replication-related access control entries (ACE)

Other default ACLs for ADAM include the ACLs in the following table.

Other Default ADAM ACLs

Security Principal	ACLs
Everyone	“Query self quota” control on quota objects
Administrators group	Full Control on the Roles container Full Control on the Quotas container Full Control on the Lost and Found container
Readers group	Read control on the Roles container (inheritable) Read control on the Lost and Found container
User and inetOrgPerson classes	“Change password” control for “self” in the default security descriptor in the schema

Adding SIDs to ACLs

By adding the SIDs of particular users to the ACL of a particular object, you can provide access to that object to the security principals that the SIDs represent. To add a SID to an ACL in ADAM, you can use the Dsacls.exe command-line tool.

The general syntax to add a SID to an ACL using dsacls for granting permissions is as follows:

dsacls "\\servername:portnumber\Object DN" /G “User DN”:security descriptor

For example, to grant Delete permissions to a user named Mary Baker (CN=Mary Baker,OU=ADAM users,O=Microsoft) on the object ADAM testers (CN=ADAM testers,OU=ADAM users,O=Microsoft,C=US), you use the following syntax:

dsacls "\\servername:portnumber\CN=ADAM testers,OU=ADAM users,O=Microsoft,C=US" /G “CN=Mary Baker,OU=ADAM users,O=Microsoft,C=US”:SD;;

The general syntax to add a SID to an ACL using dsacls for denying permissions is as follows:

dsacls "\\servername:portnumber\Object DN" /D “User DN”:security descriptor

For example, to deny the Delete, Delete Child, and Delete Tree permissions to Mary Baker (CN=Mary Baker,OU=ADAM users,O=Microsoft) on the ADAM users OU (OU=ADAM users,O=Microsoft,C=US), you use the following syntax:

dsacls "\\servername:portnumber\OU=ADAM users,O=microsoft,C=US" /D “CN=Mary Baker,OU=ADAM users,O=Microsoft,C=US”:SDDCDT;;

For additional information about dsacls syntax, type dsacls /? at an ADAM command prompt. For more information about using dsacls, see article 281146, “How to Use Dsacls.exe in Windows 2000,” in the Microsoft Knowledge Base.

Matching Tokens Against an ACL

In ADAM, when a user is authenticated, ADAM (or the LSA, depending on the type of security principal) creates a security access token for that user. An access token contains the users name, the groups to which that user belongs, a SID for the user, and all of the SIDs for the groups to which the user belongs. The information in the access token is used to determine a user’s level of access to objects whenever the user attempts to access them. The SIDs in the access token are compared with the list of SIDs that make up the discretionary access control list (DACL) for the object to ensure that the user has sufficient permission to access the object.

Authentication in ADAM

Authentication is the act of ensuring the identity of a user before granting that user access to resources. ADAM implements authentication to ensure the identity of users.

ADAM supports several types of authentication, or binding, depending on the type of user being authenticated:

• Anonymous binding, for anonymous users (users that do not supply a password)

• Simple LDAP binding, for ADAM security principals (security principals that reside in ADAM)

• SASL binding, for Windows security principals (Windows security principals that reside on a local computer or in Active Directory)

• Bind redirection, for ADAM proxy users (security principals that reside in ADAM but that contain a reference to a security principal that resides in Active Directory)

Note

• Proxy users are designed for special circumstances and should only be used as a last resort, when Windows principals cannot be used directly. For more information, see “Bind Redirection for ADAM Proxy Objects” later in this section.

When a user attempts to authenticate against, or bind to, ADAM, the user might be authenticated by ADAM, the LSA, or Active Directory, depending on the type of user attempting the bind. The following table lists the types of authentication that ADAM supports, the types of users that are appropriate to each authentication method, and the authenticating authority that handles the authentication.

Authentication Methods in ADAM

Type of Authentication	Type of User	Authenticating Authority
Anonymous	Anonymous	Not applicable. The user is not authenticated.
Simple LDAP bind	ADAM security principal	ADAM
SASL bind (using Kerberos, NTLM, or negotiated)	Local Windows security principal	LSA on the local computer
SASL bind (using Kerberos, NTLM, or negotiated)	Domain Windows security principal	Active Directory
Bind redirection (Simple LDAP bind to ADAM, then SASL bind to Active Directory)	ADAM proxy object	LSA and Active Directory

The types of authentication that are used with ADAM are described in the following sections.

Anonymous Authentication

Anonymous authentication occurs when a user attempts to bind to ADAM without providing a password. Instead, the user presents ADAM with an empty (null) password in a simple LDAP bind request. In return, ADAM provides the user with anonymous access to the directory. Anonymous authentication is useful for any applications that require unrestricted, public access to data and for situations in which you do not want to maintain individual accounts for users.

Note

• By default, ADAM does not allow anonymous binding. However, you can enable anonymous binding in ADAM by modifying the dsHeuristics attribute. For more information, see “To allow anonymous LDAP binding to an ADAM instance” in the ADAM Administrators Guide. To view the ADAM Administrators Guide, click Start, point to All Programs, point to ADAM, and then click ADAM Help.

By default, the only object in ADAM to which an anonymous user has access is the rootDSE object. (The rootDSE object is visible to anonymous users whether or not anonymous binding is enabled.) If you enable anonymous binding, you can grant anonymous access to any object or attribute in the directory by assigning permissions on the object or attribute to NT Authority\Anonymous Logon (whose well-known SID is S-1-5-7). In addition to assigning permissions on the object or attribute, to allow anonymous users to read an object or attribute in ADAM, you must also grant the ADS_RIGHT_DS_LIST_OBJECT permission on the parent of the object or attribute. You can use dsacls to provide access to an object in the directory.

Note

• To grant anonymous access to an entire partition, grant anonymous access permissions on the partition head.

When a user binds to ADAM anonymously, ADAM generates a token that contains the following: S-1-5-7 (NT Authority\Anonymous Logon).

Note

• Tokens that ADAM generates for a user are exposed externally through an attribute on the rootDSE object called tokenGroups. The tokenGroups attribute is new with ADAM, and it does not appear in Active Directory.

Simple LDAP Bind for ADAM Security Principals

Simple LDAP binding occurs when a user binds to ADAM as a security principal that exists as an object in the ADAM directory. This authentication method uses a simple LDAP bind; no SASL options are available with basic authentication. This simple LDAP bind can be accomplished using the distinguished name of the security principal or the user principal name (UPN) of the security principal. In contrast to UPNs in Active Directory, the UPN for an ADAM security principal is not required to contain the @ symbol.

In a simple LDAP bind, the user password is sent in plaintext format to ADAM. For this reason ADAM requires an encrypted channel — using SSL between the client that connects to ADAM and the ADAM server — for basic authentication to occur securely. To enable SSL connections to ADAM, you must have certificates installed on the computer running ADAM. In addition, the clients that connect to ADAM should trust the certification authority (CA) that issues the certificate to the ADAM server. You can obtain certificates from a trusted CA, or, for internal use, you can issue certificates from your own internal CA by installing and using certificate services on Windows 2000 Server or Windows Server 2003.

Notes

• Before you attempt to use a certificate with ADAM, you must ensure that the service account under which ADAM is running has Read access to the certificate that you install. The certificate is located in the following directory: C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys

• Although it is not recommended for production environments, you can disable the requirement for SSL in basic authentication by using the ds-behavior option of the Dsmgmt.exe command-line tool.

Any ADAM object can be used to bind to ADAM, as long as the object class from which the object is derived contains the msDS-bindableobject auxiliary class and the unicodePwd attribute. Adding the msDS-bindableobject auxiliary class to an object class causes ADAM to generate a SID automatically for any object that is created from that class.

Note

• The default ADAM schema contains no bindable object classes. However, several optional user class object definitions are provided with ADAM, including User and inetOrgPerson. You can import these user classes during ADAM installation.

For a user that is authenticated with basic authentication, the ADAM token contains the following SIDs:

• User SID

• Everyone [S-1-1-0]

• NT AUTHORITY\Authenticated Users [S-1-5-11]

• SID of the user’s group from the user’s partition

• SIDs of any additional groups that are determined through transitive group expansion

Note

• To determine the contents of a user’s token, you can view the tokenGroups attribute on the rootDSE object.

Password policy settings and account lockouts

When basic authentication is used and ADAM is running on a computer running Windows Server 2003, ADAM supports and enforces the password policy settings and account lockout settings that are provided by Windows Server 2003, including the following:

• Minimum age

• Maximum age

• Complexity

• History

• Too many failed logon attempts

• Disabling and enabling of accounts

If the server on which ADAM is running belongs to a workgroup, the server’s local password policy settings and account lockout settings are implemented. If the server on which ADAM is running belongs to a domain, the password policy settings and account lockout settings from Active Directory are implemented. Therefore, it is possible for two ADAM instances in the same configuration set to enforce different password policy settings and account lockouts.

Note

• You can disable the enforcement of password policy settings in ADAM by setting ADAMDisablePasswordPolicies, a value in the attribute msDS-Other-Settings on CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,CN=GUID, to 1.

SASL Bind for Windows Security Principals

Integrated authentication occurs when a Windows security principal attempts to bind to an ADAM instance. ADAM does not authenticate Windows users itself. Instead, ADAM relies on the Windows Security API to authenticate the user. Integrated authentication uses SASL binds. All SASL mechanisms that are supported in Active Directory are supported in ADAM. These mechanisms include Kerberos, NTLM, and Negotiated (default). Integrated authentication supports the use of domain\user, UPN, or distinguished name as authentication credentials.

When ADAM receives a SASL bind request, ADAM forwards the request to Active Directory. If the bind request is authenticated by Active Directory, Active Directory returns a token to ADAM. ADAM uses that token in its internal context, augments it with ADAM groups that the Windows user is a member of across all the application partitions that are hosted by the ADAM instance, and then performs transitive group expansion across all the application partitions. That is, ADAM determines group memberships for the Windows user that result from the user being a member of a group that itself is a member of a different group.

For a user that is authenticated using integrated authentication, the ADAM token contains the following SIDs:

• SIDs of all groups from the Windows token that is obtained from Active Directory

• SIDs of all ADAM groups of which the Windows security principal is a member

• SIDs of any additional groups that are determined through transitive group expansion

Bind Redirection for ADAM Proxy Objects

ADAM bind redirection should be used only in special cases where an application can perform a simple LDAP bind to ADAM but the application still needs to associate the user with a security principal in Active Directory.

ADAM bind redirection occurs when a bind to ADAM is attempted using a special object called a proxy object. A proxy object is an object in ADAM that represents a security principal in Active Directory. Each proxy object in ADAM contains the SID of a user in Active Directory. When a user attempts to bind to a proxy object, ADAM takes the SID that is stored in the proxy object, together with the password that is supplied at bind time, and presents the SID and the password to Active Directory for authentication. A proxy object in ADAM does not store a password, and users cannot change their Active Directory passwords through ADAM proxy objects.

Because the initial bind request is a simple LDAP bind request, the password is presented in plaintext to ADAM. For this reason an SSL connection is required by default between the directory client and ADAM. ADAM uses Windows Security APIs to present the password to Active Directory.

Note

• Because the password that is presented to ADAM during ADAM bind redirection is an Active Directory password that is presented in plaintext, you should not disable the requirement for SSL when using bind redirection.

Proxy objects

Proxy objects (and proxy object classes) do not exist by default in ADAM. However, you can import a proxy object class into the ADAM schema during ADAM installation. A proxy object can be created from any object class that contains the msDS-bindProxy auxiliary class. The msds-BindProxy class possesses a single “must contain” attribute, ObjectSid, which holds the SID of the associated Active Directory security principal. You can set the value of ObjectSid only at the time that the object is created. After a proxy object is created, the value of its ObjectSid attribute cannot be modified. You can set the ObjectSid of a proxy object to the SID of any local Windows user or to any user who is a member of a domain or forest that is trusted by the computer on which ADAM is running.

Note

• You cannot create a proxy object for a domain user in an ADAM directory partition that already contains a foreign principal object (FPO) for that same domain user.

For a user that is authenticated through bind redirection, the token that is generated for the user is identical to a token that is generated for a Windows security principal that is binding to ADAM through integrated authentication.

ADAM Processes and Interactions

This section describes the following ADAM processes and interactions:

• Locating an ADAM instance

• Replication

• LDAP referrals

• Service publication

• Auditing

• ADAM and Microsoft Authorization Manager

• Backup and restore

Locating an ADAM Instance

For a directory-enabled application to be able to communicate with an ADAM instance, the application must specify the NetBIOS name, DNS name, or IP address of the computer on which ADAM is running. In addition, the application must specify the LDAP or SSL communication port that is used by the ADAM instance. For example, a directory-enabled application referencing an ADAM instance running on a computer with a DNS name of ADAMSrv1.microsoft.com — with a NetBIOS name of ADAMSrv and an IP address of 192.168.0.1 and using communication port 389 for LDAP connections — can address the ADAM instance by using one of the following:

• ADAMSrv1.microsoft.com:389

• ADAMSrv:389

• 192.168.0.1:389

Locating ADAM Instances in Active Directory Environments

When you run ADAM in an Active Directory environment, each ADAM instance creates and maintains service connection point (SCP) objects about itself in Active Directory. For more information, see “Service Publication” later in this document.

Server Object Names

By default, the relative distinguished name of a server object in ADAM is servername$instancename, where servername represents the computer on which the ADAM instance is running and instancename represents the service name of the ADAM instance.

Modifying Settings on a Computer Running ADAM

You initially specify the computer name, DNS name, NetBIOS name, and IP address when you set up the computer. You initially specify the communication port numbers that are used by a given ADAM instance when you install the ADAM instance.

You can change these settings on a computer running ADAM anytime. However, when you update any of these settings, you may also need to reconfigure directory-enabled applications to properly address the ADAM instance. For example, if the host name of the computer on which ADAM is running changes, your directory-enabled application may need to be updated accordingly.

Replication

ADAM uses replication to provide fault tolerance and load balancing for directory services. ADAM uses a type of replication called multimaster replication. Through replication, ADAM copies directory data updates that are made to a directory partition on one ADAM instance to other ADAM instances that hold copies of the same directory partition. ADAM instances that hold copies of the same directory partition or partitions form a logical grouping called a configuration set. ADAM prevents replication conflicts through the use of change tracking information.

Note

• An ADAM configuration set maintains its own replication topology, separate from any Active Directory replication topology that might also exist. Directory partitions cannot be replicated between ADAM instances and Active Directory domain controllers.

Multimaster Replication

With multimaster replication, you can make changes to directory data on any ADAM instance. ADAM replicates these changes to other members of the configuration set automatically. Multimaster replication is characterized by loose data consistency with convergence. That is, when you make changes to data on a given directory partition at one ADAM instance, replicas of that directory partition that are stored on other ADAM instances become inconsistent with the most up-to-date replica of the directory partition (the partition where the changes were made). However, as changes get replicated through the configuration set, all partition replicas once again become identical; that is, they converge to the most recent data.

Preventing Replication Conflicts

What if two different users make changes to the same data on replicas of the same directory partition on two different ADAM instances? In this case, each ADAM instance attempts to replicate the changes, which creates a conflict. To resolve this conflict, replication partners that receive these conflicting changes examine the attribute data that is contained in the changes, each of which holds a version and a time stamp. ADAM instances accept the change with the higher version and discard the other change. If the versions are identical, ADAM instances accept the change with the more recent time stamp.

If two or more values in a multivalue attribute on an object are updated simultaneously on two different ADAM instances, only one of the updated values will be replicated. In other words, simultaneous updates to a multivalue attribute that occur on two different ADAM instances are considered to be in conflict, even if the updates apply to different values in the multivalue attribute. The only exception to this rule is for linked-value attributes (such as group memberships), which do allow for simultaneous updates to different values in the linked-value attribute.

Sites and Replication

In ADAM, the replication topology is the set of physical connections that is used to replicate directory updates among ADAM instances in a configuration set. ADAM builds the most efficient replication topology for a configuration set based on the site or sites in which members of the configuration set reside. ADAM treats replication within a site differently than replication between sites.

Building the intersite replication topology

One ADAM server in each site, called the intersite topology generator (ISTG), is assigned to build the topology. Together, these ISTGs build a least-cost, spanning-tree algorithm that eliminates redundant replication paths between sites. The intersite replication topology is updated regularly to respond to any changes that occur in the network. You can control intersite replication through the information that you provide when you create your site links.

Determining when intersite replication occurs

ADAM preserves bandwidth between sites by minimizing the frequency of replication and by enabling you to schedule the availability of site links for replication. By default, intersite replication across each site link occurs every 180 minutes (3 hours). You can adjust this frequency to match your specific needs. (Remember that increasing this frequency increases the amount of bandwidth that is used by replication.) In addition, you can schedule the availability of site links for use by replication. By default, a site link is available to carry replication traffic 24 hours a day, 7 days a week. You can limit this schedule to specific days of the week and times of the day. You can, for example, schedule intersite replication so that it only occurs after normal business hours.

Building the intrasite replication topology

The Knowledge Consistency Checker (KCC) on each ADAM instance automatically builds the most efficient replication topology for intrasite replication using a bidirectional ring design. This bidirectional ring topology attempts to create at least two connections to each ADAM instance (for fault tolerance) and no more than three hops between any two ADAM instances (to reduce replication latency). To prevent connections of more than three hops, the topology can include shortcut connections across the ring. The KCC updates the replication topology regularly.

The KCC in ADAM operates identically to the KCC in Active Directory. For more information about how the KCC in Active Directory works, see “How Active Directory Replication Topology Works.”

Determining when intrasite replication occurs

Intrasite replication is optimized for speed, rather than bandwidth, because bandwidth within a site is assumed to be high speed. Intrasite replication occurs automatically on the basis of change notification, and it begins when a directory update occurs. By default, the source ADAM instance waits 15 seconds and then sends an update notification to its closest replication partner. If the source ADAM instance has more than one replication partner, subsequent notifications go out by default at three-second intervals to each partner. After receiving notification of a change, a partner ADAM instance sends a directory update request to the source ADAM instance. The source ADAM instance responds to the request with a replication operation. The three-second notification interval prevents the source ADAM instance from being overwhelmed with simultaneous update requests from its replication partners.

If no directory updates occur in a given time period, intrasite replication still occurs, based on a scheduled interval. By default, this scheduled interval is once per hour. For information about modifying this time period, see the ADAM Administrator’s Guide. After you install ADAM, to view the ADAM Administrator’s Guide, click Start, point to All Programs, point to ADAM, and then click ADAM Help.

Ensuring Replication Security

To ensure replication security, ADAM authenticates replication partners before replication, and replication authentication always occurs over a secure channel. ADAM replication partners authenticate each other using the service account that is specified for each respective ADAM instance. ADAM uses the Security Support Provider Interface (SSPI) to establish the appropriate authentication security level between replication partners. The method that is used for replication authentication within a configuration set depends on the value of the msDS-ReplAuthenticationMode attribute on the configuration directory partition. After replication partners authenticate, all replication traffic between the two partners is encrypted.

The following table describes the security levels for ADAM replication and the corresponding authentication mode (msDS-ReplAuthenticationMode) attribute value for each security level. The default replication security level for a new, unique ADAM instance is 1, unless a local workstation user account is specified as the ADAM service account. If a local workstation account is specified as the ADAM service account, the replication security level is 0.

ADAM Replication Security Levels

Replication Security Level	Authentication Mode	Description	Supported Environments
Mutual authentication with Kerberos	2	Kerberos authentication, using SPNs, is required. If Kerberos authentication fails, the ADAM instances will not replicate.	The configuration set must be fully contained in an Active Directory domain, forest, or forest trust.
Negotiated	1	Kerberos authentication (using SPNs) is attempted first. If Kerberos fails, NTLM authentication is attempted. If NTLM fails, the ADAM instances will not replicate.	The configuration set can contain Windows NT 4.0 member servers. This is useful for transitioning between negotiated pass-through mode and mutual authentication with Kerberos.
Negotiated pass-through	0	All ADAM instances in the configuration set use an account name and password that are identical to those of the ADAM service account.	The configuration set can include computers that are joined to one or more workgroups or that are joined to multiple domains or forests without trust relationships.

To help maintain ADAM replication security, the following best practices are recommended:

• Use the highest level of replication security that your environment can support.

• In Active Directory environments, run ADAM on member servers — rather than on domain controllers — whenever possible.

• If you run ADAM on a domain controller in an Active Directory environment, do not use the Network Service account as the ADAM service account. Instead, use a domain user account that does not have administrative privileges.

• In workgroup and Windows NT 4.0 environments, do not use an account with administrative privileges as an ADAM service account.

• Use separate configuration sets for applications with strict isolation requirements.

Replication Monitoring

You can use the Repadmin.exe command-line tool to monitor ADAM replication.

Repadmin /showutdvec shows, from the perspective of the ADAM instance on which the command is run, the most recent change that the ADAM instance has received from each of its replication partners, both directly and transitively.

You can use Repadmin /replicate to force replication between ADAM instance replication partners.

For more information about the repadmin command, type repadmin /? at an ADAM tools command prompt.

LDAP Referrals

In accordance with RFC 2251, ADAM supports the use of LDAP referrals. With LDAP referrals, you can use ADAM to direct LDAP clients to a more appropriate location in response to a query from the client. Also in accordance with RFC 2251, ADAM can return referrals in response to any LDAP operation request, except “unbind” and “abandon” requests, which have no responses. ADAM maintains referral data in crossRef objects that are stored in the partitions container of the configuration directory partition.

ADAM creates and maintains crossRef objects for all directory partitions in the configuration set, including the configuration and schema directory partitions. These crossRef objects are used to generate referrals in response to queries that request data about objects that exist in the configuration set but that are not contained in the ADAM instance handling the request.

At a minimum, at least one URL must be present in the referral. When possible, ADAM returns at least three referrals to provide referral redundancy to clients in distributed environments. A referral is not returned for a singleLevel or wholeSubtree search in which the search scope spans multiple directory partitions and several different servers must be contacted to complete the operation. Instead, continuation references are returned.

If a crossRef object with a matching directory partition exists, ADAM uses it for referrals. However, if a crossRef object does not exist, but the queried namespace uses DNS-style (DC=) naming, ADAM constructs a DNS name to be used as a referral. If the queried namespace does not use DNS-style naming, a superior reference is used, if one exists. A superior reference can be configured by setting the superiorDnsRoot attribute on the configuration partition crossRef object. If a superior reference is not configured (it is not configured by default), an operational error is returned.

Generating Referrals from a crossRef Object

If the dNSRoot attribute has been set on the crossRef object (dNSRoot is not set by default), ADAM returns the DNS name as the referral for the queried namespace. (By default, the dNSRoot attribute is set to NULL.) Then, the client can chase the referral through registered DNS records for each host that contains the queried namespace.

If the dNSRoot attribute is NULL, the referral is generated based on other information on the crossRef object, as follows:

• ADAM refers to the msDS-NC-Replica-Locations attribute to find the NTDS Settingsobjects that represent the instances hosting this partition (for example, CN=NTDS Settings,CN=Machine1$instance1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,CN={GUID}). If more than three ADAM instances host the directory partition, a randomly selected set of three instances is chosen.

• From the NTDS Settings object (the authoritative source in the directory for communications port information), ADAM retrieves the msDS-PortLDAP attribute for the communications port.

• From the parent object (Server Object), ADAM retrieves the dNSHostName attribute (instance1.machine1.domain.com). dNSHostName is the authoritative source for the server host name, and it can be either a DNS host name or a host IP address. If the server name changes, this object can be relied on to have the updated information.

• ADAM then constructs the referral based on the server and communications port information. ADAM returns multiple referrals for each request to ensure that the client can pursue the request, even if one or more hosts represented in the referrals cannot be reached. ADAM selects a random number of locations (three by default) and continues to use those defaults for five minutes, after which another three hosts are selected. Both the number of hosts and the number of minutes are configurable. If the number of specified hosts is greater than the actual number of instances holding the directory partition, all of the hosts are returned as referrals, and they will continue to be used indefinitely. This information is kept in the crossref cache, and it is refreshed anytime the crossref cache is rebuilt. The crossref cache is automatically rebuilt when msds-nc-replica-locations changes, that is, when an ADAM instance is added or removed.

• You can modify the values in the following table on the msDS-Other-Settings attribute of the directory service object — or on a crossRef object — to configure the referral behavior of an ADAM instance.

  ADAM Referral Behavior Values

  Value Name	Default	Meaning
  MaxReferrals	3	Maximum number of referrals returned by ADAM
  ReferralRefreshInterval	5 minutes	Time interval at which referral information is updated
  SelfReferralOnly	0	Setting the value to 1 prevents ADAM from providing referral information.

• Values that you set on a crossRef object take precedence over any values that you set on the directory service object.

Generating Referrals Without crossRef Objects

If a crossRef object does not exist for the search base, ADAM determines the DNS name if the distinguished name that is presented in the request uses DNS-style (DC=) syntax. Otherwise, ADAM uses the value of the supref attribute of the configuration directory crossRef object to generate a referral if supref contains a value. (This attribute is NULL by default, and it must be configured explicitly.) Otherwise, no referrals are generated.

Service Publication

In Active Directory environments, ADAM uses SCP objects to publish ADAM service information in the Active Directory directory store. Administering ADAM SCP objects includes the following operations:

• Manually creating SCPs when necessary

• Removing SCP objects when necessary

• Modifying permissions on SCP objects when necessary

• Managing SCPs efficiently

• Checking the ADAM event log for SCP errors

Creating SCPs

By default in Active Directory environments, the ADAM service creates SCPs in Active Directory when the ADAM service starts. To create SCPs successfully, the ADAM service account must have sufficient rights in Active Directory. If SCP creation fails, ADAM writes an event regarding the failure to the ADAM event log.

The default location for the ADAM SCP object is under the computer object that represents the computer on which ADAM is running. This default location can be altered by specifying a different location on the SCPPublishingService object.

When it is used as the ADAM service account on a computer that is joined to a domain, the Network Service account usually has sufficient rights to create SCPs in Active Directory. However, when it is used on an ADAM instance running on a domain controller, the Network Service account does not have sufficient rights to create SCPs in Active Directory.

Removing SCPs

An ADAM instance deletes its SCP from Active Directory when you remove the ADAM instance from the computer. Removing the SCP requires sufficient administrative credentials. If SCP removal fails, client applications may be directed to a nonexistent ADAM instance.

Modifying SCPs

An ADAM instance checks and updates, if necessary, its SCP each time that the ADAM instance starts. At startup, the ADAM instance searches the global catalog for its own GUID and retrieves the distinguished name of the SCP object. The ADAM instance then binds to that distinguished name and updates the SCP object as necessary. In addition, the ADAM instance reviews the SCP object on an hourly basis by default to confirm its validity, particularly regarding any directory partitions that have been added to or removed from the ADAM instance since the SCP object was last updated.

You can modify the default time interval at which ADAM reviews the SCP object by adding a Server information update interval (mins) value to the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\instancename\Parameters and setting this value to the time interval (in minutes) that you want to use.

Notes

• To prevent an ADAM instance from updating its SCP object, or to prevent an ADAM instance from recreating the SCP object after you have deleted the SCP object, set the registry key value HKLM\System\CurrentControlSet\Services\instance name\Parameters\Server information update interval (mins) to 0.

• To prevent the publication of SCPs for all ADAM instances in an ADAM configuration set, set the attribute Enabled on the object CN=SCP Publication Service,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,CN={GUID} to False.

For more information about publishing and using SCPs, see the Microsoft Platform SDK on MSDN and search for “Service Publication.”

Managing ADAM SCPs

One efficient way to manage SCPs for ADAM is to create an SCP container for your ADAM configuration set in Active Directory. In this container, place the computer objects of the computers on which ADAM instances are running. In addition, create a group called, for example, “ADAM instances,” and then assign permissions on the SCP container to the group. Also, delegate control of the group to the assigned ADAM administrator. Then, each time the ADAM administrator installs a new ADAM instance under a new service account, the ADAM administrator can simply add the new service account to the ADAM instances group, and the ADAM instance creates and maintains its SCPs transparently.

Checking the ADAM Event Log

SCP-related errors do not prevent an ADAM instance from functioning properly. ADAM does, however, report SCP-related errors in the ADAM event log so that errors can be resolved. ADAM reports SCP-related errors as follows:

• When an SCP creation or update fails, the ADAM instance reports the error and points to an .ldf file that can be used to resolve the problem manually. Using this .ldf file to create or update the SCPs requires administrative credentials in Active Directory.

• When ADAM fails to remove an SCP object, ADAM reports this failure both in the audit log of the appropriate domain controller and in the ADAM event log.

Auditing

As with Active Directory, you can audit objects in ADAM for such activities as creation, modification, deletion, and reads. You can also audit ADAM objects at the attribute level. That is, you can specify specific attributes that you want to audit. However, in contrast to Active Directory, no user interface (UI) exists in ADAM for specifying which objects or attributes to audit. To enable auditing in ADAM, you must modify system access control lists (SACLs) for objects and attributes programmatically or by using Ldp.exe.

Notes

• ADAM does not support auditing when it runs on Windows XP Professional.

• Before implementing auditing in ADAM, you should apply the hotfixes that are available for ADAM. For more information about ADAM hotfixes, contact Microsoft Product Support Services.

ADAM and Microsoft Authorization Manager

Microsoft Authorization Manager can use ADAM as a policy store for authorization policy. The ADAM installation process allows the installation of the Authorization Manager schema. The Authorization Manager schema must be installed and the container in which the store is to be created must exist before the Authorization Manager store is created. You can manage the policy store in ADAM either through the Authorization Manager scriptable COM interfaces or by using the Authorization Manager UI.

Note

• Currently, you cannot use ADAM to store security principals for Authorization Manager.

Backup and Restore

By default, each instance of ADAM running on an ADAM server stores its database file, Adamntds.dit, and the associated log files in Program Files\Microsoft ADAM\Instancename\Data. These files should be included as part of the regular backup plan of your organization. You can back up the directory stores using Ntbackup or any Windows Logo Program, non-Microsoft backup utility.

Restoring ADAM

When you restore a database to an existing ADAM instance, you must stop the ADAM instance before you run the restore operation. In addition, it is recommended that you move (or delete) the existing database and log files from the ADAM instance before beginning the restore operation.

Authoritative Restore

If objects in the directory are inadvertently deleted or modified, and if those objects are replicated in a configuration set, you must authoritatively restore those objects so that the correct version of the objects is replicated. To authoritatively restore directory data, run the dsdbutil utility after you have restored the data but before you restart the ADAM instance. With dsdbutil, you can mark directory objects for authoritative restore. When an object is marked for authoritative restore, its metadata version number is changed so that the number is higher than any other metadata version number in the configuration set. This ensures that any data you restore is properly replicated throughout the configuration set.

Backup Latency Interval

On computers running Windows Server 2003 with Service Pack 1 (SP1) and ADAM, a new NTDS Replication event provides a warning to administrators when an ADAM partition has not been backed up. Event ID 2089 provides the backup status of each directory partition that a domain controller stores, including application directory partitions. Specifically, event ID 2089 is logged in the Directory Service event log when partitions in the Active Directory forest are not backed up within a backup latency interval. The value for the backup latency interval is stored as a REG_DWORD value in the Backup Latency Threshold (days) entry in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters.

By default, the value of Backup Latency Threshold (days) is half the value of the tombstone lifetime of the forest. If halfway through the tombstone lifetime a directory partition has not been backed up, event ID 2089 is logged in the Directory Service event log and continues daily until the directory partition is backed up.

This event serves as a warning to administrators and monitoring applications to make sure that domain controllers are backed up before the tombstone lifetime expires. However, it is recommended that backups be taken at a much higher frequency than the default value of Backup Latency Threshold (days).

Network Ports Used by ADAM

The following table lists the network ports that are used by ADAM.

Default Port Assignments for ADAM

Service Name	UDP	TCP
LDAP	None	389
LDAP SSL	None	636
RPC Endpoint Mapper	135	135

Related Information

The following resources contain additional information that is relevant to this section:

• Article 817583, “Active Directory Services Does Not Request Secure Authorization Over an SSL Connection,” in the Microsoft Knowledge Base

• Active Directory Application Mode Tools and Settings

• Microsoft Platform SDK on MSDN for more information about DsReplicaGetInfo (in “DsReplicaGetInfo”)

• Active Directory Schema Technical Reference

• Article 281146, “How to Use Dsacls.exe in Windows 2000,” in the Microsoft Knowledge Base

• How Active Directory Replication Topology Works

• Microsoft Platform SDK on MSDN for more information about publishing and using SCPs (search for “Service Publication”)

• “Windows Server 2003 Active Directory Application Mode” on the Microsoft Web Site