Windows Server Administration

Managing identity on a single Linux server is relatively straightforward: user accounts in /etc/passwd, SSH keys in authorized_keys, and a sudo policy in /etc/sudoers. As covered in the Linux Server Planning lecture, that model works for individual machines. Organizations, however, rarely run individual machines in isolation. A company might have five hundred Windows desktops across three offices, a dozen file servers, and a set of shared drives that should automatically follow department membership. At that scale, the per-machine account model breaks down entirely. Someone leaves the organization and their access needs to be revoked on every machine they ever touched. A new security policy needs to roll out to every workstation at once. A shared folder needs to be readable by everyone in one department and writable only by their manager. Doing any of that manually is not operations: it is paperwork with a password.

Active Directory is Microsoft’s centralized answer to that problem. It is the identity and management platform that most enterprise Windows environments run on. The System Security and Hardening lecture introduced the Identity Provider (IdP) pattern and described Active Directory as a concrete instance of it: an IdP from an earlier era, one built for the tightly managed trust of a corporate network rather than the open internet. Where a modern software-as-a-service (SaaS) identity provider might issue JSON Web Tokens over HTTPS (Hypertext Transfer Protocol Secure), Active Directory issues Kerberos tickets inside a domain. The fundamental idea is the same: one authoritative system holds identity, and every machine in the environment defers to it for authentication and authorization rather than maintaining its own isolated account database. Today, Active Directory rarely stands alone. Most organizations extend it into Microsoft Entra ID, Microsoft’s cloud identity platform on Azure, creating a hybrid setup where the same user identity works both on premises and in Microsoft 365, SaaS applications, and cloud services.

When this system is healthy, it is invisible. When it breaks, the failure is not contained. Users cannot sign in. Shared drives disappear from File Explorer. A scheduled task that ran automatically yesterday stops without explanation. A printer in a remote office becomes unavailable. What looks like five separate outages is often one broken control plane radiating symptoms outward in every direction. That is the operational reality that makes Windows identity infrastructure worth understanding from the inside: the symptoms never point directly at their own cause.

The easiest way to make that control plane legible is to start with the whole shape of the environment, then drill down into the parts. The lecture begins with the platform context for Windows Server, then zooms in on Active Directory Domain Services (AD DS), the protocols that make the directory usable, Group Policy as the management layer, file services as the place where permissions become tangible, and the cloud-era services that sometimes replace or complement those classic roles.

The Whole System at a Glance

Before drilling into editions, forests, policies, and replication, it helps to see the environment as a set of cooperating layers. In a typical Windows domain, a domain controller runs Active Directory Domain Services (AD DS), the Domain Name System (DNS) records that help clients locate it, Kerberos for ticket-based authentication, Lightweight Directory Access Protocol (LDAP) services for directory lookups, and the SYSVOL share that distributes Group Policy files. File servers, printers, scheduled tasks, and line-of-business applications all sit downstream from that control plane. If that mental model stays clear, the rest of the explanation becomes a zoom-in rather than a pile of product names.

The diagram below shows the path a normal sign-in and file-share request usually follow.

flowchart TB
  User["User at a domain-joined workstation"] --> Client["Windows client"]
  Client --> DnsLookup["DNS lookup for domain services"]
  DnsLookup --> DC["Domain controller\nAD DS\nKerberos\nLDAP\nGroup Policy / SYSVOL"]
  DC --> Policy["Identity and policy data"]
  Policy --> Client
  Client --> Resource["File server, printer, or app server"]
  DC --> Resource
  Cloud["Microsoft Entra ID\nMicrosoft 365"] -. hybrid sync .-> DC

That top-level view also suggests a useful order for understanding the system. First comes the host platform itself. Then comes the directory model that makes identity central instead of per-machine. After that come policy and file services, which are the two places most users actually feel the directory. Finally, hybrid and cloud-first identity tools show how the same control-plane questions reappear in newer platforms.

Why Windows Server Still Matters

If your mental model of server administration is mostly Linux, containers, and cloud APIs, Windows Server can look like legacy infrastructure that lingers only because nobody has turned it off yet. That is the wrong frame. Windows Server is still a live platform used to run authentication, file services, Remote Desktop environments, print services, internal web applications, management tools, and line-of-business software that depends on Windows APIs and domain membership. Even organizations that are aggressively adopting SaaS and cloud identity often keep some Windows Server footprint because identity, storage, and application compatibility do not all move at the same pace.

The underlying problem Windows Server solves is not uniquely Microsoft-shaped. Every organization needs answers to the same operational questions: how do you create accounts once instead of on every machine, how do you enforce security settings consistently, how do you delegate administrative work without sharing one all-powerful password, and how do you make resource access follow group membership rather than manual one-off access control list (ACL) edits? Linux shops often answer those questions with a mix of local system files, SSH, configuration management, FreeIPA, LDAP, Kerberos, or cloud identity. Windows Server answers them with a more integrated bundle of directory services, policy distribution, Server Message Block (SMB) file sharing, and administrative tooling.

Microsoft’s current server platform is Windows Server 2025. The important point is not memorizing every SKU. It is understanding what Microsoft means by an edition, and which editions matter when you are reasoning about infrastructure.

The table below summarizes the present-day platform at a level useful for operations.

