You want to install a new instance of AD LDS.

At its most basic level, an AD LDS installation will simply copy the necessary program files and DLLs to the machine in question without creating an AD LDS instance or performing any other configuration steps. This can be useful if you want to include AD LDS as part of a base image that you deploy to your application developers, while allowing them to create their own instances and configuration sets as they see fit.

Creating a New AD LDS Instance; Creating a New Replica of an AD LDS Configuration Set

You want to create a new AD LDS instance.

An AD LDS instance refers to a single installation of AD LDS on a particular server or workstation. A single Windows computer can host multiple instances of AD LDS simultaneously; they are all independently managed and use different LDAP and LDAPS ports to communicate. Just as you can have multiple web servers operating on the same computer, with one using TCP port 80 and one using TCP port 8081, you can also have multiple AD LDS instances running simultaneously on different ports.

When you create an AD LDS instance, you also have the option to create an application directory partition to associate with the instance. An AD LDS instance can have zero, one, or multiple application partitions associated with it that will be used to store application data such as security principals as well as user and group information.

Extending the AD LDS Schema; MSDN: Binding to an Instance [ADAM]; “Create a New AD LDS Instance”; Active Directory, Fifth Edition, by Brian Desmond et al. (O’Reilly)

You want to create a new replica of an existing AD LDS configuration set.

Similar to Active Directory itself, AD LDS use multimaster replication that allows multiple computers to host, read, and make updates to one or more configuration sets. An AD LDS replica is a computer that is hosting one instance of a particular configuration set. Unlike Active Directory, you can host replica instances on computers that run any version of Windows since Windows XP (including client operating systems and server operating systems). You are not restricted to replicating data to all of your AD LDS servers unnecessarily; this can be quite useful in the case of data that is locally interesting but that doesn’t need to be replicated throughout your entire environment.

Creating a New AD LDS Instance for creating a new AD LDS instance; “Create a Replica AD LDS Instance”

You want to start or stop an AD LDS instance.

When you install an AD LDS instance on a computer (regardless of whether it is a new or replica instance), the instance will advertise itself as a typical Windows service. The service name naming convention is ADAM_<InstanceName>, where <InstanceName> is the name you specified when you installed the instance. The display name of the service will be just the <InstanceName>, where <InstanceName> is the name you specified when you installed the instance. If you need to modify the display name of the service after you’ve installed the AD LDS instance, you can use the built-in sc utility as follows:

> sc \<servername> config <servicename> displayname = "<display name>"

Listing the AD LDS Instances Installed on a Computer for listing the AD LDS instances installed on a computer; “Start, Stop, or Restart an AD LDS Instance”

You want to change the LDAP or LDAP over SSL ports that are being used by a particular AD LDS instance.

> dsdbutil
    > activate instance <instancename>
    > LDAP port <port>
    > SSL port <port>
> quit

If you need to change the LDAP and/or LDAP over SSL port that an instance is using to communicate, you must first stop the instance using one of the methods specified in Stopping and Starting an AD LDS Instance. Once the instance has stopped, use dsdbutil as shown in this recipe’s solution.

Stopping and Starting an AD LDS Instance for more on starting and stopping AD LDS instances; “Modify the Communication Ports Used by an AD LDS Instance”

You want to list all of the AD LDS instances installed on a computer.

As we discussed in Stopping and Starting an AD LDS Instance, a single computer can host multiple AD LDS instances running on different ports, each of which will advertise itself as a typical Windows service. These services will have a service name naming convention of ADAM_<InstanceName>, where <InstanceName> is the name that you specified when you installed the instance. The name of the service will remain the same even if you change the display name or description of the service at a later time, which can make the services.msc snap-in a less-than-desirable option for stopping and starting AD LDS instances if you make a habit of renaming them. By querying for service names that include the string “ADAM” using something like '%ADAM_%' in the WQL query, you can return the AD LDS instances that are installed on a local or remote computer. The method discussed in this recipe will not help you, however, if someone has modified the Registry key containing the name of the AD LDS instance. Locating AD LDS services can be a difficult task if someone in your organization is trying to hide their AD LDS instance(s). One possible solution, if you are having difficulty with this type of information gathering, would be to perform a port scan on one or more target computers; once you’ve obtained a list of listening ports, you can connect to each one in turn and look for an LDAP response.

