When Adding a Permission Removed Nothing

Effective access on Windows is the union of everything granted to the user and to every group the user belongs to, filtered by explicit denies. Inheritance means a permission set at a parent flows to every child unless inheritance is blocked or the inherited entry is removed. Every student is a member of Domain Users, and Domain Users holds Modify at the Classes root with inheritance on. Adding Period5 Read at a child folder adds a permission; it removes nothing. Period 3 students therefore still hold inherited Modify and can write anywhere under Classes. The share-level Everyone Full Control makes matters worse, but it is not the binding constraint: when share and NTFS permissions differ, the more restrictive set wins, so fixing NTFS is the real fix. Concretely: remove Domain Users Modify at the root and grant Domain Users only traverse and read where genuinely needed; on each course folder disable inheritance by converting or removing inherited entries; then grant exactly the section group Modify and a staff group Full Control. Replace per-user entries with SIS-maintained group membership, enable access-based enumeration so students do not see folders they cannot open, and verify with the Effective Access tab before Monday.

Preserve first, contain second, investigate third, remediate last, which is the reverse of the intuitive order because irreversible steps destroy evidence. Do not delete the account: deletion breaks file ownership records tied to its security identifier and removes the object the logon events reference. Instead disable sign-in, force a password reset, and revoke active sessions so the second station is cut off; that stops ongoing harm without erasing history. Before the 20 MB Security log can overwrite itself, copy it off the server along with file timestamps and an ACL export taken with icacls, record who collected what and when, and hash the copies. Then enable object-access auditing and increase log size so the next incident is investigable. Only after that identify scope: which files were touched under that account, from which stations, in what order. The concurrent logon is strong evidence of credential sharing, but the shared labuser account on the whiteboard is the likelier root cause than a compromised individual, so address both. Finally notify administration and follow the acceptable-use process; student discipline belongs to administrators, not to the CS teacher.

Three transferable ideas, each anchored to an artifact from this incident. First, authentication versus authorization: the logon established who the account was, but nothing decided what that account should reach; the exported ACL is the teaching artifact. Second, least privilege and group-based administration: students can compute effective permissions by hand for a given user and folder, then test the prediction with the Effective Access tab, which is a cheap and memorable lab. Third, shared accounts and non-repudiation: because several people used one credential, the log cannot say who overwrote Marcus's file, which is exactly why accountability requires unique identity. Place this inside the networks and security unit rather than in an assembly lecture, and follow it with an incident-response tabletop in which teams receive the sanitized timeline and must order the containment steps, defending each choice. Add the operational habit that logging must be enabled before it is needed, since the absence of object-access events is why the overwrite can never be resolved and why the process lesson is as important as the permission fix.