Edition	What It Is For	Why You Care Operationally
Standard	General-purpose server deployments with limited virtualization rights	Common choice for domain controllers, file servers, and smaller on-prem environments
Datacenter	Heavily virtualized environments and advanced datacenter features	Same core identity roles as Standard, but aimed at dense server consolidation and larger platforms
Datacenter: Azure Edition	Azure and Arc-connected Windows Server deployments	Important in hybrid/cloud deployments, but not the normal baseline for learning classic AD DS concepts
Essentials	Very small environments with simplified licensing and limits	Exists, but is not the model to build your conceptual picture around

For administration and Active Directory work, Standard and Datacenter are the editions that matter most. The identity concepts are the same across them. What changes is the surrounding operational context: how many hosts you run, how heavily you virtualize, and whether the directory lives entirely on premises or is part of a larger hybrid design.

One source of confusion for new administrators is the difference between a Windows Server role and a separate Microsoft product. Roles such as Active Directory Domain Services (AD DS), DNS Server, DHCP Server, Hyper-V, and File and Storage Services are built into Windows Server and can be installed through Server Manager or PowerShell. Products such as Exchange Server, SQL Server, and System Center are not roles. They are separate applications that may integrate tightly with the operating system and with Active Directory, but they are not part of the base server role catalog. That distinction matters because Windows Server is a platform, not a single-purpose appliance.

Another important choice is installation model. Desktop Experience gives you the familiar graphical shell and local management tools. Server Core removes the full desktop shell and expects you to manage the server through PowerShell, RSAT (Remote Server Administration Tools), Windows Admin Center, or other remote tools. Server Core exists because infrastructure servers usually do not need a person clicking around on them every day. Fewer installed components means less patching, less surface area, and less temptation to treat the server like a workstation. The tradeoff is that your operational discipline must be better. If you do not know how to manage Windows remotely, Server Core feels hostile. If you do know how, it feels appropriately boring.

Active Directory As the Identity Plane

Active Directory Domain Services (AD DS) is Microsoft’s on-premises Identity Provider. It is an identity provider from an earlier era, built for tightly managed trust inside a corporate network. This section explains what that means in practice. A directory stores objects: user accounts, computer accounts, security groups, service accounts, and policy containers. An authentication service built on Kerberos verifies who is requesting access and issues tickets that clients present to resources. DNS provides the naming layer that lets clients locate the right domain controller. Group Policy distributes configuration from the directory out to every managed machine in the fleet. Together those pieces let a single administrator define what ten thousand machines look like and who can use them.

At a small scale, local accounts seem fine. A workstation has a local Administrator account and a few local users. A file server has a few local groups. A remote system has its own password policy. That model collapses as soon as people or computers need to move across the environment. The same engineer needs access to three servers, two file shares, a virtual private network (VPN), and a remote desktop host. If every machine stores identity locally, offboarding becomes a scavenger hunt, auditing becomes nearly impossible, and mistakes accumulate silently. A directory exists so that identity becomes a shared system rather than a repeated manual task at every machine.

A Domain Controller Is a Special Kind of Server

A domain controller is the server that hosts AD DS for a domain. It is not just another member server with a management role added. Promotion changes what the machine is responsible for. It now stores a writable copy of the directory database, participates in replication, answers authentication requests, exposes LDAP for directory lookups, stores or helps distribute Group Policy data, and often runs integrated DNS for the domain. That is why you treat domain controllers more carefully than ordinary servers. They are part database server, part authentication service, part naming infrastructure, and part policy distribution system.

On a member server or workstation, local identities live in the Security Accounts Manager (SAM) database. On a domain controller, identity moves into the directory. This is one reason operational advice for member servers does not always transfer cleanly to domain controllers. For example, a local administrator model makes sense on a normal Windows machine. A domain controller has no meaningful concept of ordinary local users and groups in the way a member server does, because the machine has joined the infrastructure that defines identity for the domain.

Domains, Forests, Sites, and Trusts

The basic administrative boundary in AD DS is the domain. A domain is a set of objects that share a directory database, a naming context, and a common security boundary for many day-to-day administrative tasks. If you create corp.example.com, you are not just choosing a name. You are defining where user and computer objects live, where domain-level policy applies, and which domain controllers replicate that naming context.

Above the domain sits the forest. The forest is the broadest trust and schema boundary in Active Directory. Domains in the same forest share a common schema and configuration and automatically trust one another. That sounds abstract until you think about mergers, geography, or delegated administration. A single-domain forest is common in smaller or moderately sized environments because it keeps administration simple. Multiple domains tend to exist for specific reasons such as legal separation, legacy organizational history, or a genuine need for distinct domain-level boundaries. New administrators often imagine extra domains as a neat way to organize departments. In practice, that is usually a mistake. Departments are better represented with organizational units (OUs) and groups. Domains are expensive in both design and operations.

Sites are the part many first explanations skip, even though they matter operationally. A site models network topology, not organizational hierarchy. It tells Active Directory which subnets are close to which domain controllers so that clients authenticate locally when possible and replication across slower links is controlled intelligently. If you have offices in Seattle, Dallas, and London, the site design is how AD understands that not every domain controller is equally near every client.

Trusts determine whether authentication in one domain can be honored in another. Inside a forest, two-way transitive trust is automatic. Between forests, trust is explicit. Conceptually, trust answers this question: if a user identity is vouched for over there, under what conditions will I accept that claim over here? That is the same security question you see in federated web identity, just expressed in a different protocol and a different era of infrastructure.

