📚 NET-S2-M05: Windows Server grundopsætning / AD DS

🎯 Læringsmål

Efter dette modul kan du:

• Forklare hvorfor AD DS, DNS og tidssynk skal behandles som ét samlet design.
• Installere AD DS-rollen, promovere en server til domænecontroller og validere installationen.
• Strukturere OU’er og grupper, så administration og policy bliver skalerbar.
• Tolke output fra fx dcdiag, nltest, Get-ADDomain og gpresult.
• Anvende troubleshooting-kæden: symptom -> måling -> isolering -> fix -> verifikation.
• Dokumentere baseline, så miljøet kan genopbygges og driftes af andre.

📋 README compliance-status

Denne sektion viser eksplicit status mod de lokale krav i README.md for final-guides.

🧭 Begrebsordliste

🧭 Modulkort Fra Slides

📘 Kerneteori Eksamen

1) AD DS og DNS er en samlet løsning

Klienter finder ikke “domænet” direkte; de finder domænetjenester via DNS records (især SRV). Forkert DNS-konfiguration giver derfor ofte login-/join-fejl, selv om netværk ellers virker.

Designregel
Klientens primære DNS peger på intern AD DNS
-> Klient finder DC via SRV
-> Kerberos/LDAP virker stabilt

2) Tidssynk er sikkerhed, ikke kosmetik

Kerberos tickets har tidsvinduer. Hvis klient/DC har for stor tidsskev, bliver brugerautentifikation afvist. NTP-kilde og tidszone er derfor kritiske driftspunkter.

3) OU-design skal følge administration

OU’er bør designes efter hvem der administrerer hvilke objekter. Dette gør delegation, GPO-targeting og fejlsøgning enklere.

4) Baseline GPO reducerer incident-rate

Når password policy, lockout, firewall og opdateringskrav ligger centralt i GPO fra start, får du mere ens klientadfærd og hurtigere support.

5) Replikering og SYSVOL betyder “samme sandhed”

I miljøer med flere DC’er skal AD-objekter og SYSVOL være konsistente. Ellers opleves “tilfældige” forskelle afhængigt af hvilken DC klienten rammer.

🧠 Kerneteori masterclass

Udvidet teoridel med 10 kerneemner. Hvert emne dækker definition, mekanisme, årsag/virkning, tradeoff, edge-cases, klassiske misforståelser, verifikation og eksamensgreb.

📚 Teorifordybelse

AD DS som kontrolplan for identitet

Et AD-domæne er ikke kun en brugerdatabase. Det er en samlet kontrolplan for autentifikation (Kerberos), autorisation (grupper/GPO), navneopslag (DNS) og central drift (OU/delegation).

Årsag -> virkning i drift

• Forkert DNS -> klient finder ikke DC korrekt -> join/login/GPO fejler.
• Tidsskev -> Kerberos-ticket afvises -> intermittent login-fejl.
• Flad OU-struktur -> dårlig policy-targeting -> øget ændringsrisiko.
• Manglende verifikation -> fejl opdages sent -> højere MTTR ved incidents.

Tradeoff

Få OU’er giver enkel struktur men svag styring. Mange OU’er giver præcis styring men højere kompleksitet. Start simpelt, men med tydelig navngivning og en pilot-OU.

⚠️ Klassiske misforståelser

• "Ping virker, så AD virker" -> nej. AD kræver DNS SRV + Kerberos + LDAP + SYSVOL.
• "GPO slår igennem med det samme" -> ofte kræves gpupdate /force eller ny logon.
• "OU er kun mapper" -> OU er scope for delegation, filtering og policy-link.
• "Kun DC skal have korrekt tid" -> både klient og DC skal være synkroniseret.

🎯 Eksamensgreb

Brug denne svarskabelon i case-opgaver:

1) Krav: Hvad skal virke (join, login, policy)?
2) Designvalg: DNS, OU, grupper, GPO-link.
3) Risiko: Hvad kan bryde (DNS/tid/filtering)?
4) Måling: Hvilke kommandoer beviser tilstand?
5) Fix: Konkrete ændringer.
6) Verifikation: Hvad ser du bagefter?

📐 Kerneteori coverage-matrix

🧮 Kerneteori score-rubrik (0-5)

🖼️ Kritiske figurer fra slides

Sådan bruger du slottene: Erstat hver IMG_SLOT_0X_BASE64 med reel base64-data fra den relevante slide-render. Behold kommentarer for sporbarhed.

Figur-slot 01-04 (kerneflow)

Figur-slot 05-08 (join, GPO, fejlsøgning)

🧠 Udvidede løsningsforslag

Scenario A: Join fejler kun på én klient

1) ipconfig /all (DNS peger på DC?)
2) nslookup ucn.lab
3) nslookup -type=SRV _ldap._tcp.dc._msdcs.ucn.lab
4) nltest /dsgetdc:ucn.lab
5) Fix DNS/time, genstart Netlogon, retest join
6) Verificér i AD at computerobjektet findes (se trin 9)

Kobling: Se Trin 8 og Trin 9 i LabGuide-forløbet.

Scenario B: GPO vises i GPMC, men ikke på klient

1) gpresult /r
2) Kontroller OU-link + inheritance
3) Kontroller security filtering/WMI filter
4) gpupdate /force
5) Verificér SYSVOL-adgang og læs GroupPolicy event log
6) Kontrollér at brugeren faktisk ligger i Students-OU

Kobling: Se Trin 10 og Trin 11.

Scenario C: Login fejler sporadisk efter reboot

1) w32tm /query /status på DC og klient
2) Tjek tidskilde/NTP
3) Se KDC/Kerberos events
4) Synk tid og retest login med domænebruger
5) Kontrollér at tidszone matcher begge maskiner

Kobling: Se Trin 9 og Kerberos-kontrol i verifikations-playbook.

Scenario D: SYSVOL-adgang fejler, GPO læses ikke

1) Test: \\ucn.lab\SYSVOL fra klient
2) gpresult /r (mangler forventet GPO?)
3) Tjek SMB/firewall mellem klient og DC (port 445)
4) Kør dcdiag /test:SysVolCheck /test:Advertising
5) Bekræft DFSR/NETLOGON/SYSVOL shares på DC
6) Kør gpupdate /force og verificér igen

Kobling: Se Trin 11 og Troubleshooting-kæden.

Scenario E: Tidsskev mellem DC og klient, Kerberos fejler sporadisk

1) w32tm /query /status på begge noder
2) Sammenlign clock offset og source
3) Kør w32tm /resync (hvis relevant rettighed)
4) Læs Security/Kerberos events for afviste tickets
5) Ret NTP-kilde på DC og retest domænelogin
6) Verificér stabilitet over 2-3 loginforsøg

Kobling: Se Trin 9 samt Kerberos-emnet i masterclass.