When the application can’t federate, and can’t be changed
Adding MFA to a modern application is a configuration task. It redirects to an identity provider, the identity provider does the work, and a signed assertion comes back.
Now take the ones that can’t do that. The ERP that checks a username and password straight against Active Directory. The appliance with a fixed login screen. The in-house system nobody is allowed to touch. There is no redirect to hook and no federation to configure — and, the part that ends most projects, no way to modify the application.
The application that can’t be modified is the one that most needs a second factor.
The usual reasoning is circular: MFA needs the application to support it, the application can’t be changed to support it, so the application stays on a password. The way out is to stop asking the application to change at all.
Four ways in when the application can’t federate
The question isn’t whether the application supports MFA. It’s what the application already speaks — because that is where the second factor goes.
| If the application… | Mirket adds the second factor… | Change to the application |
|---|---|---|
| binds over LDAP or LDAPS | in the bind path, before it reaches the domain controller | None |
| is Exchange OWA or ECP | with an agent on the Exchange server, on the sign-in screen itself | None |
| is Exchange ActiveSync | as device approval, before a new handset can sync | None |
| speaks none of the above | by publishing the application through PAM | None |
That last row is the one that makes the set complete. Everything else depends on the application speaking a protocol Mirket can stand in front of; PAM doesn’t, because the user reaches the application through Mirket instead.
LDAP and LDAPS — the second factor goes in the bind
Most legacy business applications authenticate the same way: they take the username and password the user typed and bind to Active Directory with them. That bind is the hook.
The application is pointed at Mirket rather than at the domain controller. What happens next runs in reverse order to the usual second factor — the approval comes first, and the password is checked afterwards:
- The application makes its LDAP bind, exactly as it always has.
- Mirket sends a push to the phone of the person named in that bind.
- The user approves it.
- Only then is the password validated against Active Directory.
- The bind succeeds or fails, and the application gets its answer.
From the application’s side nothing has changed — it made an LDAP bind and got an answer. But the order has a consequence worth noticing: a password that nobody approves is never tested against the directory at all. A rejected or ignored push ends the attempt before Active Directory is ever asked.
- Push approval only, and there's a reason An LDAP bind is one request and one answer, with nowhere to prompt for a code. So the second factor has to happen out of band: the bind waits while the approval is answered on the phone. Where a population needs a different method, that application belongs on the PAM path instead.
- Service accounts don't wake anybody A directory is queried constantly by integrations. Binds made with service credentials are exempt from the policy and raise no prompt — the distinction is made on the bind identity, so only a real person signing in triggers a challenge.
A distinction worth keeping straight: adding a second factor to the human logins an application performs is a different job from securing the service account the application binds with. That second one — the credential that reads the directory and never signs in — is NHI LDAP Proxy and the LDAP Service Account Security pillar. This page is the human half.
Exchange OWA and ECP — on the sign-in screen, without ADFS
Outlook Web Access and the Exchange Control Panel are their own case, because the usual answer is “put ADFS in front of it” — which means standing up and maintaining a federation estate to protect one mail interface.
Mirket doesn’t need it. An agent on the Exchange server applies the challenge on the OWA sign-in screen itself, with no page redirect and no ADFS in the path. The user signs in where they always have, and the second factor appears there.
It’s selectable rather than all-or-nothing: enable it for the groups that need it, with bypasses for the ones that don’t yet.
ActiveSync — approve the device, not just the password
A mailbox reached from a phone is a different problem. The credential is entered once, in a mail app, and after that the device syncs quietly in the background — so a stolen password can bring an attacker’s handset online without anyone noticing a login at all.
Mirket handles it as device approval: a device that starts synchronising for the first time has to be approved before it reaches the mailbox. A password on its own doesn’t get a new phone onto the mail estate.
And approving it isn’t a help-desk job — a user can approve their own new device through Secure Self-Service.
PAM — for the application that speaks nothing at all
Some applications offer no hook whatsoever. No federation, no LDAP, not even a protocol to stand in front of. A thick client with its own user database. A management console with a local login. Something ancient enough that nobody documented how it authenticates.
For those the approach is inverted: instead of putting the second factor inside the application’s authentication, the application is published through Mirket PAM and the user reaches it through Mirket.
- Authenticated at every connection The user authenticates to Mirket — with any method the platform supports, not just push — and is authorised for that specific target before the connection opens.
- The credential can stay hidden The application's password is held by Mirket and injected into the session, so the user opens the application without ever knowing what it was.
This is also the answer when the LDAP path exists but the push-only constraint doesn’t suit the population — the same application can be reached through PAM with the full method set instead.
Not sure which path fits your application? Tell us how it authenticates today. Find your path →
What changes with Mirket
| Before | With Mirket |
|---|---|
| Password-only LDAP authentication | Push approval first, followed by Active Directory password validation |
| MFA requires the application to support it | The application is never touched |
| OWA needs an ADFS estate to gain MFA | An agent on the Exchange server, no ADFS |
| A stolen password brings a new phone onto the mailbox | The device is approved before it can sync |
| An application with no protocol hook is simply skipped | It is published through PAM and authenticated there |
| Every directory query would wake somebody’s phone | Service-account binds are exempt; only human logons prompt |
Frequently asked questions
How do you add MFA to an application that doesn't support SAML, OpenID Connect or another modern identity integration?
Through something else it already does. If it binds to the directory over LDAP or LDAPS, Mirket sits in that bind path. If it is Exchange OWA or ECP, an agent on the Exchange server adds the challenge to the sign-in screen. If it is ActiveSync, the device is approved before it can sync. And if it speaks none of those, the application is published through Mirket PAM and authenticated there. In every case the application itself is unchanged.
Can Mirket add MFA to an application that only speaks LDAP?
Yes, and the order may not be what you expect. Mirket LDAP Proxy uses a reverse MFA flow: the user approves the push challenge first, and only then is the directory password validated against Active Directory. The application keeps binding exactly as it does today — not a line of code changes, and nothing beyond the directory address it points at.
Which authentication method does the LDAP path use?
Push approval only. An LDAP bind is a single request with no way to prompt the user for a code, so the second factor has to happen out of band — the request waits while the approval is answered on the phone. If a population needs a different method, the right path for that application is PAM rather than LDAP.
Will every directory query trigger an MFA prompt?
No. Binds made by the service credentials that applications and integrations use are exempt and produce no prompt — the distinction is made on the bind identity. Only a genuine end-user logon raises a challenge. Without that split a directory under constant query would be unusable.
Does Mirket support MFA for Outlook Web Access?
Yes, for both OWA and the Exchange Control Panel, and without ADFS in the path. An agent on the Exchange server applies the challenge on the OWA sign-in screen itself, with no page redirect. It can be enabled for selected users or groups rather than the whole organisation.
Can Mirket protect Exchange ActiveSync?
Yes, as device approval. A mobile device that starts synchronising for the first time has to be approved before it can reach the mailbox, so a stolen password alone does not bring a new handset online. The user can approve their own device through Secure Self-Service rather than raising a ticket.
What if the application speaks nothing useful at all?
Then it is published through Mirket PAM. The user reaches it through Mirket rather than directly, authenticates there with any method the platform supports, and the session is authorised and recorded. The credential for the application can be injected rather than shown, so the user never holds it.
Does the application have to be modified?
No, on any of the four paths. That is the entire premise — the systems this page is about are the ones nobody is allowed to touch. The change is made in the path the application already uses, not in the application.
What if we can change the application?
Then a fifth option opens: Mirket publishes a single authentication endpoint that in-house software can call directly, with a Postman collection to work from. It needs development effort, so it doesn't belong with the four paths above — but where the team owns the code it is the cleanest result.
Is this the same as securing the service account the application uses?
No, and the two are often confused. This page is about the human logins an application performs. The account the application itself binds with — the non-human credential that can read the directory and never signs in — is a separate problem, covered by NHI LDAP Proxy and the LDAP Service Account Security page.
Does this work on-premise and as a service?
Yes. All four paths are available on either deployment. The agents — the LDAP proxy, the Exchange agent, the ActiveSync agent — run inside your network in both cases, because that is where the application and the mail estate are.
Related
Solutions — LDAP Service Account Security · Web & Desktop Application Access · VPN & Firewall MFA · On-Premise SSO
Products — Multi-Factor Authentication · Privileged Access Management · NHI LDAP Proxy
Industries — Manufacturing · Healthcare