The hierarchy is only part of the story, because sites are not just another child object under a domain. Domains and forests describe logical identity boundaries. Sites describe where clients and domain controllers are near one another on the network. The diagram below separates those two ideas so the terms do not blur together.

flowchart TB
  subgraph Logical["Logical identity boundaries"]
    Forest["Forest\nShared schema and top-level trust boundary"]
    DomainCorp["Domain: corp.example.com\nObjects, policy, and authentication boundary"]
    DomainLab["Domain: lab.example.com\nSeparate domain boundary"]
    Forest --> DomainCorp
    Forest --> DomainLab
    DomainCorp <--> |automatic trust within one forest| DomainLab
  end

  subgraph Topology["Network topology layer"]
    SiteSea["Site: Seattle\nNearby subnets use local DCs"]
    SiteDal["Site: Dallas\nNearby subnets use local DCs"]
    SiteLon["Site: London\nNearby subnets use local DCs"]
  end

  DomainCorp -. controllers can be placed in .-> SiteSea
  DomainCorp -. controllers can be placed in .-> SiteDal
  DomainLab -. controllers can be placed in .-> SiteLon

  PartnerForest["Partner forest"]
  Forest -. explicit forest trust .-> PartnerForest

The table below is worth internalizing because these terms solve different problems.

Term	What It Models	Why It Exists
Domain	Administrative and authentication boundary	Keeps a coherent set of objects, policies, and domain controllers together
Forest	Top-level schema and trust boundary	Defines the broadest AD security and replication universe
Site	Network topology	Helps clients find nearby domain controllers and controls replication behavior
Trust	Cross-boundary authentication relationship	Allows principals from one domain or forest to be recognized in another

You will also encounter the Global Catalog (GC), which is a forest-wide searchable partial replica of directory data. The GC exists so that logons, group lookups, and directory searches do not require every domain controller to know every attribute of every object in every domain. It is one more example of the same design theme: the directory is not a single giant flat database queried locally by one server. It is a distributed system trying to make identity feel local even when the organization is not.

DNS Is Not Optional

Active Directory depends on DNS so completely that many AD failures are really DNS failures wearing a fake mustache. Clients do not magically know where a domain controller is. They query DNS for SRV records that identify services such as Kerberos and LDAP in the relevant domain. Domain controllers register those records. Group Policy processing, domain joins, service location, and many administrative tools all depend on that naming layer working correctly.

This is why experienced administrators react strongly when they see a domain-joined Windows client pointed at a public DNS resolver. A workstation using 8.8.8.8 may resolve public websites perfectly and still fail to find the domain controller, or fail to locate the right one for its site, or miss the records that make Kerberos and LDAP function. From the user’s perspective, the failure looks like “my password stopped working.” From the system’s perspective, the failure is often “the machine cannot locate the identity infrastructure it belongs to.”

Microsoft’s own guidance on naming conventions in Active Directory is a useful reminder here. Domain names should be fully qualified DNS names, ideally based on a registered organizational namespace. A name like corp.example.com or ad.example.org is the clean modern pattern. You will still see .local in old tutorials and homelabs. Treat that as legacy shorthand, not best practice for a new deployment.

Kerberos, LDAP, and the Shadow of NTLM

Two protocols dominate the day-to-day behavior of Active Directory: Kerberos for authentication and LDAP for directory queries. Kerberos is a ticket-based protocol that predates OpenID Connect (OIDC) and Security Assertion Markup Language (SAML), and it was designed for tightly coupled trust domains. Active Directory is that trust domain. Kerberos is defined formally in RFC 4120. LDAP (Lightweight Directory Access Protocol), defined in RFC 4511, is the protocol clients and tools use to query and update directory objects. If DNS tells a client where the directory lives, Kerberos and LDAP are how the client speaks to it.

In practical terms, Kerberos lets a user prove identity once and then obtain service-specific tickets without retyping a password every time a resource is accessed. A user signs in, the client obtains a Ticket-Granting Ticket (TGT), and later the client exchanges that for service tickets to specific resources such as a file server or web application. This is why Kerberos feels like “single sign-on” inside a domain. The user is not truly authenticated once for everything forever; rather, the client is using a ticketing system to request scoped proof for each service as needed.

Kerberos has operational consequences that matter more than the abstract protocol flow. It depends on correct DNS. It depends on time being reasonably synchronized because tickets have validity windows. It depends on Service Principal Names (SPNs) being mapped correctly so the client knows which account is allowed to represent a given service. Many famous Windows troubleshooting sessions come down to one of these three conditions being violated: wrong name, wrong time, or wrong service identity.

LDAP is less glamorous but equally important. It is how administrative tools search for users, groups, computers, and policy objects. When you open Active Directory Users and Computers and browse an organizational unit (OU), that graphical user interface (GUI) is not magic. It is a management layer over directory queries. PowerShell cmdlets such as Get-ADUser, Get-ADComputer, and Get-ADGroup do the same thing in a more automatable form.

The sequence below captures the usual split. Kerberos proves identity to a service. LDAP asks the directory questions about objects and policy. NTLM appears only when the cleaner Kerberos path cannot be used.

