Learn Active Directory - History, Background & Why You Need Active Directory
Tracing the evolution of Windows networking from Windows NT domains to modern Active Directory and Azure AD, and understanding the problems Active Directory solves: centralized identity, single sign-on, security policies, and large-scale enterprise management.
#Introduction
In episode 0, you prepared your skills and lab environment — your map, compass, and harbor. Now it's time to understand why Active Directory exists. Before running any installation command, you need to understand the problems AD solves. Without this understanding, you'll be a GUI operator who memorizes clicks, not an administrator who understands the reasoning behind every decision.
The best way to understand it is to trace the history: every AD feature was born to answer the limitations of its predecessor. From the simple Windows NT domains, to the birth of Active Directory in Windows 2000, to its evolution into an enterprise identity service that supports millions of objects.
#From Workgroup to Windows NT Domains
In the beginning, small Windows networks ran as workgroups: a collection of standalone computers sharing resources without any central manager. Each computer had its own local account list. To access files on a server, you had to create a separate account on that server — and that account didn't apply to other computers.
The problem is clear: in a growing organization, accounts scattered everywhere, inconsistent, and impossible to manage. Imagine a shop with five employees and three computers: you'd have to create an account for every employee on every computer. Impractical — and that's just three machines.
In 1993, Microsoft introduced Windows NT domains to answer this problem. A Primary Domain Controller (PDC) became the central account database; other computers and several Backup Domain Controllers (BDCs) validated logins against that database. This was a huge leap forward: identity began to be centralized.
But NT domains had serious limitations:
- Flat namespace: no hierarchy. You couldn't create nested domain structures to match your organizational structure.
- Single master: only the PDC accepted changes. BDCs were read-only; if the PDC went down, changes were locked out.
- Not scalable: the account database wasn't designed for tens of thousands of users or many offices.
- No DNS foundation: domain names relied on NetBIOS, which is fragile on large networks.
These limitations are what drove Microsoft to design its replacement: Active Directory.
#The Birth and Evolution of Active Directory
In 2000, Windows 2000 Server introduced Active Directory, a directory service designed from scratch for the enterprise. Three architectural choices set it apart from NT domains:
- DNS-based: AD domain names follow the DNS hierarchy, so namespaces could be structured and global.
- LDAP-based: AD is a standard LDAP directory service, so it can be accessed and integrated with other directory ecosystems.
- Multi-master replication: all domain controllers can accept changes and replicate them to each other — no more single point of failure like the PDC.
After that, AD kept evolving: Windows Server 2003 added cross-forest trust support and the early AD Recycle Bin; 2008 introduced Read-Only Domain Controllers (RODCs) and Fine-Grained Password Policies; 2012 added Active Directory Administrative Center and a mature PowerShell module; 2016 brought Privileged Access Management; and 2019/2022 focused on security and hybrid integration.
On the cloud side, Azure Active Directory (now known as Microsoft Entra ID) brought the identity concept to cloud services — covered in more depth below.
#What Is Active Directory
Active Directory is the directory service for Windows networks: a centralized database that stores information about users, computers, groups, and other resources, plus the services that use it for authentication and authorization. Four pillars make it more than just an account database:
- Centralized authentication and authorization: one account, one login, valid across all resources.
- LDAP-based: the structure of its objects and attributes follows directory service standards.
- Kerberos as the default authentication protocol: secure ticket exchange replaces sending passwords around.
- DNS and Group Policy integration: DNS makes it discoverable, Group Policy lets it centrally control computer configuration.
The closest analogy: AD is the office receptionist. One person knows all the employees, knows who is allowed into which room, and issues access cards that work throughout the building. Without a receptionist, every room would have to keep its own employee list.
#Problems Active Directory Solves
| Problem | How AD Solves It |
|---|---|
| Centralized user management | One identity database for the entire organization |
| Single Sign-On (SSO) | Log in once, credentials work across many services |
| Centralized security policies | Group Policy configures millions of computers |
| Resource management | Access to files, printers, and applications managed through one directory |
| Scalability | Supports up to millions of objects in a single forest |
| Distributed administration | Delegation: helpdesk teams manage part of the directory without full rights |
| Representing organizational structure | OUs and domain hierarchy reflect the company structure |
Single Sign-On deserves emphasis. With SSO, an employee logs in once to the domain, and without retyping their password can access file servers, email, and domain-recognized applications. Behind the scenes, Kerberos issues a ticket that proves their identity to each service — this mechanism will be covered in the Kerberos episode.
#Active Directory vs Workgroup vs Other Directories
#AD vs Workgroup
A workgroup suits a home network with a few computers; AD is for organizations. Core differences: a workgroup has no centralized identity, no SSO, no centralized policies, and no hierarchy. AD becomes necessary when the answer to "who can access what" must be managed from a single point.
#AD vs LDAP Directory
LDAP is a protocol — a standard for reading and writing directory data. OpenLDAP and other directory servers implement this protocol. Active Directory is a product that implements LDAP, but augments it with Kerberos, DNS, Group Policy, and multi-master replication. So don't equate the two: you can query AD using an LDAP client, but AD's full capabilities go far beyond plain LDAP.
#AD DS vs Azure AD
Azure AD (Entra ID) is Microsoft's cloud identity service. The fundamental differences:
| Aspect | Active Directory (on-premises) | Azure AD |
|---|---|---|
| Location | Runs on your own servers | Managed service in the cloud |
| Authentication protocol | Kerberos, NTLM | OAuth2, OIDC, SAML |
| Group Policy | Available | No; replaced by Conditional Access |
| Application access | Windows/LDAP applications | Web and SaaS applications |
| Integration | Forest/domain | Cloud tenant |
The two are not substitutes but complements. Hybrid identity combines them through Azure AD Connect, which syncs on-premises identities to the cloud so you have one identity across two worlds. This hybrid scenario gets its own dedicated episode on Azure AD Connect.
#Active Directory Components
When people say "Active Directory", they usually mean AD DS. In fact, Microsoft's directory services family is broader:
| Component | Abbreviation | Role |
|---|---|---|
| Domain Services | AD DS | Core directory service: identity, authentication, directory |
| Certificate Services | AD CS | Public Key Infrastructure (PKI) infrastructure |
| Federation Services | AD FS | Claims-based single sign-on for external applications |
| Rights Management Services | AD RMS | Data protection for documents and email |
| Lightweight Directory Services | AD LDS | LDAP-only directory for applications without domain requirements |
This series focuses on AD DS as the foundation, and touches on other components (especially AD CS) in later episodes.
You can check your environment's current status with PowerShell — for example, using Get-CimInstance to read system properties. If the computer isn't domain-joined yet, the result will show a workgroup:
$env:USERDOMAIN
(Get-CimInstance Win32_ComputerSystem).PartOfDomain#Conclusion
In episode 1 you understand why Active Directory exists: it was born from the limitations of Windows NT domains, designed on the foundations of DNS, LDAP, and multi-master replication, then evolved into the foundation of enterprise identity — while also paving the way to hybrid identity in the cloud era.
Key takeaways:
- Workgroups suit small networks; AD exists for organizations that need centralized identity and policies.
- AD solves real problems: SSO, centralized policies, scalability, and distributed administration.
- LDAP is a protocol, AD is a product; Kerberos is the authentication engine behind SSO.
- Azure AD is fundamentally different and is connected via hybrid identity, not a replacement for on-premises AD.
In the next episode, we'll unpack Active Directory architecture and logical structure — forest, domain trees, domains, organizational units, objects, and trust relationships, plus the roles of the schema, global catalog, and FSMO roles. This is the conceptual map you'll use for as long as you manage AD. Make sure you understand episode 1's material, because everything is built on top of it!