How to Configure Kerberos Authentication on Windows Server 2022

AD LDS vs AD DS: Understanding the Difference

Active Directory Lightweight Directory Services (AD LDS) is a standalone LDAP directory service that runs on Windows Server 2022 without requiring the full Active Directory Domain Services (AD DS) infrastructure. While AD DS is the enterprise-wide identity store that controls domain logon, Group Policy, and Kerberos authentication, AD LDS is designed for application-specific directory needs where you want LDAP access but do not need — or do not want — to integrate with the domain.

Key differences between AD LDS and AD DS:

• AD LDS does not require a domain. It can run on a standalone server, a domain member, or even a workstation.
• Multiple instances. You can run multiple AD LDS instances on a single server, each listening on a different port with its own database, schema, and configuration.
• No SYSVOL, no FSMO roles, no domain-wide impact. Each instance is independent.
• Application partitions only. AD LDS does not have a domain partition; all data lives in application directory partitions that you define.
• Users authenticate via userProxy objects. AD LDS can proxy authentication to AD DS accounts, or it can maintain its own user objects with passwords.

Common use cases for AD LDS include: web application user stores (e.g., a portal that needs LDAP-based authentication without domain accounts), staging directories for identity management pipelines, LDAP-accessible address books, and any scenario where you need LDAP without the overhead of a full domain controller.

Installing AD LDS on Windows Server 2022

AD LDS is available as a Windows feature. Install it using Server Manager or PowerShell:

Install-WindowsFeature ADLDS -IncludeManagementTools

The management tools installed include ldp.exe, ADSI Edit, and the AD LDS Setup Wizard. Confirm the feature installed correctly:

Get-WindowsFeature ADLDS | Select-Object Name, InstallState, DisplayName

Running the AD LDS Setup Wizard

After installation, launch the AD LDS Setup Wizard from Administrative Tools, or run it from the command line:

adaminstall

The wizard walks you through the following decisions:

• Unique instance name: A short name used to identify this AD LDS instance (e.g., AppDirectory). The Windows service will be named ADAM_AppDirectory.
• LDAP port: Default is 389, but since AD DS may already use that port on a DC, choose a non-conflicting port such as 50000 for LDAP and 50001 for LDAPS.
• Application directory partition: The DN of the partition to create (e.g., CN=AppData,DC=example,DC=com).
• Data file location: Where to store the AD LDS database (default: C:Program FilesMicrosoft ADAMAppDirectory).
• Service account: Network Service is the default; use a dedicated service account for production.
• AD LDS administrators: The local account or AD group that will administer this instance.
• LDIF schema files: Optionally import predefined schema extensions during setup (e.g., MS-User.LDF for user objects).

You can automate instance creation fully with the adaminstall command and an answer file:

adaminstall /answer:C:ldsinstanswer.ini

Example answer file (answer.ini):

[ADAMInstall]
InstallType=Unique
InstanceName=AppDirectory
LocalLDAPPortToListenOn=50000
LocalSSLPortToListenOn=50001
NewApplicationPartitionToCreate=CN=AppData,DC=example,DC=com
DataFilesPath=C:ADLDSAppDirectory
LogFilesPath=C:ADLDSAppDirectoryLogs
ServiceAccount=CORPsvc-adlds
ServicePassword=P@ssw0rd123!
AddPermissionsToServiceAccount=yes
Administrator=CORPadlds-admins
ImportLDIFFiles=MS-User.LDF
SourceUserName=CORPAdministrator
SourcePassword=P@ssw0rd123!

AD LDS Schema

Each AD LDS instance has its own schema, stored in the CN=Schema,CN=Configuration partition of that instance. The base schema is a subset of the full AD DS schema. You can extend it by importing LDIF files using ldifde or the ldapadd equivalent tool.

Microsoft ships several LDIF schema files with AD LDS. They are located at:

C:WindowsADAM

Common LDIF files include:
MS-User.LDF (adds inetOrgPerson and user-like attributes), MS-UserProxy.LDF (adds userProxy class for proxied authentication against AD DS), and MS-AdamSyncMetadata.LDF (for AD LDS/AD DS synchronization).

Import a schema LDIF file into a running instance:

ldifde -i -f "C:WindowsADAMMS-User.LDF" `
  -s localhost:50000 `
  -b "CN=Administrator,CN=Roles,CN=AppData,DC=example,DC=com" "" "P@ssw0rd123!" `
  -j C:ADLDSlogs `
  -k

Managing AD LDS with ADSI Edit

ADSI Edit is the primary GUI tool for browsing and modifying AD LDS content. Open it from Administrative Tools and connect to your AD LDS instance rather than the domain:

adsiedit.msc

In ADSI Edit, choose Action > Connect to…, then set the connection point to the Distinguished Name of your partition (CN=AppData,DC=example,DC=com) and the server/port to localhost:50000. Authenticate with the AD LDS admin account.

To create a new Organizational Unit under the partition, right-click the partition node, choose New > Object, select organizationalUnit, and set the ou attribute. To create a user object (requires MS-User.LDF schema), select user class and set the cn and userPrincipalName attributes.

