Add Best Practices, Governance & AD Hardening documentation page

[Joel Platek (VAsHachiRoku)]

Summary

Adds a new documentation page — Best Practices, Governance & AD Hardening (docs/best-practices.md) — and wires it into the MkDocs site and the README.

Originated from community issue #33 (group manager delegation), broadened into a living best-practices reference.

What's in the page

Part 1 — General AD Guidance › Group Management & Delegation

• Documents the group Managed By (managedBy) delegation and the "Manager can update membership list" option (narrowly delegates write access to the group's member attribute).
• Golden Rule: the managedBy manager of a Tier N group must be a Tier N admin account.
  • Never a higher tier — using a Tier 0 account to manage a lower-tier group over-exposes a privileged credential (not least privilege / not JEA).
  • Never an untiered account — a cross-tier managedBy relationship breaks tier isolation.
• Includes a worked-example table (T0/T1/T2) and PAW pairing guidance.

Part 2 — AD Hardening Guidance

• Frames the Tier Model as a foundation, not a complete hardening program, and gives a high-level post-deployment checklist (patching, NTLM relay, Kerberoasting/service accounts, PAWs, legacy protocols, monitoring) that points to Microsoft's authoritative guidance.

Related Reading — Microsoft Learn (Best practices for securing AD), the Dec 2025 AD DS threat-mitigation blog, and the AD Hardening series, plus cross-links to the GPO, Canonical ACL, and Sentinel pages.

Changes

• docs/best-practices.md (new)
• mkdocs.yml — nav entry after GPO Management Guidance
• README.md — Core Documentation bullet

Notes

• Documentation only — no code, no version change, no new build.
• Accuracy verified against the repo: the Advanced Audit Policy and PowerShell Audit Policy GPOs both ship link-enabled, and the managedBy/gMSA/dMSA/tier references are consistent with the deployment config.

Closes #33

[Copilot]

Pull request overview

Adds a Best Practices, Governance & AD Hardening documentation page and links it from MkDocs and the README.

Changes:

• Adds docs/best-practices.md.
• Registers the page in MkDocs navigation.
• Adds the page to README documentation links.

Review findings:

• Moderate: Clarify required same-tier PAW logon-group membership and effective GPO verification.
• Nit: Distinguish no standing group membership from no standing permission.
• Nit: Replace the JEA comparison with least-privilege and tier-boundary guidance.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
README.md	Adds the page to core documentation
mkdocs.yml	Adds the page to site navigation
docs/best-practices.md	Adds governance and AD hardening guidance

Suppressed comments (5)

docs/best-practices.md:90

• The linked Sentinel guide identifies the domain-root SACL configured by -EnableAuditing and the DC Advanced Audit Policy GPO as jointly required for Tier Model detections. This checklist only asks readers to enable the GPOs, so an operator can follow it, forward Security logs, and still receive no Tier Model events because the SACL is absent. Please call out the SACL as the other required prerequisite (and link to the Sentinel setup).

Hardening without visibility is incomplete. The Tier Model ships a [Microsoft Sentinel monitoring solution](sentinel-monitoring.md) for Tier-Model-specific detections — but Sentinel does not replace a full AD monitoring strategy. Confirm that Advanced Audit Policy and PowerShell audit logging GPOs are enabled on domain controllers (both ship enabled in the Tier Model). Every DC whose Security event log does not reach your SIEM is a blind spot, not partial coverage.

docs/best-practices.md:30

• Manager can update membership list is not a durable delegation for protected groups such as Domain Admins and Enterprise Admins: AdminSDHolder/SDProp periodically reapplies the AdminSDHolder security descriptor and can remove the manager's Write Members ACE. Because this page recommends the setting for privileged/admin groups, call out the adminCount=1 exception and provide a supported workflow for protected groups.

**What it is.** Every AD group exposes a **Managed By** tab in Active Directory Users and Computers (ADUC). Setting the `managedBy` attribute to a specific admin account designates that account as the group's responsible owner. Enabling **"Manager can update membership list"** on that same tab adds a single Access Control Entry (ACE) to the group: write access to the `member` attribute, scoped only to that designated account.

docs/best-practices.md:34

• Granting the manager write access to member is itself a standing privilege over the whole group: it can add the manager's own account or arbitrary nested groups/principals, including one that grants admin rights. Without an approval/automation boundary and membership validation, this does not provide the claimed separation of duties or safe JIT; document those guardrails and monitoring before presenting it as a safe delegation.

**Why it matters.** A named group manager creates separation of duties without expanding permanent privilege. An operations team manages membership for an admin group without being Domain Admins. A role owner curates their own group. A Just-in-Time workflow checks users in and out without any standing elevated access. This is an operational governance improvement that layers on top of the Tier Model without changing its architecture — no deployment script changes, no new Tier Model concepts.

docs/best-practices.md:86

• The checklist currently says to disable RC4, SMBv1, LLMNR, NetBIOS, and NTLMv1 unconditionally. Applying these changes before inventory and migration can break legacy clients, trusts, and service accounts; make the recommendation audit → migrate/test → disable, and include exception and rollback handling.

Every unnecessary protocol is an attack surface. Audit and disable SMBv1, LLMNR, NetBIOS over TCP/IP, NTLMv1, and weak Kerberos cipher suites (RC4, DES). Disable the Print Spooler service on domain controllers — this removes both PrintNightmare exploitation and NTLM coercion vectors. The Tier Model's baseline GPO set covers many of these controls; confirm your chosen baseline is link-enabled.

docs/best-practices.md:52

• The table's service account wording is broader than the rule: this repository defines tiered service-account groups (Tier1ServiceAccounts, Tier2ServiceAccounts), so a same-tier service account is not automatically an invalid manager. Qualify these entries as untiered service accounts, matching the preceding rule.

| `T1-ServerAdmins` | Tier 1 admin account | Tier 0 account — credential over-exposure, not JEA | Standard user / service account — tier boundary break |
| `T2-WorkstationAdmins` | Tier 2 admin account | Tier 0 or Tier 1 account — over-exposure | Standard user / service account — tier boundary break |

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

Suppressed comments (10)

docs/best-practices.md:40

• This same-tier rule conflicts with the shipped role model rather than merely documenting it. Tier0Admins is granted GenericAll, CreateChild, and DeleteChild over all objects under OU=Tier Model Administration (config/tiermodel-acls.json:614-625), and the Tier 0 Admins group is described as administering Tier 0, 1, and 2 resources (config/tiermodel-groups.json:15-21). A Tier 0 admin can therefore manage lower-tier groups regardless of managedBy. Either change the ACL/role design as part of this rule, or describe it as an additional governance policy and explain the existing cross-tier administration.

> **Golden Rule: The `managedBy` account for a Tier N group must be a Tier N admin account.**
>
> Same tier, always. Never up. Never down. Never untiered.

**Why this rule is non-negotiable.** Credential exposure must match the sensitivity of the resource being managed.

docs/best-practices.md:42

• JEA means Just Enough Administration, not Just Enough Access, and it is a PowerShell delegation model rather than a synonym for same-tier administration. Please correct the expansion and avoid using the tier assignment itself as evidence that JEA is or is not present.

- **Using a Tier 0 account to manage a Tier 1 or Tier 2 group** means checking out a Tier 0 credential to perform lower-tier work. That is not least privilege and not Just Enough Access (JEA). The Tier 0 credential is now in contact with the Tier 1 boundary, and any system it touches carries Tier 0 risk.

docs/best-practices.md:54

• The GPO does not use the user's OU to enforce this restriction. Its logon assignments are evaluated from the account's group memberships on the target computer; moving an account into a Tier OU alone does not make the restriction apply. Direct operators to add the manager to the corresponding TierNAdmins group and use that tier's PAW.

**Pairing with a PAW.** The manager account is most effective when restricted to log on only from a Privileged Access Workstation at the same tier. The tier's Account Restrictions GPO already enforces this for Tier Model accounts; ensure the manager account is placed in the correct Tier OU so the same Deny logon policy applies.

docs/best-practices.md:34

• Enabling this checkbox creates a persistent ACE that gives the manager a standing ability to change the group's membership, even though it is narrower than Domain Admin. JIT may remove standing membership for the users being managed, but it does not remove the manager or workflow identity's standing delegated ability. Qualify the claim that this does not expand permanent privilege.

**Why it matters.** A named group manager creates separation of duties without expanding permanent privilege. An operations team manages membership for an admin group without being Domain Admins. A role owner curates their own group. A Just-in-Time workflow checks users in and out without any standing elevated access. This is an operational governance improvement that layers on top of the Tier Model without changing its architecture — no deployment script changes, no new Tier Model concepts.

docs/best-practices.md:30

• For protected groups such as Domain Admins, AdminSDHolder/SDProp reapplies the protected security descriptor and can remove a group-specific WriteMembers ACE. As a result, checking this box does not reliably delegate membership for the privileged groups this page targets. Restrict this recommendation to non-protected role groups (nested into the privileged group as needed) or document a supported protected-group design.

**What it is.** Every AD group exposes a **Managed By** tab in Active Directory Users and Computers (ADUC). Setting the `managedBy` attribute to a specific admin account designates that account as the group's responsible owner. Enabling **"Manager can update membership list"** on that same tab adds a single Access Control Entry (ACE) to the group: write access to the `member` attribute, scoped only to that designated account.

docs/best-practices.md:78

• The dMSA add-on in this repository explicitly requires the Windows Server 2025 schema (config/tiermodel-dmsa.json:3), but this prerequisite is omitted here. A reader could satisfy the stated functional-level condition and still fail dMSA provisioning. Call out the schema requirement alongside any functional-level prerequisite.

Service accounts with registered SPNs are offline-crackable via Kerberoasting — no elevated privilege required for the ticket request, and the traffic is indistinguishable from normal Kerberos use. Prefer **group Managed Service Accounts (gMSA)** or, where the domain functional level supports it, **delegated Managed Service Accounts (dMSA)** — both use system-managed, automatically-rotating passwords that are practically uncrackable offline. For legacy accounts that cannot yet migrate, enforce long (25+ character) random passwords and audit all SPN registrations.

docs/best-practices.md:82

• This repeats the same inaccurate guarantee from line 54: the shipped deny policies isolate tier accounts, but same-tier administrators can still log on to same-tier member servers, so they do not by themselves enforce PAW-only use. Reword this as tier isolation and require a separate PAW/authentication-silo control when PAW-only logon is intended.

The Tier Model's containment guarantees are only as strong as the endpoints from which admin credentials are entered. A Privileged Access Workstation at the correct tier — hardened, network-segmented, dedicated to admin tasks only — prevents credential theft via keyloggers, clipboard capture, and lateral movement through compromised desktops. The Tier Model's Account Restrictions GPO and Deny logon framework are designed to enforce PAW use. See [GPO Management Guidance](gpo-management-guidance.md) for how the deny model is structured.

docs/best-practices.md:56

• JIT does not remove the manager account's standing member-write delegation; it only makes the target users' memberships temporary. Rephrase this to avoid suggesting that the identity performing the change has no standing access.

**Relationship to Just-in-Time.** The `managedBy` delegation complements JIT but does not require it. With JIT, the manager account triggers membership changes on demand without standing access. Without JIT, it creates a named, governed owner for each group — already a significant improvement over ad hoc Domain Admin membership edits.

docs/best-practices.md:90

• For the Tier Model Sentinel detections, the linked prerequisites require two pieces: the domain-root audit SACL configured with Deploy-TierModel.ps1 -EnableAuditing -ConfirmApply and the DC Advanced Audit Policy GPO/link. Mentioning only the two GPOs can leave operators with no SACL and therefore no expected audit events; add this prerequisite or scope the paragraph to generic AD logging.

Hardening without visibility is incomplete. The Tier Model ships a [Microsoft Sentinel monitoring solution](sentinel-monitoring.md) for Tier-Model-specific detections — but Sentinel does not replace a full AD monitoring strategy. Confirm that Advanced Audit Policy and PowerShell audit logging GPOs are enabled on domain controllers (both ship enabled in the Tier Model). Every DC whose Security event log does not reach your SIEM is a blind spot, not partial coverage.

mkdocs.yml:21

• The MkDocs Home page is a manually maintained catalogue and lists the component-management pages in docs/index.md:21-25, but the new page is absent there. The nav entry makes it reachable from the sidebar, yet users landing on Home will not discover it; add the corresponding Home-page link as part of wiring the documentation into the site.

  - Best Practices & Hardening: best-practices.md