sequenceDiagram
  participant C as Client
  participant DNS as DNS
  participant DC as Domain Controller / KDC
  participant FS as File Server
  C->>DNS: Query _kerberos._tcp and _ldap._tcp SRV records
  DNS-->>C: Closest domain controller
  C->>DC: AS-REQ
  DC-->>C: AS-REP + TGT
  C->>DC: TGS-REQ for cifs/fs01.corp.example.com
  DC-->>C: TGS-REP + service ticket
  C->>FS: Present Kerberos service ticket
  FS-->>C: Access granted
  C->>DC: LDAP query for users, groups, or policy data
  DC-->>C: Directory results
  opt If Kerberos cannot be used
    C->>FS: NTLM challenge/response
    Note over C,FS: Compatibility path, usually less desirable
  end

You will also hear about NT LAN Manager (NTLM). NTLM is the older Microsoft authentication protocol that predates modern Kerberos-based Active Directory behavior. It still appears for compatibility in certain scenarios, especially with older applications or awkward trust and naming situations. The right mental model is not “NTLM is gone.” It is “Kerberos is the design goal; NTLM is the compatibility tax.” Mature Windows environments try to reduce unnecessary NTLM because it gives up many of the security and operational properties that make domain authentication predictable.

Designing the Directory

Once you understand that Active Directory is the identity and policy plane for Windows systems, design questions stop sounding cosmetic. The name of the domain, the placement of objects, the way groups are nested, and the delegation model all change what future administration feels like. A directory can be elegant and boring, or it can become a museum of historical accidents.

Name the Domain Like It Will Still Exist in Ten Years

Domain naming should be boring, clear, and based on a namespace your organization actually controls. The safest pattern is to use a registered parent domain and place AD beneath it, such as corp.example.com, ad.example.edu, or internal.example.org. This avoids collisions, keeps the naming story coherent, and makes hybrid or internet-connected growth easier later.

The temptation to invent a cute private namespace usually comes from the false feeling that internal naming does not matter. It does matter. A directory name leaks into service principals, user principal names, certificates, DNS zones, scripts, documentation, backup tooling, and every future migration project. Bad naming choices do not stay politely contained. They become sediment.

There is also a second naming layer that many Windows explanations underplay: the NetBIOS (Network Basic Input/Output System) domain name. The fully qualified domain name (FQDN) answers the DNS question: what is the real domain name, where do clients look for service records, and what namespace appears in sign-in names like jsmith@corp.example.com? The NetBIOS short name answers the compatibility question: what short label appears in older logon formats such as CORP\jsmith and in legacy tools that still expect a compact domain name? They travel together, but they do not solve the same problem. One is the modern DNS-facing identity of the domain. The other is the short historical label that still leaks into administration.

OUs Organize Administration; Groups Organize Access

New administrators often try to use one object type for every organizational problem. Active Directory works better when you let each object type do the job it was designed for.

An Organizational Unit (OU) is primarily an administrative and policy boundary. OUs let you structure computers and users so you can delegate responsibility and target Group Policy. If the help desk should be able to reset passwords only for faculty users, or if lab computers need different policies from finance laptops, OUs are the tool.

A group is primarily a membership and authorization boundary. Groups answer the question “who belongs to this set?” If everyone in a team should reach a file share, or all printer operators should manage a printer queue, or a role account should have permission to run a scheduled task, groups are the tool.

This sounds simple until you encounter environments that use OUs as if they were access-control groups, or use giant groups as if they were substitutes for directory structure. That is when policy targeting becomes messy, delegation becomes unclear, and permission reviews become painful. The clean rule is worth repeating: OUs are for administration and policy; groups are for access and membership.

Group Scope Matters More Than the Name Suggests

Active Directory group scope exists because membership source and permission target are not the same thing. Microsoft supports several scopes, and the ones you care about most are global, domain local, and universal groups.

The table below gives the operational view that matters most.

Group Type	Typical Use	Where Members Come From	Where Permissions Can Be Assigned
Global	Collect users or computers with the same role inside one domain	The same domain	Resources in any trusting domain
Domain local	Represent access to a resource that lives in one domain	Any trusted domain	Resources in that domain
Universal	Aggregate groups across multiple domains in a forest	Any domain in the forest	Resources in any domain in the forest
Local (on one computer)	Machine-specific access on a member server or workstation	Local accounts and selected domain principals	Only that one machine

This is where the classic Accounts -> Global groups -> Domain Local groups -> Permissions (AGDLP) pattern comes from. You place people into role-based global groups, place those global groups into resource-based domain local groups, and assign permissions to the domain local groups. The value is not that the acronym is cute. The value is that role membership changes often, while ACL design should change slowly. AGDLP lets the frequent change happen in the group layer without constantly rewriting resource permissions.

Suppose you run a design share on a file server. Instead of granting the folder to 27 individual designers, you might create GG_Design_Users as the role group, DL_Share_Design_RW as the resource group, place the global group into the domain local group, and assign NTFS modify permissions to the domain local group. When one designer joins or leaves, you update the role membership. You do not edit the ACL on the share every time headcount changes.

Universal groups matter most in multi-domain forests. In a single-domain environment, many administrators can go years without needing them often. That fact is useful because it keeps you from memorizing every possible nesting rule before you understand the simpler and more common patterns.

Delegation Is Better Than Shared Admin Accounts

One quiet strength of Active Directory is that it supports administrative delegation cleanly if you design for it. A desktop support team may need to reset passwords and unlock accounts but not manage domain controllers. A department IT lead may need to join machines to the domain in one OU but not touch servers elsewhere. A print administrator may need to manage printer-related objects without holding general domain-wide rights.