Managing AD LDS with PowerShell and ldp.exe

Use ldp.exe to connect, browse, search, and modify AD LDS over LDAP. Launch it and choose Connection > Connect, entering the server name and port (e.g., localhost, port 50000). After binding with credentials, navigate the tree with Browse > Search.

From PowerShell, use the AD module cmdlets by specifying the -Server parameter to point at the LDS instance:

$server = "localhost:50000"
$cred = Get-Credential

# Create a new OU
New-ADOrganizationalUnit -Name "AppUsers" `
  -Path "CN=AppData,DC=example,DC=com" `
  -Server $server `
  -Credential $cred

# Create a new user in AD LDS
New-ADUser -Name "appuser1" `
  -SamAccountName "appuser1" `
  -UserPrincipalName "[email protected]" `
  -Path "OU=AppUsers,CN=AppData,DC=example,DC=com" `
  -AccountPassword (ConvertTo-SecureString "P@ssw0rd123!" -AsPlainText -Force) `
  -Enabled $true `
  -Server $server `
  -Credential $cred

Enable the account (AD LDS user accounts require setting the msDS-UserAccountDisabled attribute to FALSE):

Set-ADObject -Identity "CN=appuser1,OU=AppUsers,CN=AppData,DC=example,DC=com" `
  -Replace @{"msDS-UserAccountDisabled"=$false} `
  -Server $server `
  -Credential $cred

Application Directory Partitions

An AD LDS instance can host multiple application directory partitions. Each partition is an independent naming context with its own set of objects, ACLs, and replication scope. Add a second partition to an existing instance:

dsadd partition -dn "CN=SecondApp,DC=example,DC=com" -s localhost:50000

Or using PowerShell:

New-ADDirectoryServerOperationMasterRole -Identity "CN=AppData,DC=example,DC=com"

Each partition appears as a separate tree in ADSI Edit and ldp.exe. Objects in one partition cannot reference objects in another partition by DN within the same search operation.

AD LDS Replication Between Instances

AD LDS supports replication between multiple instances of the same application directory partition for high availability. Unlike AD DS, you configure this manually. All instances participating in replication must have the same partition DN and schema.

Create a second AD LDS instance on another server (or another port on the same server), then configure replication:

# On the first instance, create a replication agreement to the second instance
repadmin /add CN=AppData,DC=example,DC=com `
  SERVER1:50000 `
  SERVER2:50000 `
  /u:CORPadlds-admin /pw:P@ssw0rd123!

Alternatively, use the AD LDS Replication service management. In ADSI Edit, navigate to CN=Configuration,CN=AppData,DC=example,DC=com, then expand CN=Sites > CN=Default-First-Site-Name > CN=Servers and create connection objects for the replication topology.

Monitor replication between AD LDS instances:

repadmin /showrepl SERVER1:50000
repadmin /replsummary SERVER1:50000

Binding to AD LDS with ldp.exe and Testing Connectivity

To verify your AD LDS instance is running and accessible:

# Check service status
Get-Service ADAM_AppDirectory

# Confirm the port is listening
netstat -ano | findstr :50000

# Perform a basic LDAP query using ldifde
ldifde -f C:output.ldf -s localhost:50000 -d "CN=AppData,DC=example,DC=com" `
  -p subtree -r "(objectClass=organizationalUnit)" `
  -l "dn,ou,description"

In ldp.exe: Connect to localhost:50000, bind as CN=Administrator,CN=Roles,CN=AppData,DC=example,DC=com with a simple bind. A successful bind followed by a base search on the partition DN confirms the instance is healthy and queryable.

Using AD LDS for LDAP-Enabled Applications

Applications that support LDAP authentication (web portals, ticketing systems, VPNs) can be pointed at the AD LDS instance instead of the domain controller. Configure the application with:

• LDAP server: Hostname or IP of the AD LDS server
• Port: 50000 (LDAP) or 50001 (LDAPS)
• Base DN: CN=AppData,DC=example,DC=com
• Bind DN: CN=AppServiceAcct,OU=ServiceAccounts,CN=AppData,DC=example,DC=com
• User search filter: (&(objectClass=user)(userPrincipalName=%s))

If you want AD LDS users to authenticate using their existing AD DS credentials (without duplicating passwords), use userProxy objects. Import the MS-UserProxy.LDF schema, then create a userProxy object whose objectSid is linked to the AD DS user SID. Authentication requests against the userProxy are forwarded to AD DS Kerberos.

ldifde -i -f C:WindowsADAMMS-UserProxy.LDF -s localhost:50000 -k

# Create a userProxy object for an existing AD DS user
dsadd user "CN=jsmith,OU=AppUsers,CN=AppData,DC=example,DC=com" `
  -fn John -ln Smith -upn [email protected] `
  -samid jsmith -s localhost:50000 -cln userProxy

AD LDS gives architects a powerful, isolated directory store that integrates cleanly with application stacks without compromising or burdening the production AD DS infrastructure. Its flexibility, multi-instance support, and independent schema make it the right tool for any LDAP-backed application deployment on Windows Server 2022.