# Worked solution — Prove the gate, then restore its owned setting These are the expected reasoning and command sequence. See VALIDATION.md for separate observed Azure results. A pending release has no accepted live result simply because this solution describes it. ## 1. Establish the exact context and baseline Create a private StatePath outside the package and Git, explicitly select the subscription and complete Preflight. Review/apply Foundation, Bootstrap, review/apply Identity, Configure and Validate as shown in README.md. The two-phase plan keeps discovered domain identifiers in reviewed Terraform configuration. Use fresh per-user sessions for the protected `workshop-` namespace on both accounts. Reader reads but cannot create; Writer creates, reads, verifies and deletes a new uniquely named file; Outsider cannot access protected content. LabAdmin owns the protected namespace. Normal storage hostnames resolve privately. Service tickets target the exact CIFS names and use AES256. Sole AES-256-GCM settings on client/server plus fresh observed encrypted SMB3.1.1 sessions establish transport protection; record this evidence rather than a direct cipher getter. No storage-key mount or management-agent identity counts as a user test. ## 2. Run each complete fault/recovery cycle Run the following whole sequence for each scenario, in order. Do not skip the fault validation or combine the two repair windows into a single observation. ~~~powershell foreach ($scenario in @('Kerberos', 'ShareGate', 'Ntfs')) { ./Invoke-AzureFilesAdDsWorkshop.ps1 -Stage Validate -StatePath $state -Execute ./Invoke-AzureFilesAdDsWorkshop.ps1 -Stage Fault -Scenario $scenario -StatePath $state -Execute ./Invoke-AzureFilesAdDsWorkshop.ps1 -Stage Validate -Scenario $scenario -StatePath $state -Execute ./Invoke-AzureFilesAdDsWorkshop.ps1 -Stage Repair -Scenario $scenario -StatePath $state -Execute ./Invoke-AzureFilesAdDsWorkshop.ps1 -Stage Validate -Scenario $scenario -StatePath $state -Execute ./Invoke-AzureFilesAdDsWorkshop.ps1 -Stage Repair -Scenario $scenario -StatePath $state -Execute ./Invoke-AzureFilesAdDsWorkshop.ps1 -Stage Validate -Scenario $scenario -StatePath $state -Execute } ~~~ ### Kerberos diagnosis The missing exact exercise CIFS principal prevents a fresh exercise service ticket/session. Verify that no HOST mapping fallback applies. DNS/TCP and independent control access stay healthy, separating authentication from reachability. Capture the actual diagnostic and UTC window. Restore the exact SPN to the recorded storage-representing AD object, without adding duplicates or changing keys/ACLs. Fresh AES256 ticket and operation success establish recovery. A stale connection success proves nothing about a new ticket. For the calibrated Windows Server 2025 image, the local `klist` failure was `0xc000018b` (signed exit `-1073741429`) with GetTicket substatus `0x6fb` and the SAM computer-account/trust-relationship message. Retain these actual local fields. The separate DC evidence is Security event **4769**, exact exercise CIFS service, Status **`0x7`** (`KDC_ERR_S_PRINCIPAL_UNKNOWN`), and failure encryption type `0xffffffff`. Healthy control tickets and the physical missing-SPN readback distinguish this controlled service lookup failure from an unrelated machine-trust problem. Unknown-SPN failure events require `KdcExtraLogLevel` bit `0x01` directly under `HKLM\SYSTEM\CurrentControlSet\Services\Kdc`. The helper preserves existing bits; the documented default `2` becomes `3` on a new disposable DC. Verify its actual readback and the fault-time event rather than treating the logging setting as an event. See Microsoft's [4769 audit reference](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4769) and [KDC registry reference](https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/kerberos-protocol-registry-kdc-configuration-keys#registry-entries-and-values-under-the-kdc-key). Block 8 deletes this lab DC and its setting while the private before/after journal remains available. Closing native stdin makes the failed `net use` credential prompt finish at EOF. Its observed native exit `2` / system error `1223` is **client cancellation**; use the ticket and DC observations to diagnose Kerberos. A mount timeout (`1460` or `timedOut=true`) never passes the intended-failure gate. After repair, require a fresh successful ticket/mount and the full expected file operations, then repeat repair and validate a second fresh window. Each completed validation needs its own observed result. ### ShareGate diagnosis Writer's ticket and read work, and its protected folder still grants Modify. The exercise account's default Reader permission is therefore the limiting gate. This setting applies to every share in that account; a sibling folder cannot isolate it. The independent account's write success supplies the useful control. Restore the recorded Elevated Contributor default, allow bounded propagation and retest fresh sessions. Reader must stay read-only through NTFS, and Outsider must stay denied inside the protected namespace. ### Ntfs diagnosis The share default, ticket and transport are healthy. Writer reads Exercise but new creation fails there; sibling Control and independent account creation work. The protected Exercise folder has Writer RX instead of Modify. Restore only that owned ACE while preserving LabAdmin ownership, Reader, inheritance protection and other entries. Test a new unique filename rather than reusing an old Writer-owned file. Compare the resulting ACL/owner with the recorded intended baseline. ## 3. Corroborate the actual observations Use the query pack to find real StorageFileLogs in the exact test windows. Preserve both raw `StatusCode` and `SmbStatusCode`, `StatusText`, session/tree/file identifiers, actor and synthetic filename. For the exact Writer ShareGate file in capture 16, control SMB/Kerberos CREATE/READ/WRITE rows (majors `5/8/9`) had `StatusCode='0'` and `SmbStatusCode='0X0'`. The exercise CREATE row (major `5`) had the string `StatusCode='-1073741790'`, with empty `SmbStatusCode` and `StatusText`. Signed 32-bit interpretation yields the **derived NTSTATUS** `0xC0000022` / `STATUS_ACCESS_DENIED`, as defined by [Microsoft MS-ERREF](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-erref/596a1078-e883-4972-9bbc-49e60bebca55). Keep that derived interpretation separate and preserve the empty raw fields; this observed SMB value is not an HTTP status. The unchanged `-Stage Validate -Execute -CollectLogs` command uses core `az rest` against the official workspace Logs Query API, avoiding the optional CLI extension. See the [official query format](https://learn.microsoft.com/en-us/azure/azure-monitor/logs/api/request-format). A failure at the KDC can precede storage arrival and needs the actual client/KDC evidence. Record missing or delayed observations honestly and keep ingestion polls bounded. ## 4. Restore, clean and export ~~~powershell ./Invoke-AzureFilesAdDsWorkshop.ps1 -Stage Validate -StatePath $state -Execute -CollectLogs ./Invoke-AzureFilesAdDsWorkshop.ps1 -Stage Plan -Phase Identity -StatePath $state # Require zero unexpected changes in the restored configuration. ./Invoke-AzureFilesAdDsWorkshop.ps1 -Stage Cleanup -StatePath $state # Read the exact saved destroy plan and ownership summary. ./Invoke-AzureFilesAdDsWorkshop.ps1 -Stage Cleanup -StatePath $state -Execute -ReviewedPlan ./Invoke-AzureFilesAdDsWorkshop.ps1 -Stage Cleanup -StatePath $state -Execute -ReviewedPlan ./Invoke-AzureFilesAdDsWorkshop.ps1 -Stage Export -StatePath $state ~~~ Final healthy matrix, restored identity/defaults/ACLs and zero unexpected drift precede cleanup. Require exact resource absence twice and a zero-missing comparison against the private pre-existing-resource baseline. Preserve the private ledger while reconciling residuals. Review the sanitized export and twenty genuine capture records before publication; raw logs, identifiers, secrets, state/plans and original captures stay private.