When people say ‘Active Directory,’ they almost always mean Active Directory Domain Services, or AD DS. AD DS is the directory service built into Windows Server. It is a structured database of identity objects combined with authentication, authorisation, and policy enforcement.
Active Directory is not just a list of users. It is an operational system that helps decide who can sign in, which computers belong to the organisation, which groups a user belongs to, which settings apply to a workstation, and which resources a user or computer can access.
Active Directory stores objects such as users, groups, computers, servers, printers, service accounts, contacts, and organisational units. More importantly, it links those objects to permissions, policies, trust relationships, and administrative control.
For example, a user account might belong to a department group, a VPN access group, a file-share access group, and a mail-enabled group. A computer account might belong to an OU that receives specific Group Policy settings. A service account might be allowed to run a business application. These relationships make Active Directory central to daily operations.
A domain is the main administrative and security boundary in Active Directory. Everything inside a domain shares the same directory database and can be centrally managed. A typical company might have a domain such as corp.example.com or ad.company.com.
A forest is the top-level Active Directory structure. It can contain one or more domains and defines the overall schema and security boundary. Many organisations have a single forest with a single domain. Larger or older organisations may have multiple domains, often because of mergers, acquisitions, historical design decisions, or separation requirements.
Organisational Units, or OUs, are containers inside a domain. They are used to organise users, computers, servers, service accounts, and other objects. OUs are important because Group Policy can be linked to them. A common structure might place workstations, servers, domain controllers, service accounts, and privileged accounts into different OUs so that different policies and administrative controls can apply.
A domain controller is a Windows Server running Active Directory Domain Services. It handles authentication requests, Kerberos ticket issuance, LDAP queries, directory replication, and other directory functions.
Domain controllers are critical infrastructure. If users cannot reach a domain controller, logon, access, and policy functions may fail. Every production environment should normally have at least two domain controllers for redundancy, and larger organisations usually place domain controllers in multiple sites.
Read-Only Domain Controllers, or RODCs, are a useful option for branch offices or environments where physical security cannot be fully guaranteed. They hold a read-only copy of the directory and can cache credentials for selected users, but compromising an RODC does not provide the same level of access as compromising a writable domain controller.
Active Directory uses several important protocols.
Kerberos is the primary authentication mechanism for modern domain logons. It issues tickets that allow users and computers to access services without repeatedly sending credentials. It is the foundation of Windows Integrated Authentication in domain environments.
NTLM is an older challenge-response authentication protocol. It still exists for compatibility with older systems and workloads. It is less secure than Kerberos, harder to audit, and frequently appears in credential-based attack paths. It should be monitored and reduced where possible, but eliminating it completely often requires application and infrastructure work.
LDAP is used to query and modify directory information. Many applications integrate with Active Directory through LDAP or LDAPS. A scanner might use LDAP to search for email addresses, a VPN might check group membership, or an application might authenticate users against AD.
Group Policy is one of the major reasons Active Directory became so embedded in enterprise environments. It allows administrators to centrally configure Windows settings across many users and computers.
Group Policy can control password requirements, firewall rules, mapped drives, security baselines, software deployment, browser settings, certificate deployment, logon scripts, Windows Update behaviour, desktop restrictions, and many other settings.
Group Policy is delivered through Group Policy Objects, or GPOs. GPOs can be linked to sites, domains, or OUs. When a computer starts or a user logs on, Windows processes the applicable policies and applies the resulting settings.
Group Policy is powerful, but it can become difficult to manage. Overlapping policies, conflicting settings, scope filters, inheritance, old scripts, and years of accumulated GPOs without ownership are common sources of operational problems. Well-managed environments use clear naming standards, documented ownership, regular audits, and a simple OU structure where possible.
The standard domain password policy applies broadly to the domain. Fine-Grained Password Policies allow different password and lockout policies for different groups of users.
For example, privileged administrator accounts may require longer passwords or stricter rules than ordinary users. Service accounts may require very long passwords but different lockout behaviour. Fine-Grained Password Policies are implemented through Password Settings Objects and applied to groups or individual users.
Service accounts are accounts used to run services, scheduled tasks, application pools, or application processes. They are not tied to a human user.
Service accounts are a major security surface. They often have elevated privileges, their passwords may rarely change, and ownership may be unclear. Old service accounts are common in mature AD environments and can become dangerous if nobody knows which application depends on them.
Group Managed Service Accounts, or gMSAs, address many of these problems. Windows manages the password automatically, rotates it according to policy, and restricts which computers can use the account. No human needs to know or type the password. Where applications support gMSAs, they are usually a better option than ordinary user-style service accounts.
Active Directory does not provide multi-factor authentication natively.
This is an important gap. A domain password, however strong, is still one factor. If that password is compromised through phishing, password reuse, credential dumping, database breach, or another attack, an attacker may be able to authenticate to AD-connected systems unless additional controls exist.
Adding MFA to Active Directory-based authentication usually requires another system in the authentication path. Common approaches include Entra ID, RADIUS-based MFA, VPN integration, application proxying, third-party identity providers, or application-specific MFA support.
Microsoft Entra ID with MFA is the most common modern approach in Microsoft-centric hybrid environments. When authentication flows through Entra ID, Conditional Access and MFA can be enforced. This is how organisations commonly protect Microsoft 365, cloud applications, SaaS access, and many VPN scenarios using identities that may still originate in AD.
There is an important distinction between sign-in methods. With password hash synchronisation, Entra ID can validate cloud sign-ins using a synchronised derivative of the on-premises password hash. With pass-through authentication, Entra ID passes the authentication request to an on-premises agent, which validates it against AD in real time. Both models can allow the user to use the same password, but the validation path is different.
RADIUS-based MFA is common for VPN, Wi-Fi, and remote access scenarios. A RADIUS server or proxy sits in the authentication path and challenges the user for a second factor before granting access. Microsoft’s NPS extension for Entra MFA is one example of this pattern.
For internal on-premises applications that authenticate directly against AD through Kerberos or NTLM, with no cloud authentication path involved, adding MFA is harder. It may require application changes, a proxy, federation, third-party tools, or architectural redesign.
This is one of the practical reasons many organisations move important application authentication through Entra ID where possible. It creates a control point where MFA, Conditional Access, risk-based policies, and modern monitoring can be enforced consistently.
Active Directory is one of the highest-value targets in an enterprise network. Compromising it can mean broad access to systems, applications, and data that trust the domain. Many significant enterprise breaches involve some form of AD credential theft, lateral movement, or privilege escalation.
The most important principle is least privilege. Users should not have more access than they need. Administrative accounts should be separate from everyday user accounts. Domain Admin membership should be extremely small and limited to accounts that genuinely need to manage the domain or domain controllers.
A common framework is administrative tiering: Tier 0 includes domain controllers, AD itself, identity systems, and systems that can control identity. Tier 1 includes servers and enterprise services. Tier 2 includes workstations and end-user devices.
The goal is to prevent compromise at one tier from spreading to a higher tier. A stolen workstation admin account should not be usable on servers. A stolen server admin account should not be usable on domain controllers. Tier 0 accounts should be protected with the strongest controls.
Every domain-joined Windows machine may have a local Administrator account. If all machines use the same local administrator password, compromising one machine can enable lateral movement across many others.
Microsoft LAPS solves this by setting a unique, random local administrator password on each machine and storing it securely. Only authorised users or groups can retrieve the password. The password can rotate automatically after use or on a defined schedule. LAPS is now a foundational control for domain environments.
The Protected Users security group is a built-in AD group that applies hardened authentication restrictions to its members. Accounts in this group cannot use NTLM, cannot use weak Kerberos encryption types, cannot be delegated by services, and are subject to stricter ticket behaviour.
It can be useful for privileged accounts and high-value users, but it must be tested. Adding a service account or incompatible user account to Protected Users can break applications that depend on NTLM, delegation, or older authentication behaviour.
Domain controllers are Tier 0 assets. They should be patched regularly, monitored carefully, protected from unnecessary access, and never used for web browsing, general-purpose workloads, or non-AD software.
Access to domain controllers should be logged and reviewed. Only dedicated administrative accounts should manage them. Domain controllers should be backed up, and recovery should be tested.
A specific concern is directory replication permission. DCSync-style attacks allow an account with replication privileges to extract password hashes for AD accounts without logging on to a domain controller. Accounts and groups with replication privileges should be audited carefully.
NTLM should be monitored and reduced where possible. Many organisations discover that NTLM is still used by old applications, printers, scripts, appliances, or servers. It should not be ignored simply because everything still works.
Unsigned LDAP should be disabled or restricted where application compatibility allows. LDAP signing and channel binding help reduce relay and interception risks.
Old Kerberos encryption types, especially RC4, should be phased out where possible. Where applications still depend on old encryption, that dependency should be documented and modernised.
AD recovery is not the same as restoring an ordinary file server. If the AD database is corrupted, encrypted, or badly misconfigured, recovery requires knowledge of domain controllers, replication, tombstone lifetime, authoritative restore, non-authoritative restore, system state backup, and the order of recovery.
Organisations should have a tested AD recovery procedure. A backup that has never been tested is only a hope, not a recovery plan.
Microsoft Entra ID, formerly Azure Active Directory, is Microsoft’s cloud identity and access management platform. It is not Active Directory hosted in a cloud datacenter. It is a different product, built for different purposes and using different protocols.
Every Microsoft 365 tenant has an Entra ID tenant. If an organisation uses Microsoft 365, Exchange Online, Teams, SharePoint Online, OneDrive, or Azure, Entra ID is already part of the environment.
Entra ID handles authentication and authorisation for cloud-based services, including Microsoft 365 sign-in, Azure portal and resource access, single sign-on to SaaS applications, application registrations and API access, device identity for Entra-joined and registered devices, Conditional Access, multifactor authentication, Identity Protection, Privileged Identity Management, guest and external user access, and identity governance.
Entra ID is therefore the main identity control plane for Microsoft cloud services and many modern applications.
Entra ID does not use customer-managed domain controllers. It does not provide traditional Group Policy. It does not provide a traditional AD domain join in the same way as AD DS. It does not normally provide LDAP for legacy applications. It does not provide NTLM or traditional Windows Integrated Authentication for legacy applications in the same way AD DS does.
This is why most established organisations cannot simply replace Active Directory with Entra ID overnight. Their applications, servers, file shares, scripts, service accounts, and management processes may still depend on AD DS.
Active Directory is built around Kerberos, NTLM, LDAP, Group Policy, domain controllers, and DNS-dependent domain services.
Entra ID is built around OAuth 2.0, OpenID Connect, SAML, modern token-based authentication, Conditional Access, cloud application access, and internet-accessible identity services.
These are fundamentally different worlds. Applications built for one do not automatically work with the other.
Three similarly named technologies are often confused.
Active Directory Domain Services, or AD DS, is the traditional on-premises directory service running on Windows Server domain controllers. It provides domain join, Kerberos, NTLM, LDAP, Group Policy, and traditional Windows domain functions.
Microsoft Entra ID is the cloud identity platform used for Microsoft 365, Azure, SaaS applications, modern authentication, MFA, Conditional Access, application access, and cloud device identity. It is not a traditional domain controller service.
Microsoft Entra Domain Services is a managed domain service in Azure. It can provide domain-like capabilities such as LDAP, Kerberos, NTLM, and Group Policy support for certain legacy workloads without the customer managing domain controllers directly. It is useful in specific scenarios, but it is not the same thing as a full customer-managed AD DS forest, and it is not the same thing as Entra ID.
A simple way to remember it: AD DS is traditional domain controllers. Entra ID is cloud identity. Entra Domain Services is managed domain services for specific legacy-compatible Azure scenarios.
The most common enterprise model is hybrid identity. In this model, AD remains the identity source for on-premises systems, and Entra ID extends that identity into the cloud.
Users are created and managed in on-premises AD. A synchronisation tool replicates those accounts and selected attributes to Entra ID. The same user can then use one identity for both domain logon and Microsoft 365 sign-in.
Microsoft Entra Connect Sync is the traditional on-premises synchronisation tool. It runs on a Windows Server in the environment, connects to AD, reads objects, and writes them to Entra ID. It synchronises users, groups, and selected attributes.
Password hash synchronisation is a widely used sign-in method. Entra Connect synchronises a derivative of the AD password hash to Entra ID. Users can sign in to cloud services using the same password as their AD account. The actual clear-text password never leaves the organisation.
Pass-through authentication validates cloud sign-in attempts against on-premises AD in real time through lightweight agents. No password hash data is synchronised for authentication, but cloud sign-in depends on the availability of the agents and on-premises AD.
Federation with AD FS redirects authentication to an on-premises federation service. It was popular historically, especially for complex claim requirements or strict requirements around where authentication occurs. It also adds significant infrastructure and operational complexity. Many organisations have moved from AD FS federation toward cloud authentication where possible.
Microsoft Entra Cloud Sync is a newer, cloud-managed synchronisation approach using lightweight agents. Configuration and management happen in the cloud rather than through a full on-premises Entra Connect Sync server.
Cloud Sync can be attractive for distributed or multi-forest environments, but it does not support every Entra Connect Sync feature. Organisations should check feature compatibility before changing synchronisation models.
Windows devices can participate in identity in several ways.
AD domain-joined devices follow the traditional model. The device trusts the AD domain, receives Group Policy, and uses Kerberos for internal authentication.
Entra hybrid joined devices are joined to on-premises AD and also registered in Entra ID. This allows cloud-based Conditional Access, Intune co-management, and device identity signals while retaining traditional AD join and Group Policy.
Entra joined devices are joined directly to Entra ID and are commonly managed with Intune. This model is appropriate for cloud-first organisations, new deployments, remote users, or environments that do not require traditional AD domain join.
Where Active Directory cannot natively enforce MFA, Entra ID was built around modern access control.
Multifactor authentication in Entra ID requires another verification factor in addition to the password. This might be Microsoft Authenticator, a temporary code, a hardware token, SMS, phone call, or another supported method depending on policy.
Conditional Access is the policy engine that determines when access is allowed, blocked, or challenged. A Conditional Access policy can require MFA when signing in from outside the corporate network, block access from high-risk locations, require a compliant device for SharePoint Online, or require stronger controls for privileged roles.
Identity Protection evaluates sign-in risk and user risk, such as unusual locations, anonymous IP addresses, leaked credentials, or suspicious sign-in behaviour. High-risk sign-ins can be blocked or challenged.
Privileged Identity Management, or PIM, provides just-in-time privileged access. Instead of having permanent Global Administrator rights, an administrator can activate a role for a limited time, often with approval, justification, and automatic expiry.
In hybrid environments, these controls apply to authentication that flows through Entra ID. That includes Microsoft 365, many SaaS applications, SAML-based VPN authentication, Entra Application Proxy, and other applications integrated with Entra ID.
Active Directory is widely integrated with other enterprise systems because it is often the central identity store.
Windows file servers commonly use AD groups for permissions. Assigning access directly to individual users does not scale. The better pattern is to assign permissions to groups and manage access through group membership.
For example, a file share might grant read/write access to a group called Finance-Share-RW. Users receive access by being added to that group.
Many internal applications authenticate users through LDAP, LDAPS, Kerberos, or Windows Integrated Authentication. The application contacts AD, validates credentials or checks group membership, and grants access.
This is why removing AD while legacy applications remain is difficult. Each application dependency must be identified and modernised or replaced.
On-premises Exchange integrates deeply with Active Directory. In Exchange hybrid and Microsoft 365 environments, AD attributes may still influence mailbox configuration, proxy addresses, recipient properties, and mail routing.
This is why some organisations that have moved mailboxes to Exchange Online still manage mail-related attributes in AD and synchronise them to Entra ID.
Traditional VPN systems often integrate with AD through RADIUS, Network Policy Server, LDAP, or group membership checks. Modern VPN designs may route authentication through Entra ID using SAML or through an MFA extension so that Conditional Access and MFA can be enforced.
This is a common pattern when organisations want to keep AD identities but add modern MFA to remote access.
Enterprise Wi-Fi commonly uses 802.1X with certificates or domain credentials. A RADIUS server such as NPS can evaluate authentication requests against AD and apply network policies based on user group, computer group, or certificate information.
Modern endpoint management can also issue certificates through Intune, allowing certificate-based Wi-Fi authentication without relying on user passwords.
Printers, scanners, and network appliances may use AD for LDAP address book lookup, scan-to-folder access, administrative authentication, or group membership checks.
For example, a scanner may query AD through LDAP so users can find email addresses, or it may use a service account to write scanned files to a protected file share.
Linux servers can integrate with AD using SSSD, Kerberos, LDAP, Samba, or other identity tools. This allows central user management and group-based access control without maintaining separate local accounts on every server.
Security tools use AD data heavily. SIEM systems collect authentication events, group changes, password resets, privilege changes, and failed logons. Endpoint detection tools use AD information to understand device role and user context. Privileged access tools integrate with AD to control and audit access.
Because AD is the central identity system in many organisations, its logs are among the most valuable sources of security evidence.
Mature organisations often connect HR systems to identity workflows. When a new employee joins, an account is created. When an employee changes role, group memberships change. When someone leaves, accounts are disabled and access is removed.
This reduces manual work and lowers the risk of orphaned accounts.
In a traditional on-premises model, AD is the primary identity platform. Users log on to domain-joined machines, access file servers, and authenticate to internal applications. Microsoft 365 may or may not be present.
This model still exists in industrial, regulated, isolated, server-heavy, or legacy environments.
Hybrid identity is the realistic current state for many established organisations. AD remains authoritative for on-premises users, groups, computers, and applications. Accounts synchronise to Entra ID. Users have one identity for both on-premises and cloud access.
AD provides domain logon, Group Policy, file server access, Kerberos, LDAP, and legacy application authentication. Entra ID provides Microsoft 365, SaaS SSO, MFA, Conditional Access, cloud application access, device identity, and modern authentication.
In a cloud-first model, Entra ID is the primary identity platform. Devices are Entra joined and managed by Intune. Applications authenticate through Entra ID using OAuth, OpenID Connect, or SAML. AD may still exist only for specific legacy systems.
This works best for organisations with modern applications, cloud-managed endpoints, and limited legacy dependencies.
Most organisations have a mixture. They may have domain-joined servers, hybrid-joined laptops, Entra-joined new devices, cloud SSO applications, legacy LDAP applications, VPN with MFA, file servers using AD groups, and Conditional Access through Entra ID.
The challenge is not only technical. The challenge is knowing which system is authoritative for each identity, device, group, application, and policy.
Active Directory is mature, proven, and widely supported. Many applications, tools, administrators, and operational processes understand it.
It provides centralised identity for traditional Windows environments. Users, groups, computers, permissions, and policies can be managed centrally instead of separately on each system.
It supports strong integration with Windows logon, Kerberos, file shares, server administration, and internal applications.
Group Policy provides powerful central management for Windows computers and users.
AD groups provide a scalable way to manage access to file shares, applications, VPNs, Wi-Fi, and administrative roles.
It works well for legacy and internal systems that require Kerberos, NTLM, LDAP, domain join, or Windows Integrated Authentication.
It can continue to support internal authentication even when cloud connectivity is unavailable, provided domain controllers and internal DNS are healthy.
Active Directory can become complex over time. Old OUs, nested groups, stale accounts, delegated permissions, trusts, GPO sprawl, and legacy applications can make the environment hard to understand.
It is a major security target. If AD is compromised, many systems that trust the domain may be compromised as well.
It does not natively provide MFA for ordinary domain authentication.
It often carries legacy protocols and behaviours such as NTLM, unsigned LDAP, old Kerberos encryption types, old service accounts, and applications that cannot use modern authentication.
It depends heavily on domain controllers and DNS. If those are unhealthy, many services fail.
It is difficult to remove once many applications, file permissions, service accounts, scripts, and operational processes depend on it.
Hybrid integration with Entra ID adds value but also adds complexity around synchronisation, attribute authority, device identity, Conditional Access, password writeback, and legacy dependencies.
The practical conclusion is that AD is still extremely useful, but it must be actively managed, secured, documented, and gradually modernised. It should not be treated as invisible background infrastructure.
The first common mistake is assuming Entra ID is ‘Active Directory in Azure.’ It is not. It has different protocols, different management models, different trust boundaries, and different capabilities.
The second mistake is keeping AD without knowing what still depends on it. Every organisation should understand which applications, services, scripts, devices, and workflows still require AD.
The third mistake is synchronising stale data to Entra ID. Entra Connect can synchronise old users, stale groups, abandoned service accounts, and incorrect attributes if AD is not cleaned up.
The fourth mistake is over-privileged accounts. Domain Admins and Global Administrators are high-value targets. Their membership should be small, controlled, monitored, and justified.
The fifth mistake is no MFA or strong protection for privileged accounts. MFA is essential for cloud privileged roles, and strong administrative controls are essential for AD privileged roles.
The sixth mistake is ignoring NTLM. Many organisations still use NTLM without knowing where. It should be monitored, documented, and reduced where possible.
The seventh mistake is using groups without ownership or lifecycle review. Groups that nobody owns or reviews become long-term access risk.
The eighth mistake is changing objects in both AD and Entra ID without understanding which system is authoritative. In hybrid environments, AD is often authoritative for synchronised objects, and direct cloud edits may be overwritten.
The ninth mistake is treating MFA as a complete identity security strategy. MFA helps, but it does not replace least privilege, monitoring, device security, privileged access controls, application governance, and recovery planning.
The tenth mistake is moving to the cloud while leaving AD unmanaged and insecure. Hybrid identity is only as strong as its weakest side.
Consider a professional services firm with 800 employees, on-premises file servers, Windows workstations, a small number of application servers, Microsoft 365 with Teams and SharePoint Online, a legacy CRM that authenticates through LDAPS, and VPN for remote access.
Active Directory handles Windows domain logon for workstations and servers, Group Policy for security baselines, mapped drives, and certificate deployment, file server permissions through AD groups, legacy CRM authentication through LDAPS, service accounts for application processes, and LAPS for local administrator passwords on workstations.
Entra ID handles Microsoft 365 authentication, MFA enforcement through Conditional Access, SaaS SSO, Entra Application Proxy for selected internal applications, device compliance signals through Intune, and PIM for privileged cloud roles.
Integration works through Entra Connect Sync with password hash synchronisation so users have one password for both environments. VPN authenticates through SAML to Entra ID so MFA and Conditional Access can apply before the VPN connection is granted.
Known gaps include auditing NTLM, retiring legacy applications that cannot use LDAPS or modern authentication, moving new workstations toward Entra join and Intune management, reviewing old AD groups and service accounts, and reducing permanent privileged access.
This is a realistic hybrid environment. It is not theoretically perfect, but it is operationally sound and improving.
The direction of enterprise identity is clear, although the pace varies by organisation.
Entra ID becomes the primary access control layer for cloud, SaaS, and progressively more internal applications. MFA and Conditional Access become standard controls rather than exceptions. Passwordless authentication, such as Windows Hello for Business, FIDO2 keys, and passkeys, becomes more common.
Devices move toward Entra join and Intune management where possible. AD becomes smaller, cleaner, more protected, and more focused on systems that genuinely still require it. Identity governance becomes more important, including lifecycle workflows, access reviews, entitlement management, and privileged access controls.
AD will not disappear quickly. Legacy applications, file servers, industrial systems, Windows server estates, and operational dependencies create real constraints that can take years to remove. But new dependencies on AD should be minimised where modern alternatives meet the requirement.
The future is not simply ‘AD is gone.’ A more realistic future is that AD remains for specific legacy and internal requirements while Entra ID becomes the main control plane for modern access.
Active Directory manages on-premises Windows identity: users, computers, authentication, Group Policy, access control, and legacy application access. It does not natively provide MFA.
Microsoft Entra ID manages cloud identity: Microsoft 365, Azure, SaaS applications, modern authentication, Conditional Access, MFA, device identity, guest access, and identity governance. It is not Active Directory in the cloud.
Microsoft Entra Domain Services provides managed domain services for specific legacy-compatible Azure scenarios, but it is not the same as customer-managed AD DS and not the same as Entra ID.
Most established organisations need both AD and Entra ID for some period of time. The practical questions are: which system is authoritative for which identity, where does authentication actually happen, how is MFA enforced, what still depends on AD, how those dependencies will be reduced, and how the whole identity environment will be secured, monitored, governed, and recovered.
A good identity environment is not one where everything runs on the newest platform. It is one where access is controlled, credentials are protected, privileges are justified, changes are tracked, recovery is tested, and the team knows what they have.
These questions are designed to check conceptual understanding rather than simple recall. A good answer should explain the reasoning, dependencies, and operational consequences.
1. Why is it misleading to describe Microsoft Entra ID as ‘Active Directory in the cloud’?
2. An organisation already synchronises users from AD to Entra ID. Does that mean it can remove all domain controllers? Explain your reasoning.
3. A company wants MFA for all Microsoft 365 access but also has legacy internal applications using Kerberos. Why can the Microsoft 365 requirement be solved more easily than the legacy application requirement?
4. A user is disabled in on-premises AD but still appears in Entra ID. What concept should the administrator think about before assuming this is a cloud-side problem?
5. Why are AD groups a better access-control mechanism than assigning permissions directly to individual users?
6. A legacy application still requires NTLM. Why is this not only a technical compatibility issue but also a security and modernisation issue?
7. Why is Active Directory recovery different from restoring an ordinary server from backup?
8. A new SaaS application can use SAML or OpenID Connect. Should it normally authenticate directly against AD with LDAP instead? Why or why not?
9. Why does adding Entra ID to an environment not automatically make the identity design secure?
10. A company wants to move new laptops to Entra join and Intune management, but it still uses file shares and legacy applications that depend on AD. What identity model does this suggest?
11. Why should service accounts be treated as a major security surface rather than just background technical accounts?
12. Why is MFA important but not sufficient as a complete identity security strategy?
13. A user signs into Microsoft 365 using a synchronised account with password hash synchronisation. Where is the password actually validated, and why does that matter?
14. Why might a user still successfully authenticate without MFA even when Conditional Access policies require it?
15. Why should a Domain Admin account not be used on a normal workstation, even if MFA is enabled?
1. Why is it misleading to describe Microsoft Entra ID as ‘Active Directory in the cloud’?
Because Entra ID and AD DS solve identity problems in different ways. AD DS uses domain controllers, Kerberos, NTLM, LDAP, Group Policy, and traditional domain join. Entra ID is a cloud identity platform based on modern token-based authentication, Conditional Access, MFA, cloud applications, and internet-facing identity services. They overlap in purpose, but not in architecture or protocol model.
2. An organisation already synchronises users from AD to Entra ID. Does that mean it can remove all domain controllers? Explain your reasoning.
Not necessarily. Synchronisation only gives Entra ID a cloud representation of the identities. Domain controllers may still be required for domain-joined computers, Kerberos, LDAP, NTLM, Group Policy, file servers, service accounts, and legacy applications. Domain controllers can be removed only after those dependencies are identified and replaced or redesigned.
3. A company wants MFA for all Microsoft 365 access but also has legacy internal applications using Kerberos. Why can the Microsoft 365 requirement be solved more easily than the legacy application requirement?
Microsoft 365 authentication flows through Entra ID, where MFA and Conditional Access can be enforced. Legacy applications using Kerberos authenticate directly against AD and may never pass through a modern identity provider. Adding MFA to those applications often requires a proxy, application change, federation, third-party integration, or redesign.
4. A user is disabled in on-premises AD but still appears in Entra ID. What concept should the administrator think about before assuming this is a cloud-side problem?
They should think about hybrid identity and synchronisation authority. In many environments, on-premises AD is authoritative for synchronised users, and changes are replicated to Entra ID by Entra Connect Sync or Cloud Sync. The administrator should check synchronisation status, sync timing, filtering, object scope, and whether the cloud object is actually synchronised or cloud-only.
5. Why are AD groups a better access-control mechanism than assigning permissions directly to individual users?
Groups separate access from individual identities. Permissions can be granted to a role-based or resource-based group, and users receive access through membership. This makes onboarding, role changes, access reviews, and offboarding more manageable and avoids permissions being scattered directly across many resources.
6. A legacy application still requires NTLM. Why is this not only a technical compatibility issue but also a security and modernisation issue?
NTLM is older, less secure, and commonly appears in credential theft and relay attack paths. If an application requires NTLM, it may also block moves toward modern authentication, MFA enforcement, and cleaner identity architecture. The dependency should be documented, monitored, and eventually removed or modernised where possible.
7. Why is Active Directory recovery different from restoring an ordinary server from backup?
AD is replicated, security-sensitive, and stateful across domain controllers. Restoring it incorrectly can create replication conflicts or fail to recover deleted or corrupted objects properly. AD recovery may require system state restore, authoritative or non-authoritative restore decisions, awareness of tombstone lifetime, domain controller roles, and careful sequencing.
8. A new SaaS application can use SAML or OpenID Connect. Should it normally authenticate directly against AD with LDAP instead? Why or why not?
Usually no. A modern SaaS application should normally integrate with Entra ID or another modern identity provider using SAML or OpenID Connect. This enables SSO, MFA, Conditional Access, better auditing, and cloud identity governance. Direct LDAP against AD adds legacy dependency and usually does not provide the same modern access controls.
9. Why does adding Entra ID to an environment not automatically make the identity design secure?
Entra ID adds modern controls, but security still depends on configuration and governance. AD may remain weak, over-privileged, or full of stale accounts. Conditional Access may be incomplete. Privileged roles may be permanent. Legacy protocols may remain. Hybrid identity is only secure when both the AD side and the Entra ID side are protected and monitored.
10. A company wants to move new laptops to Entra join and Intune management, but it still uses file shares and legacy applications that depend on AD. What identity model does this suggest?
It suggests a mixed or hybrid model. New endpoints can move toward Entra join and Intune, while AD remains for servers, file shares, legacy applications, Kerberos/LDAP dependencies, and possibly existing domain-joined devices. The important task is to define which system is authoritative for users, devices, access, and policy in each case.
11. Why should service accounts be treated as a major security surface rather than just background technical accounts?
Service accounts often run important applications, may have elevated permissions, may be used on multiple systems, and often have passwords that rarely change. If ownership is unclear or privileges are excessive, they become attractive attack targets. Managed service accounts, limited privileges, ownership, monitoring, and lifecycle review reduce this risk.
12. Why is MFA important but not sufficient as a complete identity security strategy?
MFA reduces the risk of password-only compromise, but it does not fix over-privileged accounts, insecure service accounts, poor device security, legacy protocols, weak application permissions, unmonitored admin activity, or lack of recovery planning. Identity security also requires least privilege, monitoring, governance, device trust, privileged access controls, and tested recovery.
13. A user signs into Microsoft 365 using a synchronised account with password hash synchronisation. Where is the password actually validated, and why does that matter?
The Microsoft 365 sign-in is validated by Entra ID using the synchronised password-hash-derived data, not by sending the password back to an on-premises domain controller in real time. This matters because cloud sign-in can continue even if on-premises AD or the synchronisation server is temporarily unavailable. However, password changes, account disablement, and attribute changes made in AD still need to synchronise to Entra ID before they affect cloud sign-in.
14. Why might a user still successfully authenticate without MFA even when Conditional Access policies require it?
Conditional Access only applies when the sign-in is evaluated by Entra ID and matches the policy scope. A user might avoid an MFA prompt because they are excluded from the policy, the application is not covered, the sign-in comes from a trusted location, a previous MFA claim is still valid, the account is a break-glass exception, or the authentication path bypasses Entra ID entirely, such as a legacy on-premises Kerberos, NTLM, LDAP, or RADIUS flow. The important lesson is that ‘MFA is configured’ does not automatically mean every authentication path is protected.
15. Why should a Domain Admin account not be used on a normal workstation, even if MFA is enabled?
MFA helps protect interactive sign-in, but it does not make an untrusted workstation safe for privileged administration. If the workstation is compromised, an attacker may capture credentials, Kerberos tickets, hashes, session tokens, or administrative tools after the user has authenticated. A Domain Admin account is a Tier 0 identity and should be used only from hardened administrative workstations or other approved privileged access paths, not from ordinary user devices.