Active Directory / Basic / Lesson 1
AD DS and identity boundaries
Identify the directory service, its security responsibilities, and its boundaries before choosing a domain, cloud identity integration, or administrative action.
On this page
Lesson goals
- Distinguish AD DS from Microsoft Entra ID and related services.
- Explain directory objects, domain controllers, and resource authorization.
- State what an offline model can and cannot verify.
Name the service and baseline precisely
This course concerns Active Directory Domain Services, the Windows Server directory service used for domains, Kerberos-based authentication, directory access, and Group Policy. The reference baseline is Microsoft documentation for Windows Server 2025, reviewed on 2026-10-26. It is not a claim that a domain or Windows environment was deployed or tested. Server operating-system version, schema, and domain/forest functional levels are separate facts. Later lessons label those distinctions explicitly. The synthetic namespace ad.example.test is a documentation fixture, not a recommendation to rename an existing directory or a production namespace design.
Similar identity names do not imply identical protocols
Microsoft Entra ID is a cloud identity service and is not simply an AD DS domain controller hosted on the internet. Microsoft Entra Domain Services is another managed domain-service offering, while AD LDS serves application directory scenarios without being a full AD DS domain. Hybrid synchronization or federation connects selected identity relationships; it does not make every object, policy, or authentication flow identical. The complete Python classification below compares declared requirements only. It performs no discovery or protocol connection and deliberately avoids treating a product label as a complete architecture decision. Validate actual application requirements before selecting a service.
requirements = {"domain_logon", "group_policy"}
capabilities = {
"AD DS": {"domain_logon", "group_policy", "ldap"},
"cloud_identity_model": {"oauth_apps", "cloud_groups"},
}
for service, supported in capabilities.items():
print(service, requirements <= supported)
AD DS True
cloud_identity_model False
AD DS is True and the limited cloud model is False. These sets are a teaching abstraction, not a product feature inventory or an authentication test.
Separate an identity record from permission to a resource
A directory stores users, computers, groups, and other objects with attributes governed by a schema. Domain controllers host directory replicas and provide services; member computers are not additional writable directory replicas merely because they join the domain. Authentication establishes an identity under a protocol, while authorization evaluates whether that identity may perform an operation. Group membership can contribute authorization data, but the target resource and its access policy still matter. A successful sign-in therefore does not prove access to a file, application, or directory attribute. Keep actor, target, action, and decision visible in troubleshooting notes.
Document the trust boundary before a change
The planning record below names one forest, one domain, two conceptual controllers, and a protected resource. It is not a Windows configuration or an import format. A real design must identify administrative authority, physical and network dependencies, supported versions, and recovery ownership before any change. Domain controllers are security-sensitive infrastructure because control over directory administration can affect many resources. Do not place routine user work and privileged administration into one undifferentiated identity path. This course uses only offline fixtures and never binds to LDAP, runs Windows commands, or requests credentials.
{"forest":"ad.example.test","domain":"ad.example.test","controllers":["dc-a","dc-b"],"resource":"course-files","authority":"directory-team"}
Expected review result: every named identity system and administrative owner is explicit. This record creates no forest, domain, controller, or resource.
Make evidence proportional to the claim
An offline model can verify a relationship or arithmetic rule in its synthetic inputs. It cannot establish DNS reachability, Kerberos success, actual directory permissions, replication health, or recoverability. Real investigations need authorized evidence collected under an operational process, with sensitive data minimized. Keep configuration proposals separate from measured observations and from approved changes. This course focuses on AD DS architecture and reasoning, rather than repeating a general Windows Server installation overview. Record service identity and scope first so later policy, replication, and recovery conclusions are about the correct system instead of a similarly named cloud service.
Common errors and fixes
Entra ID is treated as a drop-in AD DS controller.
- Why it happens
- Cloud identity and domain protocols were conflated.
- How to fix it
- Map the actual authentication and policy requirements to the correct service.
- Prevent it next time
- Name each identity system explicitly in designs.
Successful sign-in is assumed to grant file access.
- Why it happens
- Authentication was mistaken for authorization.
- How to fix it
- Evaluate the target resource action and access policy separately.
- Prevent it next time
- Record identity and permission evidence independently.
A local model is called a domain health test.
- Why it happens
- Synthetic reasoning was confused with infrastructure observation.
- How to fix it
- State the model’s tested inputs and limitations.
- Prevent it next time
- Label operational fragments and observations accurately.
Check your understanding
1. An application requires OAuth sign-in and has no LDAP, domain-join, or Group Policy dependency. Explain why the model alone should not force an AD DS deployment.
Show worked solution
The declared requirements differ from the model’s domain-logon fixture. Review the application’s identity provider, token, authorization, and lifecycle contracts rather than selecting AD DS because it appears in an existing diagram. A cloud identity service may fit, but that conclusion still needs the actual application and organizational requirements. No infrastructure change follows automatically from a set comparison.
2. A learner can authenticate but cannot read course-files. Name the next evidence categories without proposing a live administrative command.
Show worked solution
Identify the authenticated account and session, the exact resource and requested action, relevant group or token information, and the resource’s effective access policy. Also distinguish a permission denial from a missing path or network failure. Use authorized existing records and a synthetic access model first; do not reset accounts or broaden groups merely because authentication succeeded.
Key takeaways
- AD DS is a specific directory and domain service.
- Authentication, authorization, and cloud integration differ.
- Offline evidence must not be presented as live verification.