Build and harden the identity foundation

Before you start

• Use an isolated Windows Server practice environment. The network's routing and default-deny segmentation are in place, with the access control list (ACL) register that records every permitted path.
• Provision each part's systems when the part begins: two Windows Server virtual machines for SBD-DC01 (10.0.10.10) and SBD-DC02 (10.0.10.11) on different hosts, then the PKI systems (part 6), the DHCP server (part 7) and the administration seats (part 8).
• Work at each server's VM console with an authorized administrator account until part 8 builds AdminJumpBox01; after that, administration happens from the Tier 0 seats.
• Have an approved connected system and the removable-media procedure for bringing downloaded DISA content and other software into the lab.

1. Design the forest, domain and OUs

About 30 min · Open this lesson

• Active Directory Domain Services keeps one directory of users, computers and groups that every domain member trusts, and the domain controllers hold and replicate it. Everything later in this course, from DNS to tiered administration, depends on the decisions made here.
• Microsoft calls the forest the security and administrative boundary for everything in it: whoever controls one domain controller can reach every domain in the forest. Prefer a single forest unless a hard isolation or autonomy requirement forces another. This network uses one forest, sbd.test.
• A domain is a replication and administrative boundary, not a security boundary. Add domains only for replication, administration or policy reasons, never for isolation. The domain name is also a DNS name, so part 2 settles the namespace with this decision.
• Design OUs for two purposes only, delegating administration and applying Group Policy, not replication. Sketch the top level now (Tier 0, Admin, Servers, Workstations and Users) and plan to redirect the default containers; part 5 builds the structure and links the DISA baselines to it.
• List what controls the directory: both domain controllers, the PKI built in part 6, and the accounts, groups and workstations that manage them. That is Tier 0. Administer it only from devices of equal or higher trust; part 8 builds those seats. Write each decision and the authority behind it in the design record.

Get-ComputerInfo | Select-Object CsName, WindowsProductName, OsBuildNumber
Get-NetIPConfiguration | Select-Object InterfaceAlias, IPv4Address, IPv4DefaultGateway
# Nothing is promoted yet: save this starting state beside the design record.

Notes / result / date:

2. Give every system a purpose

About 30 min · Open this lesson

• Use new, patched Windows Server installations (Desktop Experience) with console access and the required administrative credentials. Connect both to VLAN 10, the segment reserved for domain controllers; nothing else joins it. Obtain approved media and updates through your established offline process.
• Rename the servers SBD-DC01 and SBD-DC02 and restart as needed. Use 10.0.10.10/24 and 10.0.10.11/24 with 10.0.10.1, the core's VLAN 10 address, as the default gateway. Every other segment reaches the controllers only through the core, which denies anything a rule doesn't permit.
• Set SBD-DC02's preferred Domain Name System (DNS) server to 10.0.10.10 so it can find the domain when you promote it, and leave it that way; part 2 explains the DNS design. Confirm both clocks agree and document the intended internal time source: SBD-DC01, which part 3 makes the domain's time source.

hostname
Get-NetIPConfiguration
w32tm /query /status

Notes / result / date:

3. Create the first domain controller

About 30 min · Open this lesson

• On DC01, open Server Manager → Manage → Add Roles and Features. Choose the local server and Active Directory Domain Services, including its management tools.
• Select Promote this server to a domain controller, then Add a new forest. Enter sbd.test. Because both controllers run the same Windows Server release, select the highest forest and domain functional levels the wizard offers. Leave the DNS server option selected; the wizard's DNS delegation warning is expected, and part 2 explains both. The first controller in a forest is always a global catalog. Enter and confirm a unique Directory Services Restore Mode password on the server.
• Review the SBD NetBIOS name, paths, and prerequisite results. Read any warnings, resolve blocking errors, install, and allow the restart. Then inspect the services and domain.

Get-ADDomain | Select-Object DNSRoot, NetBIOSName
Get-Service NTDS,Netlogon
Get-SmbShare -Name SYSVOL,NETLOGON

Notes / result / date:

4. Give the domain a second service point

About 30 min · Open this lesson

• On DC02, check that DC01 answers at 10.0.10.10 and that both clocks agree before promotion.
• Install the AD DS role and management tools. In the promotion wizard choose Add a domain controller to an existing domain, enter sbd.test, and authenticate with an authorized Domain Admin account. Leave the DNS server and global catalog options selected, leave Read only domain controller unselected, and set the DSRM password securely.
• Review site placement, replication source, and prerequisite results; install and restart.

Get-ADDomainController -Filter * |
  Select-Object HostName, IPv4Address, IsGlobalCatalog
repadmin /replsummary
repadmin /showrepl SBD-DC02

Notes / result / date:

5. Ask the domain to prove it works

About 30 min · Open this lesson

• In an elevated PowerShell window on either controller, run DCDiag against SBD-DC01 and then SBD-DC02. Its default tests cover connectivity, advertising, replication, SYSVOL, services, and role holders. Read each test's result, not just the last line.
• Run the replication summary, then list each controller's inbound partners. Expect recent successful attempts from DC01 to DC02 and from DC02 to DC01, with no failures. If an error appears right after promotion, wait a few minutes and run the checks again; record any error that persists.
• List both controllers with their global catalog status, then the operations master (FSMO) role holders; in this build SBD-DC01 holds all five. Confirm SYSVOL and NETLOGON are shared on SBD-DC02 as well. If they are not, its first SYSVOL replication has not finished.
• On each controller, confirm the network profile is DomainAuthenticated and that the effective firewall policy is on for the Domain, Private, and Public profiles and blocks unsolicited inbound connections. A controller that reports the Public or Private profile is applying a different rule set than the domain expects; find out why before you rely on it.

dcdiag /s:SBD-DC01
dcdiag /s:SBD-DC02
repadmin /replsummary
repadmin /showrepl *
Get-ADDomainController -Filter * | Select-Object HostName, IsGlobalCatalog
netdom query fsmo
Get-SmbShare -Name SYSVOL,NETLOGON -CimSession SBD-DC02
Get-NetConnectionProfile | Select-Object InterfaceAlias, NetworkCategory
Get-NetFirewallProfile -PolicyStore ActiveStore |
  Select-Object Name, Enabled, DefaultInboundAction

Notes / result / date:

6. Leave a build someone else can understand

About 30 min · Open this lesson

• Record the domain, both controllers, their segment and gateway, site placement, and actual role holders. Preserve the distinction between the intended design and observed configuration.
• Store your environment outputs locally with descriptive filenames and collection times. In this companion, write a short summary and the file references; the form does not upload or collect your screenshots, server output, or credentials.
• List remaining hardening, auditing, backup, recovery, and client-validation work. Assign an owner or next action. Revisit checks after relevant configuration changes. Sign in so your notes and checks follow you to another device.

Get-ADDomain |
  Select-Object DNSRoot, PDCEmulator, RIDMaster, InfrastructureMaster
Get-ADForest |
  Select-Object RootDomain, SchemaMaster, DomainNamingMaster

Notes / result / date:

7. Map names to the network

About 35 min · Open this lesson

• Start with what DNS answers. An A record maps a host name to an IPv4 address (AAAA maps to IPv6), so SBD-DC01.sbd.test resolves to 10.0.10.10. Service (SRV) records advertise which servers offer a service: a domain member asks for _ldap._tcp.dc._msdcs.sbd.test, resolves a listed controller's name, contacts it, and only then authenticates. DNS never checks a password, and it works on an isolated network with no internet access.
• Record the domain, each subnet, both DNS addresses, and the owner of each service name. Keep host records and service aliases distinguishable.
• On each domain controller, confirm the DNS Server service is installed and running; an address typed into a network adapter installs nothing. Then open DNS Manager and review the sbd.test and _msdcs.sbd.test zones that promotion created, without creating duplicates. The DNS delegation warning from part 1's promotion is expected: no parent zone exists above the isolated .test namespace, so no action is needed.
• Set each controller's DNS client order. Promotion pointed SBD-DC01 at itself (the loopback address, 127.0.0.1) while it was the only controller, and SBD-DC02 pointed at SBD-DC01 so it could find the domain. Run the replication summary first; once replication succeeds in both directions, list the partner controller first and the loopback address second on each, and never an outside resolver. Domain members list both controllers; a public resolver is not an alternate for this environment.
• Confirm the network's service-path register permits DNS: every networked system to both domain controllers on TCP and UDP 53 (rule F01 in the System Hub). A member has to find a controller before any Kerberos, LDAP, or Group Policy traffic can start.
• Decide whether any separate internal namespace needs a conditional forwarder. With no recursive dependencies, document a no-recursion design; do not add internet forwarders or delete every root hint as a shortcut.
• The DNS design reference sets the baseline this part follows. Name the forest as a subdomain of a domain you have registered, or use ICANN's reserved .internal; never use .local or a single-label name. sbd.test uses a name reserved for testing, which suits a practice network only. Store the zones in Active Directory with secure-only updates, run at least two DNS servers on different hosts, and forward only to an approved upstream; this air-gapped network forwards nothing. The authorities differ in places: NIST SP 800-81r3 prefers dedicated DNS servers and advises against signing internal zones unless a policy requires it, while Microsoft runs DNS on domain controllers and the DISA DNS STIG requires DNSSEC, with NSEC3 on internal zones. Record which rule your build follows, and why.

Invoke-Command SBD-DC01,SBD-DC02 { Get-WindowsFeature DNS; Get-Service DNS }
repadmin /replsummary
Get-DnsClientServerAddress -AddressFamily IPv4 -CimSession SBD-DC01,SBD-DC02
# After replication succeeds both ways (adapter name varies):
Set-DnsClientServerAddress -CimSession SBD-DC01 -InterfaceAlias Ethernet `
  -ServerAddresses 10.0.10.11,127.0.0.1
Set-DnsClientServerAddress -CimSession SBD-DC02 -InterfaceAlias Ethernet `
  -ServerAddresses 10.0.10.10,127.0.0.1
Get-DnsClientServerAddress -AddressFamily IPv4 -CimSession SBD-DC01,SBD-DC02
Get-DnsServerZone -ComputerName SBD-DC01

Notes / result / date:

8. Configure forward and reverse zones

About 20 min · Open this lesson

• In DNS Manager, inspect sbd.test Properties. Confirm that it is AD-integrated and choose the domain or forest replication scope that matches the DNS servers intended to host it. Domain-wide zones live in the DomainDnsZones partition and forest-wide zones in ForestDnsZones, the partitions you saw in part 1's replication and DCDiag output.
• Use secure dynamic updates for the AD-integrated zone. Review delegation and permissions before broadening who can change records.
• Under Reverse Lookup Zones, create an IPv4 primary AD-integrated zone for network ID 10.0.10 if an equivalent zone does not already exist. Select the approved replication scope and secure updates.
• Review zone-transfer settings. AD replication between these DCs does not require enabling transfers to arbitrary DNS servers; restrict any separately required secondary-server transfers explicitly.

Get-DnsServerZone -ComputerName SBD-DC01 |
  Select-Object ZoneName, ZoneType, IsDsIntegrated, DynamicUpdate, ReplicationScope, SecureSecondaries
Get-DnsServerZone -ComputerName SBD-DC02

Notes / result / date:

9. Create and maintain service records

About 20 min · Open this lesson

• Review the DC A and PTR records first. Correct mismatches through the owning host and DNS administration process rather than blindly adding another record with the same name.
• Choose one approved service host from your address plan. In sbd.test, use New Host (A or AAAA), enter its actual name and address, and select the associated PTR option when the reverse zone is ready.
• For a service alias, use New Alias (CNAME) and enter the intended fully qualified host. For the part 6 PKI, create pki.sbd.test as an alias for SBD-PKI-MGMT01.sbd.test, the internal publication host that course builds at 10.0.30.30; the alias answers with an address once that host exists, and it never points at the offline root.
• Set the record lifetime to the operational plan, record static ownership, and remove only records confirmed obsolete. An alias cannot coexist with other record types at the same name.

Get-DnsServerResourceRecord -ComputerName SBD-DC01 -ZoneName sbd.test
Resolve-DnsName SBD-DC01.sbd.test -Type A -Server 10.0.10.10
Resolve-DnsName 10.0.10.10 -Type PTR -Server 10.0.10.10
# The alias part 6 relies on; its target is built in part 6
Add-DnsServerResourceRecordCName -ComputerName SBD-DC01 -ZoneName sbd.test -Name pki -HostNameAlias SBD-PKI-MGMT01.sbd.test
Resolve-DnsName pki.sbd.test -Type CNAME -Server 10.0.10.11   # after replication: SBD-PKI-MGMT01.sbd.test

Notes / result / date:

10. Prove resolution and directory discovery

About 30 min · Open this lesson

• From a domain client or either controller, query each DNS server by address for both controllers' host records, so each result tells you which server answered. Expect SBD-DC01.sbd.test at 10.0.10.10 and SBD-DC02.sbd.test at 10.0.10.11 from both servers.
• Query the domain controller locator service (SRV) records against both servers. These records let a client discover domain controllers; an ordinary host lookup does not prove discovery works, and a locator answer does not by itself prove that every listed controller is reachable.
• Run the DNS diagnostics against every domain controller, then the replication summary. Classify root-hint, forwarder, and delegation findings against the documented isolated design instead of treating them as faults, and investigate everything else.
• During an approved lab test, make one DNS server unavailable to the test client and verify resolution through the other. Restore connectivity and repeat for the opposite server. Do not interrupt shared production services for this exercise.
• Optional: see the locator query on the wire. On SBD-DC02, in an elevated PowerShell window, capture port 53 with Packet Monitor (pktmon), which is built into Windows Server, while you query SBD-DC01, so the request crosses the network. Expect a query from 10.0.10.11 to 10.0.10.10 on UDP port 53 and an answer naming both controllers on port 389. Read the text file, or open the .pcapng file in a packet analyzer such as Wireshark, and keep the capture with your evidence; it holds only the traffic the filter allowed.

foreach ($server in '10.0.10.10','10.0.10.11') {
  Write-Output "DNS server: $server"
  Resolve-DnsName 'SBD-DC01.sbd.test' -Type A -Server $server
  Resolve-DnsName 'SBD-DC02.sbd.test' -Type A -Server $server
  Resolve-DnsName '_ldap._tcp.dc._msdcs.sbd.test' -Type SRV -Server $server
}
dcdiag /test:DNS /e /v
repadmin /replsummary
# Optional, on SBD-DC02: capture the locator query
New-Item -ItemType Directory C:\Evidence -Force
pktmon filter remove
pktmon filter add DNS -p 53
pktmon start --capture --comp nics --pkt-size 0 --file-name C:\Evidence\dc-locator.etl
Resolve-DnsName '_ldap._tcp.dc._msdcs.sbd.test' -Type SRV -Server 10.0.10.10
pktmon stop
pktmon etl2txt C:\Evidence\dc-locator.etl --out C:\Evidence\dc-locator.txt
pktmon etl2pcap C:\Evidence\dc-locator.etl --out C:\Evidence\dc-locator.pcapng
pktmon filter remove

Notes / result / date:

11. Find the fault and record the fix

About 15 min · Open this lesson

• For a failing lookup, record the exact name, record type, client, resolver, timestamp, and error. Compare the fully qualified name with any short-name search behavior.
• Query both servers directly. If they disagree, inspect zone scope and replication. If both are correct but the client is not, inspect client DNS settings and cached data.
• Distinguish a missing name (NXDOMAIN) from a timeout or service failure. Fix the owning configuration first, then use Clear-DnsClientCache on the test client if stale cache remains relevant.
• Repeat the original test and the redundancy checks. Record what changed and the rollback method. Review aging/scavenging separately against DHCP, static records, and backup practices before enabling automatic deletion.

Get-DnsClientServerAddress -AddressFamily IPv4
Get-DnsClientCache
Resolve-DnsName SBD-DC02.sbd.test -Server 10.0.10.10
Resolve-DnsName SBD-DC02.sbd.test -Server 10.0.10.11

Notes / result / date:

12. Plan the domain's time

About 35 min · Open this lesson

