Legacy Haven University

Active Directory Domain Services (AD DS) stores identities, group memberships, and trust decisions for most Windows enterprises. Kerberos is the ticket protocol those domain controllers use to prove who a user or service is without sending a password to every server. CompTIA SecurityX (CAS-005) does not list “forest hardening” or “Kerberoasting” as named exam bullets. It does list Kerberos under IAM troubleshooting, directory service misconfiguration as an attack class, and credential dumping, privilege escalation, and lateral movement as endpoint/server tactics. Treat the marketing title as the operational problem; treat the official objectives as the testable map.

What a forest actually is

A forest is the AD DS security boundary. Microsoft defines it as one or more domain trees that share one schema, one configuration partition, and one global catalog. A domain is the administrative container for users, groups, and computers. A domain tree is one or more domains that share a contiguous DNS namespace and parent–child trusts. One domain can be an entire forest.

The first domain you create is the forest root. That domain holds forest-wide roles such as the schema master. Every other domain in the forest inherits the same schema and configuration. That is why a compromise of a domain controller (DC) is not “just one server.” The DC hosts the Kerberos Key Distribution Center (KDC) and the account database the KDC reads.

Inside one forest, Windows creates two-way, transitive Kerberos trusts as you add domains. Transitive means: if Domain A trusts Domain B, and Domain B trusts Domain C, Domain A trusts Domain C. Across forests you create explicit forest trusts. Those trusts carry authorization data, including SIDs. Microsoft enables SID filtering (domain quarantine) by default on forest and domain trusts so a trusted domain cannot inject foreign SIDs through SID History and walk into resources it does not own.

CAS-005 objective 2.4 asks you to design access, authentication, and authorization systems: identity providers, service providers, federation, SSO, access-control models, and policy decision/enforcement points. An AD forest is the on-premises identity provider for that design. Objective 2.6 then forces the Zero Trust question: do you still treat every ticket inside the forest as implicit trust, or do you keep authorizing the subject against the object on each request?

Kerberos under the hood

Kerberos Version 5 is specified in RFC 4120. Microsoft’s Windows implementation is documented as MS-KILE and runs on every writable DC. The KDC has two logical services: the Authentication Service (AS) and the Ticket-Granting Service (TGS). Clients talk to them on TCP/UDP 88.

Three exchanges move identity across the network.

1. AS exchange (get a TGT)
The client sends KRB_AS_REQ with its principal name and, in a hardened domain, pre-authentication data. The KDC looks up the account in AD DS and returns KRB_AS_REP: a ticket-granting ticket (TGT) plus a logon session key. The TGT’s encrypted part is sealed with the KDC’s long-term key. The client’s copy of the session key is sealed with a key derived from the user’s secret. After this step the client can drop the password-derived key for the rest of the logon session and use the session key instead.

2. TGS exchange (get a service ticket)
The client sends KRB_TGS_REQ that carries the TGT, an authenticator, and the target service principal name (SPN). An authenticator is a fresh timestamp encrypted with the TGT session key. It proves the client holds the session key and is not replaying an old ticket. The TGS opens the TGT with the KDC key, checks the authenticator, and returns KRB_TGS_REP: a service ticket encrypted with the target service’s long-term key, plus a new client/server session key.

3. AP exchange (use the service)
The client sends KRB_AP_REQ to the application server: the service ticket plus a new authenticator. The server decrypts the ticket with its own long-term key, extracts the session key, and validates the authenticator. The server does not have to call a DC unless it needs to validate the Privilege Attribute Certificate (PAC) — the Windows authorization blob that rides inside the ticket and lists SIDs and group memberships.

Default Microsoft TGT lifetime is 10 hours and is renewable for the logon session. That number matters later when you rotate the KDC key.

Kerberos replaces NTLM pass-through. NTLM assumed the server was genuine and made the server call a DC on every authentication. Kerberos assumes neither end is trusted until tickets and authenticators check out, and it supports mutual authentication. CAS-005 lists both Kerberos and NTLM in the official acronym list; 3.1 lists Kerberos next to SAML, OpenID, OAuth, MFA, SSO, PAM, and 802.1X as authentication and authorization components you must troubleshoot.

