Active Directory Lightweight Directory Services

Active Directory® Lightweight Directory Services (AD LDS) is a Lightweight Directory Access Protocol (LDAP) directory service in the Windows Server® 2008 operating system that provides flexible support for directory-enabled applications, without the dependencies and domain-related restrictions of Active Directory Domain Services (AD DS). You can run AD LDS on member servers or stand-alone servers. You can also run multiple instances of AD LDS—each with its own independently managed schema—on one server.

AD LDS was previously called Active Directory Application Mode (ADAM). Under that name, it was available in the Microsoft® Windows Server 2003 R2 operating system and as a separate download for the Microsoft Windows® XP Professional operating system and Windows Server 2003.

  • Overview of AD LDS

  • Checklist: Create a New Instance of AD LDS

  • Checklist: Create a Replica of an Existing AD LDS Instance

  • Checklist: Import Data from LDIF Files

  • Checklist: Create an Application Directory Partition

  • Checklist: Manage Group Memberships

  • Checklist: Back Up or Restore an AD LDS Instance

  • Checklist: Synchronize Data from AD DS to AD LDS

  • Working with Instances

  • Working with Directory Partitions

  • Working with Authentication and Access Control

  • AD LDS Administration Tools

  • User Interface: Active Directory Lightweight Directory Services Setup Wizard


Overview of AD LDS

Introducing AD LDS

For organizations that require flexible support for directory-enabled applications, Microsoft has developed Active Directory Lightweight Directory Services (AD LDS). AD LDS is a Lightweight Directory Access Protocol (LDAP) directory service.

AD LDS provides data storage and retrieval for directory-enabled applications, without the dependencies that are required for Active Directory Domain Services (AD DS). AD LDS provides much of the same functionality as AD DS, but it does not require the deployment of domains or domain controllers. You can run multiple instances of AD LDS concurrently on a single computer, with an independently managed schema for each AD LDS instance.

What's new in AD LDS

The following features are new to AD LDS in Windows Server 2008:

  • The AD LDS server role

  • Integration with AD DS

Microsoft directory technologies

With AD LDS, Microsoft provides a choice of directory services. Both AD LDS and AD DS build on the same core Microsoft directory service technologies, but they address different needs in an organization.

AD DS provides directory services for both the Windows server operating system and for directory-enabled applications. For the server operating system, AD DS stores critical information about the network infrastructure, users and groups, network services, and so on. In this role, AD DS must adhere to a single schema throughout an entire forest.

AD LDS provides directory services specifically for directory-enabled applications. AD LDS does not require or rely on AD DS domains or forests. However, in environments where AD DS exists, AD LDS can use AD DS for the authentication of Windows security principals.

AD LDS and AD DS can run concurrently in the same network. In addition, AD LDS can support both domain users and workgroup users simultaneously, as shown in the following illustration.

AD LDS and AD DS in a single network

Directory-enabled applications

A directory-enabled application uses a directory, rather than (or in addition to) a database, flat file, or other data storage structure, to hold its data. Many off-the-shelf applications, as well as many custom applications, use a directory-enabled design. Examples of the types of applications that often use a directory-enabled design include customer relationship management (CRM) applications, human resource (HR) applications, and global address book applications.

Directory services (such as AD LDS) and relational databases both provide data storage and retrieval, but they differ in their optimization. Directory services are optimized for read processing, while relational databases are optimized for transaction processing. In general, consider implementing a directory service if your application reads data more frequently than it writes data. Consider implementing a relational database if your application writes or modifies data more frequently than it reads data.

In addition, directory services also provide such benefits as distributed architecture (multimaster design, replication, and geographical scalability); storage of identity data that is common to applications and platforms throughout an enterprise; flexible data schema; and fine-grained access policies.

Additional references

  • Active Directory Lightweight Directory Services


Checklist: Create a New Instance of AD LDS

An instance of Active Directory Lightweight Directory Services (AD LDS) is a single running copy of AD LDS. Multiple copies of AD LDS can run simultaneously on the same computer. (This is not true for Active Directory Domain Services (AD DS).) This improves availability and load balancing when instances are replicated across multiple servers. Each instance of AD LDS has a separate directory, a unique service name, and a unique service description that is assigned when the instance is created.

Task | Reference
Read about AD LDS instances. | Understanding AD LDS Instances
Run the Active Directory Lightweight Directory Services Setup Wizard. | Create a New AD LDS Instance

Additional references

  • Active Directory Lightweight Directory Services


Checklist: Create a Replica of an Existing AD LDS Instance

Replicating Active Directory Lightweight Directory Services (AD LDS) instances on multiple servers provides greater load balancing and fault tolerance by distributing application data across servers. A replica of an existing AD LDS instance contains replicated copies of the configuration and schema directory partitions, including any schema extensions. You can specify a running AD LDS instance as the source from which to replicate, or you can use a restored copy of a previously backed up AD LDS instance as the data source.

Task | Reference
Read about AD LDS instances. | Understanding AD LDS Instances
Read about AD LDS replication. | Understanding AD LDS Replication and Configuration Sets
Run the Active Directory Lightweight Directory Services Setup Wizard. | Create a Replica AD LDS Instance

Additional references

  • Active Directory Lightweight Directory Services


Checklist: Import Data from LDIF Files

LDAP Data Interchange Format (LDIF) files provide a mechanism for importing schema definitions into an instance of Active Directory Lightweight Directory Services (AD LDS). You can use LDIF files to transfer objects between Active Directory Domain Services (AD DS) and AD LDS partitions. You can import one of several Microsoft-supplied LDIF files to create user objects or proxy objects. You can also create LDIF files containing object definitions that are exported from other Lightweight Directory Access Protocol (LDAP)–compliant directories.

Task | Reference
Read about AD LDS instances. | Understanding AD LDS Instances
Read about the AD LDS schema. | Understanding the AD LDS Schema
Read about Ldifde. | Ldifde
Copy the LDIF file that you want to import to the server. |
Run Ldifde. | Import Data into an AD LDS Instance

Additional references

  • Active Directory Lightweight Directory Services


Checklist: Create an Application Directory Partition

Each instance of Active Directory Lightweight Directory Services (AD LDS) can contain one or more application directory partitions to hold application data. All application directory partitions in an AD LDS directory instance share a single schema that defines the objects and attributes that can be stored in the directory. When you create an application directory, you can create a new, empty application partition, or you can replicate one or more application directory partitions from an existing AD LDS instance.

Task | Reference
Read about AD LDS application directory partitions. | Understanding Directory Partitions
Create an application directory partition. | Create an Application Directory Partition

Additional references

  • Active Directory Lightweight Directory Services


Checklist: Manage Group Memberships

To control access to directory data, Active Directory Lightweight Directory Services (AD LDS) relies on permissions that are granted to users and groups. AD LDS supports the simultaneous use of both Windows users and AD LDS users as members of AD LDS groups. AD LDS provides four default role-based groups. You can create additional AD LDS groups as necessary. To create AD LDS users, you must first import the user object class definitions that are provided with AD LDS, or you can supply your own user object definitions.

Task | Reference
Read about AD LDS users and groups. | Understanding AD LDS Users and Groups
Extend the schema of an instance to include user classes. | Import the User Classes That Are Supplied with AD LDS
Add users to the directory. | Add an AD LDS User to the Directory
Add members to AD LDS groups. | Add or Remove Members to or from an AD LDS Group

Additional references

  • Active Directory Lightweight Directory Services


Checklist: Back Up or Restore an AD LDS Instance

By default, each instance of Active Directory Lightweight Directory Services (AD LDS) that is running on an AD LDS server stores its database file and the associated log files in an instance-specific directory. Include these files as part of the regular backup plan of your organization. You can back up the directory using Windows Server Backup or another backup utility.

Task | Reference
Read about AD LDS instances. | Understanding AD LDS Instances
Read about backing up and restoring AD LDS instances. | Understanding AD LDS Instance Backup and Restore
Run Windows Server Backup. If you are backing up an instance, ensure that the instance that you intend to back up is running. If you are restoring an instance, ensure that the instance is stopped. Use the Services snap-in to start or stop an AD LDS instance. | Back Up AD LDS Instance Data Restore AD LDS Instance Data

Additional references

  • Active Directory Lightweight Directory Services


Checklist: Synchronize Data from AD DS to AD LDS

You can use command-line tools to synchronize data from Active Directory Domain Services (AD DS) to an Active Directory Lightweight Directory Services (AD LDS) configuration set. This makes it possible for your application to access objects that are stored in AD DS as well as objects that are created and stored in AD LDS. You cannot use these tools to synchronize passwords between directory services.

Task | Reference
Read about AD LDS instances. | Understanding AD LDS Instances
Read about AD LDS users and groups. | Understanding AD LDS Users and Groups
Import AD DS user class definitions into the instance that you are synchronizing. | Checklist: Import Data from LDIF Files
Run Adamsync. | Synchronize with Active Directory Domain Services

Additional references

  • Active Directory Lightweight Directory Services


Working with Instances