• Start with why the clocks must agree. Kerberos refuses a request whose timestamp differs from the domain controller's clock by more than the domain's tolerance — five minutes by default — so drift turns into failed sign-ins and failed replication. The logging courses (1.3–1.5) line events up across systems by their timestamps, certificates from the part 6 PKI are valid only between two fixed times, and domain controllers need agreeing clocks to replicate accurately.
• Learn the hierarchy that carries one clock everywhere. The PDC emulator of the forest root domain is at the top; every other domain controller takes its time from the PDC emulator, and every member server and workstation from the domain controller that authenticated it — the NT5DS client type every domain member uses by default. sbd.test is the forest's only domain, so SBD-DC01 is the top and SBD-DC02 follows it, and each Windows member's time arrives signed with its computer's Net Logon session key.
• Face the air gap. With no internet or outside NTP server, SBD-DC01 serves time from its own clock and is the reference by declaration, so name an approved reference that never connects to this network, such as a GPS receiver's display, and write down who compares SBD-DC01 with it, when — after any restart, restore or revert of SBD-DC01 included — and how a correction is made and recorded. Record the fallback too: if SBD-DC01 is lost for long, SBD-DC02 eventually stops advertising as a time source, so the PDC emulator role moves to it and it becomes the source (lesson 16).
• Decide what verification will show. Every system should name the source the hierarchy gives it, and its measured offset from that source should be small and stay stable from one reading to the next. Five minutes is where Kerberos fails, not a target: an offset that grows or jumps is the warning to act on long before that.
• Confirm the service path. Rule F09 in the System Hub permits every domain member to both controllers on UDP 123, and each controller's inbound firewall rule for the Windows Time service accepts it; SBD-DC02's own requests to SBD-DC01 stay inside VLAN 10, where only the host firewalls see them. SBD-REPO01 (course 1.2) is not a domain member, so F09 does not list it yet; course 1.2 adds it.
• The time design reference keeps the default Active Directory hierarchy: the forest-root PDC emulator, SBD-DC01, is the reliable source, and every other member follows the domain. Upstream counts differ by authority: CIS, NSA and CISA say at least two sources, Microsoft three or more, and RFC 8633 four or more; DoD systems must use USNO or another approved DoD source. This network is air-gapped and has no upstream, so record that as an accepted gap. Keep the Kerberos clock tolerance at 5 minutes, the default and the DISA requirement, and never let a virtualized domain controller take time from its host.

Get-ADForest | Select-Object RootDomain, Domains       # sbd.test: the forest root and its only domain
Get-ADDomain | Select-Object PDCEmulator               # expected: SBD-DC01.sbd.test
# The domain's Kerberos tolerance, from the Default Domain Policy (expected: MaxClockSkew = 5, in minutes)
Select-String -Pattern MaxClockSkew -Path "\\sbd.test\SYSVOL\sbd.test\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\MACHINE\Microsoft\Windows NT\SecEdit\GptTmpl.inf"
# Each controller's inbound UDP 123 rule, and where each takes its time today
Invoke-Command SBD-DC01,SBD-DC02 {
  Get-NetFirewallPortFilter -PolicyStore ActiveStore | Where-Object { $_.Protocol -eq 'UDP' -and $_.LocalPort -contains '123' } |
    Get-NetFirewallRule | Select-Object DisplayName, Direction, Enabled, Action
  w32tm /query /source }

Notes / result / date:

13. Make SBD-DC01 the domain's time source

About 30 min · Open this lesson

• Confirm which domain controller holds the PDC emulator role — SBD-DC01 in this sample. The PDC emulator of the forest root domain sits at the top of the Windows Time hierarchy, so it is the one system you configure; everything else follows it.
• Turn off the hypervisor's time synchronization for both controller VMs — SBD-DC01 on SBD-HV01 and SBD-DC02 on SBD-HV02 — so no host clock can silently override the PDC emulator. On Hyper-V that is the Time synchronization integration service; other hypervisors have an equivalent guest-tools setting, and some also set the guest clock after a resume or restore, so check those settings too. Inside each guest, w32tm /query /source must no longer name a hypervisor provider such as VM IC Time Synchronization Provider.
• On SBD-DC01, mark Windows Time as a reliable time source and restart the service. w32tm /config /reliable:yes writes AnnounceFlags 5 — always a time server (0x1) and always a reliable one (0x4) — in place of the automatic default, 10 (0x2 and 0x8). Leave the client type at NT5DS and add no manual peer: the forest root's PDC emulator has nothing above it, so it serves its own clock, and clients accept time from a server that synchronizes with nothing only because it is marked reliable.
• Read what SBD-DC01 now advertises: source Local CMOS Clock, stratum 1, reference ID LOCL, and a root dispersion of 10 seconds — the default LocalClockDispersion for a local clock, which you leave alone (lesson 14 sets the Linux servers to accept it). Expect Time-Service warning 12, which says the forest root's PDC emulator has nothing above it and will act as the authoritative source: that is the designed state, so record it rather than fix it. nltest /dsgetdc:sbd.test /gtimeserv should return SBD-DC01 with the GTIMESERV flag, the reliable time server Net Logon now advertises.
• Run the first reference check with lesson 12's procedure: read the approved reference and SBD-DC01's clock at the same moment and record both. If they differ, correct SBD-DC01 by the measured difference (Set-Date -Adjust), never by typing a time from memory; Security event 4616 records the change, and your log records who made it and why.

Get-ADDomain | Select-Object PDCEmulator   # expected: SBD-DC01.sbd.test
# Hyper-V example (other hypervisors have an equivalent setting). On SBD-HV01, and the same for SBD-DC02 on SBD-HV02:
Disable-VMIntegrationService -VMName SBD-DC01 -Name 'Time Synchronization'
Get-VMIntegrationService -VMName SBD-DC01 -Name 'Time Synchronization'   # Enabled: False
# On SBD-DC01 (the PDC emulator): the reliable source, serving its own clock
w32tm /config /reliable:yes /update
Restart-Service w32time
w32tm /query /configuration   # AnnounceFlags: 5 (Local); NtpClient Type: NT5DS (Local)
w32tm /query /source          # Local CMOS Clock
w32tm /query /status          # Stratum: 1, ReferenceId: LOCL, Root Dispersion: 10s
nltest /dsgetdc:sbd.test /gtimeserv   # DC: \\SBD-DC01.sbd.test; Flags include GTIMESERV
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-Time-Service'; Id=12} -MaxEvents 1 |
  Format-List TimeCreated, Message
# Reference check: run this as you read the approved reference, and log both readings
Get-Date -Format 'yyyy-MM-dd HH:mm:ss.fff K'
# A correction is made only by the measured difference (example: SBD-DC01 two seconds slow):
# Set-Date -Adjust ([TimeSpan]::FromSeconds(2))

Notes / result / date:

14. Bring every system onto the hierarchy

About 35 min · Open this lesson

• Leave SBD-DC02 and every Windows member on the defaults: client type NT5DS, no manual peer list, and on SBD-DC02 the automatic AnnounceFlags 10, so it serves time without claiming to be the reliable source. w32tm /query /configuration shows each value with where it came from, (Local) or (Policy), and a system someone once set by hand returns with w32tm /config /syncfromflags:domhier /update and a restart of the service.
• Keep time out of Group Policy. The Windows Time Service policies (Computer Configuration > Administrative Templates > System > Windows Time Service) overwrite the local W32Time settings, so one that names an NTP server or sets the type to NTP pulls its targets off the hierarchy, and one that reaches SBD-DC01 overrides what makes it the source. Leave them Not Configured in every GPO, the STIG GPOs of parts 4–5 included: the STIGs expect members on the domain hierarchy, and their rule that the PDC emulator take time from an authorized external source becomes a recorded deviation in part 5's exception record.
• Keep hypervisors out of every virtual machine's time, as you did for the controllers. When a later course builds a virtual machine, server or client — SBD-ADMIN-PC01, the Tier 2 seat on SBD-ADMIN-SRV01, included — turn off its hypervisor time synchronization, so the domain stays the only time authority: a Windows guest whose source reads VM IC Time Synchronization Provider, or any other hypervisor provider, is not following the domain.
• Write the chrony configuration every Linux server uses. In /etc/chrony.conf (Red Hat Enterprise Linux family), remove every pool, server and sourcedir line, add server SBD-DC01.sbd.test iburst, server SBD-DC02.sbd.test iburst and maxdistance 16, and add no allow line, because these servers serve time to no one; then enable and restart chronyd. Domain-joined Linux servers authenticate with Kerberos through SSSD, so the same five-minute limit applies to them.
• Record why maxdistance 16 is this path's choice. Serving its own clock, SBD-DC01 advertises 10 seconds of root dispersion and SBD-DC02 a little more, while chrony refuses any source whose root distance is above 3 seconds by default, so without the line chronyc sources marks both controllers ^? (unusable). Sixteen seconds is the largest dispersion NTP defines, so the setting admits both controllers without admitting an unsynchronized source; the time itself is unsigned, which is why F09 limits it to the two controllers.
• Apply the same file to every Linux server before its first domain join or package update: SBD-REPO01 (course 1.2), which is not domain-joined, so F09's member list leaves it out until course 1.2 adds it; SBD-SPLUNK01 (course 1.5) and SBD-WEB01 (course 1.11) when they are built; and SBD-NESSUS01 when course 1.10, coming soon, arrives. The offline root CA (part 6) is the one clock no network reaches: set it against the approved reference before each signing ceremony.

# On SBD-DC02, and on a Windows test client or member server if you have one:
w32tm /query /configuration | Select-String 'AnnounceFlags|Type:'   # SBD-DC02: AnnounceFlags: 10 (Local); Type: NT5DS (Local)
w32tm /query /configuration | Select-String '\(Policy\)'           # expected: no output
w32tm /query /source                                                # a controller, never a hypervisor provider
# A system once set by hand returns to the hierarchy:
#   w32tm /config /syncfromflags:domhier /update; Restart-Service w32time; w32tm /resync /rediscover
# The Linux chrony file, filed now (/etc/chrony.conf on the Red Hat Enterprise Linux family):
#   server SBD-DC01.sbd.test iburst
#   server SBD-DC02.sbd.test iburst
#   maxdistance 16
# ...with no pool, other server, sourcedir or allow lines; then:
#   sudo systemctl enable chronyd; sudo systemctl restart chronyd
# Each Linux build later checks:
#   chronyc sources -v     # ^* one controller, ^+ or ^- the other (^? = unusable)
#   chronyc ntpdata | grep -E '^(Remote address|Stratum|Root dispersion|Authenticated)'
#   chronyc tracking       # Reference ID: a controller; System time small and stable

Notes / result / date:

15. Prove the time chain

About 30 min · Open this lesson

• Read each link's source and status, from the top down. SBD-DC01 reports Local CMOS Clock at stratum 1, SBD-DC02 reports SBD-DC01.sbd.test at stratum 2, and a member reports a controller at stratum 2 or 3; a member showing Local CMOS Clock, Free-running System Clock or a hypervisor provider is not following the domain (lesson 16).
• Measure the controllers against each other: w32tm /monitor queries each controller in the domain, marks the PDC emulator, and reports every other controller's NTP offset from it. SBD-DC02's offset should be small and stay small from one reading to the next; the ICMP line is only a ping, and the NTP offset is the measurement.
• Measure a member from the member itself: w32tm /stripchart against SBD-DC01 takes timed samples of its offset, and five that are small and close to one another show a member following its source. On a Linux server later, chronyc tracking reports the same measure as System time, beside a root dispersion of about 10 seconds that is the controllers' advertised error, not an offset.
• Keep the Time-Service events that tell the chain's story, from the System log: 12 on SBD-DC01 (it serves as the authoritative source), 35 and 37 on the followers (a source chosen, valid time arriving), and 36, 129 and 142 as warnings worth an alert (no synchronization for a long period, no domain source found, a controller no longer advertising as a time source). Security event 4616 records every change to a clock, your reference corrections included; list these for the event set course 1.3 collects.
• Write the dated evidence record: for each system, its source, stratum and measured offsets, plus its time zone, since audit time stamps must be in UTC or carry their offset; then the event extracts, the reference check log, and who ran each check. Repeat the offset checks after any change to a controller.

New-Item -ItemType Directory C:\Evidence\time -Force | Out-Null
$f = "C:\Evidence\time\$env:COMPUTERNAME-$(Get-Date -Format yyyyMMdd)"
# On SBD-DC01, SBD-DC02 and a member:
w32tm /query /source | Out-File "$f-source.txt"
w32tm /query /status | Out-File "$f-status.txt"
w32tm /tz | Out-File "$f-tz.txt"
# On a controller: each controller's NTP offset from the PDC emulator
w32tm /monitor /domain:sbd.test | Out-File "$f-monitor.txt"
# On the member: five timed samples against SBD-DC01
w32tm /stripchart /computer:SBD-DC01.sbd.test /samples:5 /dataonly | Out-File "$f-stripchart.txt"
# The Time-Service events to keep, and every clock change (4616)
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-Time-Service'; Id=12,35,36,37,129,142} -MaxEvents 50 |
  Select-Object TimeCreated, Id, Message | Export-Csv "$f-time-events.csv" -NoTypeInformation
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4616} -MaxEvents 20 |
  Select-Object TimeCreated, Message | Export-Csv "$f-4616.csv" -NoTypeInformation

Notes / result / date:

16. Find the time fault and record the fix

About 30 min · Open this lesson

• Recognize skew by its symptoms. Kerberos errors that name time — KRB_AP_ERR_SKEW, or 'There is a time and/or date difference between the client and server' at sign-in — access-denied errors in replication between the controllers, and certificates reported as not yet valid all point at a clock; if the controllers audit Kerberos failures, Security event 4771 with failure code 0x25 names the client. Measure before you change anything: w32tm /stripchart from the failing system to SBD-DC01 shows the offset.
• Find out why a member left its source. Local CMOS Clock or Free-running System Clock means no usable source, a hypervisor provider means its host's time sync is on, and a peer name means someone set it by hand; a (Policy) value in w32tm /query /configuration points at a GPO, and events 129 and 36 show how long it has been adrift. Practice on the test client or SBD-DC02: set a manual peer with w32tm /config /manualpeerlist:SBD-DC01.sbd.test,0x8 /syncfromflags:manual /update, note that its time is still right but unauthenticated and off the hierarchy, then put it back with /syncfromflags:domhier.
• Move the source with the PDC emulator role. When the role moves — a planned transfer, or a seizure after SBD-DC01 is lost — run w32tm /config /reliable:yes /update on the new holder and w32tm /config /syncfromflags:domhier /reliable:no /update on the old one, restart Windows Time on both, move the reference check to the new holder, and confirm that nltest /gtimeserv names it. Otherwise the old holder still advertises itself as the reliable source and the domain's time can keep flowing from a controller that is no longer the PDC emulator; practice only if you can move the role back the same day, because later courses expect SBD-DC01 to hold it.
• Treat a restored or reverted VM as a clock problem as well as a directory one. It can come back with the clock it had when it was saved: members correct themselves, a domain controller corrects at most 48 hours each way (MaxPosPhaseCorrection and MaxNegPhaseCorrection) and logs an event instead, and SBD-DC01 has nothing to correct it at all, so every member follows its old time. After any restore or revert of SBD-DC01, compare it with the reference before you trust it.
• Resync safely. On Windows, w32tm /resync /rediscover finds the source again and resynchronizes; on Linux, sudo chronyc makestep steps the clock once a controller is selectable. When an offset is beyond what the service will correct, set the clock close by hand first, correct SBD-DC01 only by the measured difference, and never point a system at an outside or manual source to make an error go away.
• Record the fix like any other change: the symptom and when it started, the first offset measured, the cause, what you changed, the evidence that the chain is whole again — source, offset and events — and the rollback. A moved role also updates the time plan: who now runs the reference check, and the reverse procedure for when the role returns.