The KRBTGT key is the forest’s master seal

The TGT is encrypted with a key derived from the krbtgt account password. That account is the KDC’s service account. Anyone who obtains the krbtgt secret can mint TGTs the KDC will accept. Microsoft’s own forest-recovery guidance therefore resets the krbtgt password — and it tells you to do it twice. The account’s password history is 2. One reset leaves the previous key valid; the second reset drops the stolen key out of history. Wait at least one maximum TGT lifetime (default 10 hours) between the two resets on a writable DC so replication finishes and outstanding tickets expire. Do not delete RODC krbtgt accounts if you plan to recover those RODCs.

This is secrets management in the CAS-005 sense: a long-term key, rotation, and deletion of the old material. Objective 3.1 lists tokens, certificates, passwords, keys, rotation, and deletion under secrets management. The krbtgt password is the directory’s most important key.

How directory misconfiguration becomes an attack path

CAS-005 4.2 names directory service misconfiguration as a vulnerability class. It also lists insecure configuration, embedded secrets, outdated software, and weak ciphers. Map those generic labels onto Kerberos and AD with mechanisms Microsoft documents — not with exam fan fiction.

Weak encryption types.
A service ticket is encrypted with the service’s long-term key. Any authenticated domain user can request a ticket for an SPN that exists. If that service still accepts RC4, an attacker takes the ticket offline and attacks the encryption. Microsoft documents this class of service-account credential theft as kerberoasting and introduced delegated Managed Service Accounts (dMSA) in Windows Server 2025 specifically to stop password-based harvesting of those accounts. Protected Users and AES-only policy are the older controls: members of Protected Users cannot use DES or RC4 in Kerberos pre-authentication, cannot use NTLM, cannot be delegated, and cannot renew a TGT past a four-hour initial lifetime.

Unconstrained delegation.
Kerberos delegation lets a front-end service impersonate a client at a back-end service. Unconstrained delegation lets that front-end service impersonate the user to any service. Microsoft’s guidance is blunt: get rid of unconstrained delegation and move to constrained or resource-based constrained delegation so the resource owner names the exact front-end principals that may act on a user’s behalf. That is subject–object binding (CAS-005 2.6) applied to tickets.

NTLM fallback.
If Kerberos fails — missing SPN, broken DNS, time skew, missing AES keys — Windows often falls back to NTLM. NTLM has no mutual authentication of the kind Kerberos provides and remains the path for relay and pass-the-hash style credential reuse. Microsoft’s AD hardening training tells you to restrict NTLM, disable NTLMv1 where you can, and prefer Kerberos. CAS-005 3.1 will test whether you can tell an IAM failure (bad SPN, clock drift, wrong encryption type, missing pre-auth) from an intended protocol choice.

Unsigned LDAP.
LDAP on 389 without signing lets an on-path attacker alter queries and answers. LDAPS uses 636. Microsoft’s DC firewall table lists 389, 636, 3268/3269 (global catalog), 88 (Kerberos), 53 (DNS), and 445 (SMB) as the core directory ports. Windows Server 2025 new deployments require LDAP signing by default. Enforce signing and channel binding; reject simple binds on cleartext.

Over-privileged service accounts and SPN sprawl.
An SPN tells the TGS which account’s key will seal the service ticket. A user account with an SPN and a static password is a directory secret sitting in the open. gMSA/dMSA, least privilege, and PAM (all in 3.1) exist to shrink that secret’s lifetime and who can use it.

Trusts without SID filtering or with selective authentication left off.
A forest trust without quarantine lets SID History from the trusted side impersonate high-privilege groups on your side. Selective authentication requires an explicit “Allowed to authenticate” grant on the target. Leave those controls off and 2.4’s policy enforcement point is the trust itself — wide open.

Objective 3.2 then names the TTP sequence you see after a directory mistake: credential dumping, privilege escalation, lateral movement. A forged or stolen ticket is how that sequence crosses machines without dumping a new password each hop.