In Active Directory Lightweight Directory Services (AD LDS), a "service instance" (or, simply, "instance") refers to a single running copy of AD LDS. Multiple copies of AD LDS can run simultaneously on the same computer. (This is not true for Active Directory Domain Services (AD DS.) Each instance of AD LDS has a separate directory data store, a unique service name, and a unique service description that is assigned during installation. An instance can be part of a configuration set that provides replication of instance data to instances that run on separate servers.

  • Understanding AD LDS Instances

  • Understanding the AD LDS Schema

  • Understanding AD LDS Replication and Configuration Sets

  • Understanding AD LDS Instance Backup and Restore

  • Create a New AD LDS Instance

  • Create a Replica AD LDS Instance

  • Install an AD LDS Replica from Media

  • Start, Stop, or Restart an AD LDS Instance

  • Use ADSI Edit to Manage an AD LDS Instance

  • Use Ldp.exe to Manage an AD LDS Instance

  • Import Data into an AD LDS Instance

  • Back Up AD LDS Instance Data

  • Restore AD LDS Instance Data

Additional references

  • Active Directory Lightweight Directory Services


Understanding AD LDS Instances

Active Directory Lightweight Directory Services (AD LDS) uses the same architecture—and even the same code base—as Active Directory Domain Services (AD DS). AD LDS provides a hierarchical data store, a directory service component, and interfaces that clients can use to communicate with the directory service. AD LDS does not require a domain controller or a Domain Name System (DNS) server.

The following illustration shows the relationships between the components of AD LDS.

AD LDS architecture

AD LDS manages the directory data store, responding to directory requests from directory clients and from other directory services. The AD LDS directory service runs in the security context of the account that is specified as the AD LDS service account. The AD LDS directory service provides all the following functions:

  • Authentication of directory users

  • Fulfillment of data requests

  • Data synchronization between directory servers (through multimaster replication)

  • Data management

AD LDS manages replication by grouping AD LDS instances into configuration sets. For more information about AD LDS replication, see Understanding AD LDS Replication and Configuration Sets.

The AD LDS directory service allows or denies access to clients based on credentials that the clients provide. AD LDS supports all the same authentication, or binding, methods as AD DS. For more information about authentication and data security, see Working with Authentication and Access Control.

AD LDS service account requirements vary, depending on the computer on which AD LDS is installed and also on the replication scenario. For more information, see Service Account Selection.

In AD LDS, a "service instance" (or, simply, "instance") refers to a single running copy of the AD LDS directory service. Multiple copies of the AD LDS directory service can run simultaneously on the same computer. (This is not true for AD DS.) Each instance of the AD LDS directory service has a separate directory data store, a unique service name, and a unique service description that is assigned during installation.

Additional references

  • Working with Instances

  • Understanding the AD LDS Schema

  • Understanding AD LDS Replication and Configuration Sets

  • Create a New AD LDS Instance

  • Install an AD LDS Replica from Media


Understanding the AD LDS Schema

An Active Directory Lightweight Directory Services (AD LDS) schema defines, using object classes and attributes, the types of objects and data that can be created and stored in an AD LDS directory. Each AD LDS configuration set has its own independently manageable schema, which is stored in the schema directory partition. In keeping with the AD LDS design concepts of simplicity and flexibility, the base (or default) AD LDS schema contains only the classes and attributes that are needed to start an AD LDS 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 AD LDS directory is an instance of an object class that is defined in a schema, as shown in the following illustration.

AD LDS schema

Object classes

An object class represents a category of objects, such as users, printers, or application programs, 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. The list of attributes for a class is divided into those attributes that an object of that class must contain and additional attributes that an object may contain. The definition of each class also lists the classes whose objects can be parents of objects of a given class.

For example, the following table shows the definition for the AD LDS User class.

Attribute | Value
Dn | CN=User,CN=Schema,CN=Configuration
objectClass | top; classSchema;
cn | User;
distinguishedName | CN=User,CN=Schema,CN=Configuration;
subClassOf | organizationalPerson;
mayContain | audio; carLicense; departmentNumber; displayName; employeeNumber; employeeType; givenName; homePostalAddress; jpegPhoto; labeledURI; photo; preferredLanguage; roomNumber; secretary; uid; userPKCS12; userSMIMECertificate; x500uniqueIdentifier;
rDNAttID | cn;
adminDisplayName | User;
adminDescription | User;
objectClassCategory | 1;
lDAPDisplayName | user;
name | User;
objectGUID | dac9093a-d2aa-408a-81bb-0fe8179165da;
schemaIDGUID | bf967aba-0de6-11d0-a285-00aa003049e2;
objectCategory | CN=Class-Schema,CN=Schema,CN=Configuration;
defaultObjectCategory | CN=Person,CN=Schema,CN=Configuration;

Attributes

The schema also 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 referenced by many object classes.

The following table shows the attribute definition for telephone number, a representative schema attribute.

Attribute | Value
objectClass | top; attributeSchema;
cn | Telephone-Number;
distinguishedName | CN=Telephone-Number,CN=Schema,CN=Configuration;
instanceType | 0x4 = ( IT_WRITE );
whenCreated | 11/12/2002 13
22 | 14 Pacific Standard Time Pacific Daylight Time;
whenChanged | 11/12/2002 13
22 | 14 Pacific Standard Time Pacific Daylight Time;
uSNCreated | 217;
attributeID | 2.5.4.20;
attributeSyntax | 2.5.5.12;
isSingleValued | TRUE;
rangeLower | 1;
rangeUpper | 64;
uSNChanged | 217;
showInAdvancedViewOnly | TRUE;
adminDisplayName | Telephone-Number;
adminDescription | Telephone-Number;
oMSyntax | 64;
searchFlags | 0;
lDAPDisplayName | telephoneNumber;
name | Telephone-Number;
objectGUID | bf19d7eb-ea0f-4f2d-af67-f439a037d8a4;
schemaIDGUID | bf967a49-0de6-11d0-a285-00aa003049e2;
attributeSecurityGUID | 77b5b886-944a-11d1-aebd-0000f80367c1;
systemOnly | FALSE;
systemFlags | 0x10 = ( FLAG_SCHEMA_BASE_OBJECT );
isMemberOfPartialAttributeSet | TRUE;
objectCategory | CN=Attribute-Schema,CN=Schema,CN=Configuration;

Single-valued and multivalued attributes

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

Note

A multivalued 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 multivalued attribute.

Indexed attributes

Indexing attributes helps to improve the performance of queries that are based on the indexed attribute. Both single-valued and multivalued attributes can be indexed; classes cannot be indexed. Attributes can be marked for indexing through their schema definition. Indexing an attribute also makes it possible for users to use wildcards (*) 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 multivalued attributes, can negatively affect replication and object creation time, as well as directory database size. Therefore, you should index only commonly used attributes.

For general information about schemas, see Active Directory Schema (http://go.microsoft.com/fwlink/?LinkId=80809).

Additional references

  • Working with Instances

  • Understanding AD LDS Instances

  • Understanding AD LDS Replication and Configuration Sets

  • Import Data into an AD LDS Instance


Understanding AD LDS Replication and Configuration Sets

Replication and configuration sets

Active Directory Lightweight Directory Services (AD LDS) uses replication to provide fault tolerance and load balancing for directory services. AD LDS uses a type of replication called multimaster replication. Through replication, AD LDS copies directory data updates that are made to a directory partition on one AD LDS instance to other AD LDS instances that hold copies of the same directory partition. AD LDS instances that hold copies of the same directory partition or partitions form a logical grouping called a configuration set.

Multimaster replication

Multimaster replication simply means that you can make changes to directory data on any AD LDS instance. AD LDS replicates these changes to other members of the configuration set automatically. Multimaster replication is characterized by loose data consistency with convergence. When you make changes to data on a given directory partition at one AD LDS instance, replicas of that directory partition that are stored on other AD LDS 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.

Configuration sets

AD LDS instances replicate data based on participation in a configuration set. All AD LDS instances that are joined to the same configuration set must replicate a common configuration directory partition and a common schema directory partition. AD LDS instances in a configuration set can also replicate any number of application directory partitions. AD LDS instances in a configuration set are not required to replicate all application directory partitions in the configuration set. A single AD LDS instance can replicate all—or any subset of—the application directory partitions in its configuration set. An AD LDS instance cannot, however, replicate an application directory partition from a different configuration set.

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

Two AD LDS configuration sets with two instances
Note

An AD LDS instance can be joined to a configuration set only during installation of the instance.

Preventing replication conflicts

What if two different users make changes to the same data on replicas of the same directory partition on two different AD LDS instances? In this case, each AD LDS instance attempts to replicate the changes, creating 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. AD LDS instances accept the change with the higher version and discard the other change. If the versions are identical, AD LDS instances accept the change with the more recent time stamp.

If two or more values in a multivalued attribute on an object are updated simultaneously on two different AD LDS instances, only one of the updated values will be replicated. In other words, simultaneous updates to a multivalued attribute that occur on two different AD LDS instances are considered to be in conflict, even if the updates apply to different values within the multivalued 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 within the linked-value attribute.

Replication topology

Knowledge Consistency Checker (KCC), a process that runs as part of each AD LDS instance, automatically constructs the most efficient topology for replication traffic to follow based on the network. The KCC regularly recalculates the replication topology to adjust for any network changes that occur in the environment.

Note

An AD LDS configuration set maintains its own replication topology, separate from any Active Directory Domain Services (AD DS) replication topology that might also exist. Directory partitions cannot be replicated between AD LDS instances and AD DS domain controllers.

Ensuring replication security

To ensure replication security, AD LDS authenticates replication partners before replication, and replication authentication always occurs over a secure channel. AD LDS uses 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 have successfully authenticated, all replication traffic between the two partners is encrypted.

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

Replication security level | Authentication mode | Description | Supported environments
Mutual authentication with Kerberos | 2 | Kerberos authentication, using service principal names (SPNs), is required. If Kerberos authentication fails, the AD LDS instances will not replicate. | The configuration set must be fully contained in an AD DS 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 AD LDS instances will not replicate. | The configuration set can contain Microsoft Windows NT® 4.0 member servers.
Negotiated pass-through | 0 | All AD LDS instances in the configuration set use an identical account name and password as the AD LDS 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 AD LDS replication security, the following best practices are recommended:

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

  • In AD DS environments, run AD LDS on member servers, rather than on domain controllers, whenever possible.

  • If you run AD LDS on a domain controller in an AD DS environment, do not use the Network Service account as the AD LDS 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 AD LDS service account.

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

For more information about AD LDS replication requirements for service accounts, see Service Account Selection.

Additional references

  • Working with Instances

  • Understanding AD LDS Instances

  • Understanding the AD LDS Schema

  • Working with Directory Partitions


Understanding AD LDS Instance Backup and Restore

Backing up and restoring AD LDS

Active Directory Lightweight Directory Services (AD LDS) data and log files should be backed up regularly to ensure the continued availability of data to applications and users in the event of a system failure.

Backing up AD LDS

By default, each instance of AD LDS running on an AD LDS 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 Windows Server Backup or any Windows Logo Program, third-party backup utility. For information about backing up an AD LDS instance, see Back Up AD LDS Instance Data.

Restoring AD LDS

When you restore a database to an existing AD LDS instance, you must stop the AD LDS instance before you run the restore operation. In addition, we recommend that you move (or delete) the existing database and log files from the AD LDS instance before 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 restore the data but before you restart the AD LDS instance. With dsdbutil, you can mark directory objects for authoritative restore. When an object is marked for authoritative restore, its update sequence number is changed so that the number is higher than any other update sequence number in the configuration set. This ensures that any data you restore is properly replicated throughout the configuration set.

For more information about restoring an AD LDS instance, including authoritative restores, see Restore AD LDS Instance Data.

If you restore an AD LDS backup over a running AD LDS instance, Windows Server Backup leaves the restored files in a pending state, and it does not write the files to disk until the computer is rebooted. In this situation, any directory changes that are made to the running AD LDS instance after Windows Server Backup is run are lost.

If you accidentally start a restore of an AD LDS instance over a currently running AD LDS instance, we recommend that you immediately restart the computer, stop the AD LDS instance, and then perform the restoration again.

Additional references

  • Working with Instances


Create a New AD LDS Instance

You use the Active Directory Lightweight Directory Services Setup Wizard to create Active Directory Lightweight Directory Services (AD LDS) service instances. In AD LDS, a "service instance" (or, simply, "instance") refers to a single running copy of the AD LDS directory service. Multiple instances of the AD LDS can run simultaneously on the same computer. (This is not true for Active Directory Domain Services (AD DS).) Each instance of the AD LDS directory service has a separate directory data store, a unique service name, and a unique service description that is assigned during installation. During AD LDS installation, you have the option of creating an application directory partition if your Lightweight Directory Access Protocol (LDAP) application does not create one for you.

Membership in the Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To use the Active Directory Lightweight Directory Services Setup Wizard to create a new AD LDS instance

  1. Click Start, point to Administrative Tools, and then click Active Directory Lightweight Directory Services Setup Wizard.

  2. On the Welcome to the Active Directory Lightweight Directory Services Setup Wizard page, click Next.

  3. On the Setup Options page, click A unique instance, and then click Next.

  4. Finish creating the new instance by following the wizard instructions.

Additional references

  • Working with Instances

  • Understanding AD LDS Instances

  • Understanding Directory Partitions


Create a Replica AD LDS Instance

You use the Active Directory Lightweight Directory Services Setup Wizard to create Active Directory Lightweight Directory Services (AD LDS) service instances. In AD LDS, a "service instance" (or, simply, "instance") refers to a single running copy of AD LDS. To provide fault tolerance and load balancing, AD LDS instances can be part of a configuration set. All AD LDS instances in a configuration set replicate a common configuration directory partition and a common schema directory partition, plus any number of application directory partitions.

To create an AD LDS instance and join it to an existing configuration set, use the Active Directory Lightweight Directory Services Set Wizard to create a replica AD LDS instance. You need to know the Domain Name System (DNS) name of the server running an AD LDS instance that belongs to the configuration set, as well as the Lightweight Directory Access Protocol (LDAP) port that was specified when the instance was created. You can also supply the distinguished names (also known as DNs) of specific application directory partitions that you want to copy from the configuration set to the AD LDS instance that you are creating.

Membership in the Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To create a replica AD LDS instance

  1. Click Start, point to Administrative Tools, and then click Active Directory Lightweight Directory Services Setup Wizard.

  2. On the Welcome to the Active Directory Lightweight Directory Services Setup Wizard page, click Next.

  3. On the Setup Options page, click A replica of an existing instance, and then click Next.

  4. Finish creating the new instance by following the wizard instructions.

Additional references

  • Working with Instances

  • Understanding AD LDS Instances

  • Understanding AD LDS Replication and Configuration Sets

  • Understanding Directory Partitions


Install an AD LDS Replica from Media

When you install an Active Directory Lightweight Directory Services (AD LDS) replica from media, you use a restored backup of an AD LDS instance as the data source, rather than another AD LDS instance.

Membership in the Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To install an AD LDS replica from media

  1. Restore a backup copy of the AD LDS instance from which you want to install to an alternate location. (Do not restore the backup to the original location of the AD LDS instance.)

  2. At a command prompt, type the following command, and then press ENTER:

    %windir%\adam\adaminstall /adv

  3. Follow the steps in the Active Directory Lightweight Directory Services Setup Wizard.

Additional considerations

  • To open a command prompt, click Start, right click Command Prompt, and then click Run as administrator.

  • You can install an AD LDS replica only from media that is created by restoring a backup copy of an AD LDS instance.

  • When you restore an AD LDS instance for use in a replica installation from media, you must restore the files to an alternate location, rather than to the original location from which they were backed up.

  • After you restore AD LDS files from a backup to an alternate location, the Adamntds.dit file and Edb*.log files will be nested in the specified alternate location. For example, if you specify C:\restore_dir as the restore location for the AD LDS files, Adamntds.dit and the Edb*.log files will be located at C:\restore_dir\Program Files\Microsoft ADAM\instancename\data, where instancename represents the AD LDS instance that was restored.

Additional references

  • Working with Instances

  • Back Up AD LDS Instance Data

  • Restore AD LDS Instance Data


Start, Stop, or Restart an AD LDS Instance

An Active Directory Lightweight Directory Services (AD LDS) instance runs as a service. Therefore, you can start, stop, and restart an AD LDS instance using the same methods as you use for other services running on Windows Server 2008.

Membership in the Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

Starting, stopping, or restarting an AD LDS instance

  • Using the graphical user interface

  • Using the command prompt

To start, stop, or restart an AD LDS instance using the graphical user interface

  1. Open Server Manager.

  2. In the console tree, double-click Roles, and then click Active Directory Lightweight Directory Services.

  3. In the details pane, in the System Services list, click the AD LDS instance that you want to manage.

  4. Click Start, Stop, or Restart.

Additional considerations

  • To open the Server Manager snap-in, click Start, click Administrative Tools, and then click Server Manager.

  • By default, an AD LDS instance is configured to start automatically.

To start or stop an AD LDS instance using a command prompt

  1. Open a command prompt.

  2. Do one of the following:

    • To start an AD LDS instance, at the command prompt, type the following command, and then press ENTER:

      net start instance_name

      where instance_name represents the AD LDS instance that you want to start.

    • To stop an AD LDS instance, at the command prompt, type the following command, and then press ENTER:

      net stop instance_name

      where instance_name represents the AD LDS instance that you want to stop.

Additional considerations

  • To open a command prompt, click Start, right-click Command Prompt, and then click Run as administrator.

  • You cannot pause or resume an AD LDS instance from a command prompt.

  • By default, an AD LDS instance is configured to start automatically.

  • For more information about the net command, type net /? at a command prompt or see Help and Support.

Additional references

  • Working with Instances

  • Understanding AD LDS Instances


Use ADSI Edit to Manage an AD LDS Instance

ADSI Edit is a Microsoft Management Console (MMC) snap-in for general administration of Active Directory Lightweight Directory Services (AD LDS). It is installed as part of the AD LDS server role. To use ADSI Edit to administer an AD LDS instance, you must first connect and bind to the instance. You can administer containers and objects in the instance by browsing to the containers or objects and then right-clicking them.

Membership in the Administrators group of the AD LDS instance is the minimum required to complete this procedure. By default, the security principal that you specify as the AD LDS administrator during AD LDS setup becomes a member of the Administrators group in the configuration partition. For more information about AD LDS groups, see Understanding AD LDS Users and Groups.

To connect and bind to an AD LDS instance using ADSI Edit

  1. Open ADSI Edit.

  2. In the console tree, click ADSI Edit.

  3. On the Action menu, click Connect to.

  4. In Select or type a domain or server: (Server | Domain[:port], type the Domain Name Service (DNS) name, NetBIOS name, or IP address of the computer on which the AD LDS instance is running, followed by a colon (:) and the Lightweight Directory Access Protocol (LDAP) communication port that the AD LDS instance to which you want to connect is using.

    Note

    If you have previously connected to the instance on this computer, the server and port might already be in the list.

  5. Under Connection point, do one of the following:

    • Click Select or type a distinguished name (DN) or naming context, and then specify the distinguished name to which you want to connect.

    • Click Select a well-known naming context, and then click Configuration, RootDSE, or Schema.

  6. To connect with an alternative account, click Advanced; click Specify Credentials; and then, under Connect using these credentials, type the domain, user name, and password of the account.

Additional considerations

  • To open ADSI Edit, on a computer with the AD LDS server role installed, click Start, click Administrative Tools, and then click ADSI Edit.

  • To create additional connections to AD LDS instances, on the Action menu, click Connect to for each new connection.

  • The default communication port for LDAP is 389.

  • To connect to an AD LDS instance running on the local computer, type localhost as the server name.

Additional references

  • Working with Instances

  • Understanding AD LDS Instances

  • Understanding the AD LDS Schema

  • Use Ldp.exe to Manage an AD LDS Instance


Use Ldp.exe to Manage an AD LDS Instance

Ldp.exe is a graphical user interface (GUI) tool for general administration of a Lightweight Directory Access Protocol (LDAP) directory service. To use Ldp.exe to administer an Active Directory Lightweight Directory Services (AD LDS) instance, you must connect and bind to the instance and then display the hierarchy (tree) of a distinguished name of the instance. You can then browse to an object in the tree and right-click the object to administer it.

Membership in the Administrators group of the AD LDS instance is the minimum required to complete this procedure. By default, the security principal that you specify as the AD LDS administrator during AD LDS setup becomes a member of the Administrators group in the configuration partition. For more information about AD LDS groups, see Understanding AD LDS Users and Groups

To view the contents of an AD LDS instance using Ldp.exe

  1. Open Ldp.

  2. On the Connection menu, click Connect.

  3. In Server, type the Domain Name System (DNS) name, NetBIOS name, or IP address of the computer on which the AD LDS instance is running.

  4. In Port, type the LDAP or Secure Sockets Layer (SSL) communication port number that the AD LDS instance to which you want to connect is using, and then click OK.

  5. On the Connection menu, click Bind.

  6. Do one of the following:

    • To bind using the credentials that you logged on with, click Bind as currently logged on user.

    • To bind using a domain user account, click Bind with credentials, type the user name, password, and domain name (or the computer name, if you are using a local workstation account) of the account that you are using, and then click OK.

    • To bind using just a user name and password, click Simple bind, type the user name and password of the account that you are using, and then click OK.

    • To bind using an advanced method (NTLM, Distributed Password Authentication (DPA), negotiate, or digest), click Advanced (method), click Advanced, in Method select the desired method, set other options as needed, and then click OK.

  7. When you are finished specifying the bind options, click OK.

  8. On the View menu, click Tree.

  9. In the BaseDN list, click the distinguished name of the object to use as the base object in the navigation pane.

Additional considerations

  • To open Ldp, click Start, point to Run, type ldp, and then click OK.

  • The default communication port for LDAP is 389. The default communication port for SSL is 636.

  • To connect to an AD LDS instance running on the local computer, type localhost as the server name.

Additional references

  • Working with Instances

  • Understanding AD LDS Instances

  • Understanding the AD LDS Schema

  • Use ADSI Edit to Manage an AD LDS Instance


Import Data into an AD LDS Instance

The ldifde utility creates, modifies, and deletes directory objects. You can use ldifde to populate Active Directory Lightweight Directory Services (AD LDS) with data from other directory services. You can also use ldifde to extend the schema and export user and group information to other applications or services. For example, you can use ldifde to export directory objects from another directory service and then use ldifde to import the directory objects into an AD LDS instance.

Membership in the Administrators group of the AD LDS instance is the minimum required to complete this procedure. By default, the security principal that you specify as the AD LDS administrator during AD LDS setup becomes a member of the Administrators group in the configuration partition. For more information about AD LDS groups, see Understanding AD LDS Users and Groups.

To import or export directory objects using ldifde

  1. Open a command prompt.

  2. Do one of the following:

    • To import directory objects, at the command prompt, type the following command, and then press ENTER:

      ldifde -i -f filename -s servername:port -m -a username domain password

    • To export directory objects, at the command prompt, type the following command, and then press ENTER:

      ldifde -e -f filename -s servername:port -m -a username domain password

Parameter Description

-i

Performs an import.

-e

Performs an export.

-f

Specifies the file to import or export.

filename

The name of the file to import or export.

-s

Specifies the host name and port of the AD LDS instance or other directory service.

servername

The host name of the AD LDS instance or other directory service.

port

The port for the AD LDS instance or other directory service.

-m

Ignores (that is, does not import or export) attributes that are used only by Active Directory Domain Services (AD DS).

You can use this parameter when you export directory objects from an existing AD DS forest and import them into AD LDS.

-a

Specifies account credentials. If they are not provided, ldifde uses the credentials of the currently logged on user.

username

The user name of the account to be used to bind to the specified directory service.

domain

The domain name of the account to be used to bind to the specified directory service.

password

The password of the account to be used to bind to the specified directory service.

-h

Allows the importing of passwords using simple authentication and security layer (SASL) encryption.

-c String1 String2

Replaces all occurrences of String1 with String2. With AD LDS, you can use the constants #schemaNamingContext and #configurationNamingContext in place of the distinguished names of the schema directory partition and configuration directory partition when you replace strings in .ldf files.

To view the complete syntax for this command, at a command prompt, type the following command, and then press ENTER:

Ldifde /?

Additional considerations

  • To open a command prompt, click Start, right-click Command Prompt, and then click Run as administrator.

Additional references

  • Working with Instances

  • Understanding AD LDS Instances

  • Understanding the AD LDS Schema

  • Ldifde


Back Up AD LDS Instance Data

Active Directory Lightweight Directory Services (AD LDS) instance data is stored in a set of files that is contained in a folder with the same name as the instance. By default, AD LDS database and log files are located in %ProgramFiles%\Microsoft ADAM\instancename where instancename equals the AD LDS instance name. You back up AD LDS instance data by backing up (copying) these files.

Important

Before you back up the AD LDS folder of an instance, use the Services snap-in to confirm that the instance is started. To start Services, click Start, click Administrative Tools, and then click Services. Because the instance service must be running when the files are backed up, you must use a backup utility (such as Windows Server Backup) that can back up open files.

Membership in the Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To back up an AD LDS instance using Windows Server Backup

  1. Click Start, point to Administrative Tools, and then click Backup.

  2. On the Action menu, click Backup once.

  3. In the Backup Once Wizard, click Different options, and then click Next.

  4. Click Custom, and then click Next.

  5. Select the volume that contains the AD LDS database and log files.

  6. Complete the wizard to begin the backup operation.
Caution

If you backed up data from an NTFS file system volume, it is recommended that you restore the data to an NTFS volume of the same version to prevent loss of data.

Additional references

  • Working with Instances

  • Understanding AD LDS Instance Backup and Restore

  • Start, Stop, or Restart an AD LDS Instance

  • Restore AD LDS Instance Data


Restore AD LDS Instance Data

The procedure that you follow to restore an Active Directory Lightweight Directory Services (AD LDS) instance depends on whether the instance already exists and whether it belongs to a configuration set.

  • Restoring AD LDS data on an existing AD LDS instance that belongs to a configuration set

  • Restoring a corrupted database that is preventing an existing AD LDS instance from starting

  • Restoring an AD LDS instance that does not belong to a configuration set

  • Restoring an AD LDS instance that belongs to a configuration set

Restoring AD LDS data on an existing AD LDS instance that belongs to a configuration set

Membership in the Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To authoritatively restore AD LDS data on an AD LDS instance that belongs to a configuration set

  1. If it is running, stop the AD LDS instance for which data will be restored.

  2. Open Backup.

  3. On the Action menu, click Recover.

  4. Follow the steps in the Recovery Wizard to specify the location of the source backup data and to identify the specific backup from which you want to recover instance data.

  5. In Click Select recovery type, click Files and folders, and then click Next.

  6. In Select items to recover, browse to and select the folder that contains the instance data files. By default, AD LDS database and log files are located in %ProgramFiles%\Microsoft ADAM\instancename, where instancename is the AD LDS instance name.

  7. In Specify recovery options, click Original locations and Overwrite existing files with recovered files, and then click Next.

  8. To complete the restore, click Finish.

  9. After the restore is complete, close Backup.

  10. Open a command prompt.

  11. At the command prompt, type the following command, and then press ENTER:

    dsdbutil

  12. At the dsdbutil: prompt, type the following command, and then press ENTER:

    activate instance instancename

    where instancename represents the service name of the AD LDS instance on which you want to restore data.

  13. At the dsdbutil: prompt, type the following command, and then press ENTER:

    authoritative restore

  14. At the authoritative restore: prompt, type one of the commands in the following table.

    Command Description

    restore database

    Performs authoritative restore of the entire directory database.

    restore object dn

    Performs authoritative restore of the directory object whose distinguished name is represented by dn.

    restore subtree dn

    Performs authoritative restore of the directory subtree whose distinguished name is represented by dn.

Additional considerations

  • To open Backup, click Start, click Administrative Tools, and then click Backup.

  • To open a command prompt, click Start, right-click Command Prompt, and then click Run as administrator.

  • Use the Services snap-in to stop an AD LDS instance.

  • You can use this procedure if you want the data being restored to authoritatively override existing data in the configuration set.

  • For more information about the authoritative restore command in dsdbutil, at the authoritative restore: prompt, type ?, and then press ENTER.

  • If you accidentally start a restore of an AD LDS instance over a currently running AD LDS instance, we recommend that you immediately restart the computer, stop the AD LDS instance, and then perform the restoration again.

Restoring a corrupted database that is preventing an existing AD LDS instance from starting

Membership in the Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To restore a corrupted database that is preventing the existing AD LDS instance from starting

  1. If it is running, stop the AD LDS instance for which data will be restored.

  2. Open Backup.

  3. On the Action menu, click Recover.

  4. Follow the wizard steps to specify the location of the source backup data and to identify the specific backup from which you want to recover instance data.

  5. In Select recovery type, click Files and folders, and then click Next.

  6. In Select items to recover, browse to and select the folder that contains the instance data files. By default, AD LDS database and log files are located in %ProgramFiles%\Microsoft ADAM\instancename, where instancename equals the AD LDS instance name.

  7. In Specify recovery options, click Original locations and Overwrite existing files with recovered files, and then click Next.

  8. To complete the restore, click Finish.

  9. After the restore is complete, close Backup.

  10. Restart the AD LDS instance.

Additional considerations

  • Use the Services snap-in to stop and start an AD LDS instance.

  • To open Backup, click Start, click Administrative Tools, and then click Backup.

  • If the AD LDS instance fails to start after you perform this procedure, perform the appropriate procedure for completely restoring an AD LDS instance, depending on whether your AD LDS instance belongs to a configuration set or is unique.

  • If you accidentally start a restore of an AD LDS instance over a currently running AD LDS instance, we recommend that you immediately restart the computer, stop the AD LDS instance, and then perform the restoration again.

Restoring an AD LDS instance that does not belong to a configuration set

Membership in the Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To completely restore an AD LDS instance that does not belong to a configuration set

  1. Using the Active Directory Lightweight Directory Services Setup Wizard, create an AD LDS instance, specifying the same settings that you used during your original AD LDS installation. However, do not create an application directory partition during setup.

  2. Stop the AD LDS instance that you just created, as follows:

    1. Click Start, click Administrative Tools, and then click Services.

    2. In Services, right-click the AD LDS instance, and then click Stop.

  3. Open Backup.

  4. On the Action menu, click Recover.

  5. Follow the steps in the Recovery Wizard to specify the location of the source backup data and identify the specific backup from which you want to recover instance data.

  6. In Select recovery type, click Files and folders, and then click Next.

  7. In Select items to recover, browse to and select the folder that contains the instance data files. By default, AD LDS database and log files are located in %ProgramFiles%\Microsoft ADAM\instancename, where instancename is the AD LDS instance name.

  8. In Specify recovery options, click Original locations and Overwrite existing files with recovered files, and then click Next.

  9. To complete the restore, click Finish.

  10. After the restore is complete, close Backup.

  11. Start the AD LDS instance that you just created, as follows:

    1. Click Start, click Administrative Tools, and then click Services.

    2. In Services, right-click the AD LDS instance, and then click Start.

Additional considerations

  • To open Backup, click Start, click Administrative Tools, and then click Backup.

  • If you accidentally start a restore of an AD LDS instance over a currently running AD LDS instance, we recommend that you immediately restart the computer, stop the AD LDS instance, and then perform the restoration again.

Restoring an AD LDS instance that belongs to a configuration set

Membership in the Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To completely restore an AD LDS instance that belongs to a configuration set

  1. On one of the remaining AD LDS instances in the configuration set, delete the server object representing the AD LDS instance that you want to restore, as follows:

    1. Open a command prompt.

    2. At the command prompt, type dsmgmt, and then press ENTER.

    3. At the dsmgmt: prompt, type metadata cleanup, and then press ENTER.

    4. At the metadata cleanup: prompt, type select operation target, and then press ENTER.

    5. At the select operation target: prompt, type connections, and then press ENTER.

    6. At the server connections: prompt, type the following command, and then press ENTER.

      connect to server computername:portnumber

      where computername:portnumber represents the AD LDS instance to which you are connecting.

    7. At the server connections: prompt, type q, and then press ENTER.

    8. At the select operation target: prompt, type list sites, and then press ENTER. Identify the number corresponding to the site in which the server object that you want to delete resides.

    9. At the select operation target: prompt, type select site n, and then press ENTER, where n represents the number identified in the previous step.

    10. At the select operation target: prompt, type list naming contexts, and then press ENTER. Identify the number that corresponds to a naming context previously held by the server whose server object you want to delete.

    11. Type select naming context n, and then press ENTER, where n represents the number identified in the previous step.

    12. Type list servers in site, and then press ENTER. Identify the number that is associated with the server whose server object you want to delete.

    13. Type select server n, and then press ENTER, where n represents the number identified in the previous step.

    14. At the select operation target: prompt, type q, and then press ENTER.

    15. At the metadata cleanup: prompt, type remove selected server, and then press ENTER. Click yes to confirm the deletion of the server object.

    16. In addition, you must delete the server object from the sites container:

      CN=Servers,CN=sitename,CN=Sites,CN=Configuration,CN={GUID}

      where sitename represents the name of the site in which the server object exists, and GUID represents the globally unique identifier (GUID) of the AD LDS instance.

  2. Open Backup.

  3. On the Action menu, click Recover.

  4. Follow the steps in the Recovery Wizard to specify the location of the source backup data and identify the specific backup from which you want to recover instance data.

  5. In Select recovery type, click Files and folders, and then click Next.

  6. In Select items to recover, browse to and select the folder containing the instance data files. By default, AD LDS database and log files are located in %ProgramFiles%\Microsoft ADAM\instancename where instancename is the AD LDS instance name.

  7. In Specify recovery options, click Alternate location, specify a temporary location for the recovered files, and then click Next.

  8. To complete the restore, click Finish.

  9. At a command prompt, type the following command, and then press ENTER:

    %windir%\adam\adaminstall /adv

  10. Follow the steps in the Active Directory Lightweight Directory Services Setup Wizard.

Additional considerations

  • To open Backup, click Start, click Administrative Tools, and then click Backup.

  • To open a command prompt, click Start, right-click Command Prompt, and then click Run as administrator.

  • For help with dsmgmt, at a dsmgmt prompt, type ?, and then press ENTER.

  • If you accidentally start a restore of an AD LDS instance over a currently running AD LDS instance, we recommend that you immediately restart the computer, stop the AD LDS instance, and then perform the restoration again.

Additional references

  • Working with Instances

  • Understanding AD LDS Instance Backup and Restore

  • Back Up AD LDS Instance Data

  • Start, Stop, or Restart an AD LDS Instance


Working with Directory Partitions

The Active Directory Lightweight Directory Services (AD LDS) directory store is organized into logical directory partitions, or naming contexts. Three different types of directory partitions exist: configuration, schema, and application. Each AD LDS directory store must contain a single configuration directory partition and a single schema directory partition, and it can contain zero or more application directory partitions. An application directory partition holds the data that your application uses. You can create an application directory partition when you create a new AD LDS instance or anytime afterward.

  • Understanding Directory Partitions

  • Administering Directory Partitions

  • Create an Application Directory Partition

Additional references

  • Active Directory Lightweight Directory Services


Understanding Directory Partitions

Active Directory Lightweight Directory Services (AD LDS) stores directory data in a hierarchical, file-based directory store. By default, the directory store for a given AD LDS instance is located in the following file:

%ProgramFiles%\Microsoft ADAM\instancename\data\adamntds.dit

Each AD LDS instance has a separate directory store. Any data operation that you perform in AD LDS, including searches, reads, imports, exports, indexing, replication, backups, and restores, uses the AD LDS directory store in some way. The directory store is organized into logical directory partitions, also called naming contexts.

Note

Like Active Directory Domain Services (AD DS), AD LDS uses the Extensible Storage Engine (ESE) to manage its directory store.

Directory partitions

The AD LDS directory store is organized into logical directory partitions. There are three different types of directory partitions: configuration, schema, and application. Each AD LDS directory store must contain a single configuration directory partition and a single schema directory partition, and it can contain zero or more application directory partitions. The following table summarizes these partition types, their contents, and AD LDS requirements.

Partition type | Distinguished name | Required/optional | Contents
Configuration | CN=Configuration,CN={GUID} | Required | AD LDS configuration information
Schema | CN=Schema,CN=Configuration,CN={GUID} | Required | Class and attribute definitions
Application | Assigned during partition creation | Optional | Application data

Configuration directory partition

The configuration directory partition holds information about AD LDS 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.

Schema directory partition

The schema directory partition holds the definitions for the type of data that can be held by the directory store. The AD LDS directory service relies on the definitions in the schema partition for maintaining data consistency. In addition, applications can refer to the schema partition to determine the type of data that the AD LDS instance allows. You can extend the schema to allow AD LDS to hold data that is specific to a particular application. For more information about AD LDS schemas, see Understanding the AD LDS Schema.

Note

A common configuration partition and a common schema partition are replicated to AD LDS service instances that belong to the same configuration set. For more information about replication, see Understanding AD LDS Replication and Configuration Sets.

Application directory partitions

Application directory partitions hold the data that is used by your applications. You can create an application partition during AD LDS 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, AD LDS holds the application partition reference objects in CN=Partitions,CN=Configuration.

Additional references

  • Working with Directory Partitions

  • Administering Directory Partitions

  • Create an Application Directory Partition


Administering Directory Partitions

Administering directory partitions

There are three types of directory partitions in Active Directory Lightweight Directory Services (AD LDS): configuration, schema, and application. Configuration and schema directory partitions are created automatically during installation. Application directory partitions can be created either during or after installation. Every AD LDS directory partition has a unique distinguished name. Distinguished names for directory partitions in AD LDS support both Domain Naming System (DNS)–style and X.500-style naming. An AD LDS instance does not specify a naming context by default, but it can be configured to provide a default naming context to clients. You can view and manage AD LDS configuration and schema directory partitions using AD LDS administration tools, which are installed during AD LDS setup. Application directory partitions are typically managed through directory-enabled applications.

Creating directory partitions

The schema and configuration directory partitions are created automatically during installation of an AD LDS instance. (In fact, the schema and configuration directory partitions can be created only during AD LDS installation.) If you choose to join the AD LDS instance being installed to an existing configuration set, the schema and configuration directory partitions from an AD LDS instance in the configuration set are replicated to the new instance. If you install a new AD LDS instance, the installation process creates default versions of the schema and configuration directory partitions for you. If you install an AD LDS instance from media, the schema and configuration directory partitions for the new AD LDS instance are replicas of the directory partitions from the media.

When you install a new AD LDS instance, you can also choose to replicate one or more application directory partitions from an existing AD LDS instance. Or, you can choose to create a new application partition. When you create a new application directory partition during installation, you must specify a unique distinguished name for the partition. The new application directory partition consists only of a partition container object with the distinguished name that you specify.

Naming directory partitions

Each AD LDS directory partition has its own, unique distinguished name. AD LDS supports both DNS-style and X.500-style names for top-level directory partitions, including the distinguished name attributes that are listed in the following table.

Distinguished name attribute | Meaning
C= | Country/region
CN= | Common name
DC= | Domain component
L= | Location
O= | Organization
OU= | Organizational unit

Specifying a default naming context

By default, an AD LDS instance does not provide a default naming context. You can, however, configure AD LDS to provide a default naming context by specifying a value for the msDS-defaultNamingContext attribute on the NTDSA object.

By default, this msDS-defaultNamingContext attribute contains no value. If a value is set in the attribute, that value is returned to a client through the defaultNamingContext attribute of the rootDse object when the rootDSE object is read.

When a bind is requested on the rootDSE object, AD LDS returns the value of defaultNamingContext if the msDS-defaultNamingContext attribute on the NTDSA object is set to the distinguished name of a top-level container of an instantiated naming context. Otherwise, no value is returned.

Importing and exporting directory objects

You can use a number of methods to import and export directory objects, both to and from the schema directory partition as well as to and from application directory partitions. You can use the ldifde command-line tool to import and export .ldf files. You can use the csvde command-line tool to import and export .csv (comma-delimited) files.

Administering application directory partitions

You can create an application directory partition during setup. You can also create application directory partitions anytime after installation, either through AD LDS administration tools or through your directory-enabled application. In production environments, you typically manage your application directory partitions and the data that they contain through your directory-enabled applications.

For information about creating application directory partitions, see Create an Application Directory Partition.

Additional references

  • Working with Directory Partitions

  • Understanding Directory Partitions

  • Create an Application Directory Partition


Create an Application Directory Partition

You use Ldp.exe to add a new application directory partition to an existing instance of Active Directory Lightweight Directory Services (AD LDS).

Membership in the Administrators group of the AD LDS instance is the minimum required to complete this procedure. By default, the security principal that you specify as the AD LDS administrator during AD LDS setup becomes a member of the Administrators group in the configuration partition. For more information about AD LDS groups, see Understanding AD LDS Users and Groups.

To add an application directory partition to an existing AD LDS instance

  1. Open LDP, and then connect and bind to an AD LDS instance. For more information, see use Use Ldp.exe to Manage an AD LDS Instance.

  2. On the Browse menu, click Add child.

  3. In Dn, type a distinguished name for the application partition.

  4. Under Edit entry, type ObjectClass in the Attribute box and container in the Values box, and then click Enter.

  5. Under Edit entry, type instanceType in the Attribute box and 5 in the Values box, and then click Enter.

  6. Click Run.

    After the new application directory partition is added, the following information appears in the details pane:

    Added {distinguished name}

    where distinguished name is the distinguished name that you typed in step 3.

  7. Click Close.

Additional considerations

  • To open Ldp, click Start, point to Run, type ldp, and then click OK.

  • Application directory partitions can be of any object class, but they must have a value of 5 for the instanceType attribute.

Additional references

  • Working with Directory Partitions

  • Understanding Directory Partitions

  • Use Ldp.exe to Manage an AD LDS Instance

  • Ldp


Working with Authentication and Access Control

Access control in Active Directory Lightweight Directory Services (AD LDS) consists of two parts. First, AD LDS authenticates the identity of users requesting access to the directory, allowing only successfully authenticated users into the directory. Second, AD LDS uses security descriptors, called access control lists (ACLs), on directory objects to determine to which objects an authenticated user has access.

Users, or security principals, request directory data from AD LDS through directory-enabled applications, which in turn make requests to AD LDS using Lightweight Directory Access Protocol (LDAP). Before making a request for data, the directory-enabled application must present the user's credentials to AD LDS for authentication, or binding. This request includes a user name, password, and—depending on the type of bind—a domain name or computer name.

AD LDS can accept authentication, or bind, requests from both AD LDS security principals and Windows (local and domain) security principals. AD LDS security principals are authenticated directly by AD LDS. Local Windows security principals are authenticated by the local computer. Domain security principals must be authenticated by an Active Directory Domain Services (AD DS) domain controller.

  • Understanding AD LDS Users and Groups

  • Import the User Classes That Are Supplied with AD LDS

  • Synchronize with Active Directory Domain Services

  • Add an AD LDS User to the Directory

  • Add an AD LDS Group to the Directory

  • Add or Remove Members to or from an AD LDS Group

  • View or Set Permissions on a Directory Object

  • Disable or Enable an AD LDS User

  • Set or Modify the Password of an AD LDS User

  • Add an Organizational Unit to the Directory

Additional references

  • Active Directory Lightweight Directory Services


Understanding AD LDS Users and Groups

Active Directory Lightweight Directory Services (AD LDS) relies on users and groups to provide and control access to directory data. AD LDS supports the simultaneous use of both Windows users and AD LDS users. AD LDS provides four default, role-based groups. You can create additional AD LDS groups as necessary. Both Windows users and AD LDS users can be members of AD LDS groups. To create AD LDS users in AD LDS, you must first import the user object class definitions that are provided with AD LDS, or you can supply your own user object definitions.

Default groups

AD LDS provides four default, role-based groups: Administrators, Instances, Readers, and Users. These groups reside in the configuration partition and in each application partition, but not in the schema partition. Within a configuration set, AD LDS replicates these groups, along with all other directory data.

The following three groups reside in the CN=Roles container of each directory partition:

  • Administrators (CN=Administrators,CN=Roles)

  • Readers (CN=Readers,CN=Roles)

  • Users (CN=Users,CN=Roles)

The following group resides only in the CN=Roles container of the configuration directory partition:

  • Instances (CN=Instances,CN=Roles)

The following table lists the default AD LDS groups, along with the default members and default access assigned to each group.

Group | Default members | Default access
Administrators (CN=Administrators,CN=Roles) | Configuration partition: AD LDS administrators that are assigned during AD LDS setup Application partitions: The Administrators group from the configuration partition | Full access to all partitions
Instances (CN=Instances,CN=Roles) | All instances |
Readers (CN=Readers,CN=Roles) | None | Read access to the partition
Users (CN=Users,CN=Roles) | Configuration partition: Transitively, all AD LDS users Application partitions: Transitively, all AD LDS users that are created in the partition | None

Groups from the configuration partition can be assigned permissions in any partition of an AD LDS instance or configuration set. Groups from an application partition can be assigned permissions only in that application partition. Windows security principals can be assigned permissions in any application partition.

Security principals

The term "security principal" refers to any object that has a security identifier (SID) and that can be assigned permissions to directory objects. In AD LDS, security principals can reside in AD LDS, on a local computer, or in an Active Directory Domain Services (AD DS) domain.

Note

You can retrieve an active user's individual and group SIDs by explicitly querying the tokenGroups attribute on the rootDSE.

AD LDS security principals

AD LDS does not include any default security principals. However, AD LDS does provide importable schema extensions that you can use to create users in AD LDS. Users that are created from these user classes can be used as security principals. In addition, you can make any object class in the AD LDS schema a security principal by adding the msDS-bindableobject auxiliary class and the unicodePwd attribute to the schema definition of an object class. Each AD LDS security principal must be assigned an account and password, which AD LDS uses for authentication.

Windows security principals

AD LDS allows the use of Windows security principals for authentication and access control. Local Windows users and groups, as well as domain users and groups, can be used with AD LDS. In addition, you can add Windows security principals membership to AD LDS groups as members. By default, the security principal that you specify as the AD LDS administrator during AD LDS setup becomes a member of the Administrators group in the configuration partition. For Windows security principals, AD LDS relies on the Local Security Authority (LSA) on the local computer (for local accounts) or the LSA on a domain controller (for domain accounts) for authentication.

Additional references

  • Working with Authentication and Access Control

  • Add an AD LDS User to the Directory

  • Add an AD LDS Group to the Directory

  • Add or Remove Members to or from an AD LDS Group

  • Disable or Enable an AD LDS User


Import the User Classes That Are Supplied with AD LDS

To create users in Active Directory Lightweight Directory Services (AD LDS), you must first import the optional user classes that are supplied with AD LDS into the AD LDS schema. These user classes are provided in importable .ldf files, which you can find in the directory %windir%\adam on the computer where AD LDS is installed.

Membership in the Administrators group of the AD LDS instance is the minimum required to complete this procedure. By default, the security principal that you specify as the AD LDS administrator during AD LDS setup becomes a member of the Administrators group in the configuration partition. For more information about AD LDS groups, see Understanding AD LDS Users and Groups.

To import the user classes that are supplied with AD LDS

  1. Open a command prompt.

  2. At the command prompt, type the following command, and then press ENTER:

    ldifde -i -f %windir%\adam\ filename -s computername:port [-b username domain password] -k -j . -c "CN=Schema,CN=Configuration,DC=X" #schemaNamingContext

    where filename represents the name of one of the .ldf files that is supplied with AD LDS, computername:port represents the computer name and port number of an AD LDS instance, and username domain password represents the account with which to run the command.

    When you run this command, you should see results similar to the following:

    Connecting to "localhost"
Logging in as current user using SSPI
Importing directory from file "ms-user.ldf"
Loading entries................................
65 entries modified successfully.

The command has completed successfully

Parameter | Description
-i | Performs an import.
-f | Specifies the file to import or export.
-s | Specifies the host name and port of the AD LDS instance.
-b | Specifies the security credentials to use during the operation.
-k | Continues the operation in the event of errors.
-j | Creates a log file in the specified directory, in this case, the current (".") directory.
-c "CN=Schema,CN=Configuration,DC=X" #schemaNamingContext | Do not modify this string. The -c parameter replaces a specified string in the .ldf file with a different string during import. The distinguished name that is specified in the .ldf file (for example, CN=Schema,CN=Configuration,DC=X) is replaced with the distinguished name of the schema directory partition for your particular AD LDS instance, as passed by the #schemaNamingContext constant.

To view the complete syntax for this command, and for information about entering user account information, at a command prompt, type the following command, and then press ENTER:

ldifde /?

Additional considerations

  • To open a command prompt, click Start, right-click Command Prompt, and then click Run as administrator.

  • AD LDS includes the following .ldf files containing user classes that you can import. These files are located in the %windir%\adam directory.

    .ldf file User classes Import this file if ...

    MS-ADAM-DisplaySpecifiers-0409.LDF
    • Not applicable

    You want to use an Active Directory snap-in (such as Active Directory Sites and Services) with AD LDS.

    MS-AdamSyncMetadata.LDF
    • Not applicable

    You want to use adamsync to synchronize AD LDS with Active Directory Domain Services (AD DS).

    MS-AZMan.LDF
    • Not applicable

    You want to use Windows Authorization Manager with AD LDS.

    MS-InetOrgPerson.LDF
    • Person

    • Organizational-Person

    • User

    • inetOrgPerson

    You want to create user objects in the AD LDS directory, and you want to create users of the InetOrgPerson class (as defined in RFC 2798). MS-InetOrgPerson.LDF is a sample file that you can modify to meet your particular requirements.

    MS-User.LDF
    • Person

    • Organizational-Person

    • User

    You want to create user objects in the AD LDS directory, but you do not want to create users of the InetOrgPerson class (as defined in RFC 2798). MS-User.LDF is a sample file that you can modify to meet your particular requirements.

    MS-UserProxy.LDF
    • User-Proxy

    You want to create simple proxy objects in AD LDS for use in bind redirection. MS-UserProxy.LDF is a sample file that you can modify to meet your particular requirements.

    MS-UserProxyFull.LDF
    • User-Proxy-Full

    You want to create complete proxy objects in AD LDS for use in bind redirection. To use this file, you must also import MS-InetOrgPerson.LDF or MS-User.LDF. MS-UserProxyFull.LDF is a sample file that you can modify to meet your particular requirements.
  • As an alternative to using ldifde, you can import the optional AD LDS user classes during AD LDS setup.

  • If you do not specify user credentials using the -b parameter, ldifde uses the credentials of the currently logged on user.

Additional references

  • Working with Authentication and Access Control

  • Import LDIF Files

  • Ldifde


Synchronize with Active Directory Domain Services

Synchronizing data from an Active Directory Domain Services (AD DS) forest to the configuration set of an Active Directory Lightweight Directory Services (AD LDS) instance requires two steps:

  1. Prepare the AD LDS instance for synchronization.

  2. Synchronize the data.

Typically, you perform the first step only once. You perform the second step whenever you want to update the AD LDS instance.

Membership in the Administrators group of the AD LDS instance is the minimum required to complete this procedure. By default, the security principal that you specify as the AD LDS administrator during AD LDS setup becomes a member of the Administrators group in the configuration partition. For more information about AD LDS groups, see Understanding AD LDS Users and Groups.

Preparing an AD LDS instance for synchronization

To prepare an AD LDS instance for synchronization

  1. Open a command prompt.

  2. At the command prompt, type the following command, and then press ENTER:

    cd %windir%\adam

  3. Do one of the following:

    • To prepare to synchronize an AD LDS instance with a Windows Server 2003 forest, type the following command, and then press ENTER:

      ldifde -i -u -f ms-adamschemaw2k3.ldf -s server:port -b user_name domain password -j . -c "cn=Configuration,dc=X" #configurationNamingContext

    • To prepare to synchronize an AD LDS instance with a Windows Server 2008 forest, type the following command, and then press ENTER:

      ldifde -i -u -f ms-adamschemaw2k8.ldf -s server:port -b user_name domain password -j . -c "cn=Configuration,dc=X" #configurationNamingContext

    Important

    You must include the period (.) between -j and -c.

  4. Type the following command, and then press ENTER:

    ldifde -i -s server:port -c CN=Configuration,DC=X #ConfigurationNamingContext -f MS-AdamSyncMetadata.ldf

  5. Type the following command, and then press ENTER:

    notepad MS-AdamSyncConf.xml

  6. In Notepad, make the following changes to the contents of the configuration file:

    • Replace the value of <source-ad-name> with the name of the source AD DS domain controller.

    • Replace the value of <source-ad-partition> with the distinguished name of the source domain.

    • Replace the value of <source-ad-account> with the name of an account in the Domain Admins group of the source domain.

    • Replace the value of <account-domain> with the fully qualified Domain Name System (DNS) name of the source domain.

    • Replace the value of <target-dn> with the name of the partition of the target AD LDS instance.

    • Replace the value of <base-dn> with the base distinguished name of the source domain.

  7. In Notepad, on the File menu, click Save As, type a new name for the file, click Save, and then close Notepad.

  8. At the command prompt, type the following command, substituting the file name that was used in the previous step for xml_file, and then press ENTER:

    adamsync /install server:port .xml_file

After you prepare the AD LDS instance for synchronization, you can perform the following procedure as needed to synchronize data from the specified AD DS forest to the AD LDS instance.

Synchronizing AD DS forest data to an AD LDS instance

To synchronize AD DS forest data to an AD LDS instance

  • At a command prompt, type the following command, and then press ENTER:

    adamsync /sync server:port configuration_dn /log

Additional considerations

  • To open a command prompt, click Start, right-click Command Prompt, and then click Run as administrator.

  • The following table contains the parameters for the preceding procedures and other commonly used adamsync parameters. For more information about adamsync parameters, at a command prompt, type adamsync /?, and then press ENTER.

    Parameter Description

    /?

    Displays command-line options.

    /i or /install input_file

    Installs the configuration that is contained in the specified input file.

    /sync configuration_dn

    Synchronizes the specified configuration.

    /fs configuration_dn

    Performs a full replication synchronization for the specified configuration.

    /ageall configuration_dn

    Performs an aging search for the specified configuration. An aging search determines—by searching for the AD LDS objects in AD DS—if the AD LDS objects in a configuration have been deleted in AD DS.

    /so configuration_dn object_dn

    Performs a replication synchronization for the specified object in the specified configuration. Use the distinguished name of the object.
  • You must have Read or Dirsync access to the objects or partitions in the AD DS forest that you want to synchronize.

  • You must have full control of an application directory partition on an AD LDS instance to run this command.

Additional references

  • Working with Authentication and Access Control

  • Understanding AD LDS Users and Groups

  • Import the User Classes That Are Supplied with AD LDS

  • Adamsync


Add an AD LDS User to the Directory

You can administer users and groups in Active Directory Lightweight Directory Services (AD LDS) through the ADSI Edit snap-in or through your directory-enabled applications. For information about users and groups in AD LDS, see Understanding AD LDS Users and Groups.

To create users in AD LDS, you must first import the optional user classes that are provided with AD LDS into the AD LDS schema. These user classes are provided in importable .ldf files, which you can find in the directory %windir%\adam on the computer where AD LDS is installed.

Membership in the Administrators group of the AD LDS instance is the minimum required to complete this procedure. By default, the security principal that you specify as the AD LDS administrator during AD LDS setup becomes a member of the Administrators group in the configuration partition. For more information about AD LDS groups, see Understanding AD LDS Users and Groups.

To add an AD LDS user to the directory

  1. Open ADSI Edit.

  2. Connect and bind to the AD LDS instance and directory partition to which you want to add a user. For more information, see Use ADSI Edit to Manage an AD LDS Instance.

  3. In the console tree, double-click the directory partition to which you want to add the user.

  4. In the console tree, right-click the container to which you want to add the user, point to New, and then click Object.

  5. In Select a class, click the class that you want to use (user, inetOrgPerson, person, or OrganizationalPerson), and then click Next.

  6. In Value, type a value for the common name (CN) attribute of the new user, and then click Next.

  7. If you want to set values for additional attributes, click More attributes.

  8. After setting any additional attributes for the new user, click Finish.

Additional considerations

  • To open ADSI Edit, on a computer with the AD LDS server role installed, click Start, click Administrative Tools, and then click ADSI Edit.

  • By default, an AD LDS user account is enabled when the user account is created. However, no initial password is set on an AD LDS user account that is created with ADSI Edit. On AD LDS instances running on Windows Server 2008, where local or domain password policy restrictions are in effect, the AD LDS user account is disabled by default. Before you can enable the user account, you must set a password for it that meets the password policy restrictions that are in effect.

  • Any object class can be used as a security principal in AD LDS, if the object class definition contains the SecurityPrincipal static auxiliary class and the unicodePwd attribute.

  • The user, inetOrgPerson, and OrganizationalPerson object classes are not available until you import the AD LDS user class definitions into the schema.

Additional references

  • Working with Authentication and Access Control

  • Use ADSI Edit to Manage an AD LDS Instance

  • Understanding AD LDS Users and Groups

  • Import the User Classes That Are Supplied with AD LDS

  • Set or Modify the Password of an AD LDS User


Add an AD LDS Group to the Directory

You can administer users and groups in Active Directory Lightweight Directory Services (AD LDS) through the ADSI Edit snap-in or through your directory-enabled applications. For information about users and groups in AD LDS, see Understanding AD LDS Users and Groups.

To create users in AD LDS, you must first import the optional user classes that are provided with AD LDS into the AD LDS schema. These user classes are provided in importable .ldf files, which you can find in the directory %windir%\adam on the computer where AD LDS is installed.

Membership in the Administrators group of the AD LDS instance is the minimum required to complete this procedure. By default, the security principal that you specify as the AD LDS administrator during AD LDS setup becomes a member of the Administrators group in the configuration partition. For more information about AD LDS groups, see Understanding AD LDS Users and Groups.

To add an AD LDS group to the directory

  1. Open ADSI Edit.

  2. Connect and bind to the AD LDS instance to which you want to add a group. For more information, see Use ADSI Edit to Manage an AD LDS Instance.

  3. In the console tree, double-click the directory partition to which you want to add the group.

  4. In the console tree, right-click the container to which you want to add the group, point to New, and then click Object.

  5. In Select a class, click Group, and then click Next.

  6. In Value, type a common name (CN) for the new group, and then click Next.

  7. If you want to set values for additional attributes, click More attributes.

  8. After setting all the desired attributes for the new group, click Finish.

Additional considerations

  • To open ADSI Edit, on a computer with the AD LDS server role installed, click Start, click Administrative Tools, and then click ADSI Edit.

  • When you type a value for the groupType attribute, 2147483650 (equivalent to 0x80000002 hexidecimal) represents a group type of "account."

Additional references

  • Working with Authentication and Access Control

  • Use ADSI Edit to Manage an AD LDS Instance

  • Understanding AD LDS Users and Groups

  • Import the User Classes That Are Supplied with AD LDS


Add or Remove Members to or from an AD LDS Group

Active Directory Lightweight Directory Services (AD LDS) relies on users and groups to provide and control access to directory data. AD LDS supports the simultaneous use of both Windows users and AD LDS users. AD LDS provides four default, role-based groups. You can create additional AD LDS groups as necessary. Both Windows users and AD LDS users can be members of AD LDS groups. To create AD LDS users in AD LDS, you must first import the user object class definitions that are provided with AD LDS, or you can supply your own user object class definitions.

AD LDS provides four default, role-based groups: Administrators, Instances, Readers, and Users. These groups reside in the configuration partition and in each application partition, but not in the schema partition. Within a configuration set, AD LDS replicates these groups, along with all other directory data.

Membership in the Administrators group of the AD LDS instance is the minimum required to complete this procedure. By default, the security principal that you specify as the AD LDS administrator during AD LDS setup becomes a member of the Administrators group in the configuration partition. For more information about AD LDS groups, see Understanding AD LDS Users and Groups.

To add or remove members to or from an AD LDS group

  1. Open ADSI Edit.

  2. Connect and bind to the AD LDS instance containing the group that you want to modify. For more information, see Use ADSI Edit to Manage an AD LDS Instance.

  3. In the console tree, double-click the directory partition containing the group that you want to modify.

  4. Right-click the group that you want to modify, and then click Properties.

  5. In Attributes, click Member, and then click Edit.

  6. For each AD LDS security principal that you want to add to the group, click Add DN, type the distinguished name of the new member, and then click OK.

  7. For each Windows security principal that you want to add to the group, click Add Windows account, type the account name of the new member, and then click OK.

  8. For each group member that you want to remove from the group, click the member that you want to remove, and then click Remove.

  9. After making the changes that you want to the group, click OK twice.
Note

In AD LDS it is possible for an AD LDS administrator, or for a user with sufficient access to the Administrators group, to remove member accounts from the AD LDS Administrators group, possibly leaving AD LDS without any valid administrators. To recover from this scenario, the assigned AD LDS administrator, as the owner of the Administrators group, can repopulate the AD LDS Administrators group with the appropriate accounts.

Additional considerations

  • To open ADSI Edit, on a computer with the AD LDS server role installed, click Start, click Administrative Tools, and then click ADSI Edit.

Additional references

  • Working with Authentication and Access Control

  • Use ADSI Edit to Manage an AD LDS Instance

  • Understanding AD LDS Users and Groups

  • Import the User Classes That Are Supplied with AD LDS


View or Set Permissions on a Directory Object

You can govern access control in Active Directory Lightweight Directory Services (AD LDS) at the directory partition level by assigning user memberships to the role-based groups that are located on each partition. You can also customize access control in AD LDS on an object-by-object basis using the dsacls command-line tool.

Membership in the Administrators group of the AD LDS instance is the minimum required to complete this procedure. By default, the security principal that you specify as the AD LDS administrator during AD LDS setup becomes a member of the Administrators group in the configuration partition. For more information about AD LDS groups, see Understanding AD LDS Users and Groups.

To view or set permissions on a directory object

  1. Open a command prompt.

  2. At the command prompt, do one of the following:

    • To list the effective permissions on a directory object, type the following command, and then press ENTER:

      dsacls \\ hostname : portnumber \ object_dn

      Parameter Description

      hostname

      The name of the computer on which the AD LDS instance that holds the directory object is running.

      portnumber

      The communications port number on which the AD LDS instance communicates.

      object_dn

      The distinguished name of the directory object.
      Example:

      dsacls \\localhost:389\O=Microsoft,C=US

    • To grant permissions on a directory object, type the following command, and then press ENTER:

      dsacls \\ hostname : portnumber \ object_dn /G user_or_group:Permissions

      Parameter Description

      hostname

      The name of the computer on which the AD LDS instance that holds the directory object is running.

      portnumber

      The communications port number on which the AD LDS instance communicates.

      object_dn

      The distinguished name of the directory object.

      user_or_group

      The user or group for whom the permissions apply.

      Permissions

      The permissions to grant.
      Example:

      dsacls "\\localhost:389\cn=Object1, cn=container1,O=Microsoft,C=US" /G "CN=inetuser1,O=Microsoft,C=US":SD

    • To deny permissions on a directory object, type the following command, and then press ENTER:

      dsacls \\ hostname : portnumber \ object_dn /D user_or_group:PermissionStatement

      Parameter Description

      hostname

      The name of the computer on which the AD LDS instance that holds the directory object is running.

      portnumber

      The communications port number on which the AD LDS instance communicates.

      object_dn

      The distinguished name of the directory object.

      user_or_group

      The user or group for whom the permissions apply.

      PermissionStatement

      The permissions to deny.
      Example:

      dsacls "\\localhost:389\cn=Object1, cn=container1,O=Microsoft,C=US" /D "CN=inetuser1,O=Microsoft,C=US":SD

Additional considerations

  • To open a command prompt, click Start, right-click Command Prompt, and then click Run as administrator.

  • For a complete description of all the parameters that apply to dsacls, including the setting of inheritance, type dsacls /? at the command prompt.

  • A directory object that resides on multiple replicas of a given directory partition possesses the same permissions on all the replica partitions.

Additional references

  • Working with Authentication and Access Control

  • Understanding AD LDS Users and Groups


Disable or Enable an AD LDS User

When you disable and enable an Active Directory Lightweight Directory Services (AD LDS) user, you control whether that user can bind to the AD LDS directory. You use the ADSI Edit snap-in to disable and enable AD LDS users.

Membership in the Administrators group of the AD LDS instance is the minimum required to complete this procedure. By default, the security principal that you specify as the AD LDS administrator during AD LDS setup becomes a member of the Administrators group in the configuration partition. For more information about AD LDS groups, see Understanding AD LDS Users and Groups.

To disable or enable an AD LDS user

  1. Open ADSI Edit.

  2. Connect and bind to an AD LDS instance. For more information, see Use ADSI Edit to Manage an AD LDS Instance.

  3. Browse to the AD LDS user that you want to disable or enable, right-click that user, and then click Properties.

  4. In Attributes, click msDS-UserAccountDisabled, and then click Edit.

  5. Do one of the following, and then click OK:

    • To disable the AD LDS user, click True.

    • To enable the AD LDS user, click either False or Not set.

Additional considerations

  • To open ADSI Edit, on a computer with the AD LDS server role installed, click Start, click Administrative Tools, and then click ADSI Edit.

  • By default, an AD LDS user is enabled when the user is created. However, if you assign a new AD LDS user a password that does not meet the password policy restrictions in effect on the local server or domain, that AD LDS user will be disabled by default.

  • If the AD LDS user that you want to enable or disable is currently logged on to the AD LDS instance, that user must log off for the new setting to take effect.

Additional references

  • Working with Authentication and Access Control

  • Use ADSI Edit to Manage an AD LDS Instance

  • Understanding AD LDS Users and Groups


Set or Modify the Password of an AD LDS User

You can set and modify passwords for Active Directory Lightweight Directory Services (AD LDS) security principals over Secure Sockets Layer (SSL) connections (using Ldp.exe) or over encrypted, non-SSL connections (using ADSI Edit or Ldp.exe). To establish an SSL connection to AD LDS, you must install certificates on the computer running AD LDS and on all the clients. To make SSL connections to an AD LDS instance, you must use Ldp.exe; ADSI Edit does not support SSL connections.

By default, an AD LDS instance automatically enforces any local or domain password policies that exist. If you create a new AD LDS user, and if you assign a password to that user that does not meet the requirements of the password policy that is in effect, the user will be disabled.

By default, AD LDS supports and enforces the password policy settings and account lockout settings that are provided by Windows Server 2008, including the following:

Minimum age

Maximum age

Complexity

History

Too many failed logon attempts

Disabling and enabling of accounts

If the server on which AD LDS is running belongs to a workgroup, the server's local password policy settings and account lockout settings are implemented. If the server on which AD LDS is running belongs to a domain, the password policy settings and account lockout settings from Active Directory Domain Services (AD DS) are implemented.

Membership in the Administrators group of the AD LDS instance is the minimum required to complete this procedure. By default, the security principal that you specify as the AD LDS administrator during AD LDS setup becomes a member of the Administrators group in the configuration partition. For more information about AD LDS groups, see Understanding AD LDS Users and Groups.

Setting or modifying the password of an AD LDS user

  • Using ADSI Edit

  • Using Ldp over an encrypted, non-SSL connection

  • Using Ldp over an SSL connection

Using ADSI Edit

To set or modify the password of an AD LDS user using ADSI Edit

  1. Open ADSI Edit.

  2. Connect and bind to the directory partition containing the AD LDS user for whom you want to set or modify the password. For more information, see Use ADSI Edit to Manage an AD LDS Instance.

  3. Browse to the directory object representing the AD LDS user, and then right-click the directory object.

  4. Click Reset password, and then type a password for the user in New password and in Confirm password.

Additional considerations

  • To open ADSI Edit, on a computer with the AD LDS server role installed, click Start, click Administrative Tools, and then click ADSI Edit.

Using Ldp over an encrypted, non-SSL connection

To set or modify the password of an AD LDS user using Ldp over an encrypted, non-SSL connection

  1. Open Ldp.

  2. On the Options menu, click Connection Options.

  3. In Option Name, click LDAP_OPT_ENCRYPT.

  4. In Value, type 1, click Set, and then click Close.

  5. Connect and bind to the AD LDS instance, and then view the directory partition that contains the AD LDS user for whom you want to set a password. For more information, see Use Ldp.exe to Manage an AD LDS Instance.

  6. Right-click the AD LDS user, and then click Modify.

  7. In Attribute, type userpassword, and then, in Value, type a password for the account.

  8. Click Enter, and then click Run. The details pane displays a message similar to the following:

    ***Call Modify...
ldap_modify_s(ld, 'CN=Mary Baker,O=Microsoft,C=US',[1] attrs);
Modified "CN=Mary Baker,O=Microsoft,C=US".

Additional considerations

  • To open Ldp, click Start, click Run, type ldp, and then click OK.

  • You can also use ADSI Edit to set or modify passwords: right-click the directory object that represents the AD LDS security principal in ADSI Edit, and then click Reset Password.

  • By default, an AD LDS instance running on Windows Server 2008 automatically enforces any local or domain password policies. If you set a password for an AD LDS user that does not meet the requirements of the password policy in effect, the user account will be disabled.

  • The AD LDS user for whom you set or modify the password must use the new password the next time that the user logs on.

  • This procedure applies to any object class that is used as a security principal in AD LDS. Any object class in AD LDS can be used as a security principal, as long as the object class definition contains the msDS-bindableobject auxiliary class and the unicodePwd attribute.

  • The user, person, inetOrgPerson, and OrganizationalPerson object classes are not available by default in the AD LDS schema. You must first import them.

Using Ldp over an SSL connection

To set or modify the password of an AD LDS user using Ldp over an SSL connection

  1. Install a server certificate on the computer where the AD LDS instance is running, and install a matching client certificate on the computer from which you administer the AD LDS instance.

  2. Open Ldp.

  3. Connect and bind to the AD LDS instance (select SSL in the Connect dialog box) containing the user for whom you want to set or modify a password. For more information, see Use Ldp.exe to Manage an AD LDS Instance.

  4. Right-click the AD LDS user, and then click Modify.

  5. In Attribute, type userpassword, and then in Value, type a password for the account.

  6. Click Enter, and then click Run. The details pane displays a message similar to the following:

    ***Call Modify...
ldap_modify_s(ld, 'CN=Mary Baker,OU=Beta
users,O=Microsoft,C=US',[1] attrs);
Modified "CN=Mary Baker,OU=Beta users,O=Microsoft,C=US".

Additional considerations

  • To open Ldp, click Start, click Run, in Open type ldp, and then click OK.

  • Establishing SSL connections requires the presence of certificates on the server and clients.

  • By default, an AD LDS instance running on Windows Server 2008 automatically enforces any local or domain password policies. If you set a password for an AD LDS user that does not meet the requirements of the password policy in effect, the user account will be disabled.

  • If the AD LDS user is currently logged on, that user must log off for the new password to take effect.

  • This procedure applies to any object class that is used as a security principal in AD LDS. Any object class in AD LDS can be used as a security principal, as long as the object class definition contains the SecurityPrincipal static auxiliary class and the unicodePwd attribute.

  • The user, person, inetOrgPerson, and OrganizationalPerson object classes are not available by default in the AD LDS schema. You must import them first. For more information, see Import the User Classes That Are Supplied with AD LDS.

Additional references

  • Working with Authentication and Access Control

  • Understanding AD LDS Users and Groups

  • Use ADSI Edit to Manage an AD LDS Instance

  • Use Ldp.exe to Manage an AD LDS Instance

  • Import the User Classes That Are Supplied with AD LDS


Add an Organizational Unit to the Directory

To keep your Active Directory Lightweight Directory Services (AD LDS) users and groups organized, you may want to place users and groups in organizational units (OUs). In Active Directory Domain Services (AD DS) and in AD LDS, as well as in other Lightweight Directory Access Protocol (LDAP)-based directories, OUs are the most commonly used method for keeping users and groups organized.

Membership in the Administrators group of the AD LDS instance is the minimum required to complete this procedure. By default, the security principal that you specify as the AD LDS administrator during AD LDS setup becomes a member of the Administrators group in the configuration partition. For more information about AD LDS groups, see Understanding AD LDS Users and Groups.

To add an OU to the directory

  1. Open ADSI Edit.

  2. Connect and bind to the directory partition of the AD LDS instance to which you want to add an OU. For more information, see Use ADSI Edit to Manage an AD LDS Instance.

  3. In the console tree, double-click the directory partition, right-click the container to which you want to add the OU, point to New, and then click Object.

  4. In Select a class, click organizationalUnit, and then click Next.

  5. In Value, type a name for the new OU, and then click Next.

  6. If you want to set values for additional attributes, click More attributes.

  7. After you set all desired attributes for the new OU, click Finish.

Additional considerations

  • To open ADSI Edit, on a computer with the AD LDS server role installed, click Start, click Administrative Tools, and then click ADSI Edit.

  • By default, OUs can be added only under OU (OU=), country/region (C=), organization (O=), or domain-DNS (DC=) object classes. For example, you can add an OU to o=Microsoft,c=US. You cannot add an OU to cn=test,o=Microsoft,c=US. You can, however, update the schema definition of the OU object class to allow other superior object classes.

Additional references

  • Working with Authentication and Access Control

  • Use ADSI Edit to Manage an AD LDS Instance

  • Understanding AD LDS Users and Groups


AD LDS Administration Tools

There are a number of Active Directory Lightweight Directory Services (AD LDS) tools that you can use to manage AD LDS instances, directory partitions, and data.

  • Adamsync

  • ADSI Edit

  • Csvde

  • Ldifde

  • Ldp

Additional references

  • Active Directory Lightweight Directory Services


Adamsync

Adamsync

Synchronizes objects from Active Directory Domain Services (AD DS) to an instance of Active Directory Lightweight Directory Services (AD LDS).

Note

Before you use this command, you must import the user class definitions that are contained in the MS-AdamSyncMetadata.LDF file. For more information, see Import the User Classes That Are Supplied with AD LDS.

Syntax

adamsync [/?] [/l] [/d configuration_dn] [/i input_file] [/download configuration_dn output_file] [/export configuration_dn output_file] [/sync configuration_dn] [/reset configuration_dn] [/mai configuration_dn] [/fs configuration_dn] [/ageall configuration_dn] [/so configuration_dn object_dn] [/passPrompt]

Parameters

/?
Displays command-line options.

/l or /list
Displays all available configurations of AD DS to AD LDS Synchronizer.

/d or /delete configuration_dn
Deletes the specified configuration.

/i or /install input_file
Installs the configuration that is contained in the specified input file.

/download configuration_dn output_file
Creates an output file in XML that contains the specified configuration.

/export configuration_dn output_file
Saves the current configuration to the specified output file.

/sync configuration_dn
Synchronizes the specified configuration.

/reset configuration_dn
Resets the replication cookie of the specified configuration.

/mai configuration_dn
Configures the specified configuration as the authoritative instance.

/fs configuration_dn
Performs a full replication synchronization for the specified configuration.

/ageall configuration_dn
Performs an aging search for the specified configuration. An aging search determines—by searching for the AD LDS objects in AD DS—if the AD LDS objects in a configuration have been deleted in AD DS.

/so configuration_dn object_dn
Performs a replication synchronization for the specified object in the specified configuration. Use the distinguished name of the object.

/passPrompt
Prompts for user credentials.

Formatting legend

Format | Meaning
Italic | Information that you supply
Bold | Elements that you type exactly as shown
Ellipsis (...) | A parameter that can be repeated several times in a command line
Between brackets ([]) | Optional items
Between braces ({}); choices separated by pipe (|). Example: {even|odd} | A set of choices from which you must choose only one
Courier font | Code or program output

Additional references

  • AD LDS Administration Tools

  • Working with Authentication and Access Control

  • Synchronize with Active Directory Domain Services

  • Import the User Classes That Are Supplied with AD LDS


ADSI Edit

ADSI Edit

ADSI Edit runs as a Microsoft Management Console (MMC) snap-in. To open ADSI Edit, on a computer with the Active Directory Lightweight Directory Services (AD LDS) server role installed, click Start, click Administrative Tools, and then click ADSI Edit.

The following sections describe user interface (UI) options in the ADSI Edit snap-in, depending on the node that you click in the console tree or the command that you click on the Action menu.

  • ADSI Edit node

  • Connection node

  • Object node

ADSI Edit node

To view the following UI options, in the console tree, click ADSI Edit, and then, on the Action menu, click Connect to. The Connection Settings dialog box appears

You can use the following options in the Connection Settings dialog box to create a connection to a directory partition on an instance of Active Directory Lightweight Directory Services (AD LDS).

Option Details

Name

Type a display name for the connection. The connection will be listed in the console tree using the connection name that you provide.

Connection Point

Specify how you want to connect to the AD LDS instance. You can connect to a distinguished name or naming context in the AD LDS instance, or you can select a well-known naming context.

Note

AD LDS does not provide a naming context by default.

Computer

Specify the computer running the AD LDS instance that you want to administer. You must specify the server name or IP address. If the AD LDS instance is not using the default Lightweight Directory Access Protocol (LDAP) communications port number (389), you must also specify the port number that the AD LDS instance is using.

Advanced

Click this button to specify the credentials and bind method that you want to use for connections to the AD LDS instance

The Refresh command on the Action menu updates the information about connections and objects that is displayed in ADSI Edit.

Connection node

To view the following commands, in the console tree, click a connection node for an already established connection, and then, on the Action menu, click one of the commands in the following table.

Command | Details
Remove | Removes the currently selected connection node from ADSI Edit. This command affects only the contents of the ADSI Edit console tree; the command does not delete any objects from the AD LDS instance.
Update Schema Now | Reloads the schema information from AD LDS into the cache of the local computer.
New | Creates a new query when you point to New and then click Query.
Rename | Specifies a new name for the connection node.
Refresh | Updates the information about connections and objects that is displayed in ADSI Edit.

Object node

To view the following commands, in the console tree, click a directory object in a directory partition in an AD LDS instance, and then, on the Action menu, click one of the commands in the following table.

Command | Details
Move | Moves the object to another container in AD LDS. Opens a dialog box that you can use to select the destination container.
New Connection from Here | Creates a new connection and adds the new connection to the console tree.
New | Creates a new child object in the selected container when you point to New and then click Object. Opens a set of chained dialog boxes that begins with the class of the object. If you do not have permission to create an object in the selected container, no classes are listed. After a class is selected, a dialog box opens for each required attribute. In the final dialog box, click More to view and edit any optional attributes.
Delete | Deletes the selected object from AD LDS. A dialog box appears asking you to confirm the deletion. This command does not appear in the menu if you do not have permissions to delete the object from AD LDS.
Rename | Changes the name of the object in AD LDS.
Refresh | Updates the information that is displayed in ADSI Edit about connections and objects.
Properties | Opens a dialog box in which you can edit the attribute values of an object.
Reset Password | This option is available only for objects that contain a unicodePwd attribute. This option provides a dialog box in which the value of the unicodePwd attribute can be reset.

Additional references

  • AD LDS Administration Tools

  • Use ADSI Edit to Manage an AD LDS Instance

  • Ldp


Csvde

Csvde

Imports and exports data from Active Directory Lightweight Directory Services (AD LDS) using files that store data in the comma-separated value (CSV) format. You can also support batch operations based on the CSV file format standard.

Syntax

csvde [-i] [-f FileName] [-s ServerName] [-c String1 String2] [-v] [-j Path] [-t PortNumber] [-d BaseDN] [-r LDAPFilter] [-p Scope] [-l LDAPAttributeList] [-o LDAPAttributeList] [-g] [-m] [-n] [-k] [-a UserDistinguishedName Password] [-b UserName Domain Password]

Parameters

-i
Specifies the import mode. If the import mode is not specified, the default mode is export.

-f FileName
Identifies the import or export file name.

-s ServerName
Specifies the domain controller to perform the import or export operation.

-c String1 String2
Replaces all occurrences of String1 with String2. You generally use this when you importing from one domain to another and the distinguished name of the export domain (String1) must be replaced with the distinguished name of the import domain (String2).

-v
Sets verbose mode.

-j Path
Sets the log file location. The default is the current path.

-t PortNumber
Specifies a Lightweight Directory Access Protocol (LDAP) port number. The default LDAP port is 389. The global catalog port is 3268.

-d BaseDN
Sets the distinguished name of the search base for data export.

-r LDAPFilter
Creates an LDAP search filter for data export.

-p Scope
Sets the search scope. Search scope options are Base, OneLevel, or SubTree.

-l LDAPAttributeList
Sets the list of attributes to appear in the results of an export query. If this parameter is omitted, all attributes are returned.

-o LDAPAttributeList
Sets the list of attributes to be omitted from the results of an export query. You typically use this when you export objects from Active Directory Domain Services (AD DS) and then import them into another LDAP-compliant directory. If the attributes are not supported by another directory, you can omit the attributes from the result set using this option.

-g
Omits paged searches.

-m
Omits attributes that cannot be written, such as the ObjectGUID and objectSID attributes.

-n
Omits export of binary values.

-k
Ignores errors during the import operation, and continues processing. The following is a complete list of ignored errors:

  • Object already exists.

  • Constraint violation.

  • Attribute or value already exists.

-a UserDistinguishedName Password
Sets the command to run using the supplied UserDistinguishedName and Password. By default, the command runs using the credentials of the user who is currently logged on to the network.

-b UserName Domain Password
Sets the command to run as UserName Domain Password. By default, the command will run using the credentials of the user who is currently logged on to the network.

-?
Displays the command menu.

Remarks

  • Applications such as Microsoft Excel are capable of reading and saving data in the CSV format. In addition, Microsoft Exchange Server administration tools are also capable of importing and exporting data using the CSV format, as are many other non-Microsoft tools.

    The CSV format consists of one or more lines of data, with each value separated by a comma. The first line (sometimes referred to as the header) of the CSV file must contain the names of each attribute in the same order as the data in any line following the first line.

    Example:

    CN , FirstName , SurName , Description

    FirstUserLogonName , 1stUserFirstName , 1stUserSurName , Manager

    SecondUserLogonName , 2ndUserFirstName , 2ndUserSurName , President

  • You can use csvde -r to create an LDAP search filter for data export. For example, the following filter exports all users with a particular surname:

    csvde -r (and(objectClass= User )(sn = SurName ))

Formatting legend

Format | Meaning
Italic | Information that you supply
Bold | Elements that you type exactly as shown
Ellipsis (...) | A parameter that can be repeated several times in a command line
Between brackets ([]) | Optional items
Between braces ({}); choices separated by pipe (|). Example: {even|odd} | A set of choices from which you must choose only one
Courier font | Code or program output

Additional references

  • AD LDS Administration Tools

  • Administering Directory Partitions


Ldifde

Ldifde

Creates, modifies, and deletes directory objects. You can also use ldifde to extend the schema, export user and group information to other applications or services, and populate Active Directory Lightweight Directory Services (AD LDS) with data from other directory services.

Syntax

ldifde [-i] [-f FileName] [-s ServerName] [-c String1 String2] [-v] [-j Path] [-t PortNumber] [-d BaseDN] [-r LDAPFilter] [-p Scope] [-l LDAPAttributeList] [-o LDAPAttributeList] [-g] [-m] [-n] [-k] [-a UserDistinguishedName Password] [-b UserName Domain Password] [-?]

Parameters

-i
Specifies import mode. If the import mode is not specified, the default mode is export.

-f FileName
Identifies the import or export file name.

-s ServerName
Specifies the computer on which to perform the import or export operation. By default, ldifde will run on the computer on which ldifde is installed.

-c String1 String2
Replaces all occurrences of String1 with String2. You generally use this when you import data from one domain to another and the distinguished name of the export domain (String1) must be replaced with the distinguished name of the import domain (String2).

-v
Sets verbose mode.

-j Path
Sets the log file location. The default is the current path.

-t PortNumber
Specifies a Lightweight Directory Access Protocol (LDAP) port number. The default LDAP port is 389. The global catalog port is 3268.

-d BaseDN
Sets the distinguished name of the search base for data export.

-r LDAPFilter
Creates an LDAP search filter for data export. For example, to export all users with a particular surname, you can use the following filter: -r (and(objectClass=User)(sn=SurName))

-p Scope
Sets the search scope. Search scope options are Base, OneLevel, or SubTree.

-l LDAPAttributeList
Sets the list of attributes to return in the results of an export query. If this parameter is omitted, all attributes are returned.

-o LDAPAttributeList
Sets the list of attributes to omit from the results of an export query. You typically use this when you export objects from Active Directory Domain Services (AD DS) and then import them into another LDAP-compliant directory. If attributes are not supported by another directory, you can omit the attributes from the result set using this option.

-g
Omits paged searches.

-m
Omits attributes that cannot be written, such as the ObjectGUID and objectSID attributes.

-n
Omits export of binary values.

-k
Ignores errors during the import operation, and continues processing. The following is a complete list of ignored errors:

  • Object is already a member of the group.

  • Object class violation (meaning that the specified object class does not exist) if the object being imported has no other attributes.

  • Object already exists.

  • Constraint violation.

  • Attribute or value already exists.

  • No such object.

-a UserDistinguishedName Password
Sets the command to run using the supplied UserDistinguishedName and Password. By default, the command will run using the credentials of the user who is currently logged on to the network. This option cannot be used with the -b option.

-b UserName Domain Password
Sets the command to run using the supplied UserName Domain Password. By default, the command will run using the credentials of the user who is currently logged on to the network. This option cannot be used with the -a option.

-?
Displays the command menu.

Remarks

  • With the -c parameter, you can use the constants #schemaNamingContext and #configurationNamingContext in place of the distinguished names of the schema directory partition and configuration directory partition.

  • When you create the import file to use with the ldifde command, use a changeType value to define the type of changes that the import file will contain. The changeType values in the following table are available.

    Value Description

    add

    Specifies that new content is contained in the import file.

    modify

    Specifies that existing content has been modified in the import file.

    delete

    Specifies that content has been deleted in the import file.

The following is an example of an LDAP Data Interchange Format (LDIF) import file format using the add value:

DN: CN=SampleUser,DC=DomainName

changetype: add

CN: SampleUser

description: DescriptionOfFile

objectClass: User

userPrincipalName: SampleUser

Examples

To retrieve only the distinguished name, common name, first name, surname, and telephone number of the returned objects, type:

-l DistinguishedName, CN, GivenName, SN, Telephone

To omit the globally unique identifier (GUID) for an object, type:

-o whenCreated, whenChanged, objectGUID

Formatting legend

Format | Meaning
Italic | Information that you supply
Bold | Elements that you type exactly as shown
Ellipsis (...) | A parameter that can be repeated several times in a command line
Between brackets ([]) | Optional items
Between braces ({}); choices separated by pipe (|). Example: {even|odd} | A set of choices from which you must choose only one
Courier font | Code or program output

Additional references

  • AD LDS Administration Tools

  • Import Data into an AD LDS Instance

  • Import the User Classes That Are Supplied with AD LDS

  • Administering Directory Partitions


Ldp

Ldp

The Ldp dialog box consists of two panes: the console tree and the details pane. The console tree lists the base object and any child objects. The details pane lists the results of the Lightweight Directory Access Protocol (LDAP) operations. To start Ldp, click Start, right-click Command Prompt, click Run as administrator, type ldp at the command prompt, and then press ENTER.

The following sections describe the commands on the Ldp menus:

  • Connection

  • Browse

  • View

  • Options

  • Utilities

Connection

The following table describes the commands on the Connection menu.

Command Details

Connect

Opens a dialog box that you can use to open a session with a specified LDAP server. A connection must be established with an LDAP server before any other LDAP commands can be run. Type the appropriate port number for the service that you are connecting to. By default, LDAP uses TCP for a connection-oriented session. To use User Datagram Protocol (UDP) for a connectionless session, select the Connectionless check box. By default, a successful connection results in the appearance of RootDSE information in the details pane.

Bind

Opens a dialog box that you can use to authenticate a specified LDAP server. Type a user name and password of an account that has permissions to the LDAP server. If you do a simple bind with an empty password, you will be connected with anonymous credentials. As a shortcut, use the Bind command without using the Connect command to connect, and then authenticate with the server that you last connected to. Click Advanced on the Bind dialog box to open the Bind Options dialog box and configure authentication method options.

The following table describes the options in the Bind Options dialog box.

Option | Description
Function Type | Specifies a category of authentication for Ldp to use when choosing authentication methods.
Generic | Specifies the use of a standard authentication protocol.
Simple | Specifies the use of no authentication protocol, and sends the password in plaintext.
Extended | Not available.
Method | Specifies the type of authentication that Ldp uses when passing credentials.
Synchronous | Specifies that the authenticating server must respond immediately to requests. This option works only with simple authentication.
Use auth. identity | Allows the use of alternate authentication credentials. All authentication methods except simple methods require synchronous calls.

Disconnect

Terminates an open session with a specified LDAP server. Closing Ldp automatically disconnects any open sessions.

New

Keeps the currently connected session, but clears the details pane. The keyboard shortcut for this action is CTRL+N.

Save

Saves changes to a previously saved file.

Save as

Saves the contents of the details pane to a text file. Use the Open command to view the contents of this file in the details pane later.

Print

Prints the contents of the details pane.

Browse

The following sections describe the commands on the Browse menu.

Add Child

Opens a dialog box that you can use to add objects to Active Directory Lightweight Directory Services (AD LDS). You must enter the full distinguished name of the object, as well as all the mandatory attributes for the class of object that you are adding.

The following table describes the options in the Add dialog box.

Option | Details
Dn | Type the full distinguished name of the new object.
Attribute | Type the required or optional attribute.
Values | Type the values that are associated with the attribute. Separate multiple values for a single attribute with a semicolon. No spaces are required.
Enter | Adds the entered attribute and values to the Entry List box, and clears the Attribute and Values boxes. Continue entering attributes and values until all required and desired optional attributes are in the Entry List box.
Insert file | Opens a dialog box that you can use to open a text file with the appropriate attributes and values.
Entry List | Displays the attributes and values that you enter.
Edit | Opens a dialog box that you can use to enter changes to the selected entry in the Entry List box.
Remove | Deletes the selected entry from the Entry List box.
Extended | Select this check box if the object that you are adding is part of an extended control.
Synchronous | If this check box is selected (which is the default), Ldp is required to wait for a response from the destination server before continuing. If you clear this check box, Ldp continues before a response is received. Clear this check box when slow wide area network (WAN) connections are causing Ldp commands to time out.
Run | Adds the current attributes and values in the Entry List to AD LDS. If Ldp encounters any errors, the object is not added and an error message appears in the details pane.

Delete

This command opens a dialog box that you can use to delete an object from AD LDS. Attributes can be deleted only if they are defined as optional and if they contain no values. To delete an attribute's values, on the Browse menu in the Add dialog box, click Edit.

Option | Details
DN | Type the full distinguished name of the new object.
Extended | Select this check box if the object being modified is part of an extended control.
Synchronous | If this check box is selected (which is the default), Ldp is required to wait for a response from the destination server before continuing. If you clear this check box, Ldp continues before a response is received. Clear this check box when slow WAN connections are causing Ldp commands to time out.
Recursive (client) | Deletes all objects in a container, but does not delete the container.

Modify

This command opens a dialog box that you can use to change the attributes of an object that is stored in AD LDS.

The following table describes the options in the Modify dialog box.

Option | Details
Dn | Type the full distinguished name of the new object.
Attribute | Type the required or optional attribute.
Values | Type the values that are associated with the attribute. Separate multiple values for a single attribute with a semicolon. No spaces are required.
Insert file | Opens a dialog box that you can use to open a text file with the appropriate attributes and values.
Enter | Adds the entered attribute and values to the Entry List section of the dialog box, and clears the Attribute and Values fields. Continue entering attributes and values until all required and desired optional attributes are in the Entry List box.
Operation | Add, Delete, or Replace. To add a new value to an existing attribute, click Add. To permanently remove an attribute from the listed object, click Delete. Attributes that contain data cannot be deleted. Also, attempting to delete required attributes results in an error. To replace an existing value with another or to change listed values for an existing attribute, click Replace.
Entry List | Displays the existing attributes and values for an object.
Edit | Opens a dialog box that you can use to make changes to the selected entry in the Entry List box.
Synchronous | If this check box is selected (which is the default), Ldp is required to wait for a response from the destination server before continuing. If you clear this check box, Ldp continues before a response is received. Clear this check box when slow WAN connections are causing Ldp commands to time out.
Extended | Select this check box if the object being modified is part of an extended control.
Run | Sends the edited values in the Entry List box to AD LDS.

Modify DN

Opens a dialog box that you can use to change the relative distinguished name of an object. This option is designed to modify leaf objects only. If you rename the container portion of the distinguished name, the object moves to the container that is named.

The following table describes the options in the Modify RDN dialog box.

Option | Details
Old Dn | Type the current distinguished name of the object.
New Dn | Type the new distinguished name for the object.
Delete Old | If this check box is selected (which is the default), the old distinguished name is removed from the LDAP directory.
Synchronous | If this check box is selected (which is the default), Ldp is required to wait for a response from the destination server before continuing. If you clear this check box, Ldp continues before a response is received. Clear this check box when slow WAN connections are causing Ldp commands to time out.
Extended rename | Select this check box if the object being renamed is part of an extended control.
Run | Sends the change to AD LDS.

Search

Opens a dialog box that you can use to create a customized search filter and to perform the search on the directory information tree. The search base must be specified as a distinguished name, and the filter must be a valid LDAP filter. Items that are returned from a search are separated by >> characters.

The following table describes the options in the Search dialog box.

Option | Details
Base Dn | Type a distinguished name to specify where the search starts.
Filter | Type the search criteria, separated by LDAP search filters. Type attributes and values to find an object or set of objects. Note that LDAP search filters are defined in RFC 2254 and in the article 255602 at the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?linkid=4441).
Scope | Specifies how many levels the search encompasses.
Base | Searches the base object only.
One Level | Searches objects immediately subordinate to the base object, but does not search the base object.
Subtree | Searches the entire subtree, from the base object down to all child objects.
Options | Opens the Search Options dialog box. You can use these options to apply filters that allow some entries and exclude others from the search and that allow you to control the way the search is processed.
Run | Sends the search request to AD LDS.

Compare

Opens a dialog box that you can use to compare the value of an attribute of an object with a specified value. The result returned is either true or false.

The following table describes options in the Compare dialog box.

Option | Details
Dn | Type the full distinguished name of the object whose values will be compared.
Attribute | Type the attribute to be compared.
Value | Type the value that will be compared with the existing value in AD LDS. Separate multiple values for a single attribute with a semicolon. No spaces are required.
Synchronous | If this check box is selected (which is the default), Ldp is required to wait for a response from the destination server before continuing. If you clear this check box, Ldp continues before a response is received. Clear this check box when slow WAN connections are causing Ldp commands to time out.
Run | Starts the comparison.

Extended Op

Opens a dialog box that you can use to submit an extended operation to an LDAP directory by specifying an LDAP object identifier (also known as OID) and an applicable value.

The following table describes the options in the Extended Operations dialog box.

Option | Details
Oid | Type the object identifier number.
Data | Type the value of the object identifier attribute.
Controls | See Controls Option in the Options section.
Send | Submits the extended operation to AD LDS.

GetLastError

Calls the LDAP GetLastError function.

Security

Opens a dialog box that you can use to submit an extended operation to an LDAP directory by specifying an LDAP object identifier and an applicable value.

The following table describes the options in the Security Descriptor dialog box.

Option | Details
Security Descriptor | Opens a dialog box that you can use to view access permissions on an object.

Replication

Opens a dialog box that you can use to submit an extended operation to an LDAP directory by specifying an LDAP object identifier and an applicable value.

The following table describes the options in the Replication Metadata dialog box.

Option | Details
Replication/View Metadata | In Object DN, type the distinguished name of the object whose replication metadata you want to view.

Process Pending

Opens a dialog box that shows the list of requests that are not finished processing.

View

The following table describes the commands on the View menu.

Command | Details
Tree | In BaseDN, type the distinguished name of the object to use as the base object in the navigation pane.
Enterprise Configuration | This menu option does not apply to AD LDS.
Status Bar | Shows or hides the status bar, which is located along the bottom of the LDAP window.

Options

The following sections describe the commands on the Options menu.

Search

The following table describes the options in the Search Options dialog box.

Option | Details
Time limit | Type the number of milliseconds that the search can take on the server. By default, the maximum is 120 seconds.
Size limit | Type the maximum number of bytes that the search can return. Typing a null value does not place a maximum size on the data that is returned.
Timeout (s) | Type the number of seconds that Ldp waits for the LDAP server to respond to a search request.
Timeout (ms) | Type the number of milliseconds that Ldp waits for the LDAP server to respond to a search request.
Page size | Type the maximum size, in bytes, of each page of returned data.
Attributes | Specifies which attributes to return in the search. Separate multiple attributes with a semicolon. Use the wildcard character (*) to indicate all attributes.
Search Call Type | Specifies a call type to use in the search. If the search will take some time, you can click Async. so that you can perform other tasks while waiting for the search to complete.
Attributes Only | Select this check box to return only attributes of objects. The distinguished name is not returned.
Chase referrals | Performs a search for objects that are found in external LDAP directories. By default, the objects' trusts of external LDAP directories return only a referral instead of the actual object.
Display Results | Displays a detailed list of objects that are returned by the search. By default, only a success or failure and the number of objects found appear.
Sort Keys | Opens the Sort Keys dialog box. See the Sort Keys section below.
Controls | Opens the Controls dialog box.

Pending

Opens a dialog box that you can use to place filters on the list of processes that have not yet completed.

The following table describes the options in the Pending Options dialog box.

Option | Details
All search results | Specifies that all search results display.
Blocking | Clear this check box to set a time limit.
Time Limit (sec): | Type a time limit in seconds.
Time Limit (millisec): | Type a time limit in milliseconds.

General

The following table describes the options in the General Options dialog box.

Option | Details
Value Parsing | Specifies the display format of the LDAP data. Binary displays the LDAP information in its native numerical format. String converts the LDAP information from its native format to ASCII characters so that it is more readable when it is displayed. This is the default setting. Values that are too long to be converted are still displayed in binary form.
LDAP Version | Specifies which version of LDAP the server is using. The default is version 3.
DN processing | Converts the distinguished names, which are displayed in component parts, by extending the data types that Ldp returns when it performs a command.
Buffer Size | In Number of lines, type the number of returned lines to display per command. In Chars per line, type the number of returned characters to display per command.
Auto default NC query | Specifies that Ldp queries the default naming context when a connection to the LDAP server is made. The default naming context is the RootDSE. This setting is used when the distinguished name value in the View|Tree dialog box is left blank.
Virtual List View (VLV) | Select the Auto VLV browse when check box to display a virtual list view whenever the object count is greater than the value that is displayed in the container size is greater than box. The default value is 100.

Connection Options

Opens a dialog box that you can use to change the value of any option.

The following table describes the options in the Connection Options dialog box.

Option | Details
Option Name | Type the name of the option whose value will be reset.
Value | Type the new value for the specified option.
Set | Sends the information to the LDAP directory.

Controls

In the Controls dialog box, enter information to extend the functionality of LDAP.

The Object Identifier option must be specified when you implement a control. To obtain a list of object identifiers, view the supportedControls property in the RootDSE of a domain controller.

Additional considerations

  • Only server controls can be sent to a server. Client controls work only with LDAP application programming interfaces (APIs).

  • To view a list of extended LDAP controls, see article 222560 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?linkid=4441).

Sort Keys

Sort Keys is a type of control that formats the display of search results. To format the display of your search results, in the Sort Keys dialog box, type an attribute type.

TLS

The following table describes the subcommands for the TLS command.

Option | Details
StartTLS or StopTLS | Starts or stops a secure session with the LDAP server that uses Transport Layer Security (TLS).

Utilities

The following table describes the commands on the Utilities menu.

Option | Details
Large Integer Converter | To convert long integers into high and low parts, type a value in the String box.
SID Lookup | To determine the domain\user that is associated with a given security ID (SID), type a SID into List of sids, and then click OK. The associated domain\user appears in the details pane.

Additional references

  • AD LDS Administration Tools

  • Use Ldp.exe to Manage an AD LDS Instance

  • ADSI Edit


User Interface: Active Directory Lightweight Directory Services Setup Wizard

The Active Directory Lightweight Directory Services Setup Wizard creates an Active Directory Lightweight Directory Services (AD LDS) instance. The following topics provide information about how to complete each step in the wizard:

  • Setup Options

  • Instance Name

  • Ports

  • Application Directory Partition

  • File Locations

  • Service Account Selection

  • AD LDS Administrators

  • Import LDIF Files

  • Ready to Install

The following steps appear when you create a replica instance of AD LDS:

  • Joining a Configuration Set

  • Administrative Credentials for the Configuration Set

  • Copy Application Directory Partitions

  • Copying Application Information

Additional references

  • Understanding AD LDS Instances


Setup Options

On the Setup Options page in the Active Directory Lightweight Directory Services Setup Wizard, you choose whether to install a unique Active Directory Lightweight Directory Services (AD LDS) instance or join an existing configuration set.

Setup option | Result
A unique instance | If you choose to install a unique AD LDS instance, the AD LDS instance that you install will not be a part of any existing configuration set, and it will not have any replication partners. The wizard will create new, default copies of the configuration and schema directory partitions for the new AD LDS instance that you are creating. Any schema extensions that you have added to any other AD LDS instance will not be available in this new AD LDS instance.
A replica of an existing instance | If you choose to install a replica of an existing AD LDS instance, the AD LDS instance that you are installing will contain replicated copies of the configuration and schema directory partitions (including any schema extensions) from the instance from which you choose to replicate. In addition, you have an opportunity in the wizard to selectively replicate any application directory partitions that exist in the source configuration set. You must specify a running AD LDS instance as the source from which to replicate. To speed up the replication process for the new instance, you can use a restored copy of a previously backed-up AD LDS instance as the data source.

An AD LDS instance consists of a single copy of the AD LDS directory service, along with its associated directory store, assigned Lightweight Directory Access Protocol (LDAP) and Secure Sockets Layer (SSL) ports, and application event log. You can run multiple AD LDS instances simultaneously on a single computer.

You can join an AD LDS instance to a configuration set only during AD LDS installation.


Instance Name

On the Instance Name page, you must provide an easily recognizable name for the Active Directory Lightweight Directory Services (AD LDS) instance that you are installing. This name is used on the local computer to uniquely identify this AD LDS instance.

The name that you specify appears in the following places:

  • Event Viewer

  • Services snap-in

  • Add or Remove Programs

Note

The Active Directory Lightweight Directory Services Setup Wizard presents a default instance name of instanceX, where X equals 1 for the first AD LDS instance that is installed on the computer, 2 for the second AD LDS instance that is installed on the computer, and so on.

The name that you specify must meet the following requirements:

  • It must be unique with respect to other AD LDS 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 instance name that you specify is used to construct the service name, the service display name, and the service description, as described in the following table.

Name supplied during setup | Service name | Service display name | Service description
instance1 | ADAM_instance1 | instance1 | Blank (No default description is provided.)


Ports

On the Ports page, you specify the communications ports that the Active Directory Lightweight Directory Services (AD LDS) instance will use to communicate with directory-enabled applications. Directory-enabled applications locate an AD LDS instance by using a combination of the name of the computer on which the AD LDS instance is running and a communication port number. An AD LDS instance can communicate using Lightweight Directory Access Protocol (LDAP) or Secure Sockets Layer (SSL). You must provide a port number for each.

If you are not sure what communication port numbers to use, accept the default values.

Notes
  • By default, AD LDS uses the default communication port numbers of 389 and 636 for LDAP and SSL, respectively. If either of these ports is already in use on the computer, AD LDS specifies the first available port starting at 50000.
  • If you plan to run AD LDS and Active Directory Domain Services (AD DS) concurrently on the same computer, you must assign ports other than 389 and 636 to AD LDS. AD DS requires the use of ports 389 and 636 (as well as ports 3268 and 3269 if the domain controller running AD DS is configured as a global catalog).


Application Directory Partition

On the Application Directory Partition page, you can create a new application directory partition during setup for Active Directory Lightweight Directory Services (AD LDS). An application directory partition holds data that is specific to one or more directory-enabled applications. The Active Directory Lightweight Directory Services Setup Wizard does not require that you create an application directory partition. You can also create application directory partitions anytime after you create an AD LDS instance.

If you choose to create an application directory partition, you must specify a distinguished name for the new partition. AD LDS supports both X.500-style and Domain Name System (DNS)–style distinguished names. When you specify an application partition in AD LDS, you can use any of the distinguished name attribute types in the following table. You must include at least one attribute in the distinguished name that you specify.

Distinguished name attribute | Type
C | Country/region
CN | Container
DC | Domain component
L | Locality
O | Organization
OU | Organizational unit

Example:

CN=Partition1,DC=Woodgrove,DC=COM

Important

If you want to add organizational unit (OU) containers in your application directory partition, limit the distinguished name that you specify to the following object classes: OU, C, O, and DC. By default, OUs can be added only under these object classes. For example, you can add an OU to o=Microsoft,c=US. You cannot add an OU to cn=test,o=Microsoft,c=US.


File Locations

On the File Locations page, you can view and change the default installation directories for Active Directory Lightweight Directory Services (AD LDS) data (.dit) files and recovery (.log) files.

By default, AD LDS data files and recovery files are installed on the destination computer in the following directory:

\%ProgramFiles%\Microsoft ADAM\instancename\data

where instancename equals the AD LDS instance name that you specified on the Instance Name page.

By default, AD LDS program files and administration tools are installed in the following directory:

\%windir%\ADAM

Notes
  • If the directory paths that you specify do not already exist, the Active Directory Lightweight Directory Services Setup Wizard creates them for you.
  • The Active Directory Lightweight Directory Services Setup Wizard does not accept environmental variables in file location paths.


Service Account Selection

On the Service Account Selection page in the Active Directory Lightweight Directory Services Setup Wizard, you must select a service account for use by this instance of Active Directory Lightweight Directory Services (AD LDS). The account that you select determines the security context in which the AD LDS instance runs. Changing the service account after installation may require some additional configuration.

In most cases, the Active Directory Lightweight Directory Services Setup Wizard defaults to the Network Service account as the service account. The Network Service account is a special, built-in account, with authority similar to the authority of an authenticated user account.

The name of the account is NT AUTHORITY\NetworkService. The Network Service account has limited access to the local computer. It has authenticated access, as the computer account, to network resources. This limited access helps safeguard your system if individual services or processes are compromised. Services that run as the Network Service account access network resources using the credentials of the computer account.

Notes
  • To enable auditing for an AD LDS instance that runs under a service account other than the Network Service account, you must grant the Generate security audits right to the account that is used as the AD LDS service account.
  • To enable a workstation or domain user account as a service account, you must grant the Log on as a service right to the account that is used as the AD LDS service account.


AD LDS Administrators

On the AD LDS Administrators page, you must select a user or group to become the default administrator for this Active Directory Lightweight Directory Services (AD LDS) instance. The user or group that you select will have full administrative control of the AD LDS instance.

By default, the Active Directory Lightweight Directory Services Setup Wizard specifies the currently logged on user as the administrator for the AD LDS instance. You can change this selection to any local or domain account or group on your network.

Notes
  • If you specify a group to become the AD LDS administrator, every member of that group will have administrative control of the AD LDS instance.
  • The user or group that you select automatically becomes a member of the Administrators group in the configuration directory partition of the AD LDS instance.
  • Do not specify built-in groups or built-in accounts, such as DOMAIN\Administrators, as the AD LDS administrator. Instead, if you want to specify a group, specify a domain group, such as domainname\Domain Admins, where domainname represents the name of your domain.


Import LDIF Files

On the Import LDIF Files page, you can specify that optional LDAP Data Interchange Format (LDIF) files be imported. Together, these files contain several user class schema definitions—along with objects for use with Windows Authorization Manager—that can be imported into the schema of the new instance of Active Directory Lightweight Directory Services (AD LDS) that is currently being installed.

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

.LDF file User classes Import this file if ...

MS-ADAM-DisplaySpecifiers-0409.LDF
  • Not applicable

You want to use an Active Directory Microsoft Management Console (MMC) snap-in (such as Active Directory Sites and Services) with AD LDS.

MS-AdamSyncMetadata.LDF
  • Not applicable

You want to use the adamsync command-line tool to synchronize AD LDS with Active Directory Domain Services (AD DS).

MS-AZMan.LDF
  • Not applicable

You want to use Windows Authorization Manager with AD LDS.

MS-InetOrgPerson.LDF
  • Person

  • Organizational-Person

  • User

  • inetOrgPerson

You want to create user objects in the AD LDS directory, and you want to create users of the InetOrgPerson class (as defined in RFC 2798). MS-InetOrgPerson.LDF is a sample file that you can modify to meet your particular requirements.

MS-User.LDF
  • Person

  • Organizational-Person

  • User

You want to create user objects in the AD LDS directory, but you do not want to create users of the InetOrgPerson class (as defined in RFC 2798). MS-User.LDF is a sample file that you can modify to meet your particular requirements.

MS-UserProxy.LDF
  • User-Proxy

You want to create simple proxy objects in AD LDS for use in bind redirection. MS-UserProxy.LDF is a sample file that you can modify to meet your particular requirements.

MS-UserProxyFull.LDF
  • User-Proxy-Full

You want to create complete proxy objects in AD LDS for use in bind redirection. To use this file, you must also import MS-InetOrgPerson.LDF or MS-User.LDF. MS-UserProxyFull.LDF is a sample file that you can modify to meet your particular requirements.
Notes
  • If you choose not to import these LDIF files during setup, you can import them at a later time using the ldifde command-line tool.
  • This wizard page appears only during the installation of a unique AD LDS instance and not during the installation of a replica AD LDS instance.
  • You must be logged on as an account that is specified as the AD LDS administrator to import these schema class definitions into the AD LDS schema.


Ready to Install

On the Ready to Install page, you can review the Active Directory Lightweight Directory Services (AD LDS) setup options that you selected. You can click Back to return to a previous wizard page that contains a setting that you want to change.

Note

After you click Next on the Ready to Install page, the Active Directory Lightweight Directory Services Setup Wizard automatically begins copying files and configuring the new AD LDS instance.


Joining a Configuration Set

On the Joining a Configuration Set page, you must specify an Active Directory Lightweight Directory Services (AD LDS) instance from which to replicate the configuration and schema directory partitions for the new AD LDS instance that you are installing. The AD LDS instance that you specify on this page also determines the AD LDS configuration set in which the new AD LDS instance will participate.

Important

If you are installing a replica AD LDS instance into an existing configuration set that includes AD LDS instances in multiple forests, use the full Domain Name System (DNS) name, rather than the IP address, when you specify the source AD LDS instance from which to replicate.


Administrative Credentials for the Configuration Set

On the Administrative Credentials for the Configuration Set page, you must specify valid administrative credentials for the configuration set to which you are joining the Active Directory Lightweight Directory Services (AD LDS) instance.

Note

The account that you specify on this wizard page must belong to the Administrators group in the configuration directory partition of the configuration set that you are joining (CN=Administrators,CN=Roles,CN=Configuration,CN={GUID}).


Copy Application Directory Partitions

On the Copy Application Directory Partitions page, you can specify one or more application directory partitions to copy from the configuration set that you are joining. You are not required to copy any application directory partitions when you join a configuration set.

The configuration and schema directory partitions are always copied from the configuration set that you are joining, even if you choose not to copy any application directory partitions.

Note

If Available partitions does not contain any application directory partitions, the Active Directory Lightweight Directory Services (AD LDS) instance that you specified on the Joining a Configuration Set page does not contain any application directory partitions.


Copying Application Information

On the Copying Application Information page, you can specify the Active Directory Lightweight Directory Services (AD LDS) instance or media location from which the replica AD LDS instance will be created. You can use the network to create a replica of an AD LDS instance that is currently running on another server, or you can install an AD LDS instance that has been restored from an AD LDS backup.