That is a healthier model than the lazy alternative of one shared administrator password known by everybody who might need it. Shared admin accounts destroy accountability, complicate incident response, and make least privilege nearly impossible. Good directory design is therefore not just about convenience. It is a security design exercise. You are choosing where authority lives, how narrowly it can be granted, and how reviewable it remains months later.

Group Policy and the Windows Management Model

If Active Directory is the identity plane, Group Policy is the distribution mechanism that turns identity into fleet behavior. Group Policy lets administrators push security settings, scripts, registry-based configuration, software-related settings, mapped drives, and many other controls to users and computers in a domain. It is one of the clearest examples of Microsoft’s integrated approach. In many Linux environments, you would reach for an external configuration management tool first. In a Windows domain, a large class of those tasks begins with Group Policy Objects (GPOs).

What a GPO Actually Is

A Group Policy Object (GPO) has two important halves. One half lives in the directory as the Group Policy Container (GPC), which stores metadata about the object. The other half lives in the SYSVOL share, the replicated domain-wide path that stores policy files and scripts, as the Group Policy Template (GPT). That split matters because it explains why GPO problems can involve both directory replication and file replication.

When a Windows computer starts, it processes computer-targeted policy. When a user signs in, the system processes user-targeted policy. The machine consults domain controllers, reads the applicable GPOs, and applies settings according to scope, inheritance, and precedence rules. This is why Group Policy feels powerful: one change in the directory can alter behavior across an entire fleet. It is also why it feels dangerous: one wrong setting can alter behavior across an entire fleet.

Policies are not all the same kind of thing. Some are true policy settings that enforce a value and may prevent local override. Others come from Group Policy Preferences, which are more like centrally delivered defaults or convenience actions. Preferences can create mapped drives, place shortcuts, set registry values, deploy printers, or configure scheduled tasks. The difference matters because a preference does not always behave like a hard lock. If you confuse preferences with enforced policy, troubleshooting becomes muddy.

Processing Order, Inheritance, and Precedence

The beginner mnemonic for Group Policy processing is LSDOU: Local, Site, Domain, Organizational Unit. That is a good starting point because it explains the broad direction of policy application. But it is not enough if you want to troubleshoot real environments.

The order is easier to reason about when you picture it as a narrowing funnel. Broad defaults apply first, and more specific containers can narrow or replace them later.

flowchart LR
  Local["Local policy"] --> Site["Site-linked GPOs"]
  Site --> Domain["Domain-linked GPOs"]
  Domain --> Parent["Parent OU GPOs"]
  Parent --> Child["Child OU GPOs"]
  Child --> Result["Effective user or computer configuration"]

That flow is only the starting point. Link order, enforcement, security filtering, and other mechanisms can still change the final result.

Policies linked to nested OUs are processed from parent to child, so the settings closest to the object usually win when there is conflict. Within a single site, domain, or OU, link order matters. A GPO with the highest precedence for that container is processed last for that container. On top of that, administrators can block inheritance on an OU or enforce a higher-level GPO so it cannot be overridden below. There is also security filtering, which changes which principals are allowed to apply a GPO, and Windows Management Instrumentation (WMI) filtering, which can target policies based on characteristics of the target system.

This sounds like a lot of moving parts because it is. Windows policy distribution is powerful precisely because it lets you layer global defaults with local exceptions. The price is that you must reason about both scope and precedence. A finance laptop in a child OU may inherit a domain-wide password policy, a parent-OU workstation baseline, a child-OU device hardening policy, and a specific filtered GPO for BitLocker settings. All four can be correct at the same time.

One especially important feature is loopback processing. Normally, user settings come from the user’s location in the directory, and computer settings come from the computer’s location. Loopback changes that behavior for certain machines. It lets the computer’s OU influence which user settings apply when someone signs in there. This is useful for shared kiosks, classroom machines, Remote Desktop Services (RDS) session hosts, and other systems where the machine’s role matters more than the user’s normal home OU. Loopback is one of those features that feels obscure until you need it. Then it suddenly explains why two logons by the same user behave differently on two different computers.

The table below captures the knobs that administrators use most often when policy behavior gets complicated.

Mechanism	What It Changes	Typical Use
Link order	Precedence among GPOs linked to the same container	Resolve which of several peer GPOs wins
Block inheritance	Prevents higher-level GPOs from flowing down normally	Isolate an OU from broad parent policy
Enforced	Prevents lower-level GPOs from overriding the link	Make a higher-level security baseline stick
Security filtering	Limits which principals may apply the GPO	Target a subset of users or computers
WMI filtering	Applies the GPO only when system properties match	Target by OS version, hardware traits, or other conditions
Loopback	Alters how user policy is determined on specific machines	Shared computers, kiosks, Remote Desktop Services hosts

Why GPO Troubleshooting Feels Slippery

A common Windows administration experience goes like this: you changed one GPO, but the client still behaves as if the old setting exists, or the setting works on one machine but not another, or the Resultant Set of Policy (RSoP) is not what you expected. These problems feel slippery because policy is not a single local file you inspect once. It is distributed state. You must reason about replication, scope, filtering, precedence, refresh cycles, and whether the setting is a computer policy, a user policy, or a preference.

Useful tooling exists, but only if you think to use it early. The first command below is the fast text summary on a client. The second produces a fuller HTML Resultant Set of Policy report when you need something you can inspect in detail or hand to someone else.

