How to Set Up AD LDS (Lightweight Directory Services) on Windows Server 2025

How to Set Up AD LDS (Lightweight Directory Services) on Windows Server 2025

Active Directory Lightweight Directory Services (AD LDS) is a standalone LDAP directory service that runs independently of Active Directory Domain Services. Unlike AD DS, AD LDS requires no domain membership, supports multiple isolated instances on a single server, and imposes no Group Policy or Kerberos infrastructure requirements. This makes it ideal for application-specific directory needs — particularly when ISVs or internal developers need an LDAP store for storing user credentials, application configuration, or extranet identities without touching the corporate AD. Windows Server 2025 ships with an improved AD LDS setup experience and full support for modern TLS configurations. This guide walks through installing the AD LDS role, creating and configuring an instance, connecting to it with administrative tools, importing custom schema, and securing the instance with SSL.

Prerequisites

• Windows Server 2025 (Standard or Datacenter edition), domain-joined or workgroup
• Local Administrator rights on the target server
• Understanding of basic LDAP concepts (Distinguished Names, Object Classes, Attributes)
• Optional: An AD CS certificate authority for SSL/TLS configuration
• RSAT tools installed if managing remotely (RSAT-ADLDS)
• LDIF files ready if you plan to import a custom schema

Step 1: Install the AD LDS Role

AD LDS is a Windows Server role that can be installed independently from AD DS. Install it via PowerShell:

# Install AD LDS role
Install-WindowsFeature ADLDS -IncludeManagementTools

# Verify installation
Get-WindowsFeature ADLDS, RSAT-ADLDS | Select-Object Name, InstallState

# If you are managing remotely, install RSAT on your admin workstation
# (Windows 10/11 with RSAT)
Add-WindowsCapability -Online -Name Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0

Step 2: Create an AD LDS Instance with adamssetup

Each AD LDS deployment is an independent instance with its own database, port, and configuration. You can run multiple instances on the same server — for example, one for a web application and another for a partner portal. Use adamssetup.exe to create your first instance:

# Launch AD LDS Setup Wizard (GUI)
adamssetup.exe

# For unattended/silent installation, use an answer file
# Create the answer file:
@'
[ADAMInstall]
InstallType=Unique
InstanceName=AppDirectory
LocalLDAPPortToListenOn=389
LocalSSLPortToListenOn=636
NewApplicationPartitionToCreate=DC=AppDir,DC=local
DataFilesPath=C:WindowsADAMAppDirectory
LogFilesPath=C:WindowsADAMAppDirectory
ServiceAccount=.ADAMLDSSvc
ServicePassword=P@ssw0rd!
Administrator=contosoAppDirAdmin
ImportLDIFFiles=MS-User.LDF MS-UserProxy.LDF MS-InetOrgPerson.LDF
SourceUserName=contososvcLDSSetup
SourcePassword=SetupP@ss!
'@ | Out-File -FilePath "C:Tempadam-setup.ini" -Encoding ascii

# Run silent setup using the answer file
adamssetup.exe /answer:"C:Tempadam-setup.ini"

If a standard AD DS installation already occupies port 389, choose an alternative port (e.g., 50000 for LDAP and 50001 for LDAPS). Multiple instances on the same server must each have unique ports.

Step 3: Connect to AD LDS with ldp.exe and ADSI Edit

After the instance is running, verify connectivity using built-in administrative tools:

# Check that the AD LDS service is running
Get-Service -Name "ADAM_AppDirectory" | Select-Object Name, Status, StartType

# Check which port the instance is listening on
netstat -ano | findstr ":50000"

To connect with ldp.exe:

1. Open ldp.exe from Start or run ldp.exe in PowerShell
2. Go to Connection → Connect, enter the server name and your custom port (e.g., 50000)
3. Go to Connection → Bind, choose Simple bind and enter the AD LDS administrator’s credentials
4. Browse the directory tree via View → Tree

To connect with ADSI Edit:

1. Open adsiedit.msc
2. Right-click ADSI Edit and choose Connect to…
3. Under Connection Point, enter your Application Partition DN: DC=AppDir,DC=local
4. Under Computer, enter the server and port: ADSRV01:50000

Step 4: Understand the Difference Between AD DS and AD LDS

AD LDS differs from AD DS in several fundamental ways:

• No domain: AD LDS does not create a Windows domain. There are no trust relationships, no Kerberos KDC, and no domain-wide authentication.
• No Group Policy: GPOs do not apply to AD LDS instances or their objects.
• Multiple instances per server: You can run many independent AD LDS instances on one server, each with a separate database, schema, and port.
• Application-scoped schema: The AD LDS schema is separate from the AD DS schema and can be extended without affecting your production forest.
• Flexible authentication: Supports simple bind (username/password over LDAPS), SASL, and Windows-integrated security (proxying to AD DS accounts via userProxy objects).
• No SYSVOL or replication topology complexity: Replication is configured explicitly between AD LDS instances using replication agreements.

Step 5: Import Custom Schema with ldifde

AD LDS ships with several built-in LDIF schema files located in %windir%ADAM. You can import these or your own custom schema definitions:

# List built-in AD LDS LDIF schema files
Get-ChildItem "$env:windirADAM*.ldf" | Select-Object Name

# Import the MS-User schema (adds user object class support)
ldifde -i -f "$env:windirADAMMS-User.LDF" `
    -s localhost:50000 `
    -k `
    -j "C:Templdifde-logs" `
    -b ADAMAdmin localhost ""

# Import the MS-InetOrgPerson schema
ldifde -i -f "$env:windirADAMMS-InetOrgPerson.LDF" `
    -s localhost:50000 `
    -k `
    -j "C:Templdifde-logs" `
    -b ADAMAdmin localhost ""

# Import a custom schema extension LDIF file
ldifde -i -f "C:TempMyApp-Schema.ldf" `
    -s localhost:50000 `
    -c "DC=X" "DC=AppDir,DC=local" `
    -j "C:Templdifde-logs"

To export existing directory data for migration or backup:

# Export all objects from the application partition
ldifde -f "C:TempAppDir-Export.ldf" `
    -s localhost:50000 `
    -d "DC=AppDir,DC=local" `
    -p subtree

Step 6: Common Use Cases

AD LDS is well-suited for several real-world scenarios:

• Web application user store: Store application-specific user profiles, preferences, and credentials without polluting the corporate AD. Applications authenticate directly to the AD LDS LDAP endpoint.
• Extranet or partner portal: Provision external partners or contractors in an isolated directory that has no access to internal resources.
• Directory-aware application development: Developers test LDAP integrations against a local AD LDS instance without needing access to production AD DS.
• Schema prototyping: Test schema extensions in AD LDS before applying them to the production forest.

Step 7: Configure SSL for AD LDS

By default, AD LDS accepts plaintext LDAP connections. For production deployments, always enable LDAPS. You need a certificate with a Server Authentication EKU bound to the AD LDS service account:

# Request a certificate for the AD LDS instance using certreq
# First, create a request INF file
@'
[Version]
Signature="$Windows NT$"

[NewRequest]
Subject = "CN=ADSRV01.contoso.com"
KeySpec = 1
KeyLength = 2048
Exportable = TRUE
MachineKeySet = TRUE
SMIME = False
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = PKCS10
KeyUsage = 0xa0
HashAlgorithm = SHA256

[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1 ; Server Authentication
'@ | Out-File -FilePath "C:Templdaps-request.inf" -Encoding ascii

# Submit the certificate request
certreq -new "C:Templdaps-request.inf" "C:Templdaps-request.req"
certreq -submit -config "CA01.contoso.comContoso-CA" "C:Templdaps-request.req" "C:Templdaps.cer"
certreq -accept "C:Templdaps.cer"

# Bind the SSL certificate to the AD LDS instance using dsmgmt
dsmgmt
# At the dsmgmt prompt:
# ldap policies
# connections
# connect to server localhost:50000
# q
# q
# q
# Then restart the AD LDS service
Restart-Service "ADAM_AppDirectory"

# Verify SSL is working
ldp.exe  # Connect on port 50001 with SSL checkbox checked

Conclusion

AD LDS on Windows Server 2025 provides a lightweight, flexible LDAP directory service that meets the needs of application developers and architects who require directory functionality without the overhead of a full Active Directory domain. By supporting multiple instances per server, a customizable schema, and standard LDAP interfaces, AD LDS integrates cleanly with web applications, partner portals, and development environments. Once your instance is running, harden it immediately by enabling SSL, restricting anonymous binds, and auditing LDAP connections. As your directory grows, consider adding replication between AD LDS instances for high availability — a capability built directly into the service and configurable through standard AD replication tools.