Active Directory and Microsoft Entra ID Fundamentals
Before you start
Who is this for?
For Windows and Microsoft 365 learners who need to distinguish directory services from cloud identity.
Prerequisites
- Windows Fundamentals
- Basic networking and DNS
What you'll be able to do
- Explain AD DS structure
- Describe LDAP, Kerberos, Group Policy, and DNS dependencies
- Distinguish Entra ID and Entra Domain Services
- Recognize hybrid identity patterns
Practical outcome
Draw identity components and choose relevant first checks for a sign-in or policy failure.
Understand AD DS structure and protocols, then distinguish them from cloud and hybrid identity.
A directory service stores identities and related objects so systems can find accounts and make access decisions. Active Directory Domain Services (AD DS) is the traditional Windows Server directory used for domain membership, directory queries, Kerberos authentication, and Group Policy. Microsoft Entra ID is Microsoft’s cloud identity and access management service for cloud applications and devices. Entra ID is not simply AD DS hosted in the cloud.
1. AD DS: forests, domains, and OUs
Section titled “1. AD DS: forests, domains, and OUs”A forest is the highest-level AD DS structure. It contains one or more domains that share a schema, configuration, and global catalog. A domain stores directory objects and provides an administrative and replication scope. A single-domain forest is common; adding domains creates operational complexity and should meet a real requirement.
An organizational unit (OU) is a container used to organize objects, delegate administration, and scope Group Policy. An OU is not a security boundary like a separate forest. Users, groups, and computer accounts are directory objects; security groups help assign access without granting permissions one person at a time.
A domain controller (DC) runs AD DS and commonly provides DNS and Kerberos services. Multiple DCs replicate directory data. Availability depends on DNS, network connectivity, time, replication health, and the client locating a suitable DC. Microsoft describes this forest/domain structure in its AD DS logical design guidance.
2. DNS, LDAP, and Kerberos
Section titled “2. DNS, LDAP, and Kerberos”AD DS relies heavily on DNS. Domain members use DNS records, including service records, to find domain controllers and services. A wrong DNS server can therefore break domain logon or policy processing even when a DC is powered on. Check client DNS configuration and DC locator records before assuming the directory database is unavailable.
LDAP is a protocol for reading and updating directory information. A directory object is identified by attributes and a distinguished name. Simple LDAP binds must be protected with TLS or an equivalent approved protection; avoid transmitting credentials over an unprotected connection.
Kerberos is a ticket-based authentication protocol. A client obtains a ticket-granting ticket from the Key Distribution Center (KDC) on a domain controller, then requests a service ticket for a named service. Correct DNS names, time synchronization, account state, and service principal names matter. The client’s password is not sent to every application server for each access. See the Microsoft Kerberos overview.
3. Group Policy
Section titled “3. Group Policy”Group Policy centralizes supported user and computer settings. Group Policy Objects (GPOs) link to sites, domains, or OUs, and settings apply according to scope, inheritance, filtering, and precedence. The policy data is stored across Active Directory and SYSVOL; clients need DNS and network access to retrieve and process it.
For diagnosis, compare the intended OU and GPO links with the computer or user that is affected, then collect gpresult /r or gpresult /h report.html from an authorized Windows client. A GPO that exists is not necessarily in scope or successfully applied. Review Resultant Set of Policy and Group Policy operational events rather than changing several links at once. Microsoft documents Group Policy scope and processing.
4. Microsoft Entra ID and related services
Section titled “4. Microsoft Entra ID and related services”Microsoft Entra ID provides cloud identity, sign-in, application access, and policy capabilities. Modern applications commonly use protocols such as OpenID Connect, OAuth 2.0, or SAML. Its object model and protocols differ from AD DS: an Entra ID tenant is not an AD DS forest, and Entra ID does not natively provide the same LDAP, domain join, Kerberos, and Group Policy behavior as a Windows Server domain.
Microsoft Entra Domain Services is a separate managed service that supplies selected AD-compatible domain protocols and features for workloads that need them. It is not identical to customer-operated AD DS; Microsoft operates the domain controllers and the managed domain has service-specific limitations. Use Microsoft’s identity comparison and Domain Services documentation for current capability details.
5. Hybrid identity
Section titled “5. Hybrid identity”A hybrid environment connects on-premises AD DS with cloud identity. An organisation may synchronize selected users and groups to Entra ID and choose an authentication design. Synchronization copies or matches identity data; it does not mean every sign-in uses the same protocol or the same source of authority. Password hash synchronization, pass-through authentication, and federation are distinct designs with different operational trade-offs.
Before changing synchronization or sign-in settings, identify the authoritative directory for each object, the sign-in method, recovery accounts, and the impact of a connector or network outage. Follow current Microsoft deployment guidance; hybrid identity configuration is version-, tenant-, and licensing-dependent.
6. Troubleshooting map
Section titled “6. Troubleshooting map”| Symptom | First checks |
|---|---|
| Domain sign-in cannot find a DC | Client DNS servers, SRV lookup, VPN/VLAN, time, DC availability |
| Group Policy is missing | gpresult, OU membership, GPO link/filter, SYSVOL reachability, Group Policy log |
| Kerberos service access fails | Client and service time, DNS name, SPN, account status, KDC reachability |
| Cloud application sign-in fails | Entra sign-in logs, account status, Conditional Access result, app redirect/protocol configuration |
| Synced identity is stale | Object source of authority, sync health, connector logs, scope and attribute rules |
Use read-only checks and collect the error, host, user, and timestamp before making directory changes. Domain, tenant, and identity edits can affect many users; make them through a reviewed change process.
Practical exercise
Section titled “Practical exercise”For a fictional company with a local Windows domain, Microsoft 365, and laptops, draw the user account source, domain controller, DNS path, and cloud sign-in path. Mark which clients use AD DS and which access Entra ID directly. Add one failure case and the first log or command you would inspect.