“We still run on-premises Active Directory. Is that a problem?”
It’s one of the most common questions we hear from IT managers across the United States, usually asked a little nervously, as if they’re confessing something. So let’s clear that up first: running on-premises Active Directory isn’t a crime, and you’re far from alone. Thousands of organizations still rely on domain controllers sitting in a server room, and many of them run just fine.
But “it works” and “it’s the right setup for where you’re headed” aren’t the same thing. In this post, we’ll talk through it the way we would on a call: when on-prem AD is fine, when it starts holding you back, and what moving from On-Prem Active Directory to Microsoft Entra ID really involves.
Is On-Premises Active Directory Actually a Problem?
Short answer: not automatically. On-premises Active Directory is still the backbone of identity for a huge number of organizations, and Windows Server will keep supporting it for years. If your domain controllers are patched, monitored, and backed up, you’re not in trouble today.
The real question is whether it still fits your business objectives and goals. Most teams now live in Microsoft 365, sign in to cloud applications all day, and support users who rarely sit inside the office network. Microsoft Entra ID (the service we all used to call Azure AD) was built for that world as a true cloud IdP. It’s a cloud-based identity and access management service that handles cloud authentication, single sign-on, and security for users, groups, and devices wherever they are.
So the honest answer is: on-prem AD isn’t a problem until it starts costing you more than it gives back. Let’s talk about how to tell.
Signs Your On-Prem AD Is Holding You Back
Here are the signals we look for when we sit down with a client. If two or three of these sound familiar, it’s worth a closer look.
Remote work still depends on VPNs. Users connect through a virtual private network (VPN) just to reach a domain controller or an internal app. With Microsoft Entra ID for VPN authentication, or by removing the VPN entirely, MFA connectivity no longer depends on VPNs.
You’re maintaining an on-premises federation system. Active Directory Federation Services (AD FS) servers need patching, certificates, and load balancers. Microsoft now recommends moving from AD FS to cloud authentication with Password Hash Synchronization (PHS) or Pass-through Authentication (PTA).
Your MFA is aging out. Azure Multifactor Authentication Server (MFA Server) is retired, so anyone still relying on it needs to move to Microsoft Entra multifactor authentication.
Security tools can’t see the whole picture. Features like Conditional Access, Microsoft Entra ID Protection, and Privileged Identity Management work best when the cloud is your primary identity provider, not an afterthought.
Group Policy is doing all the heavy lifting. Hundreds of Group Policy Objects (GPOs) that nobody fully understands make every change risky.
Hardware refreshes keep coming up. Every new domain controllers purchase is a good moment to ask whether you need them at all.
Legacy protocols are everywhere. Kerberos, NTLM, Radius, and LDAP still power older applications, and nobody’s sure which ones.
If two or three of those signs sound familiar, it’s worth a closer look.
We can run an identity assessment, map your app and LDAP dependencies, and tell you which of the three paths fits your business.
Your Three Real Options
When clients ask what they should do, we usually lay out three paths. Each one has trade-offs, and there’s no single right answer for everyone.
Option 1: Stay on-prem (for now)
This makes sense if you have heavy legacy application dependencies, strict data residency or data sovereignty requirements, or you need full administrative control over every server. Some organizations want full control over IAM and simply aren’t ready to change. That’s fine, as long as you keep Windows Server patched, run monitoring, and protect your domain controllers with tools like Microsoft 365 Defender for Identity.
Option 2: Go hybrid identity
This is where most of our clients land first. You keep on-premises Active Directory as the source of truth and use identity synchronization to copy directory data to your Microsoft Entra tenant. You get cloud authentication, single sign-on to SaaS apps, and Conditional Access, without disrupting on-premises workloads.
You have two sync engines to choose from:
Microsoft Entra Connect Sync (make sure you’re on Microsoft Entra Connect V2) is the long-standing option. It handles complex scenarios like merging objects from disconnected sources and custom attribute mapping.
Microsoft Entra Cloud Sync is lighter, uses small agents instead of a full server, and is Microsoft’s recommended direction. Check Microsoft Entra Cloud Sync supported topologies and scenarios before you switch, because matching across forests doesn’t occur with cloud sync.
Common topologies include a single forest, single Microsoft Entra tenant setup, a multi-forest, single Microsoft Entra tenant setup, and even disconnected Active Directory forests after a merger.
Hybrid is often an interim step, not the destination. And that’s okay.
Option 3: Move toward cloud-only
This is the full move from On-Prem Active Directory to Entra ID, sometimes called decoupling from on-premises AD DS. Users, groups, and devices live in Microsoft Entra ID, devices use Microsoft Entra Join, and apps authenticate with modern protocols like SAML, OpenID Connect, OAuth 2.0, and WS-Federation through the Microsoft identity platform. For most organizations, this is a goal of AD DS footprint reduction rather than turning off every domain controller overnight.
What a Move to Microsoft Entra ID Actually Looks Like
People picture a big-bang cutover weekend. In reality, good migration strategies are boring, gradual, and planned. Here’s how a typical phased migration flows.
Start with an identity assessment. Build a discovery baseline: a dependency inventory and an application inventory showing which apps use LDAP, Kerberos, NTLM, or AD FS. The AD FS application activity report in the Entra admin center shows which relying parties can move to Entra ID. For LDAP, tools like Event1644Reader or PSLDAPQueryLogging capture LDAP queries made to domain controllers. Collect at least 24 hours of data, and ideally 30 days, so you catch monthly jobs.
Set up sync the right way. Choose your source anchor (usually ms-DS-ConsistencyGuid, which is based on the ObjectGUID) and check your UserPrincipalName attribute. A matching UPN suffix in the cloud saves a lot of pain later. Use scoping filters, scoping the users and groups accordingly, so you only sync what you need. Watch out for overlapping attribute mappings and schema extensions you’ve forgotten about.
Move authentication to the cloud. Replace AD FS with PHS or PTA, roll out Microsoft Entra multifactor authentication with authentication apps, push notifications, or YubiKey/Token2 hardware tokens, and turn on Conditional Access.
Migrate applications. SaaS apps like Salesforce and Slack usually have a built-in connector from the Azure App Gallery, with SAML-based SSO and SCIM 2.0 application provisioning. Older web apps that rely on headers, cookies, and similar techniques for SSO can be published through Microsoft Entra application proxy or a secure hybrid access partner, which also replaces reverse proxy solutions and WAM systems like Symantec SiteMinder. Expect some potential reconfiguration of apps along the way.
Move devices and policies. Manage Windows 10 devices and Windows 11 with Microsoft Intune as your mobile device management solution. Group Policy analytics in Intune shows which GPOs can become a Settings Catalog policy, and security baselines cover the rest. Macs get Platform SSO for macOS 13 and later. Cloud Kerberos trust lets Windows Hello for Business users still reach on-prem file shares.
Run a pilot group first. A proof of concept pass with a small pilot group, then expand in waves. Done well, the goal is simple: no downtime, no duplicate accounts.
Shrink what’s left. Once users and apps are off AD, you can retire servers and shrink your AD DS footprint step by step.
Along the way, Microsoft Entra entitlement management, Access Reviews, and lifecycle workflows can replace a lot of what Microsoft Identity Manager used to do. And Microsoft Entra External ID with B2B collaboration handles partners and guests without creating accounts in your domain.
“But What About…?” Common Worries, Answered
These are the follow-up questions we get almost every time.
“We have apps that only speak LDAP.”
Very common, and very solvable. LDAP-dependent applications can point to Microsoft Entra Domain Services, a managed domain in Azure that supports LDAP bind, secure LDAP (LDAP over TLS), Kerberos, and NTLM. Some teams use a cloud-hosted LDAP directory such as Foxpass Cloud LDAP or an LDAP Bridge for LDAP compatibility. Long term, many of those apps have SaaS alternatives or can move to modern serverless hosting.
“What about our servers? Can we domain-join servers in Microsoft Entra ID?”
Not the way you’re used to. Entra ID doesn’t offer the same read/write of directory objects, ACLs, or Group Policy that an on-premises database directory like AD does. Your options are to keep a domain controller running on an Azure VM, extend AD DS to IaaS over an Azure virtual network (with VPN gateway connections or Azure ExpressRoute), run an independent AD DS instance in IaaS on Azure infrastructure as a service (IaaS), or use Microsoft Entra Domain Services. Many workloads can also move to platform as a service (PaaS) or serverless hosting, which removes the domain requirement entirely.
Your application server management strategy changes too. Azure Arc brings on-premises servers and Linux machines into Azure for configuration management with Azure Machine Configuration, update management with Azure Update Manager (replacing Windows Server Update Services), and monitoring with Azure Monitor and Azure Monitor VM insights instead of System Center Operations Manager. Microsoft Configuration Manager can stay in the picture during co-management.
“Our network access depends on Radius and VPNs.”
Modern VPN clients like Palo Alto Networks GlobalProtect and Cisco Secure Firewall – Secure Client support SAML sign-in with Entra ID, and the Windows built-in VPN client can use Entra ID too. Radius-based network access can use the NPS extension during the transition. Good VPN gateway design keeps remote access to internal applications working while you modernize.
“What about printers, NAS devices, and old PCs?”
Printers and NAS devices that rely on AD accounts often need firmware updates or a different authentication method. Windows 7 or 8.x machines can’t use Microsoft Entra Join at all, so they need to be replaced. Linux virtual machine (VM) workloads and Linux machines can sign in with Entra ID in many cases, and Remote Desktop, virtual desktop infrastructure (VDI), Azure Virtual Desktop, and Windows 365 all support Entra-based sign-in.
“What if something gets deleted by mistake?”
With soft deletes in Microsoft Entra ID, a deleted user stays restorable for 30 days before it’s hard deleted from Microsoft Entra ID. That’s one more reason to keep good logs and configuration backups during the move.
“Isn’t this a security risk?”
It’s usually the opposite. Moving identity to the cloud gives you Conditional Access, Microsoft Entra ID Protection, and Privileged Identity Management, which help you limit standing Global Administrator access. Security policy management becomes centralized instead of scattered across GPOs and servers.
“Do we need special tools for the actual migration?”
For a straight hybrid setup, Microsoft’s own sync tools are usually enough. For tenant-to-tenant moves, mergers, or moving accounts to a different domain, teams often add third-party tools such as MigrationWiz, CoreView, or MSAdvance. Feature names vary, but most follow a similar pattern:
A Source Agent reads from AD using a service account with AD objects read permissions, sometimes with a SQL Database Connection String if it reads from SQL Server instantiations.
A Target Agent writes to Entra ID through an Application Registration, using an Application (client) ID, Directory (Tenant) ID, and client secret, plus Microsoft Graph permissions like User.ReadWrite.All, Group.ReadWrite.All, and User.EnableDisableAccount.All.
Matching criteria link existing accounts using fields like Employee ID, Email Address, Full UPN, UPN Prefix, SAM Account Name, Display Name, the Alias attribute, or CustomAttribute1 (Extension Attribute). Because the onPremisesObjectIdentifier ties synced users back to AD, matching rules matter.
Options like Simulate Change, Start Scan and Transmit, and Enable Account in Target let you preview changes, run the sync, and activate accounts. You’ll also decide whether incoming data overwrites the target data.
Auto-Sync or continuous sync keeps changes flowing, with faster sync times than manual runs.
A small pilot can often be synced in under an hour. Larger runs are usually scheduled in windows of 60 minutes, 120 minutes, or 240 minutes, depending on volume. The same discipline applies to CI/CD systems and service accounts: inventory them first so nothing breaks.
So, Is It a Problem? Our Honest Take
Running on-premises Active Directory isn’t a problem by itself. It becomes one when it slows down your people, adds risk you can’t see, or keeps you paying for servers and VPNs you don’t really need.
The good news is you don’t have to choose between “do nothing” and “rip it all out.” Most organizations start with hybrid identity, move authentication to the cloud, migrate apps one by one, and shrink on-prem AD at a pace that fits their team. The path from On-Prem Active Directory to Microsoft Entra ID is a series of small, safe steps.
Not sure where you stand? Windows Management Experts can run an identity assessment of your environment, map your app and LDAP dependencies, and recommend the right path for your business, whether that’s hybrid today or cloud-only tomorrow. Talk to our team and let’s figure it out together.
Hybrid today or cloud-only tomorrow, the path is a series of small, safe steps.
We’ll assess your identity environment, map your app and LDAP dependencies, and recommend the right path for your business.