Forest-level hardening that Microsoft actually publishes

Hardening is configuration that removes implicit trust. Microsoft’s domain-controller and AD DS guidance is specific. Use that list; do not invent a “CIS-style” checklist CompTIA never printed.

Treat every DC as a tier-0 host.
Only Domain Admins sign on to DCs. Block outbound internet from DCs. Do not browse the web from a DC. Prefer Server Core. Patch on a short cycle. Put physical DCs in dedicated racks. Require TPM and BitLocker on DC volumes. Run virtual DCs on hosts that do not mix with general workloads. Use an RODC in a site you cannot physically lock down; an RODC holds only a filtered secret set and uses its own krbtgt account.

Put privileged users in Protected Users.
On the workstation: no cached plaintext, no NTOWF cache, no DES/RC4 key creation, no offline sign-in. On a Windows Server 2012 R2 or later DC: no NTLM, no DES/RC4 pre-auth, no constrained or unconstrained delegation, no TGT renewal past four hours. Service and computer accounts cannot join this group; harden those with NTLM block policy, AES encryption types, and managed service accounts instead. Test before you drop Domain Admins into the group — the built-in Administrator lacks AES keys until its password is changed on a Windows Server 2008 or later DC.

Retire RC4 and require AES.
Microsoft is moving KDC defaults toward AES-first and is deprecating RC4. Disable RC4 only after every client, server, and trust in the path supports AES (Windows Vista / Windows Server 2008 onward). Use Group Policy for encryption types; Windows Server 2025 no longer honors the legacy SupportedEncryptionTypes registry key.

Sign LDAP. Sign SMB. Bind the TLS channel.
These close the on-path gap that ticket and directory traffic still have when they ride unsigned sessions.

Kill unconstrained delegation.
Inventory TRUSTED_FOR_DELEGATION and convert those accounts to constrained or resource-based constrained delegation. Resource-based constrained delegation puts the allow-list on the target object (msDS-AllowedToActOnBehalfOfOtherIdentity), which matches a Zero Trust subject–object rule better than a front-end “trust me for everything” bit.

Rotate krbtgt on a maintenance cadence, not only after a breach.
One reset, wait for replication and ticket lifetime, second reset. A double reset before replication finishes is a break-glass forest-recovery move: it invalidates live TGTs and will knock application services off Kerberos until they re-issue tickets.

Instrument 3.1’s logging and monitoring requirement.
Watch Kerberos pre-auth failures, encryption-type downgrades, TGS requests for high-value SPNs, LDAP binds without signing, NTLM from accounts that should be Kerberos-only, and trust authentication that fails SID or name checks. Objective 4.1 (operations monitoring) and 3.1 (IAM logging) meet at the DC event log and at whatever SIEM you feed it.

How this shows up on CAS-005

CompTIA’s objectives PDF also states that the bullet lists are not exhaustive. A performance item can still drop you into an AD/Kerberos scenario without using the word “forest.” Read the verbs: design, troubleshoot, analyze, recommend. The exam wants the control and the failure mode, not a vendor blog’s attack nickname.

Operator sequence

1. Draw the forest: root domain, child domains, external forest trusts, and which DCs hold which FSMO roles.
2. Confirm every DC is tier-0: no browsing, no extra software, BitLocker, restricted RDP.
3. Inventory SPNs, unconstrained delegation, RC4 accounts, and NTLM usage.
4. Enforce LDAP signing and AES Kerberos; add privileged users to Protected Users after a pilot.
5. Replace static service-account passwords with gMSA or dMSA.
6. Rotate krbtgt twice on a planned interval; document the 10-hour wait.
7. Turn on SID filtering and selective authentication on every forest trust.
8. Alert on TGS spikes for admin SPNs, etype downgrades, and unsigned LDAP binds.

That sequence hardens the directory that issues tickets. Kerberos then stops being an implicit passport for the whole enterprise and becomes what CAS-005 3.1 describes: one IAM protocol you can troubleshoot, constrain, and rotate.