In Windows Server 2008 and later, the "ADAM_" prefix was dropped from the service display name, which makes the dsbutil option the most appropriate option for listing AD LDS instances on a Windows Server 2008 instance.

Stopping and Starting an AD LDS Instance; MSDN: Querying with WQL [WMI]; MSDN: WQL Operators [WMI]; “List the AD LDS Instances Installed on a Computer”

You want to extend the AD LDS Schema with new classes or attributes.

The schema that you receive when you install AD LDS contains a subset of the classes and attributes that exist in the Active Directory Schema. You have the same ability to extend the schema in AD LDS as you do in AD, which means that you can expand and modify the schema to be the same as the AD Schema, or to match any changes made by your third-party or home-grown applications. Because of this, AD LDS is a great place to test potential schema modifications that you want to make in Active Directory. Because the schema extension process works the same in both AD and AD LDS, and because you can easily install, uninstall, and reinstall AD LDS instances, you can use AD LDS to quickly test new extensions, tweaking the definitions until you get exactly what you want.

Every instance of AD LDS will have at least two partitions: the Configuration partition and the Schema partition; you can create additional application partitions during or after installation, as described in Active Directory, Fifth Edition, by Brian Desmond et al. (O’Reilly). Similar to the Active Directory Schema NC, the AD LDS Schema partition contains definitions of classes and attributes that can be used to create objects within a particular AD LDS instance. An AD LDS Schema is unique to an individual AD LDS instance or configuration set; changes to the schema in one instance or configuration set will not affect the schema in other, separate instances or configuration sets. AD LDS comes with a number of preconfigured LDIF files that you can import to create common object types such as user, contact, and inetOrgPerson objects. You can import these LDIF files during the initial creation of an AD LDS instance as well as after the instance has been created.

Creating a New AD LDS Instance; MSDN: Adding User Classes [ADAM]; MSDN: Adding Contact Classes [ADAM]; MSDN: Extending the Active Directory Application Mode Schema [ADAM];“Create an Application Directory Partition”; “Delete an Application Directory Partition”; Active Directory, Fifth Edition, by Brian Desmond et al. (O’Reilly)

You want to add or remove an application partition.

An AD LDS installation creates up to three partitions by default: Configuration, Schema, and an application. The Configuration and Schema partitions get created automatically during the creation of a new AD LDS instance; you can create application partitions during the initial installation or after the instance has been created. If you’re installing a replica of an existing configuration set, the existing Schema and Configuration partitions are automatically replicated to the new instance. The Configuration partition stores information about AD LDS replication and partitions, while the Schema partition contains definitions for the types of objects that you can create within the instance. Note that these partitions correspond quite closely to the Configuration and Schema naming contexts within Active Directory.

When you create a new application directory partition, you need to specify a distinguished name for the partition; this name needs to be unique within your environment.

MSDN: Using Application Directory Partitions [ADAM]; MSDN: Creating an Application Directory Partition [ADAM]; MSDN: Deleting an Application Directory Partition [ADAM]; Chapter 20 of Active Directory, Fifth Edition, by Brian Desmond et al. (O’Reilly)

You want to create or delete OUs within an AD LDS instance.

Creating OUs in AD LDS is identical to creating them within Active Directory. Just like in AD, AD LDS OUs are containers that can contain other objects such as users, groups, contacts, or other OUs. You can also delegate permissions to an OU, allowing a user or group to have rights to the OU itself and to objects within that OU.

Managing AD LDS Permissions for more on managing AD LDS permissions; Chapter 5 for more on managing Active Directory OUs; “Add an Organizational Unit to the Directory”

You want to create or delete user objects within an AD LDS instance.

Creating users in AD LDS is quite similar to creating users in Active Directory. The most significant difference is that AD LDS users do not have the sAMAccountName attribute. You could conceivably define such an attribute within AD LDS and associate it with the user class, but it will not have the same properties that it does in Active Directory, particularly the AD constraint in which sAMAccountName uniqueness is enforced across a domain. AD LDS also would not be able to use a manually created attribute like that for user logons the way that sAMAccountName is used in AD.