gpresult /r

Get-GPResultantSetOfPolicy -ReportType Html -Path C:\Temp\rsop.html

The lesson is larger than the commands themselves. Group Policy teaches a broader operational habit: do not confuse intended configuration with effective configuration. The policy you linked is not the same thing as the policy the client received. In systems administration, that gap appears everywhere.

gpresult /r is usually the starting point. Get-GPResultantSetOfPolicy is optional depth, not a mandatory second step every time.

Policy Sprawl Is a Real Operational Cost

Because GPOs are convenient, environments often accumulate too many of them. One team adds printer deployment. Another adds desktop restrictions. A security hardening initiative adds registry settings. A contractor adds login scripts. Years later, nobody is sure which GPO still matters, which one exists only for a retired Windows version, or which preference item is rewriting a setting during every refresh.

This is why mature Windows environments treat GPOs more like code than like a junk drawer of useful tweaks. They document ownership, keep naming conventions predictable, test changes in limited scopes, and periodically remove stale policy. You can think of this as the policy equivalent of configuration management hygiene. A messy GPO environment is not just annoying. It lengthens incident response because the answer to “why is this happening?” becomes hidden in historical sediment.

Cloud-managed devices do not escape this problem. Intune configuration profiles and compliance policies can accumulate the same kind of historical sediment if nobody owns them clearly.

File Services, SMB, and the Permission Model

If identity answers who you are, file services answer what you may touch. Windows file sharing is one of the oldest and most common workloads tied to Active Directory, and it remains relevant because shared storage is where central identity becomes concrete. A group is not abstract when it determines whether finance can open payroll files or whether engineering can write to a deployment share.

SMB Is the Network Doorway; NTFS Is the Usual Lock in Windows

Windows file sharing commonly uses SMB (Server Message Block) over the network and NTFS (New Technology File System) permissions on the filesystem underneath. That pairing is common in Windows, not a property of SMB itself. SMB is a network file-sharing protocol that can be served by Windows, by Samba on Linux, or by managed services such as Azure Files. The permission model underneath can therefore be NTFS access control lists (ACLs), POSIX permissions and ACLs, or some service-specific cloud authorization model.

In the classic on-prem Windows pattern, share permissions apply when the folder is accessed over the network, while NTFS permissions apply to the underlying files and directories whether they are reached locally or remotely. The effective access a user receives over the network is the combination of both, with the more restrictive outcome winning.

This is why many administrators keep share permissions intentionally broad and make NTFS the place where detailed authorization lives. If the share grants authenticated domain users a broad right such as Change or Full Control, while NTFS precisely expresses who can read, modify, or traverse the directory tree, troubleshooting becomes easier. You avoid playing a two-layer guessing game every time a user sees Access Denied.

It is also worth drawing a boundary around where Microsoft 365 changes the picture. SharePoint Online, OneDrive, and Teams-backed document libraries solve many collaboration problems that older departments once solved with SMB shares: browser access, link sharing, co-authoring, version history, and files that follow a Microsoft 365 group instead of one server path. They are not a transparent drop-in replacement for every filesystem workload. Applications that expect direct file-protocol semantics, deep directory trees, legacy line-of-business shares, or lift-and-shift behavior still keep SMB relevant.

Where SMB is still the right tool, it is not just an old file protocol. It has become a security and performance surface in its own right. Features such as SMB signing, SMB encryption, multichannel, and improved transport behavior all matter. In the classic Windows design, SMB exposes the resource; Active Directory groups describe who should have access; NTFS expresses the detailed permission model.

Stable Paths Matter More Than One Server Name

A file service design problem that novices underestimate is path stability. If users are trained to browse directly to \\fs01\engineering, then the server name itself becomes part of the user workflow, the documentation, and every script. If you later move the data, rename the host, or redesign the storage layer, that dependency becomes friction.

Windows environments often address this with DFS (Distributed File System) Namespaces, which provide stable logical paths independent of the underlying server hosting the data. That is conceptually similar to using a service name or load-balanced endpoint instead of hardcoding one machine name in application infrastructure. You are separating the identity of the service from the identity of one current host.

That pattern of stable names over changing implementations runs throughout Windows identity infrastructure. Active Directory itself does the same kind of abstraction: users authenticate to a domain, not to one specific controller. Clients look up services through DNS instead of memorizing one IP. DFS hides backend file hosts behind a logical namespace. Mature infrastructure tries to give humans and applications stable names while letting operators change the implementation behind those names.

Design Access with Groups, Not ACL Whack-a-Mole

A clean Windows file permission model uses the same pattern discussed earlier for directory design: use groups to represent roles and resources, then attach permissions to the resource groups rather than to people directly. For example, if a department share needs read-write access for one team and read-only access for another, create separate domain local groups for those permission sets and populate them through global role groups.

This design has two operational advantages. First, permission reviews become legible. You can inspect the ACL and see resource-oriented groups instead of a pile of individual names. Second, onboarding and offboarding become membership changes, not repeated ACL surgery. That is the same reason Unix administrators prefer group-based permissions to lots of per-user exceptions.

It is also worth understanding inheritance. NTFS permissions usually flow from parent folders to child folders and files. That is helpful because it keeps a directory tree coherent. It becomes dangerous when administrators break inheritance casually, create one-off exceptions, then forget those exceptions exist. Months later, nobody remembers why one folder behaves differently from the tree around it. Sometimes breaking inheritance is appropriate. It is rarely free.