# Measure before changing anything (on the failing system)
w32tm /stripchart /computer:SBD-DC01.sbd.test /samples:3 /dataonly
w32tm /query /source
w32tm /query /configuration | Select-String 'Type:|NtpServer:|\(Policy\)'
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-Time-Service'; Id=36,129} -MaxEvents 10 |
  Format-Table TimeCreated, Id -AutoSize
# Practice fault, then the fix (test client or SBD-DC02)
w32tm /config /manualpeerlist:SBD-DC01.sbd.test,0x8 /syncfromflags:manual /update
w32tm /query /source            # SBD-DC01.sbd.test,0x8: a manual peer, off the hierarchy
w32tm /config /syncfromflags:domhier /update
Restart-Service w32time
w32tm /resync /rediscover
w32tm /query /source            # a controller again
# If the PDC emulator role moves to SBD-DC02:
#   SBD-DC02: w32tm /config /reliable:yes /update; Restart-Service w32time
#   SBD-DC01: w32tm /config /syncfromflags:domhier /reliable:no /update; Restart-Service w32time
nltest /dsgetdc:sbd.test /gtimeserv   # must name the current PDC emulator
# Linux: sudo chronyc makestep, then chronyc tracking

Notes / result / date:

17. Understand STIGs, SCAP and checklists

About 35 min · Open this lesson

• Start with the two layers the Defense Information Systems Agency (DISA) publishes. A Security Requirements Guide (SRG) states requirements for a class of technology, such as general-purpose operating systems; a STIG turns them into checks and fixes for one product, so every STIG rule traces back to an SRG requirement.
• Read a rule's identity and weight. Each rule has a Group ID (V-…), a Rule ID (SV-…r…_rule, where the r number is its revision), a STIG ID naming the product and check, and a severity category: CAT I (high) when exploiting the weakness directly and immediately causes loss of confidentiality, integrity or availability, CAT II (medium) when it has the potential to, and CAT III (low) when it degrades the protections against that loss.
• Separate what a scanner can read from what a person must answer. A Security Content Automation Protocol (SCAP) benchmark is the automated part of a STIG — rules written in XCCDF with OVAL checks — which the SCAP Compliance Checker (SCC) evaluates on a host. Every other rule is a manual check, and STIG Viewer is where you build a checklist for each assessed asset, import SCC's results and record the human answers.
• Trace rules to controls and keep a scan's limits honest. Each rule cites Control Correlation Identifiers (CCIs), DISA's single, actionable requirement statements, each mapped to a NIST SP 800-53 control, so a result can serve as control evidence. A scan shows settings on one host, at one moment, against one release: it can err or miss, it says nothing about procedures, and a pass is not an authorization.
• Record what applies. These controllers take the Windows Server STIG (its domain controller rules included) plus the Active Directory Domain and Active Directory Forest STIGs. They also run DNS and Windows Defender Firewall, which have STIGs of their own — list those with an owner and a review date instead of dropping them silently.
• The DISA STIGs reference ties each rule to the Risk Management Framework: every STIG rule cites one or more CCIs, and each CCI breaks a NIST SP 800-53 control into one testable statement. NIST's National Checklist Program re-lists DISA's STIGs, with their SCAP content and the GPO package, beside CIS and vendor checklists. The unclassified STIGs, SCAP benchmarks, the GPO package, STIG Viewer and SCC are free downloads from the DoD Cyber Exchange (cyber.mil). Decide the baseline set for each system before you scan, so this part and the Group Policy part measure the same thing.

Get-CimInstance Win32_OperatingSystem | Select-Object CSName, Caption, Version
(Get-CimInstance Win32_ComputerSystem).DomainRole   # 5 = primary domain controller (holds the PDC emulator role), 4 = backup domain controller
Get-WindowsFeature AD-Domain-Services, DNS | Select-Object Name, InstallState
Get-ADForest | Select-Object Name, ForestMode, Domains

Notes / result / date:

18. Stage the DISA content across the air gap

About 20 min · Open this lesson

• On an approved connected system, download from DISA's Cyber Exchange: SCC for Windows and STIG Viewer 3 with their published checksums; the SCAP benchmarks for Windows Server and for the Windows client; the Windows Server, Windows client, Active Directory Domain and Active Directory Forest STIGs and the CCI list from the document library; and the current GPO package. The Windows client content waits for the Tier 2 seat in part 8 and the fleet in course 1.6, and the GPO package travels now so part 5 imports policies from the same quarterly release as the STIGs you measure; note each file's version and release.
• Check SCC and STIG Viewer against DISA's published checksums, then hash every file with Get-FileHash into connected-side-hashes.csv, which travels with the media, and transfer the set with the approved removable-media procedure. No live link to the lab is created for convenience.
• In the lab, at SBD-DC01's console, copy the files into C:\Staging\DISA and the hash list into C:\Evidence\baseline\transfer, and compare every hash before opening anything; repeat on SBD-DC02 with the same full set, so its comparison is one-to-one as well, although it needs only SCC and the Windows Server benchmark. A mismatch stops the work, exactly as it will in the part 6 signing ceremony.
• Install SCC on both controllers and STIG Viewer on SBD-DC01, then install the Windows Server benchmark into SCC on each controller. Until part 8 builds AdminJumpBox01, administration happens at the controllers' consoles; part 8 then moves both tools there and removes them from the controllers. Record SCC's, STIG Viewer's, each benchmark's and each STIG's version, and leave the GPO package (for part 5) and the Windows client content hashed in C:\Staging\DISA.

Get-ChildItem C:\Staging\DISA -File | Select-Object Name, Length, LastWriteTime
New-Item -ItemType Directory C:\Evidence\baseline\transfer -Force | Out-Null
Get-ChildItem C:\Staging\DISA -File | Get-FileHash -Algorithm SHA256 | Export-Csv C:\Evidence\baseline\transfer\lab-side-hashes.csv -NoTypeInformation
# connected-side-hashes.csv came with the media; no output means every hash matches
Compare-Object (Import-Csv C:\Evidence\baseline\transfer\connected-side-hashes.csv).Hash (Import-Csv C:\Evidence\baseline\transfer\lab-side-hashes.csv).Hash

Notes / result / date:

19. Capture the pre-hardening baseline

About 25 min · Open this lesson

• On each controller's console, run SCC locally against the Windows Server STIG benchmark staged in lesson 2. DISA content offers several mission assurance category (MAC) and confidentiality profiles: use the one your direction calls for, the same on both controllers, and record it. Each scan is a dated session; note SCC's version and the benchmark's version and release with it.
• Open the results and read, don't just count. Note which checks already pass: the newest Windows Server release ships with defaults such as required signing on outbound SMB connections and LDAP sealing on new deployments, so part of the STIG is green before you touch anything.
• Separate the automated results from the manual checks. SCAP answers what a scanner can read; the manual rules, and any check that returned an error rather than a pass or a fail, go to STIG Viewer for a human answer in lesson 4.
• Store the raw results unmodified, with recorded hashes: copy each session into C:\Evidence\baseline\<host name> and hash it, then carry SBD-DC02's set to the evidence folder on SBD-DC01, where its hashes must match again. The baseline is evidence; a cleaned-up copy is a summary, not the record.

# On each controller, after its SCC scan. Adapt the path to SCC's results directory.
New-Item -ItemType Directory C:\Evidence\baseline -Force | Out-Null
$session = Get-ChildItem "$env:USERPROFILE\SCC\Sessions" -Directory | Sort-Object Name | Select-Object -Last 1
Copy-Item $session.FullName -Destination "C:\Evidence\baseline\$env:COMPUTERNAME" -Recurse
Get-ChildItem "C:\Evidence\baseline\$env:COMPUTERNAME" -Recurse -Filter '*XCCDF-Results*.xml' | Select-Object Name, LastWriteTime
Get-ChildItem "C:\Evidence\baseline\$env:COMPUTERNAME" -Recurse -File | Get-FileHash -Algorithm SHA256 | Export-Csv "C:\Evidence\baseline\$env:COMPUTERNAME-hashes.csv" -NoTypeInformation
# On SBD-DC02: carry its set to SBD-DC01. Then, on SBD-DC01, no output means the copy is identical.
Copy-Item C:\Evidence\baseline\SBD-DC02, C:\Evidence\baseline\SBD-DC02-hashes.csv -Destination '\\SBD-DC01\C$\Evidence\baseline\' -Recurse
Compare-Object (Import-Csv C:\Evidence\baseline\SBD-DC02-hashes.csv).Hash (Get-ChildItem C:\Evidence\baseline\SBD-DC02 -Recurse -File | Get-FileHash -Algorithm SHA256).Hash

Notes / result / date:

20. Build the checklists and answer the manual checks

About 40 min · Open this lesson

• On SBD-DC01, open STIG Viewer, add the staged STIGs to its library, and create three checklists: SBD-DC01 and SBD-DC02, each with the Windows Server STIG, and sbd.test with the Active Directory Domain and Active Directory Forest STIGs, whose rules assess the domain and the forest rather than one host. Fill in each controller's target data — host name, fully qualified domain name, address, and the domain controller role.
• Import each controller's XCCDF results from C:\Evidence\baseline into its own checklist with Import XCCDF or CMRS Results, and record the import summary: rules matched, rules matched with a different revision, and rules not matched. A revision mismatch means the rule changed between the benchmark and the STIG release in the checklist, so align the releases or review those rules by hand — don't include loosely matched results blindly.
• Work every rule still Not Reviewed — the manual checks, the whole sbd.test checklist, and anything the scan could not evaluate. Read the check text, look at the system, and set Open, Not A Finding, or Not Applicable. Write what you observed in Finding Details (the command or screen and what it showed) and the context in Comments (who reviewed, when, and any related decision).
• Change an automated result only with evidence in Finding Details, and never lower a severity to improve the numbers: STIG Viewer requires an override reason because an assessor will read it. Save the checklists in STIG Viewer's CKLB format in C:\Evidence\baseline\checklists as SBD-DC01.cklb, SBD-DC02.cklb and sbd.test.cklb, then hash them.

foreach ($t in 'SBD-DC01', 'SBD-DC02', 'sbd.test') {
  $ckl = Get-Content "C:\Evidence\baseline\checklists\$t.cklb" -Raw -Encoding UTF8 | ConvertFrom-Json
  $ckl.stigs | Select-Object @{n='Checklist';e={$t}}, stig_name, version, release_info | Format-Table -AutoSize
  $ckl.stigs.rules | Group-Object status | Select-Object @{n='Checklist';e={$t}}, Name, Count | Format-Table -AutoSize   # expect no not_reviewed
}
Get-ChildItem C:\Evidence\baseline\checklists -Filter *.cklb | Get-FileHash -Algorithm SHA256 | Export-Csv C:\Evidence\baseline\checklists-hashes.csv -NoTypeInformation

Notes / result / date:

21. Write the findings record for hardening

About 30 min · Open this lesson

• Export the open rules from all three checklists into one findings record, C:\Evidence\baseline\findings\findings-record.csv, and count them per checklist by severity. Read the CAT I items first: their exploitation directly and immediately causes loss.
• Classify every open item with one of three values. Fix by GPO: the DISA package sets it, so part 5's import should close it. Deviation candidate: the setting conflicts with a design decision — for example a rule expecting the PDC emulator to synchronize with an authorized external time source, where the part 3 design declares and checks its own clock — and part 5 decides and records it. POA&M candidate: the fix lies outside Group Policy, such as the PKI server certificate the STIG expects on every domain controller, which the part 6 PKI issues, so it needs an owner and a planned date — the start of a Plan of Action and Milestones (POA&M) entry.
• Trace each finding to its controls. A rule's CCIs map to NIST SP 800-53 controls in DISA's CCI list, and STIG Viewer shows them with each rule — CCI-000366, for example, is implementing the security configuration settings under CM-6 — so the record tells an assessor which control each open item weakens.
• Write the handoff part 5 works from as C:\Evidence\baseline\findings\handoff.txt: SCC's version, the benchmark release and profile, the STIG releases, the GPO package release waiting hashed in C:\Staging\DISA, and where the checklists and this record live. Then hash the whole folder into C:\Evidence\baseline-manifest.csv. Part 5 checks that manifest, rescans with exactly those versions into C:\Evidence\hardened, updates copies of the checklists there, and closes or records every item.

New-Item -ItemType Directory C:\Evidence\baseline\findings -Force | Out-Null
$rows = foreach ($t in 'SBD-DC01', 'SBD-DC02', 'sbd.test') {
  $ckl = Get-Content "C:\Evidence\baseline\checklists\$t.cklb" -Raw -Encoding UTF8 | ConvertFrom-Json
  $ckl.stigs.rules | Where-Object status -eq 'open' | Select-Object @{n='Target';e={$t}}, @{n='GroupId';e={$_.group_id}}, @{n='StigId';e={$_.rule_version}}, @{n='Severity';e={$_.severity}}, @{n='CCIs';e={$_.ccis -join ' '}}, @{n='Title';e={$_.rule_title}}, Classification, Owner, TargetDate
}
$rows | Group-Object Target, Severity | Select-Object Name, Count
$rows | Export-Csv C:\Evidence\baseline\findings\findings-record.csv -NoTypeInformation
# After you fill in Classification, Owner and TargetDate and write handoff.txt, close the baseline:
Get-ChildItem C:\Evidence\baseline -Recurse -File | Get-FileHash -Algorithm SHA256 | Export-Csv C:\Evidence\baseline-manifest.csv -NoTypeInformation
Get-FileHash -Algorithm SHA256 C:\Evidence\baseline-manifest.csv

Notes / result / date:

22. Design and build the OU structure

About 30 min · Open this lesson

• Design the structure by administration: a top-level SBD OU containing Servers, Workstations, Users, Groups, and an Admin OU for privileged accounts. The built-in Domain Controllers OU stays where it is and keeps its name.
• Create the planned OUs with accidental-deletion protection enabled. Record each OU's purpose and who will administer its contents; an OU with no delegation or policy purpose is clutter.
• Redirect the default containers with redircmp and redirusr: new computer accounts to the Workstations OU and new user accounts to the Users OU. Group Policy cannot be linked to the default containers, so anything landing there would get only domain-level policy, never the OU-linked hardening. Join servers straight into the Servers OU with Add-Computer -OUPath, so they never pass through the workstation policies.
• Keep privileged accounts and systems separate: the Admin OU holds the identities that administer the domain controllers. The domain-joined PKI servers from part 6 and SBD-DHCP01 from part 7 join the Servers OU, and part 8 adds a Tier 0 Servers OU and the admin seats' sub-OUs. Do not nest deeper than the delegation plan requires.
• The Active Directory design reference says OUs exist for exactly two purposes, delegating administration and applying Group Policy, not replication. Redirect the default Users and Computers containers so new objects land where policy reaches them. Keep GPOs few and well scoped, and deliver baselines such as the DISA GPO package through GPOs linked to the right OUs, tested first. Block Inheritance hides policy and is discouraged; use Enforced sparingly, for settings that must apply.

New-ADOrganizationalUnit -Name SBD -Path 'DC=sbd,DC=test' -ProtectedFromAccidentalDeletion $true
'Servers', 'Workstations', 'Users', 'Groups', 'Admin' | ForEach-Object { New-ADOrganizationalUnit -Name $_ -Path 'OU=SBD,DC=sbd,DC=test' -ProtectedFromAccidentalDeletion $true }
redircmp 'OU=Workstations,OU=SBD,DC=sbd,DC=test'
redirusr 'OU=Users,OU=SBD,DC=sbd,DC=test'
New-Item -ItemType Directory C:\Evidence\hardened -Force | Out-Null
Get-ADOrganizationalUnit -Filter * -Properties ProtectedFromAccidentalDeletion | Select-Object Name, DistinguishedName, ProtectedFromAccidentalDeletion | Export-Csv C:\Evidence\hardened\ou-design.csv -NoTypeInformation
Get-ADDomain | Select-Object ComputersContainer, UsersContainer
Get-ADDomainController -Filter * | Select-Object Name, ComputerObjectDN

Notes / result / date:

23. Learn how Group Policy applies

About 30 min · Open this lesson