Changing the Password for an AD LDS User to configure the password for an AD LDS user; MSDN: Managing Users [ADAM]; MSDN: Set or Modify the Password of an ADAM User [ADAM]; “Add an AD LDS User to the Directory”

You want to change the password for an AD LDS user.

To create user objects within an AD LDS instance, you first need to import the optional LDIF files that are provided with the AD LDS installer into the AD LDS schema, including ms-User.ldf, ms-InetOrgPerson.ldf, and ms-UserProxy.ldf. The ms-user.ldf file allows you to create Person, organizational-Person, and User objects. Any AD LDS user objects that you create will adhere to whatever local or domain password and account lockout policies are in place on the server that’s hosting the instance. You can use the procedures listed here to change the password for an AD LDS user, or to set a password for an AD LDS user that was created without specifying an initial password.

> admod -h . -b cn=jsmith,o=test userpassword::mypasswordQ1 -kerbenc

MSDN: Setting User Passwords [ADAM]; “Modify the Password of an AD LDS User”

You want to enable or disable an AD LDS user object.

AD LDS users can be enabled or disabled by modifying the msDS-UserAccountDisabled property. A new user will be enabled by default when you first create it, unless the password you’ve assigned for it doesn’t meet the requirements of the password policy, which is in effect on the machine.

Changing the Password for an AD LDS User for more on setting the password of an AD LDS user; MSDN: ms-DS-User-Account-Disabled Attribute [AD Schema]; “Disable or Enable an AD LDS User”

You want to create or delete a group object within AD LDS.

Group objects in AD LDS are greatly simplified compared to their Active Directory counterparts, since the notion of security and distribution groups as two separate entities does not exist. In addition, all AD LDS groups have the same scope: a group that has been created within an application partition can only be used within that partition, whereas a security principal that’s been created in the Configuration NC can be used in all naming contexts in that instance. This means that a group or user that was created in Instance1 cannot be used to assign permissions on objects in Instance2 or be added to a group in Instance2 (unless Instance1 and Instance2 are members of the same configuration set). Windows security principals can be assigned permissions in any application partition. And just like AD LDS user objects, AD LDS group objects do not contain the sAMAccountName attribute.

MSDN: Enumerating Users and Groups [ADAM]; MSDN: Creating Groups [ADAM]; “Add an AD LDS Group to the Directory”; MSDN: Deleting Groups [MSDN]; Active Directory, Fifth Edition, by Brian Desmond et al. (O’Reilly)

You want to manage the groups that an AD or AD LDS user is a member of.

AD LDS group objects can contain both AD LDS users and Windows security principals, which allows you to assign permissions to data stored in AD LDS instances using a consistent method. In the case of groups that were created within a specific application partition, they can only be assigned permissions within that partition; groups that were created within the Configuration partition can be assigned permissions to objects in any partition within the instance.

MSDN: Adding a User to a Group [ADAM]; MSDN: Removing Members from Groups [ADAM]; “Add or Remove Members to or from an AD LDS Group”

You want to view the attributes of an object within an AD LDS instance.

Just like in Active Directory, each AD LDS instance possesses a schema that defines what types of objects you can create and what sorts of attributes those objects possess. One of the major advantages of working with AD LDS is that you can make changes to the schema of an AD LDS instance without affecting the AD schema, thus allowing for more flexible application development that doesn’t run the risk of making permanent or far-reaching changes to an entire Active Directory forest. Similar to AD, object classes can have both mandatory and optional attributes that you can view.

MSDN: Active Directory Application Mode Schema [ADAM]; MSDN: Extending the Active Directory Application Mode Schema [ADAM]

You want to perform a bulk import of object data into an AD LDS instance.

For more information on the LDIF format, check RFC 2849.

Importing Objects Using an LDIF File for information on importing data using LDIF files; RFC 2849 (The LDAP Data Interchange Format [LDIF]—Technical Specification); “Import or Export Directory Objects Using Ldifde”

You want to create a replication schedule for an AD LDS application partition that is hosted on multiple computers within a single site.