Least Privilege Applies to File Servers Too

Windows environments make it very easy to blur the line between file access and administrative authority. A user who only needs to update one shared folder does not need local administrator rights on the file server. A support technician who can map drives does not automatically need permission to read every share. A service account that runs a backup job does not need broad interactive rights.

This is one reason Windows administration sometimes gets an unfair reputation for being “all or nothing.” The platform is capable of narrow delegation. Environments become all or nothing when administrators choose convenience over design. Active Directory groups, NTFS ACLs, and delegated rights are the tools that let you avoid that trap.

Identity in a Hybrid or Cloud-Only World

Classic on-prem AD DS is still common, but it is no longer the only way to build a Microsoft-centered environment. A company starting today can often run entirely on Microsoft Entra ID, Microsoft Intune, SharePoint Online, OneDrive, Teams, and SaaS applications without deploying its own domain controllers at all. At the same time, many organizations still have Windows-integrated applications, SMB file servers, branch offices, and operational habits built around AD DS. The modern picture is therefore not one platform replacing the other cleanly. It is a mix of cloud-native and on-prem identity models solving different parts of the same problem.

AD DS Is Not Microsoft Entra ID

The rename from Azure AD to Microsoft Entra ID helped clarify something that administrators had long needed to say plainly: Entra ID is not simply “Active Directory in the cloud.” It is a cloud identity platform oriented around modern application protocols, SaaS access, conditional access policies, multi-factor authentication (MFA), device identity, and federation patterns common to web applications. AD DS is a directory and authentication system centered on domain join, Kerberos, LDAP, Group Policy, SMB-oriented resource access, and the long Windows application ecosystem.

The comparison below is intentionally simplified, but it captures the difference in posture.

Platform	Center of Gravity	Typical Protocols and Controls	Typical Workloads
AD DS	Traditional domain identity inside managed networks	Kerberos, LDAP, DNS-integrated discovery, Group Policy	Windows sign-in, file shares, legacy apps, domain-joined servers and clients
Microsoft Entra ID	Cloud identity and application access	OAuth 2.0, OpenID Connect, SAML, Conditional Access, MFA	Microsoft 365, SaaS sign-in, web apps, cloud-managed devices
Intune	Device management and compliance	Mobile device management (MDM) policies, compliance evaluation, app deployment	Cloud-managed laptops, mobile devices, modern endpoint policy

Understanding that difference keeps you from asking the wrong questions. If you need LDAP queries against an on-prem directory, Entra ID is not a direct drop-in replacement. If you need conditional access policies for SaaS sign-in from unmanaged networks, classic AD DS is not the right answer by itself. Many real organizations therefore run both.

A Cloud-Only Company Can Be Real

If you start a company today and choose mostly cloud-native workloads, the answer is often yes: you can operate without running on-prem AD DS. Users live in Microsoft Entra ID. Laptops are Microsoft Entra joined and managed through Intune. Files live primarily in SharePoint Online and OneDrive. Collaboration happens through Teams and web applications that trust modern sign-in protocols rather than Kerberos and LDAP. That is a very different operational posture from running domain controllers in a server room, yet it still answers the same broad questions of identity, device management, and access control.

The caveat is that cloud-only works best when the workloads are also cloud-native. The moment you depend on traditional Windows file servers, classic domain join, LDAP-aware or Kerberos-bound applications, Windows-integrated server management, or specialized devices that assume AD behavior, the pressure to keep or reintroduce AD DS rises quickly. Microsoft even offers managed directory options for some legacy-compatible scenarios, which is itself evidence that the cloud world still occasionally needs old interfaces.

Why Hybrid Is the Normal Case

The reason hybrid identity is common is not technical confusion. It is that organizations have mixed constraints. They may have Microsoft 365, cloud MFA, and SaaS applications on one side, while still running on-prem file servers, printers, legacy enterprise resource planning (ERP) systems, Windows-integrated database workloads, industrial devices, or branch networks that depend on traditional domain behavior on the other. Hybrid design is what happens when a business has to support both the old control plane and the new one long enough for the transition to be survivable.

This is why a product like Microsoft Entra Connect Sync matters operationally. It is the classic bridge between directory worlds. The cloud identity layer becomes aware of users and some device state from the on-prem directory, while the on-prem environment continues to do the work it is still better positioned to do. Microsoft is also steering customers toward Microsoft Entra Cloud Sync for simpler, more cloud-managed synchronization patterns, which is a useful reminder that the hybrid boundary is still evolving. The principle, however, is stable: identity migration is rarely one big switch flip. It is a period of coexistence with careful boundary management.

Cloud-Native Tools Solve Similar Problems with Different Interfaces

The interfaces change a great deal between classic Windows infrastructure and newer Microsoft cloud tooling, but the underlying questions barely change. The table below makes that continuity visible.

Classic Windows Problem	Cloud-First Microsoft Answer	What Stays the Same
Central sign-in for users and machines	Microsoft Entra ID plus Microsoft Entra join	One authoritative identity system decides who may authenticate
Push device settings and restrictions	Intune configuration and compliance policies	Centrally scoped policy still needs good targeting and change control
Shared team files on SMB shares	SharePoint Online, Teams files, and OneDrive	Group-oriented access to shared content still needs clear ownership
Kerberos and LDAP for app trust	OpenID Connect, OAuth 2.0, and SAML	Applications still defer to a central identity provider
Stable UNC paths and server abstractions	Stable SharePoint sites, libraries, and Teams spaces	Users still need stable names even when back-end implementations change