• Know where a GPO lives. Its settings sit in two halves — a container object in Active Directory and a template folder in SYSVOL — and they replicate separately, by directory replication and by DFS Replication. A change made on SBD-DC01 therefore reaches SBD-DC02 in two steps: before you judge a result there, check that the GPO's AD and SYSVOL version numbers agree.
• Learn the order. Policy applies local first, then site, domain and OU, parent OU before child, so the GPO linked closest to the computer is applied last and wins a conflict; at one OU, link order 1 is processed last and wins. Different settings add up across GPOs, but a single setting's values generally don't merge: the highest-precedence GPO that configures it wins, so a user-rights list in one GPO replaces another's instead of adding to it.
• Treat the two overrides as exceptions. Block Inheritance on an OU stops GPOs linked above it; Enforced on a link makes that GPO win over everything below it and pierces Block Inheritance. Enforced is not a shortcut — it hides a precedence problem instead of solving it — so this network uses neither unless the exception record says why.
• Read what narrows a GPO's reach. Security filtering applies it only to accounts with both Read and Apply group policy (Authenticated Users by default), and computers still need Read on GPOs that apply only to users, because user policy is read in the computer's security context; a WMI filter applies it only where its query is true. Loopback processing gives anyone who signs in to a computer the user settings from that computer's GPOs — merge adds them after the user's own, replace uses only the computer's — so use it only where the computer should decide; lesson 24 meets the one place this part needs it.
• Know when policy arrives, and build the central store. Members refresh in the background every 90 minutes with a random offset of up to 30, controllers every five minutes, and gpupdate /force reapplies everything at once, though some extensions run only at startup or sign-in. On SBD-DC01, copy C:\Windows\PolicyDefinitions with its en-US folder to \\sbd.test\SYSVOL\sbd.test\Policies\PolicyDefinitions: from then on, every Group Policy editor in the domain uses these templates instead of its local ones.
• Record the starting state before anything is imported. On both controllers, save a gpresult report of the Resultant Set of Policy (RSoP), what actually applied: the Default Domain Policy and the Default Domain Controllers Policy should be the only domain GPOs listed. Read the applied and filtered-out lists — the reasons gpresult gives, such as a security denial or a false WMI filter, are how you will troubleshoot the import.

# Once, on SBD-DC01: create the central store from the controller's own templates
Copy-Item C:\Windows\PolicyDefinitions -Destination \\sbd.test\SYSVOL\sbd.test\Policies\PolicyDefinitions -Recurse
# On SBD-DC01: links in precedence order, and each GPO's AD and SYSVOL versions
Get-GPInheritance -Target 'DC=sbd,DC=test'
Get-GPInheritance -Target 'OU=Domain Controllers,DC=sbd,DC=test'
foreach ($dc in 'SBD-DC01', 'SBD-DC02') { Get-GPO -All -Server $dc | Select-Object @{n='DC';e={$dc}}, DisplayName, GpoStatus, @{n='AD';e={$_.Computer.DSVersion}}, @{n='SYSVOL';e={$_.Computer.SysvolVersion}} }
# On each controller's console; carry SBD-DC02's report to the same folder on SBD-DC01
New-Item -ItemType Directory C:\Evidence\hardened\policy-before -Force | Out-Null
gpresult /r /scope:computer
gpresult /h "C:\Evidence\hardened\policy-before\$env:COMPUTERNAME-gpresult.html" /f

Notes / result / date:

24. Import and link the DISA GPOs

About 40 min · Open this lesson

• Start from part 4's handoff. Read the package release in C:\Evidence\baseline\findings\handoff.txt, confirm the package in C:\Staging\DISA still matches its connected-side hash, and only then extract it. Copy its ADMX files and their en-US ADML files into the central store from lesson 23, without replacing a newer Microsoft template with an older copy of the same file.
• Import each policy this network uses into a new GPO with the GPMC Import Settings wizard or Import-GPO: the Windows Server domain controller, member server and user policies, and the Windows client policies for your fleet's release, which stay unlinked until courses 1.1 and 1.6 link them. Keep DISA's names behind an SBD prefix so the source release stays identifiable. An import replaces every setting in the target GPO and brings no links, security filtering or WMI filter. Where the package's user-rights settings name placeholder groups such as ADD YOUR DOMAIN ADMINS, map them to sbd.test's real groups with a migration table — check the package's support files for one before building your own in GPMC's Migration Table Editor.
• Link by OU. Link the domain controller policy to the Domain Controllers OU at link order 1, above the Default Domain Controllers Policy, and the member-server policy to the Servers OU, so the systems later courses build there are hardened from first boot. Domain controllers read password, lockout and Kerberos policy only from GPOs linked at the domain root: if the package carries account policies, set those values in a GPO linked there above the Default Domain Policy, because at an OU they do nothing for domain accounts. Use neither Enforced nor Block Inheritance.
• Apply the user policy where people sign in. Its settings belong to every session on a hardened server, whoever signs in — an administrator from the Admin OU, or the built-in Administrator in the default Users container, where no GPO can link. So link the DISA user policy to the Domain Controllers and Servers OUs and, in a small GPO linked to both, enable Configure user Group Policy loopback processing mode set to Merge. Record that decision — it is the only loopback this part uses — and compare it with the package's own instructions for its user policy.
• Walk the settings that need a decision in this network — anything that assumes infrastructure the lab does not have or conflicts with an earlier design — and record each deviation with its rationale instead of deleting the setting. Check each fix-by-GPO item in part 4's findings record against the imported settings, so you know which ones the rescan should show closed. Then, once SBD-DC02 shows the same GPO versions, refresh policy on both controllers and confirm with gpresult that the SBD DISA GPOs apply and that replication still succeeds both ways. Finally, confirm the part 3 time design is intact with no time setting from Group Policy: w32tm /query /configuration must show no (Policy) value, and any Windows Time Service setting an imported GPO carries goes back to Not Configured, with the change recorded.

# On SBD-DC01. True means the package matches the hash recorded on the connected side.
$package = Get-ChildItem C:\Staging\DISA -Filter '*GPO*.zip' | Select-Object -First 1
(Get-FileHash $package.FullName -Algorithm SHA256).Hash -in (Import-Csv C:\Evidence\baseline\transfer\connected-side-hashes.csv).Hash
Expand-Archive $package.FullName -DestinationPath C:\Staging\GPO
# Per policy; take the exact names and folders from the package:
Import-GPO -BackupGpoName '<DISA GPO name>' -TargetName 'SBD <DISA GPO name>' -Path '<package GPOs folder>' -MigrationTable '<migration table>' -CreateIfNeeded
New-GPLink -Name 'SBD <DISA domain controller GPO name>' -Target 'OU=Domain Controllers,DC=sbd,DC=test' -Order 1
Get-GPInheritance -Target 'OU=Domain Controllers,DC=sbd,DC=test'
# On each controller's console; carry SBD-DC02's report to SBD-DC01:
gpupdate /force
gpresult /r /scope:computer
New-Item -ItemType Directory C:\Evidence\hardened\import -Force | Out-Null
gpresult /h "C:\Evidence\hardened\import\$env:COMPUTERNAME-gpresult.html" /f
w32tm /query /source   # SBD-DC01: Local CMOS Clock; SBD-DC02: a domain controller
w32tm /query /configuration | Select-String '\(Policy\)'   # expected: no output, so no time setting comes from Group Policy
repadmin /replsummary

Notes / result / date:

25. Rescan, reconcile, and record

About 35 min · Open this lesson