Like Active Directory, AD LDS uses multimaster replication to copy information between replicas of each member of a configuration set. By default, all AD LDS instances that you create will be placed within a single site, Default-First-Site-Name. Similar to AD, AD LDS’s intra-site replication takes place through update notifications, where replication partners are notified as changes occur.

MSDN: Active Directory Application Mode Schema [ADAM]; MSDN: Using Application Directory Partitions [ADAM]; “Configure Replication Frequency Within a Site”

You want to force immediate replication of an AD LDS application partition.

The repadmin command-line tool that comes with both AD and AD LDS is primarily used to display and manage the replication topology of multiple directory servers. But repadmin can do much more, such as allowing you to view object metadata, update Service Principal Names (SPNs), and display information on trust relationships. You can see all of the basic options that are available by typing repadmin /? at a command prompt. Once you’ve familiarized yourself with these switches, you can then start learning about the more advanced features available by typing repadmin /experthelp. repadmin is one of those indispensable tools for an AD or AD LDS administrator; it’s well worth the time to learn its ins and outs to help you monitor and troubleshoot your network.

MS KB 229896 (Using Repadmin.exe to Troubleshoot Active Directory Replication); MS KB 905739 (TechNet Support WebCast: Troubleshooting Active Directory replication using the Repadmin tool)

You want to manage the security of AD LDS replication.

To ensure replication security, AD LDS will authenticate replication partners within a configuration set before replication begins. The method used for replication authentication will depend 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. AD LDS uses Security Support Provider Interface (SSPI) to establish the appropriate authentication security level between replication partners, and replication authentication always occurs over a secure channel.

Table 18-1 lists the security levels for replication authentication in Windows Server 2008, Windows Server 2008 R2, and Windows Server 2012. 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, in which case the replication security level is set to 0.

MSDN: Active Directory Application Mode Schema [ADAM]; MSDN: Using Application Directory Partitions [ADAM]; “Modify the Replication Security Level of a Configuration Set”

You want to manage permissions within an AD LDS instance.

The LDP utility provides you the ability to modify both DACL and SACL entries at an extremely granular level. You also have the familiar dsacls utility that will allow you to delegate permissions from the command line. When delegating permissions, you must first determine whether you are delegating permission over an entire container and all objects contained therein, or whether you are only going to delegate control over specific child objects. (For example, you can delegate control over all AD LDS user objects within an OU.) Once you’ve made this determination, you’ll then designate the specific permissions that you’re delegating; you can delegate anything from full control of the entire object down to granting read permissions on a single attribute.

[PermissionBits];[{Object|Property}];[InheritedObjectType]

“View or Set Permissions on a Directory Object”

You want to enable auditing of directory access and modifications. Audit events are logged to the Security event log.

Since Windows Server 2008, additional auditing functionality is enabled, which allows auditing of Directory Services events, including capturing "before" and "after" values on changes and deletions to Active Directory objects. You can enable this functionality using the auditpol.exe tool discussed earlier, using syntax similar to the following:

auditpol /set /subcategory:"directory service changes"

Here is a sample event that was logged after the Administrator account created a user object called JSmith in the Sales OU:

Log Name:      Security
Source:        Microsoft Windows security auditing
Date:          11/13/2012 3:50:58 AM
Event ID:      5137
Task Category: Directory Service Changes
Level:         Information
Keywords:      Audit Success
User:          N/A
Computer:      dc01.adatum.us
Description:
A user account was created.

Subject:
    Security ID:         ADATUMAdministrator
    Account Name:        Administrator
    Account Domain:      ADATUM
    Logon ID:          0xb3405

Directory Service:
    Name:         ADAM_Partition1
    Type:         Active Directory Lightweight Directory Services
Object:
    DN:    cn=JSmith,cn=Container1,cn={61E04C68-5582-494D-9F0A-1E0B970Db2D3}
    GUID:        {7c427193-64f6-476f-9cf4-748d850f02f8}
    Class:        User
Operation:
    Correlation ID:          {dbae9153-eae6-49cd-b641-fbef24d19cee}
    Application Correlation ID:    -