--- title: 'Group Policies and Authorization Management' source: 'https://academia.sh/en/courses/identity-and-cryptography/group-policies-and-authorization-management' course: 'Identity, Access and Cryptography' language: en updated: '2026-09-26T03:02:53+00:00' license: 'CC BY-SA 4.0' objectives: - 'Measures policy reaching machines round by round as cumulative coverage' - 'Derives the number and source of machines that never receive the policy' - 'Calculates the paths opened by local overrides in terms of settings and machines' --- # Group Policies and Authorization Management Measuring central enforcement in terms of propagation: 319 of 325 machines being set to pull policy but only 295 of them being reached within the 24-hour window, first-round coverage staying at 51.4%, 30 machines never receiving the policy at all, and local overrides on 67 machines dropping 5 of 12 settings to open 335 paths. The previous lesson measured sign-in itself and counted the four paths no factor closes. What a user can do once sign-in is complete, though, is determined by a separate mechanism: the organization writes, from a single place, which setting applies on thousands of machines, and the machines pull it at regular intervals. This mechanism is called **group policy**. Comparing authorization models — role-based, attribute-based, resource-based — was measured in the **Authentication and Authorization** and **Cloud Governance, Security, and Cost** courses; it is not repeated here. What this lesson measures is a single question: the gap between what is written and what is applied. How many machines does the policy reach in how many rounds, how many items never reach it, and how many paths does local override open. These three numbers give how much the central management actually governs, and all three are smaller than the number the central console shows. ## Writing versus Applying **EI17:** central policy is not a write operation but a **propagation process**; it takes effect not the moment it is written but the moment a machine pulls it on its next round. **EI18:** a machine left outside propagation never receives the policy at all, and no error log reports this — centrally, the policy shows as "applied." **EI19:** a setting being overridable locally reopens, per machine, the path that setting closes; central enforcement's coverage is measured by the number of settings that cannot be overridden. These three claims turn the course's three columns into this mechanism. The trust root is the policy repository's integrity and the distribution channel; the chain is the items from the policy reaching a machine to it being applied; the break is how many machines **silently** receive the wrong setting if the root changes. ## Three Hundred Twenty-Five Machines The inventory and propagation below are a **model**: the machines of a fictional regional measurement network company. There is no real organization, no real machine, and no real policy. Randomness is generated with our own generator and the seed is visible; the output is the same from run to run. ```js // policy/rollout.mjs — the propagation of central policy to machines (model): the machine // inventory, renewal round, and online rate of a fictional regional measurement network company. // There is no real organization, real machine, or real policy. // EI17: central policy is not a write operation but a propagation process; it takes effect not // the moment it is written but the moment a machine pulls it on its next round. EI18: a machine // left outside propagation never receives the policy at all, and no error log reports this. // Columns: count = number of machines; managed = set to pull policy; p = the chance of being // online in one round (percent); closed = never turns on during the window; localAdmin = // number of machines with a local administrator account. export const CLASS = ` branch-workstation 96 yes 82 3 11 field-laptop 140 yes 24 17 38 warehouse-terminal 18 yes 61 1 4 server 21 yes 95 0 6 meter-collector 44 yes 88 2 2 legacy-console 6 no 0 6 6` .trim().split("\n").map((r) => { const p = r.trim().split(/\s+/); return { name: p[0], count: +p[1], managed: p[2] === "yes", p: +p[3], closed: +p[4], localAdmin: +p[5] }; }); // EI19: a setting being overridable locally reopens, per machine, the path that setting closes; // central enforcement's coverage is measured by the number of settings that cannot be overridden. // The policy carries 12 settings; each setting closes one path. The "local" column is whether // the setting can be overridden locally by a local administrator on the machine. export const SETTING = ` screen-lock-timeout local local-admin-membership central unsigned-script-block local legacy-protocol-disable central log-forwarding local disk-encryption-required central software-source-restriction central remote-desktop-disabled local password-length central auto-mount-disabled local firewall-enabled central cached-logon-timeout central` .trim().split("\n").map((r) => { const p = r.trim().split(/\s{2,}/); return { name: p[0], local: p[1] === "local" }; }); export const ROUND = 16; // number of 90-minute renewal rounds in a 24-hour window export const SEED = 20250131; ``` ```js // policy/tally.mjs — how many machines does the policy reach in how many rounds, how many items // never reach it, and how many paths does a local override open. import { CLASS, SETTING, ROUND, SEED } from "./rollout.mjs"; const print = (g, ...s) => console.log(s.map((v, i) => (g[i] < 0 ? String(v).padEnd(-g[i]) : String(v).padStart(g[i]))).join("")); const sum = (f, s = CLASS) => s.reduce((a, x) => a + f(x), 0); // Our own generator; the seed is visible, it gives the same sequence from run to run. const gen = (seed) => { let s = seed >>> 0; return () => (s = (s * 1103515245 + 12345) >>> 0) / 4294967296; }; const machines = sum((s) => s.count); const managed = sum((s) => (s.managed ? s.count : 0)); console.log(`${machines} machines, ${managed} managed, ${machines - managed} unmanaged; ` + `${SETTING.length} settings, ${ROUND} rounds, seed ${SEED}`); // The round each machine first receives the policy on; closed machines never receive it. const rnd = gen(SEED); const received = []; for (const s of CLASS) { for (let i = 0; i < s.count; i++) { let round = 0; if (s.managed && i >= s.closed) { for (let t = 1; t <= ROUND; t++) { if (rnd() * 100 < s.p) { round = t; break; } } } else { for (let t = 1; t <= ROUND; t++) rnd(); } received.push({ cls: s.name, round }); } } const A = [-20, 8, 10, 10, 12, 10]; console.log("\n1. coverage by class (at the end of the 24-hour window)"); print(A, "class", "count", "managed", "reached", "not reached", "avg round"); for (const s of CLASS) { const g = received.filter((a) => a.cls === s.name); const u = g.filter((a) => a.round > 0); print(A, s.name, s.count, s.managed ? s.count : 0, u.length, g.length - u.length, u.length ? (u.reduce((a, x) => a + x.round, 0) / u.length).toFixed(1) : "-"); } const reached = received.filter((a) => a.round > 0).length; print(A, "total", machines, managed, reached, machines - reached, "-"); const B = [-6, 10, 10, 11, 15]; console.log("\n2. round-by-round cumulative coverage"); print(B, "round", "reached", "percent", "remaining", "newly reached"); let prev = 0; for (const t of [1, 2, 3, 4, 6, 8, 12, 16]) { const u = received.filter((a) => a.round > 0 && a.round <= t).length; print(B, t, u, `${(100 * u / machines).toFixed(1)}%`, machines - u, u - prev); prev = u; } const C = [-20, 9, 13, 14, 18]; console.log("\n3. how many paths a local override opens"); const localSetting = SETTING.filter((a) => a.local).length; print(C, "class", "settings", "local admin", "opened paths", "closed remaining"); for (const s of CLASS) { const y = s.managed ? s.localAdmin : s.count; print(C, s.name, SETTING.length, y, y * localSetting, s.count * SETTING.length - y * localSetting); } const yy = sum((s) => (s.managed ? s.localAdmin : s.count)); console.log(`${localSetting} settings can be overridden locally, ` + `${SETTING.length - localSetting} cannot; total opened paths ${yy * localSetting}`); const D = [-28, 8, 8, 24]; console.log("\n4. the third column of enforcement"); const share = (n) => `${(100 * n / machines).toFixed(1)}%`; print(D, "item", "count", "share", "source"); for (const s of [ ["machines never reached", machines - reached, share(machines - reached), "closed and unmanaged"], ["reached in 16 rounds", reached, share(reached), "online"], ["machines with local admin", yy, share(yy), "inventory"], ["opened paths", yy * localSetting, "-", `${localSetting} local settings`], ["non-overridable settings", SETTING.length - localSetting, "-", "central"], ]) print(D, ...s); ``` ``` 325 machines, 319 managed, 6 unmanaged; 12 settings, 16 rounds, seed 20250131 1. coverage by class (at the end of the 24-hour window) class count managed reached not reached avg round branch-workstation 96 96 93 3 1.3 field-laptop 140 140 122 18 3.9 warehouse-terminal 18 18 17 1 2.0 server 21 21 21 0 1.0 meter-collector 44 44 42 2 1.1 legacy-console 6 0 0 6 - total 325 319 295 30 - 2. round-by-round cumulative coverage round reached percent remaining newly reached 1 167 51.4% 158 167 2 221 68.0% 104 54 3 241 74.2% 84 20 4 258 79.4% 67 17 6 270 83.1% 55 12 8 282 86.8% 43 12 12 291 89.5% 34 9 16 295 90.8% 30 4 3. how many paths a local override opens class settings local admin opened paths closed remaining branch-workstation 12 11 55 1097 field-laptop 12 38 190 1490 warehouse-terminal 12 4 20 196 server 12 6 30 222 meter-collector 12 2 10 518 legacy-console 12 6 30 42 5 settings can be overridden locally, 7 cannot; total opened paths 335 4. the third column of enforcement item count share source machines never reached 30 9.2% closed and unmanaged reached in 16 rounds 295 90.8% online machines with local admin 67 20.6% inventory opened paths 335 - 5 local settings non-overridable settings 7 - central ``` The numbers are of the **measurement** class; their inputs are EI17–EI19 and the machine inventory. ## Coverage Does Not Happen All at Once The second table turns EI17 into a number. In the first round after the policy is written, it reaches 167 of 325 machines; coverage is **51.4%**. It rises to 221 in the second round and to 258 in the fourth. By the end of sixteen rounds, 295 machines have received the policy and 30 machines still have not. The shape of the curve determines the decision. The first two rounds produce 221 of total coverage — close to three quarters of the reachable 295 — while the remaining fourteen rounds add only 74 machines. For a team publishing a security setting, these two numbers carry separate meanings: in an urgent shutdown decision, the first three hours bring most of the coverage, but **getting the last ten percent takes longer than a day**, and that ten percent holds exactly the items that are risky. The first table gives the distribution. Servers complete in the first round, with an average round count of 1.0. Branch workstations average 1.3, meter collectors 1.1. Field laptops are a class apart: an average of 3.9 rounds, and 18 machines never receive it at all. What determines propagation speed is not the policy repository or the network but the machine's **online rate**; no improvement made centrally changes this number. ## The Thirty Machines That Never Get It The fourth table counts EI18. Thirty machines — 9.2% of the inventory — never receive the policy at all, and this number comes from two separate sources. Twenty-four are machines that never turn on during the window: field laptops sitting powered off, terminals waiting in the warehouse. Six are unmanaged legacy consoles that are not set to pull policy at all. The difference between the two sources determines the shape of the fix. Machines that are off receive the policy once they are turned on; their problem is timing, and it is fixed once the window is extended. The six unmanaged consoles, on the other hand, never receive it in any window; their problem is in the inventory, and it can only be closed by hand. On the central console, both look the same — the "policy applied" line counts the 319 managed machines, not the 295 that were reached. **The coverage rate is the number of verified machines, not the number of applied policies.** A report that does not make this distinction writes 100% after the first round; the measured number is 51.4%. The 30 missing machines keep open all twelve of the paths the policy assumes it has closed. ## Local Override The third table counts EI19. Five of the twelve settings the policy carries can be overridden locally on a machine, seven cannot. The number of machines in the inventory with a local administrator account is 67, and each of them can drop five settings: a total of **335 paths** are reopened. The distribution is not even. 38 field laptops have a local administrator and open 190 paths on their own; 11 branch workstations open 55 paths. Meter collectors have only two such machines, opening 10 paths. The same policy, with the same twelve settings, produces a result that varies nineteenfold from class to class. The two tables multiply each other. Field laptops are both the slowest-reached class — average 3.9 rounds, 18 machines that never receive it — and the class most open to local override. Where central enforcement is weakest is the most crowded and most mobile part of the inventory. **The propagation rate and the override rate are not independent; both come from the same property — the machine being far from the center.** The seven central settings are the other side of this table. Even on a machine with a local administrator, these seven settings do not drop; the number of remaining closed paths is totaled in a column ranging from 1490 to 42. Central enforcement's real coverage is not the number of settings distributed but **the number of settings that cannot be overridden locally**, and in this model that is seven of twelve. ## The Root Itself: The Policy Repository What has been measured across the two tables was the policy **reaching**. The course's first column, though, asks a different question: what proves that what reaches it is correct. A machine applies the set of settings it pulls as-is; it does not check who wrote the content centrally. The trust root is the policy repository's integrity and the verification of the distribution channel, and both are outside this mechanism — the first rests on the directory measured in the first lesson, the second on the ticket flow measured in the second lesson. What happens when the root breaks is quieter than in the other lessons. If a setting is changed centrally, 295 machines pick it up within sixteen rounds and apply the wrong setting **while working correctly**. No machine errors, no user notices, and the central console stays green. This is the configuration-side counterpart of the forged-ticket pattern seen in the second lesson: because the mechanism operates flawlessly, the result is treated as valid. The renewal bill reads the same way. Rolling back a changed setting means a new propagation round; 295 machines spread across sixteen rounds again, and 30 machines go to manual handling. How many hours the wrong setting stayed open is calculated with the same propagation curve as before, and **the speed of rolling back is not different from the speed of enforcing**. The strength of central enforcement and the price paid when the root breaks are read off the same curve; speeding up the curve speeds up both outcomes at once, and slowing it down slows both down at once. ## Summary - Central policy is a propagation process, not a write operation: it reaches 167 of 325 machines in the first round, and coverage starts at 51.4%. - Most of the coverage forms in the first two rounds; the remaining fourteen rounds add only 74 machines, and getting the last ten percent takes longer than a day. - 30 machines never receive the policy: 24 because they never turn on during the window, 6 because they are unmanaged; on the central console, both look the same. - The item that determines propagation speed is not the network or the repository but the machine's online rate; the average is 3.9 rounds on field laptops and 1.0 round on servers. - 5 of 12 settings can be overridden locally, and 67 machines with a local administrator open 335 paths; enforcement's real coverage is the 7 settings that cannot be overridden. ## Next Step This lesson counted a setting being locally droppable on 67 machines. Dropping it requires being a local administrator on that machine; the real question is **how** an ordinary account obtains that privilege. On an enterprise network, this is not a single event but a set of paths: an account reaching another account's data at its own level, or rising above its own level. The next lesson treats horizontal and vertical privilege escalation as path counting: how many distinct escalation paths exist, which control closes how many of them, and which ones are not closed by any control at all.