Flamingo Raises $4.5M Seed Round · Led by Vertex Ventures, bringing total funding to $6.7M to build the open, AI-native layer for IT and security.
Aliaska Varieva
Entra ID is not Active Directory in the cloud. What carried over from on-prem AD, what has no equivalent (Kerberos, LDAP, Group Policy), how hybrid join and Connect Sync fit, and three gates to decide for a given office.
A client asks for "Active Directory in the cloud", the quote says Microsoft Entra ID, and the first week after cutover the file server stops asking who you are. The two products share a word and almost nothing else under it, and the gap shows up in exactly the places a small office depends on. If you still search for what Azure Active Directory is, the answer is Microsoft Entra ID, and this guide covers what carried over from on-prem AD, what did not, and how to decide for a given office.
Microsoft announced on 11 July 2023 that Azure Active Directory would become Microsoft Entra ID, the portals started showing the new name on 15 August 2023, and the license display names switched on 1 October 2023. Microsoft's own rename page is explicit that features, licensing, pricing, sign-in URLs, APIs and the authentication libraries all stayed the same. Only the names changed.
So "Azure AD vs Active Directory" and "Entra ID vs Active Directory" are the same question. The rename fixed a naming problem, not a product one: for a decade the word "Active Directory" in the name made people assume the cloud service was the on-prem one with a different host. It never was. If you want the on-prem product's own primer first, start with what a domain controller does and come back.
Active Directory Domain Services (AD DS) is a directory plus a set of network protocols that Windows has used since Windows 2000. A workstation joins a domain, a domain controller issues it Kerberos tickets, and those tickets open file shares, printers, SQL databases and intranet apps. Group Policy pushes settings to the machine at boot. Organizational units carry delegation. Trusts link one domain to another.
Entra ID runs on none of that. Microsoft's own comparison page describes it as Identity as a Service: it speaks HTTPS, and it authenticates with OAuth 2.0, OpenID Connect, SAML and WS-Federation. There is no Kerberos key distribution center, no NTLM, no LDAP endpoint to bind against, no Group Policy engine, and the tenant is flat. Groups and administrative units carry delegation instead of OUs. There are no domain or forest trusts, which Microsoft calls out by name as a feature Entra ID simply does not have.
That is the whole misunderstanding in one paragraph. An app that does an LDAP bind on port 389 has nowhere to bind. A file server that checks an NTFS ACL against a domain group cannot resolve a cloud-only group. A Win32 app that expects a machine account in the domain finds no machine account. For the protocol side of that story, the LDAP explainer covers how a bind works and why cloud directories dropped it.
The traffic runs the other way too. AD DS cannot sign a user into Salesforce, ServiceNow or any SaaS app without a federation server in front of it (AD FS), and it has no concept of an external guest identity beyond creating a real account for them. Entra ID was built for that job: SaaS apps that support SAML or OpenID Connect plug straight in, B2B guests get their own identity class, and SCIM provisioning creates and removes accounts in those apps automatically. If the acronyms blur, the SAML vs SSO post sorts them.
Conditional Access is the other half. AD decides "is this password right". Entra ID decides "is this password right, from a compliant device, from an expected location, with MFA satisfied for this app". Device compliance comes from Intune, which Microsoft's table lists as the replacement for Group Policy and Configuration Manager on Windows desktops, and as the only option for mobile devices, which AD never managed at all. Passwordless sign-in with Windows Hello for Business and FIDO2 keys, smart lockout, banned-password lists and self-service password reset are all Entra-side features.
In short: AD controls machines on a network you own. Entra ID controls access to apps from anywhere. One is a perimeter product and the other assumes there is no perimeter.
| What you need | Active Directory (on-prem) | Microsoft Entra ID |
|---|---|---|
| Directory of users and groups | Yes, in domains and OUs | Yes, flat tenant with groups and administrative units |
| Sign-in protocol | Kerberos, NTLM | OAuth 2.0, OpenID Connect, SAML, WS-Fed over HTTPS |
| App lookups | LDAP bind and search | Microsoft Graph API; no LDAP endpoint |
| Device settings | Group Policy at boot and logon | Intune policies via MDM channel |
| Windows device join | Domain join | Entra join, or hybrid join alongside domain join |
| File shares and printers | Native via domain groups | Needs a DC, Entra Domain Services or a cloud file service |
| SaaS and web apps | Only through AD FS or a third-party IdP | Native SSO with SAML and OIDC |
| Conditional Access and MFA | Not built in | Built in; MFA in the Free tier, Conditional Access needs P1 |
| Mobile devices | Not supported | Intune, integrated |
| Trusts between organizations | Domain and forest trusts | None; B2B guest identities instead |
| Where it runs | Your servers, your patching | Microsoft's service, no servers to run |
Two rows decide the fit for a small office: file shares and printers, and app lookups. Everything else has a cloud equivalent that is at least as good. Those two rows are the reason a domain controller survives in offices that moved everything else to Microsoft 365.
A Windows device has three possible states, and the middle one is where the confusion lives.
Domain joined is the classic: the machine has an account in AD, gets Group Policy, and needs a domain controller to log on with a domain account (cached credentials cover a laptop away from the office for a while). Entra joined is the cloud equivalent: the machine registers with the tenant, signs in with the Entra account, picks up Intune policy over the internet, and never needs a domain controller. Hybrid joined is both at once: joined to the on-prem domain and registered with Entra ID, so the device gets Group Policy and Intune, SSO to both on-prem shares and cloud apps.
The catch is in Microsoft's hybrid join page, in one sentence: hybrid-joined devices "require network line of sight to your on-premises domain controllers periodically. Without this connection, devices become unusable." A hybrid laptop that spends a quarter at a kitchen table with no VPN eventually cannot be signed into. Microsoft's own recommendation on the same page is to consider Entra join if that is a concern.
The second catch is the exit. There is no switch to flip a hybrid-joined device to Entra-joined. The device has to be reset and re-provisioned, which is why Autopilot and a staged rollout matter more than the join type itself. New devices should go straight to Entra join; existing hybrid devices move when they are reimaged anyway. Microsoft shipped a preview in late 2025 that performs hybrid join through Microsoft Entra Kerberos instead of Connect Sync, but it needs at least one Windows Server 2025 domain controller on build 26100.6905 and Windows 11 on build 26100.6584, and the client still has to reach that DC during the join. It removes a sync dependency, not the domain controller.
Hybrid identity means user accounts live in AD and get copied to Entra ID, so the same password works on the file server and in Outlook. Two agents do that copy. Microsoft Entra Connect Sync is the older one: a full sync engine installed on a server you run, with a local database and rules you can customize. Microsoft Entra Cloud Sync is the newer one: a lightweight agent on-prem, with the configuration held in the cloud, and the one Microsoft recommends for new deployments because new sync features ship there first.
There is a date attached. Microsoft's upgrade guidance states that all synchronization in Connect Sync stops working on 30 September 2026 for any install below version 2.5.79.0, and that date has passed. If a client's sync server was set up in 2022 and nobody has touched it, check the version before anything else in this post, because a stalled sync shows up as "my new user cannot sign into email" three days later.
Cloud Sync covers the common cases: password hash sync, group writeback and basic filtering. Connect Sync still wins on complex attribute-level filtering and some device-sync scenarios, so a tenant with custom sync rules stays on an upgraded Connect Sync for now. Both can coexist during a migration as long as they do not manage the same objects.
"Cloud-only" has a precise meaning: users, groups and devices exist only in Entra ID, devices are Entra joined and managed by Intune, there is no sync server, and nothing on the network authenticates with Kerberos, NTLM or LDAP. Reaching it is an inventory exercise, not a licensing one. Walk the office and list every dependency on the domain:
Each one has an answer. The shares move to SharePoint or Azure Files, print goes to Universal Print or a cloud print service, RADIUS moves to a cloud NPS or certificate-based Wi-Fi tied to Intune, and the Group Policy set gets rebuilt in Intune one profile at a time (the Group Policy editor post shows what you are rebuilding). The LOB app is the one that usually has no answer except its vendor's roadmap. That single app is why a 10-user office still has a Windows Server in the closet.
Microsoft Entra Domain Services is the thing people mean when they say "AD in the cloud", and it is a separate product from Entra ID. Per its overview page, it stands up two managed Windows Server domain controllers in an Azure region, fed by a one-way sync from Entra ID, and offers domain join, Group Policy, LDAP, LDAPS and Kerberos/NTLM to workloads that need them. You never log into those domain controllers, never patch them, and never get Domain Admin on them.
It fits a narrow case well: an AD-dependent app you are moving to an Azure VM, in a tenant that is otherwise cloud-only, where you would rather not build and patch a DC yourself. It fits a small office badly when the dependency is a NAS and a printer in the same room, because the managed domain lives in Azure and the office still needs a network path to it. Microsoft describes it as a transitional capability for Azure-hosted workloads, not a replacement for on-prem AD, and that framing is accurate. It is also a stand-alone domain, not an extension of yours, so existing GPOs and OUs do not come along.
Microsoft's road to the cloud guidance defines five states, from "cloud attached" (a tenant exists, AD does everything) through "hybrid", "cloud first", "AD minimized" and "100% cloud". Almost every office with Microsoft 365 is already in state one or two. The useful question is not "which product" but "which state is the target for this office, and what is blocking the next one".
Three gates settle it. First: does anything bind LDAP or need a Kerberos ticket, and can it be replaced or re-hosted in the next 12 months? If no, AD stays, and Entra ID runs alongside it through Cloud Sync for Microsoft 365, Conditional Access and Intune. Second: are the shares and printers movable to SharePoint, Azure Files or Universal Print? If yes and gate one passed, the office is an Entra join plus Intune candidate, and the domain controller becomes a decommission project. Third: is the existing fleet hybrid joined? If yes, new devices go Entra joined today and the rest move at refresh, which is the cheapest path through the reset requirement.
Licensing rarely blocks any of this. Microsoft's pricing page lists Entra ID P1 at $7 per user per month and P2 at $10 as of October 2026, and P1 is included in Microsoft 365 Business Premium, which is what a small office on Microsoft 365 tends to run anyway. Conditional Access and Intune both come with that bundle. The cost of going cloud-only is the app rework and the device resets, not the identity license.
Whichever state you pick, write down the join state of every device before you plan. On a Windows machine dsregcmd /status reports whether it is domain joined, Entra joined or both, and across a client's fleet the fastest way to get that is a script with the output collected, which is what OpenFrame's script runner does across a client's devices. The device list that comes back is the real migration plan.
Entra ID is not Active Directory with a cloud logo. It replaces the identity half of AD well, replaces the device-management half through Intune, and does not replace the protocol half at all. Kerberos, NTLM, LDAP and Group Policy either keep a domain controller alive, move to Entra Domain Services, or get engineered out one dependency at a time. Decide by listing what binds to the domain, not by which name is on the invoice.
Next reads: how to install ADUC on a Windows 11 admin workstation if AD is staying, and the MDM solutions comparison if Intune is about to inherit the device fleet.
Head of Platform
Hi! I’m Aliaska, and I’ve been working as a software engineer (mostly Java + a bit Kotlin) for over 8 years now. I mostly spend my time building backend services, integrating systems, fixing bugs (the fun part 🙃), and making sure things don’t fall apart behind the scenes.
Still deciding?
Ask Mingo answers from our docs and customer stories.
Still deciding?
Ask Mingo answers from our docs and customer stories.