Retiring on-premises Active Directory: apps that can stall the move

The apps, not the directory, usually stop the migration

A 2026 migration programme can look 90% complete and still fail because one payroll app only speaks NTLM, one Oracle connector still binds to LDAP on a hard-coded port, and one Windows service runs under a domain account nobody dares touch. That last 10% often consumes 60-70% of the effort, and it is where on-premises Active Directory retirement gets held hostage.

If you are planning to retire on-premises Active Directory, assume the directory is not the real blocker. The blocker is usually an application dependency graph that was never documented, never tested under modern identity controls, and never owned by a single team.

The application classes that most often block Active Directory retirement

1) Legacy line-of-business apps with hard-coded LDAP or Kerberos dependencies

These are the obvious offenders: ERP, MES, finance, and warehouse systems built before cloud identity became normal. They often use direct LDAP binds, Kerberos constrained delegation, or custom auth libraries tied to a specific domain controller IP.

A common pattern in 2026 is a vendor app that still requires:

• LDAP over 389 or LDAPS over 636 to a specific host
• NTLM fallback for service-to-service calls
• SPNs registered under a domain service account
• Password rotation only through a manual vendor utility

Example: a manufacturing execution system with 1,200 daily users may still authenticate via LDAP bind latency of 40-70 ms per request. That sounds fine until the app performs 18 binds per transaction and spikes to 1.2 seconds at peak. When you replace the bind target with Entra ID or an identity proxy, the app breaks because it expects a directory tree, not a token.

2) Windows services, scheduled tasks, and batch jobs running as domain users

These are the silent blockers. They do not show up in user login reports, but they can keep a domain alive for years.

Look for:

• DOMAIN\svc_* accounts used by Windows services
• Scheduled tasks that call network shares or SQL Server using integrated auth
• Batch jobs launched by old orchestration tools such as Control-M, Autosys, or custom PowerShell wrappers

A realistic example: a nightly billing job runs 26 minutes on-prem using a domain account with Log on as a batch job. After migration, the same job fails because the share permissions were tied to AD group membership and the SQL login mapped to a Windows SID. The fix is usually not "move the job"; it is to replace the authentication path with managed identity, certificate auth, or a service principal and then prove the run time stays within a 5% variance.

3) Apps with embedded LDAP bind credentials or static service accounts

These are the ones that cause security teams to lose sleep. The app stores a username and password in a config file, Windows registry key, Java keystore, or a third-party secrets vault that nobody audits.

In 2026, the red flag is not just static credentials. It is static credentials paired with:

• no TLS certificate validation
• no support for OAuth/OIDC
• no API-based provisioning
• no external secret rotation hook

A concrete case: an HR portal uses a Java properties file with bind.user=svc_hr_read and bind.password=.... The vendor says rotation is supported, but only after a restart, and the restart drops in-flight sessions for 90 seconds. If you have 14,000 employees using the portal, that is not a maintenance window; that is a business incident.

4) Apps that depend on AD groups for authorization, not just authentication

Many teams plan for sign-in replacement and forget authorization. The app may authenticate through SSO but still query AD groups to decide whether a user can approve invoices, release code, or export customer data.

This matters because group logic is often:

• nested 5-10 levels deep
• mapped to legacy role names
• synchronized into local app tables once per day
• used by downstream systems that never talk to the identity provider directly

If your app reads CN=Finance-Approvers,OU=Groups,DC=corp,DC=local to grant access, you need a role model migration, not just a login migration. In one retail deployment, replacing group checks with app roles cut authorization lookup time from 180 ms to 22 ms, but only after the team flattened 4,300 nested groups into 68 business roles.

5) Apps with protocol or platform constraints

Some applications can authenticate only through protocols that modern identity platforms do not expose natively. Others are tied to OS versions that cannot be patched to support newer agents or libraries.

Watch for:

• NTLM-only apps
• apps requiring SMB access to SYSVOL or NETLOGON
• Java 6/7 runtimes that cannot handle current TLS defaults
• .NET Framework apps with old LDAP libraries
• thick clients that cache domain credentials locally

If the app only supports NTLM, the migration path usually includes one of three patterns: front it with a modern auth proxy, isolate it behind a brokered access layer, or retire it. There is no magic switch that makes NTLM become OIDC.

How to find the hostage apps before they find you

Build an application dependency inventory from three angles

Do not rely on CMDB data alone. By 2026, most CMDBs are 30-50% wrong for identity dependencies.

Use three sources:

1. Directory telemetry: sign-in logs, LDAP query logs, Kerberos ticket activity, and DC audit events.
2. Infrastructure telemetry: Windows service accounts, scheduled tasks, IIS app pools, Linux Samba joins, and network flow logs.
3. Application telemetry: config files, secrets stores, code repos, and vendor documentation.

A practical rule: if an app has not generated at least one auth event in 30 days, it is either dead or hidden. Both deserve investigation.

A simple triage matrix

Use a scorecard that combines business criticality and identity complexity.

App risk score = Business criticality (1-5) + Auth complexity (1-5) + Change resistance (1-5)

Score 12-15: block retirement until remediated
Score 8-11: migrate with a parallel run and rollback plan
Score 3-7: low risk, batch into wave 2

Example output:

• SAP add-on used by finance: 15
• Internal wiki: 5
• Vendor timekeeping app: 13
• Plant floor barcode scanner: 14