Even if you spend most of your career in cloud-heavy environments, learning traditional Windows Server administration is still useful because it teaches durable infrastructure ideas. You learn that naming systems are dependencies, that authentication depends on time and service identity, that permissions should be group-driven, that policy distribution is a control-plane problem, and that delegation is safer than shared privilege.

Those lessons transfer directly to modern platforms. Conditional Access has different knobs than Group Policy, but it is still centrally distributed policy. SaaS federation has different protocols than Kerberos, but it is still a trust relationship. Cloud-managed devices do not use OU structure the way classic desktops do, but they still need scoping, delegated administration, and predictable compliance rules. Traditional Windows infrastructure is therefore not just product knowledge. It is a concentrated lesson in infrastructure design.

Linux and Windows Are Two Answers to the Same Problem

Linux and Windows look very different at the surface. The tools, the defaults, and the mental models all diverge. But every serious environment built on either platform is trying to solve the same set of problems: how to centralize identity, distribute policy, control file access, discover services, and safely delegate administrative work. The surface tools differ; the questions underneath do not.

Same Goals, Different Default Tools

In Linux, local identity often starts in /etc/passwd, /etc/shadow, and /etc/group, then grows outward into SSH keys, Pluggable Authentication Modules (PAM), System Security Services Daemon (SSSD), FreeIPA, LDAP, Kerberos, Ansible, or other tools depending on scale and culture. In Windows, central identity and policy were historically pushed closer to the center of the platform through AD DS and Group Policy. That does not make one ecosystem inherently better. It means the defaults teach different habits.

Windows administrators therefore tend to think in terms of domains, GPOs, Microsoft Management Console (MMC) consoles, and PowerShell modules. Linux administrators tend to think in terms of text configuration, service units, automation playbooks, package managers, and a smaller-tool composition model. Both approaches can be elegant. Both can be awful when designed carelessly.

The Ecosystems Meet More Often Than Newcomers Expect

Many enterprises do not maintain clean Windows-only and Linux-only islands. Linux systems may join Active Directory using SSSD (System Security Services Daemon, which brokers authentication requests to Kerberos and LDAP) and Kerberos. Samba can expose SMB shares to Windows clients while integrating with directory-backed identities. Web applications running on Linux may authenticate users against AD-backed services. Certificate services, DNS, and identity federation cross the boundary all the time.

This is another reason Windows Server is worth studying even if your own preference is Linux. Real operations is full of seams between systems. The seam between Linux and Windows is one of the most common. Understanding both sides lets you tell whether a failure belongs to the application, the operating system, the network, the DNS layer, or the identity plane that sits underneath them all.

The table below shows the most useful conceptual parallels.

Operational Problem	Linux-Oriented Answer	Windows-Oriented Answer
Centralize user identity	LDAP, FreeIPA, Kerberos, SSSD	AD DS, Kerberos, LDAP
Push configuration	Ansible, Puppet, Chef, Salt	Group Policy, Group Policy Preferences, PowerShell DSC (Desired State Configuration) in some environments
Control file access	POSIX permissions and ACLs	NTFS ACLs plus SMB share permissions
Discover services	DNS, service registries, config management	DNS SRV records, AD-integrated DNS
Delegate admin work	sudo, role separation, automation scopes	Delegation in AD, scoped admin groups, JEA (Just Enough Administration) and role-based tooling

The Next Layer Down Is Physical Infrastructure

One final connection is worth making. Active Directory can feel abstract because it is so much about names, objects, protocols, and policy. But none of it escapes hardware. Domain controllers still run on servers. SYSVOL and ntds.dit still live on storage. Replication still crosses links with latency and failure modes. DNS and authentication still depend on network reachability. The identity plane eventually lands on CPUs, memory channels, storage devices, and network paths. Abstract control planes are still made of machines.

Takeaways

If you walk away from this lecture with one strong mental model, let it be this: Windows Server and Active Directory are not “the Windows way to make people log in.” They are a control plane for identity, policy, and access. A domain controller is a database server, an authentication authority, a DNS participant, a policy distributor, and a dependency for many systems that never mention Active Directory by name in their error messages. That is why Windows identity problems are so operationally important. They sit underneath many other visible services.

Imagine a Monday morning outage. Users say they cannot sign in to some machines. A file share is missing. A scheduled task fails on an application server. A printer queue is unavailable in one office. With the concepts from this lecture, you do not chase each symptom in isolation. You ask structured questions. Is the client using the correct DNS servers? Can it find a domain controller in its site? Is time synchronized closely enough for Kerberos? Did a GPO change recently alter access or policy processing? Is replication healthy, including SYSVOL? Are the relevant permissions attached to groups designed cleanly enough to inspect quickly? That is the difference between memorizing a product and understanding a system.

This also ties together the surrounding part of the course. The Incident Response and Postmortems lecture argued that effective incident work depends on finding the real system beneath the symptom. Windows identity infrastructure is a perfect example of that idea. The On-Premises Infrastructure and Data Center Architecture lecture pushes in the opposite direction, from control plane down into hardware and facility design. Together, those perspectives explain why administration is never only about the graphical user interface in front of you or the command you just ran. It is about seeing how layers fit together well enough to operate them under pressure.