• Check that the baseline is untouched: the hash of C:\Evidence\baseline-manifest.csv must match the one part 4 recorded, and every file in C:\Evidence\baseline must still match the manifest. Read handoff.txt, confirm SCC and the benchmark on each controller are still those versions, and rescan both controllers locally with the same profile. Changing anything between scans makes the comparison meaningless.
• Copy each new session into C:\Evidence\hardened\<host name> and hash it, and carry SBD-DC02's set to SBD-DC01 as in part 4. Compare each controller with its own baseline: which rules moved from open to pass, which stayed open, and whether any regressed. Attribute each change to the GPO that caused it — the gpresult report names the winning GPO for every setting.
• Copy the three checklists from C:\Evidence\baseline\checklists into C:\Evidence\hardened\checklists and open only the copies in STIG Viewer, so nothing it saves can touch the baseline. Import each controller's new XCCDF results into its copy — with the benchmark and the checklist's STIG release unchanged, the import summary should match part 4's — then revisit every manual answer the policies may have changed, sbd.test's included, updating Finding Details and Comments with what you observed and when. Save and hash the copies; the baseline checklists stay exactly as hashed.
• Work through the findings record. Every fix-by-GPO item should now be closed; if one isn't, find out why — the GPO didn't apply, a closer GPO won, or the setting needs the domain root or a restart. Work in a copy, C:\Evidence\hardened\findings\findings-record.csv: give each item a Resolution — closed by GPO, deviation (for lesson 26's exception record) or POA&M candidate (Plan of Action and Milestones), with its owner and date — and the Evidence that shows it. Treat any new open item as a finding to fix or classify.

# On SBD-DC01: the manifest's hash must match part 4's record; no Compare-Object output means no baseline file changed
Get-FileHash -Algorithm SHA256 C:\Evidence\baseline-manifest.csv
Compare-Object (Import-Csv C:\Evidence\baseline-manifest.csv).Hash (Get-ChildItem C:\Evidence\baseline -Recurse -File | Get-FileHash -Algorithm SHA256).Hash
Get-Content C:\Evidence\baseline\findings\handoff.txt   # the SCC version, benchmark release and profile to reuse
# On each controller, after its SCC rescan (adapt the path to SCC's results directory); SBD-DC02 then copies its set to SBD-DC01
$session = Get-ChildItem "$env:USERPROFILE\SCC\Sessions" -Directory | Sort-Object Name | Select-Object -Last 1
Copy-Item $session.FullName -Destination "C:\Evidence\hardened\$env:COMPUTERNAME" -Recurse
Get-ChildItem "C:\Evidence\hardened\$env:COMPUTERNAME" -Recurse -File | Get-FileHash -Algorithm SHA256 | Export-Csv "C:\Evidence\hardened\$env:COMPUTERNAME-hashes.csv" -NoTypeInformation
Copy-Item C:\Evidence\hardened\SBD-DC02, C:\Evidence\hardened\SBD-DC02-hashes.csv -Destination '\\SBD-DC01\C$\Evidence\hardened\' -Recurse   # on SBD-DC02
# On SBD-DC01: verify the copy, then list each changed rule twice, <= its baseline result and => its result now
Compare-Object (Import-Csv C:\Evidence\hardened\SBD-DC02-hashes.csv).Hash (Get-ChildItem C:\Evidence\hardened\SBD-DC02 -Recurse -File | Get-FileHash -Algorithm SHA256).Hash
function Read-Xccdf($dir) { Get-ChildItem $dir -Recurse -Filter '*XCCDF-Results*.xml' | Select-Xml -XPath "//*[local-name()='rule-result']" | ForEach-Object { [pscustomobject]@{ Rule = $_.Node.idref; Result = $_.Node.result } } }
foreach ($h in 'SBD-DC01', 'SBD-DC02') { Compare-Object (Read-Xccdf "C:\Evidence\baseline\$h") (Read-Xccdf "C:\Evidence\hardened\$h") -Property Rule, Result | Sort-Object Rule | Export-Csv "C:\Evidence\hardened\$h-changes.csv" -NoTypeInformation }
New-Item -ItemType Directory C:\Evidence\hardened\checklists, C:\Evidence\hardened\findings -Force | Out-Null
Copy-Item C:\Evidence\baseline\checklists\*.cklb C:\Evidence\hardened\checklists
Import-Csv C:\Evidence\baseline\findings\findings-record.csv | Select-Object *, Resolution, Evidence | Export-Csv C:\Evidence\hardened\findings\findings-record.csv -NoTypeInformation
Get-ChildItem C:\Evidence\hardened\checklists -Filter *.cklb | Get-FileHash -Algorithm SHA256 | Export-Csv C:\Evidence\hardened\checklists-hashes.csv -NoTypeInformation   # after the STIG Viewer updates

Notes / result / date:

26. Set the rescan cadence and exception record

About 25 min · Open this lesson

• Consolidate the deviations from lesson 24 and the items lesson 25 resolved as deviations into one exception record, C:\Evidence\exception-record.csv — rule, setting, reason, compensating measure, risk note, owner and review date — and file a dated copy in C:\Evidence\hardened. Part 4's example belongs here — the rule expecting the PDC emulator to synchronize with an authorized external time source, which the part 3 design answers with a declared, checked clock. It stays a living record outside the sealed folder: later courses add their entries to it, and it travels into the authorization path as part of the Body of Evidence.
• Set the standing cadence: review each quarterly DISA release for applicable updates, and rescan after any role addition or significant configuration change — part 6's closing rescan of both controllers, once its certificates and autoenrollment policy reach them, is the first change-driven run. When you adopt a new release, scan once with the new content before changing any policy, so the record separates what the content changed from what your policies changed.
• Export the Group Policy reports and each GPO link into C:\Evidence\hardened: the reports make the applied policy state reviewable without a live console, and the link export records where each policy applies — the part a GPO backup never restores, since it brings back settings and permissions, not links. The backup itself belongs to course 1.12, which defines and schedules the backup of every GPO with the rest of the recovery set, so this part sets up no backup job.
• Write the handoff a future administrator or assessor would need — where the evidence lives, which versions produced it, and what is intentionally open — and hash C:\Evidence\hardened into C:\Evidence\hardened-manifest.csv. Part 8 later moves SCC and STIG Viewer to AdminJumpBox01 and links these policies to the admin seats' OUs; until then the cadence runs at the controllers' consoles.

# Seed the exception record from the findings resolved as deviations; add lesson 24's deviations and fill in every column
Import-Csv C:\Evidence\hardened\findings\findings-record.csv | Where-Object Resolution -eq 'deviation' | Select-Object Target, GroupId, StigId, Title, Setting, Reason, CompensatingMeasure, RiskNote, Owner, ReviewDate | Export-Csv C:\Evidence\exception-record.csv -NoTypeInformation -NoClobber
Copy-Item C:\Evidence\exception-record.csv "C:\Evidence\hardened\exception-record-$(Get-Date -Format yyyy-MM-dd).csv"   # once it is complete
# The applied state as records; course 1.12 schedules the GPO backup itself
Get-GPOReport -All -ReportType Html -Path C:\Evidence\hardened\gpo-report.html
'DC=sbd,DC=test', 'OU=Domain Controllers,DC=sbd,DC=test', 'OU=Servers,OU=SBD,DC=sbd,DC=test' | ForEach-Object { (Get-GPInheritance -Target $_).GpoLinks } | Select-Object Target, Order, DisplayName, Enabled, Enforced | Export-Csv C:\Evidence\hardened\gpo-links.csv -NoTypeInformation
Get-ChildItem C:\Evidence\hardened -Recurse -File | Get-FileHash -Algorithm SHA256 | Export-Csv C:\Evidence\hardened-manifest.csv -NoTypeInformation
Get-FileHash -Algorithm SHA256 C:\Evidence\hardened-manifest.csv

Notes / result / date:

27. Design the two-tier trust hierarchy

About 35 min · Open this lesson

• Draw the hierarchy: offline standalone root → enterprise issuing CA → approved server/client certificates. There is no network connection to the root.
• Record final host and CA names, key provider, algorithm, key sizes, hashes, validity periods, renewal owners, and recovery arrangements. Start from this lab's example values in the next step and change any that your own policy requires: they are examples, not universal requirements.
• Example values for this lab: the root CA uses an RSA 4096 key with SHA-256 and a 20-year certificate, and publishes a base CRL every 26 weeks with an overlap period and no delta CRL, refreshed at each offline ceremony. The issuing CA uses RSA 4096 (3072 at minimum) with SHA-256 and a 10-year certificate, a weekly base CRL, and a daily delta CRL. End-entity certificates last one to two years. NIST SP 800-57 Part 1 rates RSA 2048 at 112 bits of security, which it accepts for new signatures only through 2030, so a CA that will still be signing after 2030 uses at least 3072 bits (128 bits of security); the newest Windows Server release requires at least 2,048-bit RSA for TLS server authentication.
• Know where each value is set. You choose the key, the hash, and the root's 20-year validity in the AD CS Configuration wizard. Each CA's CAPolicy.inf sets its CRL periods (CRLPeriod, CRLPeriodUnits, CRLDeltaPeriod, CRLDeltaPeriodUnits), which certutil -setreg can change later. The issuing CA's 10-year lifetime is set on the root (CA\ValidityPeriod and CA\ValidityPeriodUnits) before the signing ceremony, because a subordinate CA's lifetime comes from the CA that signs it.
• Plan a stable internal publication name such as pki.sbd.test. The Authority Information Access (AIA) location supplies issuer certificates; the CRL Distribution Point (CDP) supplies certificate revocation lists.
• Choose the publication host, paths, access rules, and refresh schedule before issuing certificates. Clients inside this air-gapped network must reach those locations without relying on the public internet.
• The PKI design reference agrees with this design: an offline standalone root and an online enterprise issuing CA. Add a policy tier only for a concrete policy, legal or delegation need. Set the CDP and AIA locations, HTTP first, before the first certificate is issued, renew CA certificates at half-life, and avoid delta CRLs on an offline root. Microsoft, CISA, NSA and DISA agree that AD CS is Tier 0: manage it only from Tier 0 seats with dedicated CA administrator accounts, and encrypt CA backups. CISA and NSA list a hardware security module for CA keys; record whether your lab uses one.

# Run on the future issuing CA, not the offline root.
Get-CimInstance Win32_ComputerSystem | Select-Object Name, Domain, PartOfDomain
Resolve-DnsName SBD-DC01.sbd.test
Resolve-DnsName SBD-DC02.sbd.test

Notes / result / date:

28. Configure the offline Root CA

About 30 min · Open this lesson

• Verify SBD-ROOTCA01 is in a workgroup with no active network path. Prepare approved installation media, protected administration, and backup storage, and set its clock from the approved reference that part 3 names, recording both readings: no network will ever correct this clock.
• Place the reviewed CAPolicy.inf in %SystemRoot% before configuration. Tailor it to the root role: in this lab it sets CRLPeriod=Weeks and CRLPeriodUnits=26, and CRLDeltaPeriodUnits=0 so the root publishes no delta CRL. A self-signed root's own CDP/AIA choices differ from the extensions the root places into issued subordinate certificates.
• Install the Certification Authority role with management tools. In the AD CS Configuration wizard choose Standalone CA, Root CA, and a new private key, then apply the approved provider, cryptography (RSA 4096 with SHA-256 in this lab), CA name, validity (20 years), database, and log settings.
• Before signing anything, configure the root's issued-certificate AIA/CDP settings, the subordinate validity policy (CA\ValidityPeriod Years and CA\ValidityPeriodUnits 10 in this lab), and the base-CRL schedule (26 weeks with an overlap period, and no delta CRL). Hold requests for explicit approval. Produce and inspect a current root CRL, then capture a protected CA backup — a build-time step that stays inside this ceremony, and which course 1.12 accounts for in its recovery set without ever bringing it onto the network.

# Inspect locally on SBD-ROOTCA01 during the approved root session.
Get-CimInstance Win32_ComputerSystem | Select-Object Name, Domain, PartOfDomain
Get-Date -Format 'yyyy-MM-dd HH:mm:ss.fff K'   # read against the approved reference; log both readings
Get-Service CertSvc
certutil -getreg CA\CRLPublicationURLs
certutil -getreg CA\CACertPublicationURLs
certutil -getreg CA\ValidityPeriodUnits
certutil -getreg CA\CRLPeriodUnits

Notes / result / date:

29. Create the issuing CA request

About 25 min · Open this lesson

• Confirm SBD-SUBCA01 has its final hostname, domain membership, static address (10.0.30.20), internal DNS, and its time from the domain hierarchy, with the hypervisor's time synchronization off. Use a dedicated host and the privileges approved for enterprise CA configuration.
• Prepare its role-specific CAPolicy.inf (in this lab: CRLPeriod=Weeks, CRLPeriodUnits=1, CRLDeltaPeriod=Days, CRLDeltaPeriodUnits=1, and LoadDefaultTemplates=0) and protected request directory. Decide which templates may later be published instead of enabling a broad default enrollment set.
• Install the CA role and management tools. In the AD CS Configuration wizard choose Enterprise CA, Subordinate CA, and the approved new-key/provider settings (RSA 4096 with SHA-256 in this lab). Enter the planned CA identity and storage locations.
• Choose Save a certificate request to file. Inspect the resulting request's subject, public key, and CA constraints; record its SHA-256 hash before handing it to the media custodian.

w32tm /query /source   # a domain controller, never Local CMOS Clock or a hypervisor provider
# Use the actual request path chosen in the wizard.
certutil -dump C:\CAConfig\IssuingCA.req
Get-FileHash -Algorithm SHA256 C:\CAConfig\IssuingCA.req

Notes / result / date:

30. Sign through the offline ceremony

About 30 min · Open this lesson

• Use approved removable media and custody procedures to bring the request to the root. Before signing, read the root's clock against the approved reference and correct it by the measured difference if it has drifted: the certificate and CRL dates it signs come from that clock. Recalculate the request's hash, compare it with the independently recorded value, and inspect the request before submission.
• Verify the root's issued-certificate validity policy and publication extensions. In Certification Authority, submit the request, review its pending entry, and issue it only after the required approval.
• Export the subordinate certificate, root certificate, and current root CRL. Check identities, constraints, validity, signatures, URLs, and revocation data against the approved hierarchy. Record file hashes and the request ID.
• Transfer only the approved public artifacts back to the connected environment. Match published filenames to the URLs embedded in certificates, retain the ceremony record and protected backup, then shut down and secure the root.

# On SBD-ROOTCA01, first: read this against the approved reference and log both readings
Get-Date -Format 'yyyy-MM-dd HH:mm:ss.fff K'
# Inspect public artifacts; use your actual approved paths.
certutil -dump C:\CAConfig\IssuingCA.cer
certutil -dump C:\CAConfig\RootCA.crl
Get-FileHash -Algorithm SHA256 C:\CAConfig\IssuingCA.cer, C:\CAConfig\RootCA.cer, C:\CAConfig\RootCA.crl

Notes / result / date:

31. Activate the issuing CA and distribute trust

About 25 min · Open this lesson

• Verify the returned artifacts and add the approved root certificate and the current root CRL to the issuing server's local stores: the CA checks its own chain when it starts, before pki.sbd.test serves those files. Complete CA certificate installation through Certification Authority and start Certificate Services.
• Configure the issuing CA's AIA and CDP settings before issuing any certificate, pointing them at the planned pki.sbd.test locations. Every certificate the CA signs carries these URLs, so they are fixed now and served exactly as written in lessons 32 and 7.
• Distribute the approved root trust through the managed domain policy and arrange the required intermediate/directory publication with delegated administrators.
• Hold off on certificate templates: lessons 34 and 35 give template administration its own seat and publish only the templates the plan needs.

# Before installing the signed certificate: the ceremony's root certificate and CRL, into the local stores
certutil -addstore -f Root C:\CAConfig\RootCA.cer
certutil -addstore -f Root C:\CAConfig\RootCA.crl
# Inspect the issuing CA after installation and publication.
Get-Service CertSvc
certutil -getreg CA\CRLPublicationURLs
certutil -getreg CA\CACertPublicationURLs
certutil -store Root
certutil -store CA

Notes / result / date:

32. Build the pki.sbd.test publication site

About 30 min · Open this lesson

• On SBD-PKI-MGMT01, install the Web Server role and create a site (or virtual directory) whose folder will hold the published certificates and revocation lists. Serve .cer, .crt, and .crl files, and allow double escaping in that site's request filtering only, because delta CRL file names carry a + that IIS otherwise refuses; nothing else belongs in this directory.
• From SBD-DC01 in VLAN 10, outside VLAN 30, confirm the pki.sbd.test alias from part 2 resolves to 10.0.30.30 and that rule F18 in the service-path register permits HTTP to the site.
• Leave the site on plain HTTP. Revocation checking has to work before any certificate can be trusted — putting the CRL behind HTTPS creates a loop where validating the site needs the very file it serves.
• Restrict who can write to the publication folder: the CA's publishing process and the PKI administrators, nobody else. Clients read; they never write.

# On SBD-DC01 (VLAN 10): the name and the path from outside VLAN 30
Resolve-DnsName pki.sbd.test
Test-NetConnection pki.sbd.test -Port 80
# On SBD-PKI-MGMT01: the site, and double escaping allowed there for delta CRL names
Get-Website | Select-Object Name, State, PhysicalPath
Get-WebConfigurationProperty -PSPath 'IIS:\Sites\<PKI site>' -Filter system.webServer/security/requestFiltering -Name allowDoubleEscaping

Notes / result / date:

33. Publish the trust data at its advertised URLs

About 25 min · Open this lesson

• Compare the issuing CA's configured AIA and CDP URLs against the publication folder's layout. Every embedded URL must map to a real file path on the site — the filenames are not yours to improve.
• Copy the current root certificate, root CRL, issuing certificate, and issuing CRL into the folder. The root's files still arrive by approved media; the issuing CA's can be written directly by its publishing process.
• Configure the issuing CA's CRL publication to write into the site's folder on its schedule, so each new CRL replaces the old file at the same name before it expires.
• From SBD-DC01, outside VLAN 30, clear the URL cache and verify the issuing CA's certificate with live retrieval: the chain must build to the root and the root's CRL must come from the live site, not a cache. Fetch the issuing CA's own base and delta CRLs at their URLs too; the certificates it issues from lesson 35 on point clients at them.

# On SBD-DC01 (VLAN 10), with nothing cached; IssuingCA.cer is the ceremony's public certificate
certutil -urlcache * delete
certutil -verify -urlfetch C:\Evidence\pki\IssuingCA.cer
'<issuing CA CRL name>.crl', '<issuing CA CRL name>+.crl' | ForEach-Object { (Invoke-WebRequest "http://pki.sbd.test/$_" -UseBasicParsing).StatusCode }   # 200 for the base and the delta CRL
# On SBD-PKI-MGMT01: what the site serves, with timestamps
Get-ChildItem C:\inetpub\pkiroot | Select-Object Name, LastWriteTime

Notes / result / date:

34. Separate template administration

About 25 min · Open this lesson

• Install the certificate management tools on SBD-PKI-MGMT01 and confirm the Certificate Templates console can read the directory's template store from there.
• Create the SBD PKI Admins group in the directory, place it in the Admin OU from part 5, and delegate the template permissions to that group — membership is the record of who may change what the CA signs.
• Remove day-to-day template editing from everywhere else: the issuing CA's console stays for CA operations, not template design, and no Domain Admins or Enterprise Admins account edits templates as routine work.
• Write the change process: a template change names its requester, its reviewer, the versioning action (edit, duplicate, or supersede), and lands in the evidence record like any other configuration change.

Get-ADGroup 'SBD PKI Admins' -Properties Members | Select-Object Name, Members
certutil -template | Select-String 'TemplatePropCommonName' | Select-Object -First 10

Notes / result / date:

35. Publish the first working templates

About 30 min · Open this lesson

• From the administration seat, duplicate Kerberos Authentication, the template Microsoft designates for domain controllers, as SBD Domain Controller Authentication: subject name format None with the DNS name in the alternative name, a key storage provider with RSA keys of at least 2,048 bits and SHA-256, a validity within lesson 27's one-to-two-year example, and the Domain Controller, Domain Controller Authentication and Kerberos Authentication templates on its Superseded Templates tab. Confirm Domain Controllers and Enterprise Domain Controllers hold Read, Enroll and Autoenroll: this is the PKI server certificate the STIG expects on every domain controller, part 4's POA&M candidate.
• Duplicate the Computer template as SBD Computer Authentication. Set the approved key provider, a key size of at least 2,048 bits, a validity period within the same example, subject built from directory information, and autoenrollment permission for a pilot computer group only — SBD-PKI-MGMT01 for now, until the fleet arrives in course 1.6.
• Duplicate the Web Server template as SBD Server Authentication for the TLS services later courses build — the collector (course 1.3), SBD-SPLUNK01 (1.5), SBD-WSUS01 (1.7) and the business services (1.11): the subject supplied in the request, Enroll for the server administrators (a Linux host's request is made on the host and submitted from their seat) and for an SBD TLS Servers computer group (a Windows server requesting into its own computer store is checked against its computer account, so each later course adds its server to that group first), no autoenrollment, and exportable keys only if the course 1.12 recovery plan explicitly says so.
• Record each template's version, settings, and justification through the lesson 34 change process before publishing.
• Publish exactly these three templates on the issuing CA and remove any default template the plan does not call for — an unpublished template cannot be mis-enrolled.

# On SBD-PKI-MGMT01: the templates the CA publishes (use your CA's host\name configuration string)
certutil -CATemplates -config 'SBD-SUBCA01\SBD Issuing CA'
# Each SBD template's minimum key size and subject-name flags, read from the directory
Get-ADObject -SearchBase 'CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=sbd,DC=test' -Filter "Name -like 'SBD*'" -Properties displayName, msPKI-Minimal-Key-Size, msPKI-Certificate-Name-Flag | Select-Object Name, displayName, msPKI-Minimal-Key-Size, msPKI-Certificate-Name-Flag

Notes / result / date:

36. Validate enrollment, revocation, and renewal

About 35 min · Open this lesson

• Turn on autoenrollment: create SBD Certificate Autoenrollment, a GPO that enables Certificate Services Client - Auto-Enrollment with renewal and template updates, and link it at the domain root, so each member enrolls only for the templates whose permissions name it. The controllers' requests reach SBD-SUBCA01 over RPC across the core from VLAN 10, so confirm the register's enrollment row first. Refresh policy: both controllers receive SBD Domain Controller Authentication certificates and the pilot, SBD-PKI-MGMT01, an SBD Computer Authentication certificate, without a human touching a request.
• On SBD-DC01, outside VLAN 30, export its new certificate and the pilot's, clear the URL cache, and run the full verification on each: the chain must reach the approved root and every AIA and CDP URL must answer from pki.sbd.test with current CRL dates — cached success is not evidence of publication.
• Enroll a disposable test certificate, revoke only that one, publish an updated issuing CRL, and verify on SBD-DC01, with the cache cleared again, that a fresh evaluation detects the revocation. Diagnose retrieval or stale-publication problems rather than turning off revocation checks.
• Record owners and reminders for root and issuing CRL publication and certificate renewal. Schedule offline root ceremonies early enough to transfer and publish replacement CRLs before expiry, and start each one by setting the root's clock against the approved reference. Backups are not set up here: course 1.12 defines and schedules the issuing CA's backup — database, key and configuration — with the rest of the network's, accounts for the root's ceremony backup from lesson 28, and rehearses recovery, so list those items for it in the record.
• Take the first SCAP baselines of SBD-SUBCA01 and SBD-PKI-MGMT01 the part 4 way: SCC and the Windows Server benchmark from the part 4 media set, checked against its hashes, at the same versions and profile, run locally, with each session hashed and carried to C:\Evidence\pki\<host name> on SBD-DC01, where its hashes must match again, as SBD-DC02's did in part 4. List the IIS STIGs the publication site now falls under with an owner and a review date, then rescan both controllers the same way, because their certificates, root trust and autoenrollment policy are this part's change.
• Close what this part fixed: in copies of the part 5 checklists in C:\Evidence\pki\checklists on SBD-DC01, answer the rule that every domain controller has a PKI server certificate Not A Finding, with each controller's certificate as the observation, and record part 4's POA&M candidate as closed. The companion rule, that those certificates come from the DoD PKI or an approved External Certificate Authority, stays open: record it in C:\Evidence\exception-record.csv if it is not there yet, because this lab's own hierarchy stands in for DoD's. Export the new GPOs' reports and links for the change record (course 1.12 backs the GPOs up), file the enrollment, urlfetch, revocation, template and owner records with the scans, and seal C:\Evidence\pki.

# On SBD-DC01, SBD-DC02 and the pilot, SBD-PKI-MGMT01, once SBD Certificate Autoenrollment is linked at the domain root
gpupdate /force
certutil -pulse
Get-ChildItem Cert:\LocalMachine\My | Select-Object @{n='Template';e={ $x = $_.Extensions | Where-Object { $_.Oid.Value -eq '1.3.6.1.4.1.311.21.7' }; if ($x) { $x.Format($false) } }}, DnsNameList, NotAfter, Thumbprint
# On SBD-DC01 (outside VLAN 30): export its certificate, then verify it and the pilot's with nothing cached
New-Item -ItemType Directory C:\Evidence\pki -Force | Out-Null
$dc = Get-ChildItem Cert:\LocalMachine\My | Where-Object { $_.EnhancedKeyUsageList.ObjectId -contains '1.3.6.1.5.2.3.5' } | Select-Object -First 1   # KDC Authentication
Export-Certificate -Cert $dc -FilePath C:\Evidence\pki\SBD-DC01-dc.cer
certutil -urlcache * delete
certutil -verify -urlfetch C:\Evidence\pki\SBD-DC01-dc.cer
certutil -verify -urlfetch C:\Evidence\pki\pilot.cer   # the pilot's certificate, exported on SBD-PKI-MGMT01 with Export-Certificate
# On SBD-SUBCA01: revoke only the disposable test certificate, then publish a new CRL
certutil -revoke '<test certificate serial number>' 5   # 5 = cessation of operation
certutil -crl
# Back on SBD-DC01: the test certificate must now fail as revoked
certutil -urlcache * delete
certutil -verify -urlfetch C:\Evidence\pki\test.cer
# After the scans (each carried to C:\Evidence\pki\<host name> on SBD-DC01) and the checklist updates: record the new GPOs (course 1.12 backs them up), then seal the evidence
Get-GPOReport -Name 'SBD Certificate Autoenrollment' -ReportType Html -Path C:\Evidence\pki\gpo-report-autoenrollment.html   # and any root-trust GPO from lesson 31
(Get-GPInheritance -Target 'DC=sbd,DC=test').GpoLinks | Select-Object Target, Order, DisplayName, Enabled, Enforced | Export-Csv C:\Evidence\pki\gpo-links.csv -NoTypeInformation
Get-ChildItem C:\Evidence\pki -Recurse -File | Get-FileHash -Algorithm SHA256 | Export-Csv C:\Evidence\pki-manifest.csv -NoTypeInformation
Get-FileHash -Algorithm SHA256 C:\Evidence\pki-manifest.csv

Notes / result / date:

37. Design the addressing service

About 35 min · Open this lesson

• Decide where DHCP runs and for whom. Only VLAN 80 gets leases — the 50 PCs, and in this part a temporary test client; every server, every admin seat, and the core keep static addresses, because the register names them by address. SBD-DHCP01 is a member server at 10.0.20.10 on VLAN 20, never a domain controller: a DHCP server on a controller inherits the controller's right to change any record in a secure DNS zone.
• Design the scope the way Microsoft recommends: the whole subnet, 10.0.80.1–254 with mask 255.255.255.0, then exclusion ranges for what must never be leased — 10.0.80.1–99, which holds the core's gateway at .1, and 10.0.80.200–254 — leaving the pool at 10.0.80.100–199, as the System Hub records it. One hundred addresses cover the fifty PCs, test clients, and replacement machines whose old leases haven't expired. Plan no reservations: a reservation is keyed to a MAC address that any device can claim, so it is an addressing convenience, never an identity check; if a device ever needs one, record it with an owner and a reason.
• Set the lease length as the outage budget: with one DHCP server, a lease is how long clients keep working while SBD-DHCP01 is down. Keep the Windows default of 8 days as the sample value — clients try to renew halfway through (day 4) and rebind at seven-eighths (day 7) — and record your own value with that reason. Then choose the options, because every option is something every client trusts: router (option 3) 10.0.80.1, DNS servers (option 6) 10.0.10.10 and 10.0.10.11, both domain controllers and never an outside resolver, and DNS domain name (option 15) sbd.test. Add nothing else: no WINS, no boot server, no proxy auto-discovery.
• Assign three identities. Authorizing a DHCP server writes to the forest's configuration partition, so an Enterprise Admins member does it — Tier 0 work, done at SBD-DC01's console until part 8 builds AdminJumpBox01. The server is built and run by named server-administration accounts in a new group, SBD Tier 1 Admins in this sample, because part 8 makes member-server administration Tier 1; and client names are registered by a third, unprivileged account in lesson 3.
• Confirm the paths. Rule F04 in the System Hub lets VLAN 80 reach SBD-DHCP01 on UDP 67/68 through the core's DHCP relay, owned by the network owner; the relay is part of the network's build, so verify it from the network's record with the network owner — it must forward to 10.0.20.10 and nowhere else, which lesson 38's first lease then proves — and take any gap to the network owner rather than changing the router. As a domain member, SBD-DHCP01 also uses F01 (DNS), F02 (Kerberos), F03 (directory), and F09 (time); its registrations ride F01, and A02 already lists it for part 8's Tier 1 seat.
• The DHCP design reference places the service on dedicated domain-member servers authorized in Active Directory, never on a domain controller, because a DHCP service on a controller inherits its rights over AD-integrated DNS records. If DHCP registers names for clients, use one dedicated, non-privileged DNS credential on every DHCP server, enable Name Protection, keep the zones secure-only and keep DnsUpdateProxy empty. Message-level DHCP authentication is effectively unused, so protection against rogue servers belongs to the switch and the hypervisor (DHCP snooping and DHCP guard). Log the hostname, MAC address, IP address and time of every lease.

# At SBD-DC01's console (Tier 0): the values and identities the design names
Resolve-DnsName SBD-DC01.sbd.test -Server 10.0.10.11; Resolve-DnsName SBD-DC02.sbd.test -Server 10.0.10.10
Get-ADOrganizationalUnit -Identity 'OU=Servers,OU=SBD,DC=sbd,DC=test' | Select-Object Name, DistinguishedName
Get-ADGroupMember 'Enterprise Admins' | Select-Object Name   # who can authorize a DHCP server
Get-ADGroupMember DnsUpdateProxy   # expected: no members
Get-DnsServerZone -ComputerName SBD-DC01 | Select-Object ZoneName, IsDsIntegrated, DynamicUpdate, ReplicationScope

Notes / result / date:

38. Build SBD-DHCP01 and its scope

About 30 min · Open this lesson

• At SBD-DC01's console, create SBD Tier 1 Admins and a named server-administration account for each person who will run SBD-DHCP01, all in the Admin OU, and let the group create computer objects in the Servers OU. The delegation covers that OU and computer objects only, so the group can add servers but gains no rights over the ones already there, including SBD-SUBCA01 and SBD-PKI-MGMT01, which part 8 moves to their own OU.
• Install Windows Server on SBD-DHCP01 with its static address (10.0.20.10/24, the core's 10.0.20.1 as gateway, both domain controllers as DNS servers) and its hypervisor time synchronization off, then, at its console, join it straight into the Servers OU with Add-Computer -OUPath and a server-administration account, so part 5's member-server policies apply from first boot. After the restart, still as the local Administrator (the STIG policy may have renamed it), make SBD Tier 1 Admins the only domain group in its local Administrators group, in place of Domain Admins, per the current member-server STIG; from then on, work as your server-administration account.
• Install the DHCP role with its tools, create the DHCP Administrators and DHCP Users groups, and restart the service. An Enterprise Admins member then authorizes the server at SBD-DC01's console, after adding the DHCP management tools there (part 8 moves this work to AdminJumpBox01). Restart the DHCP Server service on SBD-DHCP01 so it checks its authorization now, and find event 1044: authorized, and servicing clients.
• Create the scope inactive, exactly as designed: 10.0.80.1–254, mask 255.255.255.0, the two exclusion ranges, an 8-day lease, and the router, DNS server, and domain name options. Turn dynamic DNS updates off for now (DynamicUpdates Never): a record registered under the server's own computer account stays owned by that account, so lesson 39's dedicated account could never update it. Then activate the scope.
• Verify the core's relay with the test client: on SBD-TEST80 in VLAN 80, release and renew, and confirm the lease came from 10.0.20.10 with the planned gateway, DNS servers, and suffix. The relay wrote its own VLAN 80 address, 10.0.80.1, into each request's gateway address field; that is how SBD-DHCP01 picked the 10.0.80.0 scope. On SBD-DHCP01, find the lease in the scope — and no DNS record yet, by design.

# At SBD-DC01's console (Tier 0): the group and its one delegation; then create each person's named
# server-administration account in the Admin OU and add it to the group (New-ADUser, Add-ADGroupMember)
New-ADGroup 'SBD Tier 1 Admins' -GroupScope Global -Path 'OU=Admin,OU=SBD,DC=sbd,DC=test'
dsacls 'OU=Servers,OU=SBD,DC=sbd,DC=test' /G 'SBD\SBD Tier 1 Admins:CC;computer'
# On SBD-DHCP01 as its local Administrator: join with a server-administration account, then, after the restart:
Add-Computer -DomainName sbd.test -OUPath 'OU=Servers,OU=SBD,DC=sbd,DC=test' -Credential (Get-Credential) -Restart
Add-LocalGroupMember Administrators -Member 'SBD\SBD Tier 1 Admins'; Remove-LocalGroupMember Administrators -Member 'SBD\Domain Admins'
# As a server-administration account: the role and its local groups
Install-WindowsFeature DHCP -IncludeManagementTools; Add-DhcpServerSecurityGroup; Restart-Service DHCPServer
# At SBD-DC01's console, as an Enterprise Admins member: authorize
Install-WindowsFeature RSAT-DHCP; Add-DhcpServerInDC -DnsName SBD-DHCP01.sbd.test -IPAddress 10.0.20.10
# Back on SBD-DHCP01: the authorization check, then the scope, inactive until it is complete
Restart-Service DHCPServer; Get-DhcpServerInDC
Get-WinEvent -FilterHashtable @{ProviderName='Microsoft-Windows-DHCP-Server'; Id=1044} -MaxEvents 1
Add-DhcpServerv4Scope -Name 'VLAN 80 workstations' -StartRange 10.0.80.1 -EndRange 10.0.80.254 -SubnetMask 255.255.255.0 -LeaseDuration 8.00:00:00 -State InActive
Add-DhcpServerv4ExclusionRange -ScopeId 10.0.80.0 -StartRange 10.0.80.1 -EndRange 10.0.80.99
Add-DhcpServerv4ExclusionRange -ScopeId 10.0.80.0 -StartRange 10.0.80.200 -EndRange 10.0.80.254
Set-DhcpServerv4OptionValue -ScopeId 10.0.80.0 -Router 10.0.80.1 -DnsServer 10.0.10.10, 10.0.10.11 -DnsDomain sbd.test
Set-DhcpServerv4DnsSetting -DynamicUpdates Never   # lesson 39 turns registration on
Set-DhcpServerv4Scope -ScopeId 10.0.80.0 -State Active
Get-DhcpServerv4Lease -ScopeId 10.0.80.0   # after SBD-TEST80 runs ipconfig /release and ipconfig /renew
w32tm /query /source   # a domain controller, as part 3 designed

Notes / result / date:

39. Register client names securely

About 30 min · Open this lesson

• At SBD-DC01's console, create the reverse lookup zone for 10.0.80.0/24 — Active Directory-integrated, with the replication scope you chose in part 2, and secure updates only — so client PTR records have somewhere to go; part 2 created only 10.0.10's.
• Create the update account there too: a standard user (svc-dhcp-dns in this sample) in the Admin OU and in Domain Users only, with a long random password — at least the length the current STIG sets for manually managed application accounts — set not to expire, which the current STIG allows for an application account whose owner changes the password on the schedule the STIG sets and whenever someone who knew it leaves. It needs no DNS permission of its own: any authenticated account may create a record in a secure zone and becomes the owner of what it creates. Keep DnsUpdateProxy empty: records its members create are left unsecured, so the next device to update the name takes it over.
• On SBD-DHCP01, store the credential with Set-DhcpServerDnsCredential, then set the server to register both A and PTR records for every client (DynamicUpdates Always), including clients that don't ask (UpdateDnsRRForOlderClients), to remove them when a lease expires or is deleted (DeleteDnsRROnLeaseExpiry), and to protect names (NameProtection). Name protection adds a DHCID record that ties each name to the client that registered it, and an update for that name from a different client fails instead of overwriting it.
• On SBD-TEST80, renew the lease and watch registration happen: SBD-DHCP01's audit log shows the update requested (30) and done (32), both controllers answer for the name and the address, and a DHCID record sits beside the A record. At SBD-DC01's console, read the record's owner: it must be SBD\svc-dhcp-dns, not SBD-DHCP01's computer account.
• Record the decision: one update identity for VLAN 80, its owner, where the sealed password lives, and that after any password change you set the credential again on SBD-DHCP01, because registrations fail until you do. With every VLAN 80 record owned by that one account, the server cleans up names when leases end, so VLAN 80 doesn't depend on scavenging, which part 2 left as a separate decision. Course 1.6 finishes the picture for the fleet: it turns off the workstations' own DNS self-registration by GPO on the Workstations OU, with the reason recorded, so SBD-DHCP01, as svc-dhcp-dns, stays the only writer of their records.

# At SBD-DC01's console (Tier 0): the reverse zone (part 2's replication scope), the update account, an empty proxy group
Add-DnsServerPrimaryZone -NetworkId '10.0.80.0/24' -ReplicationScope Domain -DynamicUpdate Secure
New-ADUser svc-dhcp-dns -Path 'OU=Admin,OU=SBD,DC=sbd,DC=test' -AccountPassword (Read-Host -AsSecureString) -PasswordNeverExpires $true -Enabled $true
Get-ADGroupMember DnsUpdateProxy   # expected: no members
# On SBD-DHCP01: the credential, then registration for every client, with name protection
Set-DhcpServerDnsCredential -Credential (Get-Credential 'SBD\svc-dhcp-dns')
Set-DhcpServerv4DnsSetting -DynamicUpdates Always -UpdateDnsRRForOlderClients $true -DeleteDnsRROnLeaseExpiry $true -NameProtection $true
Get-DhcpServerDnsCredential; Get-DhcpServerv4DnsSetting
# On SBD-TEST80: renew, then ask both controllers for the name, the address, and the DHCID record
ipconfig /renew
Resolve-DnsName SBD-TEST80.sbd.test -Server 10.0.10.11
Resolve-DnsName (Resolve-DnsName SBD-TEST80.sbd.test -Type A -Server 10.0.10.10).IPAddress -Type PTR -Server 10.0.10.10
Resolve-DnsName SBD-TEST80.sbd.test -Type DHCID -Server 10.0.10.10
# At SBD-DC01's console: the record's owner (sbd.test lives in DomainDnsZones in this sample)
Import-Module ActiveDirectory
(Get-Acl 'AD:DC=SBD-TEST80,DC=sbd.test,CN=MicrosoftDNS,DC=DomainDnsZones,DC=sbd,DC=test').Owner   # SBD\svc-dhcp-dns

Notes / result / date:

40. Audit leases and write the restore note

About 30 min · Open this lesson

• Read the audit log. Windows writes one file per weekday (DhcpSrvLog-Mon.log, and so on) in %windir%\System32\dhcp, each line carrying an event code, the time, the address, the host name, and the MAC address: 10 for a new lease, 11 a renewal, 12 a release, 30 and 32 a DNS update requested and done, 31 a failed one. Each file is reused a week later, and logging pauses when free disk space drops below the configured minimum, so check Get-DhcpServerAuditLog and keep that volume's free space well above it.
• Keep every day: a daily task, running as SYSTEM shortly after midnight, copies the previous day's file to D:\DHCP\AuditArchive under its date and appends its SHA-256 hash to a catalog. Keep the copies as long as your records requirement says — the period depends on your environment and policy, so record the value you chose and why — because lease history is what ties an address in any log to a machine.
• Review the leases each week: scope statistics show how full the pool is, and the lease list should hold only machines you know — today, just the test client. An unknown host name or MAC address is a finding to trace, not something to delete. The server's own event logs record every scope, option, exclusion, and reservation change with the account that made it, and warn when the scope is nearly full.
• Know what an unauthorized DHCP server can do here. A Windows DHCP server in the domain that isn't authorized refuses to lease and logs event 1046, and a workgroup Windows server stops when it meets an authorized one on its network; a server of any other kind ignores authorization entirely and can hand clients its own gateway and DNS servers, a ready-made interception point. So check that Get-DhcpServerInDC lists SBD-DHCP01 alone and that clients' DHCP server is 10.0.20.10, and record that network controls, such as 802.1X admission in course 1.6, carry the rest.
• Write the restore note. Windows backs the DHCP database up every 60 minutes, but to %windir%\System32\dhcp\backup on the same disk, so that copy fails with the server and isn't a backup of it. Course 1.12 defines and schedules SBD-DHCP01's backup — the database and an export of the configuration and leases — with every other system's, so this part sets up no backup job. What belongs here is what a restore will need: the DNS update credential isn't in a DHCP backup, so after any restore it is set again with Set-DhcpServerDnsCredential from the sealed record, before names register.

Get-DhcpServerAuditLog   # Enable: True; Path: C:\Windows\system32\dhcp
$dir = Join-Path $env:windir 'System32\dhcp'
Get-Content (Join-Path $dir ('DhcpSrvLog-{0}.log' -f (Get-Date).ToString('ddd', [cultureinfo]'en-US'))) -Tail 5
# The daily task's work (SYSTEM, 00:15): yesterday's file kept under its date, with its hash
New-Item -ItemType Directory D:\DHCP\AuditArchive -Force | Out-Null
$y = (Get-Date).AddDays(-1); $copy = 'D:\DHCP\AuditArchive\DhcpSrvLog-{0:yyyy-MM-dd}.log' -f $y
Copy-Item (Join-Path $dir ('DhcpSrvLog-{0}.log' -f $y.ToString('ddd', [cultureinfo]'en-US'))) $copy
Get-FileHash $copy -Algorithm SHA256 | Export-Csv D:\DHCP\AuditArchive\catalog.csv -Append -NoTypeInformation
# Weekly review: pool use, who holds leases, who may serve
Get-DhcpServerv4ScopeStatistics -ScopeId 10.0.80.0 | Select-Object ScopeId, InUse, Free, PercentageInUse
Get-DhcpServerv4Lease -ScopeId 10.0.80.0 | Select-Object IPAddress, HostName, ClientId, AddressState, LeaseExpiryTime
Get-DhcpServerInDC   # SBD-DHCP01 alone
# For the restore note: the automatic copy sits on the same disk (BackupPath), so course 1.12 schedules the real backup
Get-DhcpServerDatabase
Get-DhcpServerDnsCredential   # the account the note says to set again after any restore (never the password)

Notes / result / date:

41. Prove the service and hand off

About 30 min · Open this lesson

• On SBD-TEST80, release and renew, and check everything the client now believes: an address from 10.0.80.100–199, DHCP server 10.0.20.10, gateway 10.0.80.1, DNS servers 10.0.10.10 and 10.0.10.11, suffix sbd.test, and an 8-day lease. On SBD-DHCP01, find the same lease and its audit-log lines, and confirm both controllers answer for the name and the address.
• Try to take the name: shut the test client down, give it a new MAC address in the hypervisor — to the server, a new client with a new DHCID — and start it again. It gets a lease, but its registration is refused: event 1340 on SBD-DHCP01, a failed update (31) in the audit log, and the name still resolving to the original address. Restore the original MAC address, renew, delete the stray lease, and confirm the name still points at the test client.
• Take SBD-DHCP01's first SCAP baseline the part 4 way: copy SCC and the Windows Server STIG benchmark from the part 4 media set into C:\Staging\DISA, check them against the connected-side-hashes.csv that travels with the media, install the same SCC version, and scan locally with the same profile. Store the session unmodified in C:\Evidence\dhcp\baseline, classify each open finding as fix-by-GPO, deviation candidate, or POA&M candidate, and leave the manual checks for a STIG Viewer checklist on the Tier 1 seat in part 8.
• Seal both halves of the record, each into its own manifest: C:\Evidence\dhcp on SBD-DHCP01 (design, build sheet, scope export, registration and takeover results, audit catalog, restore note, baseline) and C:\Evidence\dhcp on SBD-DC01 (authorization, reverse zone, update account, record owner). Part 8 carries each to its tier's seat.
• Write the handoff to part 8: SBD-DHCP01 serves VLAN 80 and registers names as svc-dhcp-dns; SBD Tier 1 Admins runs it, still at its console; the test client stays for part 8's proof, where it joins the domain as the Tier 2 test machine; course 1.6 adds the Network Policy Server role for 802.1X to this server; and course 1.12 schedules its backup.

# On SBD-TEST80: release, renew, and read what the client believes
ipconfig /release; ipconfig /renew; ipconfig /all
# On SBD-DHCP01: the lease, then, after the MAC change, the refused takeover
Get-DhcpServerv4Lease -ScopeId 10.0.80.0 | Select-Object IPAddress, HostName, ClientId, LeaseExpiryTime
Get-WinEvent -FilterHashtable @{ProviderName='Microsoft-Windows-DHCP-Server'; Id=1340} -MaxEvents 1 | Format-List TimeCreated, Message
Resolve-DnsName SBD-TEST80.sbd.test -Server 10.0.10.10   # still the original address
Remove-DhcpServerv4Lease -IPAddress '<stray lease address>'   # after the original MAC is back
# Before installing SCC: no output means every copied file is on the connected-side list
(Get-ChildItem C:\Staging\DISA\* -File -Exclude *.csv | Get-FileHash -Algorithm SHA256).Hash | Where-Object { $_ -notin (Import-Csv C:\Staging\DISA\connected-side-hashes.csv).Hash }
# After the SCC scan: keep the session unmodified (adapt the path to SCC's results directory), then seal the folder
$session = Get-ChildItem (Join-Path $env:USERPROFILE 'SCC\Sessions') -Directory | Sort-Object Name | Select-Object -Last 1
New-Item -ItemType Directory C:\Evidence\dhcp\baseline -Force | Out-Null
Copy-Item $session.FullName -Destination C:\Evidence\dhcp\baseline\SBD-DHCP01 -Recurse
Get-ChildItem C:\Evidence\dhcp -Recurse -File | Get-FileHash -Algorithm SHA256 | Export-Csv C:\Evidence\dhcp-manifest.csv -NoTypeInformation
Get-FileHash -Algorithm SHA256 C:\Evidence\dhcp-manifest.csv
# Run the same two lines at SBD-DC01's console for the Tier 0 half, its own C:\Evidence\dhcp

Notes / result / date:

42. Design the tiers and the admin seats

About 30 min · Open this lesson

• Define three tiers against what exists, using Microsoft's rule: anything that can control a Tier 0 system is Tier 0. Tier 0 is the identity and trust fabric (DCs, both CAs, PKI-MGMT01) plus what controls it — the hypervisor hosts and their console, the core router's management, and the DC-facing parts of the tools that patch, protect, scan, monitor, and back up the DCs. Tier 1 is the member servers; Tier 2 the user endpoints. Map each tier to its OUs: Tier 0 to the Domain Controllers OU plus a new Tier 0 Servers OU for SBD-SUBCA01 and SBD-PKI-MGMT01 (lesson 44 moves them out of the Servers OU), Tier 1 to the Servers OU, where part 7's SBD-DHCP01 already sits, and Tier 2 to the Workstations OU.
• Assign the admin seats under DISA's Windows PAW Security Technical Implementation Guide (STIG): each privileged access workstation serves one tier (V-243445), and the one that manages the domain controllers is reserved for that work (V-243454, high severity). Where workstations are scarce, V-243445 allows one exception: lower-tier admin accounts in a virtual machine on a higher-tier seat, with the higher-tier accounts on the host. This network uses it to run three seats on two machines: AdminJumpBox01 for Tier 0, running no virtual machines, and SBD-ADMIN-SRV01 for Tier 1, which also runs SBD-ADMIN-PC01, the Tier 2 seat, as a virtual machine with its own name and address. Record the STIG differences in the exception record (AdminJumpBox01 manages all of Tier 0, not only the domain controllers; both physical seats run Windows Server where the STIG expects a Windows client, V-243447), and the PAW rules left open, such as smart-card sign-in (V-243457) and application allowlisting (V-243450, V-243451).
• Write the credential rule per tier: a Tier 0 account signs in only on Tier 0 systems and AdminJumpBox01; Tier 1 admins work on the SBD-ADMIN-SRV01 host; Tier 2 admins only inside the SBD-ADMIN-PC01 virtual machine, never on its host. The audit custodian uses separate accounts and sessions on SBD-ADMIN-SRV01 that ordinary server operators cannot use, and is refused on Tier 2 machines like the higher tiers. Each administrator gets separate per-tier accounts — the daily account holds no admin rights anywhere — gathered in one group per role in the Admin OU: SBD Tier 0 Admins, SBD Tier 1 Admins (part 7 created it for SBD-DHCP01), SBD Tier 2 Admins, and SBD Audit Custodians in this sample.
• Add the register rows this part needs: VLAN 60 to each tier's management ports (rules A01–A04 in the System Hub), and explicit denies from VLAN 80 into VLAN 60 — user space never initiates toward the admin plane. A02 already names SBD-DHCP01, whose administration moves to SBD-ADMIN-SRV01 in lesson 2.
• The Active Directory design reference treats the directory's control plane as Tier 0: the domain controllers, AD CS, and the accounts, groups and workstations that manage them. Administer each tier only from a device of equal or higher trust, the clean-source principle; put privileged accounts in Protected Users; and keep Tier 0 credentials off lower-tier systems. This part builds the administration seats that put those rules into practice.

# At SBD-DC01's console until lesson 43 builds AdminJumpBox01: OU targets, current account separation, and the role groups.
Get-ADOrganizationalUnit -Filter * | Select-Object Name, DistinguishedName
Get-ADGroupMember 'Domain Admins' | Select-Object Name, SamAccountName
'SBD Tier 0 Admins', 'SBD Tier 2 Admins', 'SBD Audit Custodians' | ForEach-Object { New-ADGroup $_ -GroupScope Global -Path 'OU=Admin,OU=SBD,DC=sbd,DC=test' }
Get-ADGroup -SearchBase 'OU=Admin,OU=SBD,DC=sbd,DC=test' -Filter * | Select-Object Name   # SBD Tier 1 Admins came from part 7

Notes / result / date:

43. Build the administration systems

About 45 min · Open this lesson

• Create two computer sub-OUs under the Admin OU — Admin Servers for AdminJumpBox01 and SBD-ADMIN-SRV01, Admin Workstations for the SBD-ADMIN-PC01 virtual machine — and link part 5's STIG GPOs to them before any seat joins: the member-server computer policy, the user policy, and the loopback (Merge) GPO to Admin Servers, and the Windows client computer and user policies, which part 5 imported but left unlinked, with the same loopback GPO to Admin Workstations. Part 5 linked them only to the Domain Controllers and Servers OUs, so without this step the seats would boot unhardened.
• Build AdminJumpBox01 and SBD-ADMIN-SRV01 as clean Windows Server installs and join both into Admin Servers, so the hardening applies from first boot; AdminJumpBox01 never gets the Hyper-V role or a virtual machine, because the seat that manages the domain controllers never hosts a lower tier. Give every seat its own seat GPO, linked above the STIG GPO — one on Admin Workstations, and two on Admin Servers, each filtered to its seat (deny Apply group policy to the other) — that makes the seat's own maintenance group (SBD PAW Maintenance T0, T1, or T2 in this sample), used for nothing else, the only domain group in its local Administrators: the PAW STIG gives tier accounts user rights only on their seat (V-243456, V-243462), and no group spans tiers. SBD-ADMIN-SRV01's GPO also adds NT VIRTUAL MACHINE\Virtual Machines (*S-1-5-83-0) to Create symbolic links beside Administrators: Group Policy replaces the right's local value, and without that entry, which the STIG accepts on Hyper-V hosts, the virtual machine won't start. Lesson 44 adds each seat's sign-in rights.
• Add the Hyper-V role to SBD-ADMIN-SRV01 and create SBD-ADMIN-PC01 as a generation 2 virtual machine with Secure Boot and a virtual Trusted Platform Module (TPM), set to start whenever the host starts. The Windows client needs the TPM, and Credential Guard, which the Windows client STIG requires, runs in a virtual machine only on generation 2 and on a host with an input–output memory management unit (IOMMU). Connect it through an external virtual switch on the seat's VLAN 60 adapter with its own address, 10.0.60.30, install the Enterprise or Education edition of the Windows client, and join it into Admin Workstations. Because it keeps its own name and address, the register's rule for SBD-ADMIN-PC01 (A03) still names it alone, never its host.
• Close the channels that share data between host and guest, because the virtual machine separates the tiers only while they share nothing they don't need: turn off enhanced session mode on the host, so the console carries only screen, keyboard, and mouse, with no shared clipboard, drives, or devices; keep the Guest Service Interface off, so the host can't copy files in; turn off Key-Value Pair Exchange, which passes data both ways; turn off Time Synchronization, because the guest takes its time from the domain like every virtual machine (part 3); and add no shared folders. What remains, the basic integration services and PowerShell Direct (which can run commands and copy files either way), needs Hyper-V administrator rights on the host, and PowerShell Direct also needs an account in the guest. Administrators who hold both a Tier 1 and a Tier 2 account open the console from the host with the Tier 1 account, which SBD-ADMIN-SRV01's seat GPO puts in the local Hyper-V Administrators group — the one privileged local group the PAW STIG lets a Hyper-V seat fill (V-243463), so they need no host administrator rights — and sign in inside with the Tier 2 one. One person uses the console at a time and signs out of the virtual machine before closing it, because without enhanced session mode the next person to connect takes over an open desktop; a Tier 2-only administrator needs a seat of their own.
• Strip them to purpose: no browsing to anything but internal admin interfaces, no mail, no file shares hosted, and the management tools for exactly their tier — Remote Server Administration Tools (RSAT) on the two server seats, endpoint tooling inside the SBD-ADMIN-PC01 virtual machine — with SBD-ADMIN-SRV01 running that one virtual machine and no other. Then move the console work earlier courses did onto the seats: Tier 0 directory, DNS, and DHCP authorization work moves from SBD-DC01's console to AdminJumpBox01, so remove the DHCP management tools part 7 added to SBD-DC01; and SBD-DHCP01 is administered from SBD-ADMIN-SRV01 with Tier 1 accounts, over the remote desktop and remote management paths rule A02 registers, no longer at its console.
• Register the management paths: VLAN 60 to Tier 0 and Tier 1 ports (remote desktop 3389, remote management 5985–5986, AD Web Services 9389 to the domain controllers, SSH 22 for the domain-joined Linux servers) from the specific admin host each tier allows, and the router's management on VLAN 100 from AdminJumpBox01 only; keep the VLAN 80 → VLAN 60 deny from lesson 42 in force. Require the admin seats' own local firewalls, the virtual machine's included, to accept management inbound from nowhere — sessions originate here, they never terminate here, so neither the host nor its guest can manage the other over the network. On both domain controllers, scope the existing Remote Desktop, Windows Remote Management, and Active Directory Web Services firewall rules to AdminJumpBox01 and VLAN 10: allow rules add up, so a new, narrower rule would not restrict the broad ones already enabled.

Get-ADComputer -SearchBase 'OU=Admin,OU=SBD,DC=sbd,DC=test' -Filter * | Select-Object Name, DistinguishedName
Get-GPInheritance -Target 'OU=Admin Servers,OU=Admin,OU=SBD,DC=sbd,DC=test'
Get-GPInheritance -Target 'OU=Admin Workstations,OU=Admin,OU=SBD,DC=sbd,DC=test'
Get-LocalGroupMember Administrators   # each seat: its maintenance group, no tier group
# On SBD-ADMIN-SRV01: its one virtual machine, and what host and guest share.
Get-VM | Select-Object Name, Generation, State, AutomaticStartAction   # Start
(Get-VMFirmware SBD-ADMIN-PC01).SecureBoot; (Get-VMSecurity SBD-ADMIN-PC01).TpmEnabled
Get-VMHost | Select-Object EnableEnhancedSessionMode   # False
Get-VMIntegrationService SBD-ADMIN-PC01 | Select-Object Name, Enabled   # Guest Service Interface, Key-Value Pair Exchange, Time Synchronization: False
Get-LocalGroupMember 'Hyper-V Administrators'   # the console users' Tier 1 accounts
Resolve-DnsName SBD-ADMIN-PC01.sbd.test   # 10.0.60.30
Invoke-Command SBD-DHCP01.sbd.test { Get-DhcpServerv4Scope }   # Tier 1 account, over remote management (A02)
# Inside SBD-ADMIN-PC01: Credential Guard is running when the list includes 1.
$dg = Get-CimInstance Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard
$dg.SecurityServicesRunning
w32tm /query /source   # a domain controller, never the VM IC Time Synchronization Provider
# On AdminJumpBox01: Hyper-V stays Available, never Installed.
Get-WindowsFeature Hyper-V | Select-Object Name, InstallState
Uninstall-WindowsFeature RSAT-DHCP -ComputerName SBD-DC01   # part 7's DHCP tools leave the controller
Test-NetConnection SBD-DC01.sbd.test -Port 5985
gpresult /r /scope:computer

Notes / result / date:

44. Restrict where privilege can sign in

About 45 min · Open this lesson

• Create the Tier 0 Servers OU (OU=Tier 0 Servers,OU=SBD,DC=sbd,DC=test) with deletion protection, link part 5's member-server STIG GPOs to it — the computer policy, the user policy, and the loopback GPO — so nothing loses its hardening, and move SBD-SUBCA01 and SBD-PKI-MGMT01 there. Both are Tier 0, and the Servers OU is about to deny Tier 0 sign-ins — left there, they would lock Tier 0 out of its own systems.
• Create one tier logon GPO for the Servers OU — now Tier 1 only — and one for the Workstations OU, and never link either to the Domain Controllers or Tier 0 Servers OUs. User rights don't merge across GPOs: for each right, the highest-precedence GPO that sets it wins, so each list repeats the entries part 5's STIG GPO sets for that right (such as Domain Admins and Enterprise Admins), and the tier GPO links above the STIG GPO. On the Servers OU, give SBD Tier 0 Admins Deny log on locally, Deny log on through Remote Desktop Services, Deny log on as a batch job, and Deny log on as a service. On the Workstations OU, give SBD Tier 0 Admins, SBD Tier 1 Admins, and SBD Audit Custodians those four denies plus Deny access to this computer from the network: the custodian's accounts administer the audit record, so they never sign in where Tier 2 risks apply.
• Give the tier OUs their administrators. Now that the Tier 0 servers are out, a GPO linked only to the Servers OU adds SBD Tier 1 Admins to each server's local Administrators group and removes Domain Admins (Group Policy Preferences, Local Users and Groups), as the member-server STIG expects, so every server joined there, starting with SBD-DHCP01, is run by Tier 1 from first boot; kept apart from the tier logon GPO, it lets an OU with its own administrators, such as course 1.4's Audit Servers OU, take the denies without this grant. Then join part 7's VLAN 80 test client to the domain with a Tier 2 account, delegated Create Computer objects on the Workstations OU as part 7 did for Tier 1 on the Servers OU; the part 5 redirect lands it in Workstations. Add SBD Tier 2 Admins to its local Administrators and turn on remote management there, accepted only from SBD-ADMIN-PC01 (10.0.60.30), so it can serve as this part's Tier 2 test machine.
• On the Servers OU, set Deny access to this computer from the network — SBD Tier 0 Admins plus the STIG's entries — in a separate GPO that excludes the SBD Tier 0 Console Hosts group through security filtering (deny Apply group policy). Course 1.7 adds SBD-WSUS01 to that group, so Tier 0 can manage the domain controllers' update ring there from AdminJumpBox01 with Tier 0 task accounts outside Domain Admins and Enterprise Admins (which the STIG denies network logon on member servers), and SBD-EPO01's console will join it when course 1.9, coming soon, arrives; a Kerberos network logon leaves no reusable credentials on the server. Record the exception — the group, the servers as they join it, the accounts, the reason, and its owner — in the part 5 exception record. Link both deny GPOs, this one and the tier logon GPO, to any OU created later for member servers, such as course 1.4's Audit Servers OU, before a server joins it; step 3's administrators GPO never goes there.
• Finish the seat GPOs from lesson 43 so each seat admits only its own tier, on both sides of the seat virtual machine. Allow log on locally replaces the STIG's list with Administrators and the seat's own groups: SBD Tier 0 Admins on AdminJumpBox01 (every Tier 0 account, Domain Admins and Enterprise Admins members included), SBD Tier 1 Admins and SBD Audit Custodians on SBD-ADMIN-SRV01, and SBD Tier 2 Admins inside SBD-ADMIN-PC01 (V-243452; V-243455 for the seat that manages Active Directory). The four denies plus Deny access to this computer from the network go to the other tiers: Tier 0, Tier 1, and SBD Audit Custodians inside the virtual machine, Tier 0 and Tier 2 on SBD-ADMIN-SRV01, Tier 1 and Tier 2 on AdminJumpBox01. The PAW STIG requires the higher-tier denies (V-243453, high severity if a Tier 0 account can sign in). Each deny list repeats the STIG GPO's entries for that right, except that AdminJumpBox01 leaves Domain Admins and Enterprise Admins out of Deny log on locally, because V-243455 admits them there. Record every STIG value these settings change in the exception record.
• Add Tier 0 administrators to the Protected Users group so the domain refuses their weaker authentication paths, and note the behavior of the newest Windows Server release that supports this design: RC4 ticket-granting tickets are gone and legacy remote password changes are blocked for protected accounts. Protected Users accounts also cannot be delegated, which keeps the console exception free of reusable credentials. Keep the built-in safety valve: one documented break-glass account, excluded from the deny policies and used at a domain controller's console (the admin seats admit only their own tiers), with its password sealed and its every use alarmed once course 1.5 builds the alerts. Record the multifactor decision the model calls for on VLAN 60 — smart card or certificate-based sign-in for privileged accounts is the natural follow-on to part 6's templates — with its target date, even if implementation waits.

Get-ADComputer -SearchBase 'OU=Tier 0 Servers,OU=SBD,DC=sbd,DC=test' -Filter * | Select-Object Name
Get-ADGroupMember 'Protected Users' | Select-Object Name
Invoke-Command SBD-DHCP01.sbd.test { Get-LocalGroupMember Administrators }   # from SBD-ADMIN-SRV01: SBD Tier 1 Admins, no Domain Admins
dsacls 'OU=Workstations,OU=SBD,DC=sbd,DC=test' /G 'SBD\SBD Tier 2 Admins:CC;computer'   # from AdminJumpBox01 (Tier 0)
# On the test client, as its local administrator: join with a Tier 2 account, then, after the restart, its managers
Add-Computer -DomainName sbd.test -Credential (Get-Credential) -Restart
Add-LocalGroupMember Administrators -Member 'SBD\SBD Tier 2 Admins'; Enable-PSRemoting -Force
Set-NetFirewallRule -DisplayGroup 'Windows Remote Management' -RemoteAddress 10.0.60.30
# On the Tier 2 test machine: export the effective logon rights and read the deny lines.
secedit /export /mergedpolicy /cfg C:\Evidence\tiered-admin\user-rights.inf /areas user_rights
Select-String -Path C:\Evidence\tiered-admin\user-rights.inf -Pattern 'SeDeny'
'SBD Tier 0 Admins', 'SBD Tier 1 Admins', 'SBD Audit Custodians' | ForEach-Object { (Get-ADGroup $_).SID.Value }   # from an admin seat: these SIDs must appear on those lines
# Repeat on each seat as its maintenance account, and read who may sign in there.
Select-String -Path C:\Evidence\tiered-admin\user-rights.inf -Pattern 'SeInteractive'
# After the refused Tier 0 sign-in: event 4625 with status 0xC000015B (logon type not granted).
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddHours(-1)} | Where-Object Message -match '0xC000015B' | Select-Object TimeCreated, Id

Notes / result / date:

45. Prove the tiers end to end

About 30 min · Open this lesson

• From AdminJumpBox01, manage a DC and SBD-SUBCA01 with a Tier 0 account — the Tier 0 Servers OU kept that access; from SBD-ADMIN-SRV01, manage SBD-DHCP01 with a Tier 1 account; from the SBD-ADMIN-PC01 virtual machine, opened from the host by a Tier 1 account without administrator rights there, manage the VLAN 80 test client with a Tier 2 account. Record each success with its session details, including the target's Security event 4624 (and 4672, which marks a logon that received special privileges).
• Attempt the forbidden combinations — Tier 0 credentials at the test client, a Tier 1 account and an audit custodian account inside the SBD-ADMIN-PC01 virtual machine, a Tier 2 account on its host, a session from VLAN 80 toward VLAN 60 — and capture both the refusal the user sees and the record the infrastructure writes: Security event 4625 with status 0xC000015B on the system that refused each sign-in, and the router's deny-log entry for the VLAN 80 session.
• Prove the virtual machine and its host stay apart: remote management attempts between SBD-ADMIN-PC01 and SBD-ADMIN-SRV01 fail in both directions at the target's firewall (they share VLAN 60, so no router sees them), and the console opens as a basic session, with no clipboard or drive sharing.
• Renew the test client's lease and confirm part 7's results still hold with every restriction active — the options, the relay, and the records owned by the DHCP update account; the control plane must not have broken the service plane.
• Reconcile the tier access matrix against what you just proved and file it with the register — the two documents together are the admin plane's assessable record.

Enter-PSSession SBD-DHCP01.sbd.test   # from SBD-ADMIN-SRV01, Tier 1 account
vmconnect.exe localhost SBD-ADMIN-PC01   # same account, not elevated: the console opens
Test-NetConnection SBD-ADMIN-SRV01.sbd.test -Port 5985   # from the guest: must fail
Test-NetConnection SBD-ADMIN-PC01.sbd.test -Port 5985   # from the host: must fail
ipconfig /renew   # on the VLAN 80 test client
# Where a sign-in was refused: last hour's 0xC000015B failures (logon type not granted).
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddHours(-1)} | Where-Object Message -match '0xC000015B' | Select-Object TimeCreated, Id

Notes / result / date:

46. Move the scan tools, rescan, and hand off

About 30 min · Open this lesson

• Move the assessment tools onto the seats, the last step of part 4's convention. Install SCC and STIG Viewer on AdminJumpBox01 from the part 4 media set, checked against connected-side-hashes.csv and at the same versions, and copy C:\Evidence from SBD-DC01 — the baseline and hardening folders, part 6's pki folder, and the part 7 Tier 0 folders, their manifests, and the exception record; once every set matches its manifest, remove SCC from both controllers and STIG Viewer from SBD-DC01, and retire the controllers' copy of the evidence. Each tier then assesses its own systems from its own seat: SBD-ADMIN-SRV01 gets its own copy of the tools and part 7's C:\Evidence\dhcp, and scans member servers locally in Tier 1 sessions, because A02 carries remote desktop and remote management, not the file-sharing and RPC ports SCC's remote scans use; and SBD-ADMIN-PC01 gets its own SCC copy, carried into the virtual machine on read-only media — an ISO image of the part 4 media set, attached to its virtual DVD drive from the host, because the Guest Service Interface stays off — checked against connected-side-hashes.csv, at the same version as the other seats' copies, with the Windows client benchmark part 4 staged. Keep the checked installer and the hash list in C:\Staging\DISA inside the virtual machine, where course 1.6 reuses them for the fleet's scans, and detach the ISO.
• Run first baselines on the three seats with the standard tool versions — AdminJumpBox01 and SBD-ADMIN-SRV01 with the Windows Server benchmark, SBD-ADMIN-PC01 with the Windows client benchmark, scanned locally in a Tier 2 session from its own copy — and rescan what this part changed: SBD-SUBCA01 and SBD-PKI-MGMT01, whose move to the Tier 0 Servers OU should leave their hardening intact; SBD-DHCP01, whose administrators and logon rights now come from the tier GPOs; and both domain controllers from AdminJumpBox01, whose firewall rules lesson 43 scoped and whose results also show the moved tools reproduce part 5's. Complete SBD-DHCP01's STIG Viewer checklist on SBD-ADMIN-SRV01 with the manual answers part 7 left open.
• Add this part's rows to the living records: the deny-logon, local Administrators, and Protected Users decisions into the exception record where they interact with STIG values, beside lesson 44's console network-logon exception, and the new permit and deny rows into the register with owners. The exception record stays one record, kept on AdminJumpBox01 by its owner, who adds the rows that Tier 1 and Tier 2 work sends in.
• Confirm the admin hosts appear in part 5's quarterly cadence; privileged seats are rescanned first from now on, not last.
• Write the handoff: administration now has a home, so course 1.2 can build SBD-REPO01 administered over SSH from SBD-ADMIN-SRV01 alone, and the logging courses (1.3–1.5) can require that collectors, the archive, and SIEM consoles are managed only from VLAN 60 — with the DC-facing scopes from the Tier 0 seat and audit retention under the custodian's separate accounts. Say so explicitly for course 1.2 and the courses after it.

# On AdminJumpBox01 (Tier 0): carry the evidence over; no output means a set matches its manifest
Copy-Item \\SBD-DC01\C$\Evidence -Destination C:\ -Recurse
'baseline', 'hardened', 'pki', 'dhcp' | ForEach-Object { Compare-Object (Import-Csv "C:\Evidence\$_-manifest.csv").Hash (Get-ChildItem "C:\Evidence\$_" -Recurse -File | Get-FileHash -Algorithm SHA256).Hash }
Invoke-Command SBD-DC01, SBD-DC02 { Test-Path 'C:\Program Files*\SCAP Compliance Checker*' }   # False once SCC is removed
# On SBD-ADMIN-SRV01 (Tier 1): part 7's server record, checked the same way
$s = New-PSSession SBD-DHCP01.sbd.test
Copy-Item C:\Evidence\dhcp, C:\Evidence\dhcp-manifest.csv -FromSession $s -Destination C:\Evidence\ -Recurse
Compare-Object (Import-Csv C:\Evidence\dhcp-manifest.csv).Hash (Get-ChildItem C:\Evidence\dhcp -Recurse -File | Get-FileHash -Algorithm SHA256).Hash
# Still on SBD-ADMIN-SRV01, as a Hyper-V administrator: the media set's ISO into the Tier 2 seat, read-only
Set-VMDvdDrive -VMName SBD-ADMIN-PC01 -Path '<part 4 media set ISO>'
# Inside SBD-ADMIN-PC01 (Tier 2), with the ISO as D: the installer matches the record (expected: True); keep both for course 1.6
$scc = Get-Item 'D:\<SCC installer>'
(Get-FileHash $scc.FullName -Algorithm SHA256).Hash -in (Import-Csv D:\connected-side-hashes.csv).Hash
New-Item -ItemType Directory -Force C:\Staging\DISA | Out-Null
Copy-Item $scc.FullName, D:\connected-side-hashes.csv -Destination C:\Staging\DISA\
Set-VMDvdDrive -VMName SBD-ADMIN-PC01 -Path $null   # back on the host, after the install: detach the ISO
# On each seat, after its scans: this part's evidence, hashed
Get-ChildItem C:\Evidence\tiered-admin -Recurse | Select-Object Name, LastWriteTime
Get-FileHash -Algorithm SHA256 C:\Evidence\tiered-admin\*

Notes / result / date: