Active Directory Directory foundations
AD LDS instance diagnosis
Find the right application directory, distinguish its identities and replication from AD DS, and check bind and backup assumptions.
Start with the instance and its ports
AD Lightweight Directory Services provides an application directory. Several instances can run on one Windows host, each with its own service, database and ports. It does not make the host a domain controller or provide domain logon, Group Policy or an AD DS global catalog.
Get-Service -Name 'ADAM_*' |
Select-Object Name,DisplayName,Status
Use LDP to connect to the instance’s configured LDAP port, bind with the appropriate identity, and inspect RootDSE’s namingContexts. The instance name used by Windows service management is not the application’s naming context DN. Assuming port 389 or a domain DN can send an otherwise correct query to the wrong directory.
With ADWS exposing the local instance, the AD module can select it through its instance port:
$instance = 'lds1.contoso.com:50000'
$root = Get-ADRootDSE -Server $instance
$root | Format-List dnsHostName,dsServiceName,configurationNamingContext,
schemaNamingContext,defaultNamingContext,namingContexts
The client still connects to ADWS on TCP 9389; :50000 tells ADWS which local directory instance to use. Test this path separately from a direct LDAP bind. A custom LDS service account also affects the provider’s authentication behavior. Check the NTLM behavior described in Microsoft’s server/port documentation before changing SPNs to get past an error.
Configuration sets and application partitions
Instances in a configuration set share schema and configuration. Application data lives in application partitions, each replicated to the instances selected to host it. Check the configuration set, hosted partitions and replica topology when troubleshooting. An instance can answer LDAP while its application partition is behind.
dsdbutil is the maintenance utility associated with AD LDS. Its list instances command is useful for identifying locally installed instances before entering an instance-specific maintenance context. Select the instance deliberately before any database operation. Microsoft’s Dsdbutil reference documents the utility.
Compare replicas by application partition
repadmin /showrepl lds1.contoso.com:50000 /verbose
Check the intended instance port and application naming context, source replica, last success and exact error. Configuration/schema replication does not establish that every application partition is present on the same set of instances.
AD LDS also has configuration-set schema and naming role ownership. Event 2092 can appear at service startup while the role holder waits for required initial inbound replication. Inspect subsequent replication rather than disabling the gate to silence the event. Microsoft’s LDS event 2092 guidance defines that initial-synchronization behavior.
A bind is not the same as an application authorization
AD LDS can use Windows security principals and directory-specific principals, with different supported bind mechanisms and restrictions. A successful bind establishes an identity; the directory ACL still determines what that identity may read or change. A Windows account and an AD LDS account with similar names are not interchangeable. The protocol’s supported principal types defines the combinations.
For simple binds, protect the credentials with TLS and validate the server certificate. Compare the exact bind type used by the application with LDP’s test. Testing a Windows integrated bind does not prove an application’s simple-bind password works.
Bind redirection is different from synchronization
A proxy object can refer to a Windows principal by SID so that AD LDS redirects authentication to AD DS under the documented constraints. That object is not an independent copy of the user’s password. TLS and appropriate connectivity remain dependencies.
ADAMSync synchronizes selected data from AD DS to AD LDS according to its XML configuration. It does not turn the two into one multimaster directory. Inspect the base DN, included attributes, schema mappings and synchronization state. Distinguish application data synchronization from native replication among AD LDS replicas.
For a missing user, work through the data flow: was the source object included, could ADAMSync read the required attributes, did the mapping support them, and did the result reach the instance you’re querying? Signing in to the LDS host won’t test those steps. This ADAMSync scope failure shows why the exact base DN matters.
Inspect the configuration actually installed in the instance
ADAMSync installs its XML configuration into the application’s partition head. It won’t necessarily use the file you’ve just edited on disk. Compare the installed configurationFile value with the configuration you intended, and keep the log from that synchronization run. The Microsoft ADAMSync walkthrough covers this and the required schema/metadata imports.
With the instance’s ADWS path available, an illustrative read is:
$applicationNC = 'CN=AppData'
Get-ADObject -Server $instance -Identity $applicationNC `
-Properties configurationFile |
Select-Object DistinguishedName,configurationFile
Replace the partition with the application’s DN, and restrict access to exported configuration and logs as needed. Check that the configuration was installed, the synchronization reached one replica, and the data then reached the instance the application uses. If it fails, start with the first failing object/attribute and its extended LDAP error before rerunning the whole job or importing more schema.
ADAMSync does not synchronize AD user passwords. A user-proxy transformation changes the authentication design: its SID reference depends on the AD principal and an available authentication path. Recreating or migrating that source identity can therefore break redirection even if the display name is unchanged. A bind result is not evidence that the application’s data mappings or authorization were preserved.
Check the service identity when TLS fails
The instance service must be able to use the intended certificate and its private key. Check the certificate’s purpose, name, chain, validity and key access for the actual service identity. Do not solve the problem by granting broad permissions to the whole machine-key directory. Compare a successful TLS connection and an authenticated LDAP operation separately.
Back up the instance deliberately
Check that the backup job actually selects the LDS instance and uses its VSS writer or another application-aware process. The job being called “system state” doesn’t establish that. Test an instance restore, including the service identity, certificates/private keys, configuration and application data. You’ll also need to choose authoritative or nonauthoritative recovery for replicated data.
vssadmin list writers
Run this locally in an elevated session to inspect current writer state, then compare the backup product’s actual selected components and writer results. A writer being stable now does not prove it participated in last night’s backup. The in-box LDS VSS writer identifies the instance database/log requirements and restore metadata.
After a supported restore, decide whether partner data should update that replica or selected restored data must become authoritative. Do not apply AD DS DSRM assumptions to stopping and restoring an LDS service. The LDS restore procedure describes the instance-specific use of Dsdbutil and subsequent validation.
Recycle Bin support in AD LDS is scoped to an LDS configuration set, not an AD DS forest, and needs the applicable feature support and enablement. Optional feature semantics define that scope.