Get-Acl -Audit reads the SACL together with the other sections. On a domain
member (Windows Server 2019, 2022, and 2025 of the operating-system matrix)
that read reports the SACL of an item without audit entries as protected from
inheritance, where the read of the SACL alone and Get-NTFSInheritance report
it as not protected (FileSystemSecurity2 documents the same difference).
The test 'Disable-NTFSAuditInheritance -SecurityDescriptor should take two
piped descriptors ...' asserted the on-disk flag of a fresh file with
Get-Acl -Audit, and failed in all six elevated configurations of the three
file servers. Diagnostic runs on 2019 and 2025 show both reads side by side.
Four more assertions read the flag of an item that ends without audit entries
and expect "protected"; there they could not tell a written flag from none.
The five assertions now read the SACL alone through .NET, as the module does.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: AI Assistant <ai@example.com>
Close the TestNeeded gaps of judged-inheritance.csv for the inheritance,
owner, and security-descriptor cmdlets (Disable/Enable-NTFSAccessInheritance,
Disable/Enable-NTFSAuditInheritance, Get/Set-NTFSInheritance, Get/Set-NTFSOwner,
Get-NTFSSecurityDescriptor) in one new file, Tests\ParameterSets.Inheritance.Tests.ps1.
20 new It blocks (48 data rows) assert, in the matrix's priority order:
- State: independent Get-Acl/Get-Acl -Audit oracles for access and audit
inheritance transitions, the -RemoveInherited/-RemoveExplicit switches
with a -SecurityDescriptor, Set-NTFSInheritance setting both flags in one
call, and Set-NTFSOwner leaving the Access entries and group unchanged.
- Error: ErrorId/category/target triples for a denied write, a missing
path, a denied read, and a refused owner, each continuing to the next
item; RestoreOwnerError for the three Path cmdlets that protect or set
access inheritance, which had none before.
- Pipeline: every -Path and -SecurityDescriptor set that no existing test
piped, including the direct, named Get-NTFSOwner -SecurityDescriptor
call the scan could not classify, and the documented Set-NTFSInheritance
round trip.
No existing test file, helper, or production source changed. Validated
test-first (each new assertion checked for a real, failable precondition)
and proven with 10 one-statement C# mutations in a separate, discarded
worktree: 9 detected, 1 honestly undetected (ValueFromPipelineByPropertyName
alone still binds Get-ChildItem2 output through its native FullName
property, so removing ValueFromPipeline from -Path is invisible to an
object-only pipeline test). All four configurations (elevated/basic user x
Windows PowerShell 5.1/PowerShell 7) pass with zero failures; audit- and
Restore-privilege-dependent rows skip in basic user and run elevated.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: AI Assistant <ai@example.com>