Securing LDAP Service Accounts in Active Directory: Mirket NHI LDAP Proxy

Firewalls, VPNs, NAC, print servers, ERP and legacy applications almost all bind to Active Directory over LDAP, each with a service account whose password never changes. In a new three-minute video, Mirket Security shows how those accounts get compromised and how Mirket NHI – LDAP Proxy protects them. This post summarises the approach in the video and what you should know before rolling it out.

Why accounts with never-changing passwords are so risky

Among non-human identities (NHI), LDAP service accounts are the most widespread and the least managed. Mirket's solution brief describes the problem as five layers stacked on top of each other:

• Clear text: In a simple bind over 389/tcp the username and password cross the network unencrypted; capturing a single packet is enough.
• Rotation paralysis: The same password sits in every product's configuration, backups, installation documents and support tickets. Changing it means touching dozens of products, so in practice it is never changed.
• Broad read access: Default directory read permission is rarely narrowed per product; every integration can enumerate users, groups, OUs, SPNs and passwords left in description fields.
• LDAPS alone is not enough: Some products do not support LDAPS, others disable certificate validation. A single legacy product that cannot speak LDAPS blocks LDAP signing and channel binding hardening on the domain controller.
• Detection gap: Reconnaissance with a valid service credential produces no failed logons and blends into normal traffic.

An attack chain that needs no vulnerability

What makes the scenario in the video striking is that no step exploits a vulnerability. The attacker's path looks like this:

1. Gains a position on the network from which traffic is visible.
2. Captures the service account credential during a simple bind.
3. Binds to a domain controller with it from anywhere.
4. Reads almost the entire directory.
5. Uses what was collected to build a targeted privilege escalation attack.

Because the service account has no MFA and the password has been the same for years, the captured credential becomes a key that stays valid indefinitely.

Where Mirket NHI LDAP Proxy breaks the chain

The solution places a single, policy-enforced point between the products and the domain controllers. It has two components: the LDAP Proxy agent, which terminates traffic, applies the decision and logs binds, and the Mirket Portal, which evaluates credential status, source IP, DN scope and MFA. The proxy makes no decision of its own; the decision comes from the Portal.

Virtual credentials

Each product receives its own virtual credential that only Mirket recognises and that has no counterpart in Active Directory. The real AD password never enters a product's configuration. That gives per-product attribution, lets you revoke one product's access without touching the others, and makes a stolen virtual credential useless for Kerberos, SMB or any other system.

Daily automatic password rotation

Since only Mirket knows the real password, the password on the AD side can be rotated every day without touching a single product. Rotation that has been postponed for years stops being a project and becomes a background routine.

Source IP and DN scope

Each credential is accepted only from defined source IP addresses and is limited to a specific DN scope; for example, the VPN product can query only the OU that holds VPN users. Out-of-scope searches are rejected by the proxy. A stolen credential is not portable to another machine.

Protocol uplift and ADV190023

Even if a product speaks plain LDAP to the proxy, the proxy connects to the domain controller over LDAPS or signed LDAP. The clear-text segment shrinks to the leg between product and proxy, and the LDAP signing and channel binding hardening recommended in Microsoft's ADV190023 can be enabled without touching legacy products. Certificates are managed in one place as well.

MFA for LDAP-only legacy applications

Legacy applications that support neither RADIUS, SAML nor OIDC have no stage for a second factor. The proxy sends end-user binds to the Portal; a push notification goes to the user's phone, the bind is forwarded if approved and blocked if rejected or unanswered. Service account binds are exempt from this step, and no application code change is needed.

Built-in honeytoken

A virtual credential showing up anywhere outside the proxy has no legitimate explanation, so Mirket treats it as a breach signal with a near-zero false positive rate. An attempt from an off-policy source is both blocked and raised as a security event. That signal complements the identity threat detection carried out with Mirket ITDR.

Before and after

What to know before rolling it out

The solution brief is also explicit about the order of the rollout and its limits. These points stand out when planning:

• Inventory first: Which product binds from where and how is derived from events 2886, 2887, 2888 and 2889 on the domain controller. Those events do not show LDAPS and signed clients, so they should be backed by network-level capture.
• Do not forget the Global Catalog: The control must cover ports 3268 and 3269 alongside 389 and 636; otherwise it loses its meaning.
• You cannot write a “block everything except the proxy” rule: Group Policy, certificate autoenrollment and queries between controllers need LDAP. Blocking is limited to third-party sources.
• Products move one at a time: A virtual credential is created for each product, its LDAP server address is pointed at the proxy and the result is validated. Only then are the ports and signing hardening enforced; automatic rotation and MFA come last, starting with a pilot group.
• The outage scenario must be written down: The proxy runs active-active and the Portal is redundant. Whether requests are rejected or a time-limited exception path applies when the decision layer is unreachable is decided in advance according to the organisation's risk preference.
• Signing is not encryption: Confidentiality requires LDAPS, StartTLS or SASL sealing.

Besides ADV190023, Mirket maps the solution to ISO/IEC 27001:2022, PCI DSS v4 (Requirement 8.6) and GDPR Article 32, but presents that mapping as indicative and recommends confirming it with your compliance team.

Watch the video

The roughly three-minute video walks through the problem, the attack chain and the capabilities above in order: How to Secure LDAP Service Accounts in Active Directory | Mirket NHI.

If you would like to work out together how many products in your environment bind to Active Directory over LDAP and when those accounts were last changed, get in touch with our cybersecurity solutions team.