How to fix Active Directory Lightweight Service.

Question

How to fix Active Directory Lightweight Service.

Stanley Torlowei 0

Hey there,

I recently deployed a missing system configuration from our ManageEngine Portal. Since then, I have been unable to access my Active Directory Lightweight Directory Service. I am getting an error that the service has been disabled and that I should contact my sysadmin. I believe the security config has affected how the Lightweight Directory Service operates. Do you know how I can fix this or revert it by removing the security config? ManageEngine apparently doesn't have a way to revert security configs, and they don't install as an exe or MSI.

Active Directory Lightweight Directory Service is enabled, and I am not sure it has anything to do with the AD LDS service now; there is likely a security or group policy that was altered during the security config deployment. Any insight into how to revert this so I can go back to managing my users, groups, and computers would be very helpful.

Thanks,

Stanley

0 comments

1 answer

Your answer

Answer 1

Hello @Stanley Torlowei

Based on the timing, I agree that the ManageEngine security configuration is the first thing I would investigate, but I wouldn't remove AD LDS or make broad security-policy changes yet.

One important distinction: AD LDS is instance-based. Enabling the Windows Active Directory Lightweight Directory Services feature doesn't necessarily mean the AD LDS instance is running correctly.

First, identify the AD LDS instance and check its service:

Get-Service | Where-Object {$_.DisplayName -like "*Active Directory Lightweight*"}

or:

sc query type= service | findstr /i ADAM

AD LDS instance services commonly use names such as:

ADAM_<InstanceName>

Check whether the affected instance is Running, Stopped, or Disabled. If its startup type was changed to Disabled, don't simply change it back until you determine what policy is enforcing that setting. Otherwise, the next Group Policy/security refresh may apply it again.

Since the problem appeared immediately after deploying a security configuration, I would generate the Resultant Set of Policy:

gpresult /h C:\Temp\gpresult.html

Microsoft recommends gpresult to identify the policies applied to a computer and the resulting policy configuration.

Pay particular attention to:

Computer Configuration > Windows Settings > Security Settings > System Services

This matters because Group Policy can explicitly define both the startup mode and permissions of Windows services.

I would also check Event Viewer immediately after attempting to start the AD LDS instance, particularly:

Windows Logs > System

Windows Logs > Application

Applications and Services Logs

> Directory Service

The exact service-start error/event will help distinguish between a service policy problem, permissions problem, LDAP/security configuration change, or an AD LDS instance problem.

You can also test the instance directly with ldp.exe. Connect to the configured LDAP/LDAPS port and attempt a bind. This helps separate "AD LDS isn't running" from "AD LDS is running, but the application can no longer authenticate/connect."

One other possibility is worth checking: if the security baseline changed LDAP signing requirements, AD LDS handles this per instance using:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services<InstanceName>\Parameters

and the LDAPServerIntegrity value. Microsoft documents 0 as signing disabled and 2 as signing required.

So if the AD LDS service is actually running but ManageEngine can no longer connect, compare that setting and the application's LDAP configuration with the state before the security deployment.

I would troubleshoot this in this order:

Identify the exact ADAM_<InstanceName> service and its current state/startup type.
Run gpresult /h and identify the winning GPO/security policy affecting System Services.
Check Event Viewer for errors generated when starting/accessing the instance.
Test the AD LDS instance directly using ldp.exe.
Check whether LDAP signing, service permissions, firewall rules, or other security settings were changed.
Correct or unlink the specific offending security policy, then run: gpupdate /force

I wouldn't uninstall/reinstall AD LDS or attempt to manually reverse the entire ManageEngine security configuration at this stage. If the deployed configuration changed a centrally enforced GPO/security setting, fixing the local service alone won't be permanent.

If you can share the AD LDS service status/startup type, the error generated when you try to start it, and the relevant System/Application event ID, we should be able to narrow down exactly what the security deployment changed.

Sharing these references with you:

Microsoft - Configure Group Policies to set security for system services

Microsoft - gpresult command

Microsoft - Manage LDAP signing using Group Policy and AD LDS settings

Help make this community better for everyone: if this answer resolved your issue, please accept it or leave an upvote. If not, share more details in a comment so we can continue the discussion and find the right solution.