That ranking gives you a queue, not a guess.

Trace actual dependencies with packet and log evidence

When teams say "the app only talks to AD for login," they are often wrong. Capture proof.

# Find Windows services using domain accounts
Get-CimInstance Win32_Service |
  Where-Object { $_.StartName -like '*\\*' } |
  Select-Object Name, StartName, State, StartMode

# List scheduled tasks running under domain identities
Get-ScheduledTask |
  ForEach-Object {
    $info = $_ | Get-ScheduledTaskInfo
    [PSCustomObject]@{
      TaskName = $_.TaskName
      RunAs = $_.Principal.UserId
      LastRun = $info.LastRunTime
      LastResult = $info.LastTaskResult
    }
  } | Where-Object { $_.RunAs -like '*\\*' }

Pair this with NetFlow or firewall logs to identify LDAP, Kerberos, SMB, and SQL traffic to domain controllers. In one enterprise, this exposed 47 apps still calling DCs every 15 minutes, even though only 19 were listed in the migration tracker.

The remediation patterns that actually work in 2026

Pattern 1: Put a modern auth broker in front of the app

Use this when the app can accept header-based auth, SAML, or OIDC through a reverse proxy, but cannot talk modern identity natively.

Typical stack:

• Azure Application Proxy, PingAccess, or F5 APM
• OIDC/SAML to the identity provider
• Header injection or Kerberos delegation to the backend

User -> IdP (OIDC/SAML) -> Auth Proxy -> Legacy App
                               |
                               +-> token validation, MFA, conditional access

This pattern works well for internal portals and admin tools. It usually cuts helpdesk password resets by 20-35% because users stop authenticating directly to the app.

Pattern 2: Replace domain accounts with managed identities or certificates

This is the cleanest fix for service-to-service traffic, especially for Azure-hosted workloads and APIs.

Use:

• managed identities for Azure resources
• workload identity federation for CI/CD and Kubernetes
• client certificates for older middleware
• secret rotation through a vault with API hooks

Example: a .NET API calling SQL Server can move from DOMAIN\svc_api to a managed identity plus Azure SQL or to certificate-based auth against a gateway. The result is usually a 30-60% reduction in credential sprawl and a measurable drop in privileged account exposure.

Pattern 3: Split auth from authorization

If the app still needs AD groups for permissions, keep the business roles but move the source of truth.

{
  "roles": [
    { "name": "FinanceApprover", "source": "Entra ID", "mappedFrom": "legacy-ad-group-finance-approvers" },
    { "name": "WarehouseSupervisor", "source": "app-role-store" }
  ]
}

This lets you retire AD for identity while keeping the business policy intact. In practice, teams that flatten nested group logic usually reduce authorization defects by 15-25% because the role model becomes testable.

Pattern 4: Isolate or retire the impossible apps

Some apps are not worth modernizing. If the vendor is out of support, the app requires NTLM, and the business process can be replaced in under 90 days, retire it.

If retirement is not possible, isolate it:

• place it behind a segmented access tier
• restrict it to a dedicated legacy identity bridge
• block direct DC access from user subnets
• enforce read-only access where possible

This is not elegant, but it keeps the programme moving.

Common Pitfalls

Assuming SSO means the app is ready

SSO only proves one login path works. It says nothing about service accounts, background jobs, group lookups, or API callbacks. Test the full auth chain, not just the front door.

Changing the directory before the app owner signs off

If you retire or freeze AD objects before the app team validates a replacement path, you will create outages that look like "identity issues" but are really change-control failures.

Ignoring non-Windows dependencies

Linux Samba joins, printer auth, NAS devices, VMware plugins, and backup software often depend on AD in ways no one documents. In one migration, a tape backup system caused a 14-hour delay because its service account was also used for SMB access to archive shares.

Underestimating test volume

A single successful login test is not enough. For each hostage app, run:

• one interactive login test
• one service account test
• one scheduled task or batch job test
• one failover test against a secondary identity endpoint

Teams that automate these checks usually cut cutover defects by 40-55% compared with manual validation alone.

Forgetting rollback design

If the app cannot tolerate a failed auth change, you need a rollback that restores the old path in under 15 minutes. That means keeping old SPNs, old secrets, and old proxy rules intact until the new path has survived at least one full business cycle.

A practical 30-day plan to stop the programme from stalling

1. Rank every app by business criticality and identity complexity.
2. Pull service accounts, scheduled tasks, and LDAP query evidence into one inventory.
3. Classify each blocker as broker, replace, isolate, or retire.
4. Run parallel auth tests for the top 10 risk apps.
5. Freeze any app that cannot prove a working fallback path.
6. Publish a cutover map with owners, rollback steps, and success metrics.

A realistic target for a mid-size enterprise is to identify 80% of hostage apps in 3 weeks and remediate the top 20% of them in the next 30-60 days. That is usually enough to unblock the wider Active Directory retirement workstream.

Key Takeaways

• Treat on-premises Active Directory retirement as an application remediation programme, not a directory swap.
• Start with the apps that use LDAP binds, NTLM, domain service accounts, or AD group-based authorization.
• Build your inventory from telemetry, not CMDB entries alone.
• Choose one of four fixes: broker, replace, split, or isolate.
• Test interactive login, service auth, scheduled jobs, and rollback before you cut over.
• Keep legacy paths alive until the new path survives a full business cycle.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.