LDAP Service Account Security

Nobody has to hack anything

A legacy application performs a simple LDAP bind with a real Active Directory service-account credential. If that traffic crosses the network without TLS, the credential can be read straight out of it — no malware, no privilege, no vulnerability.

The attacker does not need to crack it. They use it. They bind to Active Directory with the same credential and begin querying the directory.

As far as your domain controller is concerned, they are the application.

What comes back isn’t a list of usernames. It’s the map — group membership, who holds privilege, where the service accounts live, which machines exist, how you name things.

The credential is valid. The bind is valid. The query is valid. That is exactly why the theft is hard to distinguish from the application doing its job.

The application should never hold a domain credential

Here is the shift, and everything else on this page follows from it.

Mirket replaces the Active Directory credential stored by the application with a virtual credential that exists only inside Mirket. There is no matching Active Directory account behind it.

The application authenticates to Mirket LDAP Proxy. Mirket validates the virtual credential, the source it came from and the directory scope it is allowed, then uses the protected service-account credential to talk to Active Directory. The application never needs to know the current directory password — or that it changed.

Rotation becomes a security operation, not an application outage

The real password lives behind Mirket instead of inside every application’s configuration. Rotate it without changing the application, because the virtual credential the application holds does not change with it.

That single property is what unsticks the whole problem: rotation stops being a change-window negotiation with every integration owner at once.

What the model gives you

• A credential that only works from where it should Bind the virtual credential to the expected application source. A credential copied out of a configuration file is no longer automatically useful from another machine.
• A credential that only sees what it should Limit directory access to the required DN scope rather than handing an integration visibility across the whole tree because nobody was sure what it queried.
• A credential Active Directory cannot authenticate The virtual credential has no matching directory account. Capturing it does not give an attacker a domain password to reuse for Windows logon, SMB, Kerberos or any other direct Active Directory authentication.
• Binds you can finally see in one place Directory authentication is normally the least observed path you have, because it is spread across every application that speaks LDAP. Through the proxy it is one log.

Theft leaves the path it was given

A stolen virtual credential has no legitimate direct use against Active Directory. Attempts to use it outside its expected LDAP Proxy path become a high-confidence indicator that the credential has escaped the application.

Normal behaviour has a narrow path. Theft leaves it.

That is a quieter signal than anything behavioural, because it doesn’t rest on judging whether activity looked unusual — it rests on the credential appearing somewhere it has no reason to work.

The legacy application can stay legacy. Active Directory doesn’t have to.

An application that only supports LDAP can carry on speaking LDAP to the proxy. Mirket then communicates with Active Directory over LDAPS or a signed LDAP connection.

You modernise the directory-facing side without rewriting the application.

The legacy product keeps speaking plain LDAP. The directory doesn’t.

⚠️ Worth being precise about. This protects the proxy-to-directory leg. If the application still speaks plain LDAP to the proxy, that first hop is unchanged — which is why the proxy belongs inside the trusted segment, and why the two legs are worth discussing separately during design. LDAP and Global Catalog paths can both be brought under the same proxy control.

Humans and service accounts need different controls

The same proxy carries both, and they are not solved the same way.

For human LDAP authentication, Mirket can require a push approval before the directory password is validated at all — the second factor answers first. For service accounts, where nobody is available to approve anything, Mirket uses virtual credentials, source restriction, directory scope and credential rotation instead.

MFA for legacy applications covers the human side in full.

The four fixes everyone tries

This isn’t negligence. Every team that finds this knows what should be done.

None of these controls is wrong. The problem is that legacy applications make them dependent on each other — and Mirket breaks that dependency, because the application is no longer holding the thing all four are about.

What a fix has to do

Four outcomes. Logging and detection follow from them rather than standing alongside.

1. Remove reusable domain credentials from applications. As long as an application holds a real domain password, that password is one configuration-file read away from Kerberos, SMB and password spraying.
2. Constrain each non-human identity by source and directory scope. A firewall’s identity should work from the firewall, and should see the branch it authenticates users against.
3. Rotate the real credential without changing application configuration. If rotation means an outage across every integration, it won’t happen — it hasn’t so far.
4. Modernise the directory-facing authentication path without rewriting the legacy application. Otherwise one product keeps the weakest option alive for everyone.

Check whether legacy LDAP still exists

Active Directory can tell you this without buying anything. The Directory Service event log records unsigned and cleartext binds, which is enough to identify legacy bind activity and start the migration inventory.

Two things to know before you trust the result. Clients that already use LDAPS, or already sign, won’t appear at all — and those are exactly the ones that break when you start restricting ports. And a full business cycle matters, because month-end and quarter-end jobs authenticate too.

What changes

Related

Solutions — Service Account Password Rotation · MFA for Legacy Applications · Account Takeover Detection

Products — NHI LDAP Proxy · Multi-Factor Authentication

Industries — Manufacturing · Healthcare