Defender for Identity

Most of Harrow & Finch's devices and accounts still depend on an on-premises Active Directory domain, hf.local, with four domain controllers: two at head office, one at the Ames distribution center and one in Azure, added during Project Skylight. Active Directory is where attackers go once they have a foothold, because control of the directory is control of everything joined to it. On October 28 and 29, 2026, an outside firm ran an approved penetration test against the network, and Sunil asked Nadia to treat it as a training exercise: Ama would work the Defender for Identity alerts as if the test were real, then compare notes with the testers. This lesson explains what Defender for Identity watches, how its sensors are deployed, and what Ama learned from the test.

What Defender for Identity watches

Defender for Identity is a cloud service that uses sensors on identity infrastructure to watch authentication traffic, directory queries and changes, and Windows events. It learns normal behavior for users, devices and resources, and raises alerts for activity that matches known attack techniques or departs sharply from the baseline. It covers on-premises Active Directory domain controllers, Active Directory Federation Services servers, Active Directory Certificate Services servers, and Microsoft Entra Connect servers, which synchronize the on-premises directory to Microsoft Entra ID. Its alerts appear in the Defender portal and correlate with endpoint, email and cloud application alerts, which is why a stolen password used on a laptop and then against a domain controller ends up in one incident.

Defender for Identity also contributes to posture. Its identity security assessments, now surfaced through Microsoft Secure Score and exposure management, list risky configurations such as accounts with unconstrained Kerberos delegation, service accounts with old passwords, weak encryption types still allowed, and print spooler services running on domain controllers. Lateral movement path reports show how an attacker who compromised one ordinary account could reach a sensitive one, through chains of local administrator rights and logged-on sessions.

Sensors and deployment

A Defender for Identity sensor is installed on each domain controller and on each other supported server. Microsoft offers two forms. The classic sensor is a separate installation package. The newer sensor, often called version 3, is activated through Defender for Endpoint on domain controllers running Windows Server 2019 or later, so a domain controller already onboarded to Defender for Endpoint can have identity protection turned on from the portal. Microsoft documents which features each form supports, and some organizations run both during a transition. Sensors need a directory service account, ideally a group managed service account, with read access to the directory, and the right Windows audit policies so the needed events are recorded.

The certificate authority's health issue is a common one. Sensors depend on Windows auditing, and if the advanced audit policy for certificate services is not configured, the sensor runs but cannot see the events it needs. Defender for Identity reports such gaps as health issues in the portal. Nadia's rule is that every health issue is a gap in detection, and gets a ticket like any other.

Alerts during the penetration test

The testers started on October 28 from a laptop on the head office network, as if an attacker had compromised an ordinary user's device. Over two days Defender for Identity raised alerts that followed the classic progression of an attack on Active Directory. Ama mapped each one to its MITRE ATT&CK tactic, which is how the portal also categorizes them.

The test made two things clear to Ama. First, the alerts arrived in an order that tells a story: discovery, then credential access, then lateral movement, then an attempt to gain control of the whole domain. An analyst who sees early discovery alerts has time to act before the later stages. Second, the portal had correlated them, with the endpoint alerts from the testers' laptop, into a single incident, so the progression was visible on one page rather than spread across six notifications.

The suspected Kerberos SPN exposure alert matters because of what it implies. Any domain user can request a service ticket for an account that has a service principal name, and part of that ticket is encrypted with a key derived from the service account's password. An attacker who collects tickets can try to guess weak passwords offline, out of sight. The defense is not to detect it better but to remove the weakness: long, random passwords for service accounts, or better, group managed service accounts whose passwords the directory rotates automatically.

Investigating identities

Every user and device has an entity page that combines directory data, Defender for Identity activity, Entra ID data and endpoint data. The identity timeline lists sign-ins, directory changes, resource access and alerts. Tags show whether an account is marked sensitive, as members of privileged groups are by default, or as a honeytoken. The page also shows the lateral movement paths that lead to the account and any open alerts.

For the pass-the-ticket alert, Ama used the timeline of the test account that the testers had used and of the device where the ticket was reused. The timeline showed the account's normal sign-ins from one laptop, then the same ticket appearing from a server the account had never touched. That pattern, one identity apparently in two places with the same credentials, is the signature of the technique, and in a real incident would be grounds to treat the account as compromised.

The first two changes were made in November; the third needed a privileged access workstation for each of the three domain administrators, which Renata's team ordered for January 2027. Ama added each change to the incident's tasks so the testers could verify them in a retest planned for spring.

Response actions for identities

From a user's page or an incident, analysts can take identity actions. In on-premises Active Directory, through Defender for Identity, they can disable the user or force a password reset at next sign-in; these run through an action account, either the sensor's own identity or a configured account with the right directory permissions. In Microsoft Entra ID they can mark a user as compromised, which raises their risk and triggers any risk-based Conditional Access policies, require the user to sign in again, which revokes sessions, and suspend or disable the account. Automatic attack disruption, covered in lesson 11, can disable an account in Active Directory and in Entra ID without waiting for an analyst when it is highly confident an attack is under way.

Ama noticed a subtlety in the table. For a hybrid user, synchronized from Active Directory to Entra ID, disabling only the cloud account would be undone at the next synchronization if the on-premises account stayed enabled; disabling only the on-premises account would leave cloud sessions alive until they expired. A real response to a compromised hybrid account therefore touches both directories, which is one reason correlated XDR incidents and attack disruption matter.

service_accounts = [
    # name, years since password change, has SPN, is gMSA
    ("svc-rpt01", 9.0, True, False),
    ("svc-backup", 3.5, True, False),
    ("svc-print", 0.4, True, False),
    ("gmsa-sql01", 0.1, True, True),
    ("svc-scan", 6.2, False, False),
]
for name, age, spn, gmsa in service_accounts:
    if gmsa:
        risk = "low (password rotated by the directory)"
    elif spn and age > 1:
        risk = "HIGH: SPN with an old password, replace with a gMSA"
    elif spn:
        risk = "medium: SPN, recent password; plan a gMSA"
    else:
        risk = "medium: old password, no SPN; rotate"
    print(f"{name:<11} {age:>4.1f} y  {risk}")

svc-rpt01    9.0 y  HIGH: SPN with an old password, replace with a gMSA
svc-backup   3.5 y  HIGH: SPN with an old password, replace with a gMSA
svc-print    0.4 y  medium: SPN, recent password; plan a gMSA
gmsa-sql01   0.1 y  low (password rotated by the directory)
svc-scan     6.2 y  medium: old password, no SPN; rotate