The four ConvertTo-SecureString -AsPlainText calls of Probe-EffectiveAccess.ps1
and Run-MatrixLocalSuite.ps1 get a SuppressMessageAttribute with a
justification, as the controller already has for the same case: the lab
installation password comes from the AutomatedLab lab definition and the
passwords of the probe users are random and exist only in memory.
The header of Test-MatrixCleanup.ps1 says that Repair matches the prefixes of
the kit in the whole domain and on the whole machine, which the security review
pointed out, and that an unresolved S-1-5-21-* member of Performance Log Users
can be a real principal of a trust that is down.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: AI Assistant <ai@example.com>
The review of the matrix kit found no Blocker or Major issue and these
Minor ones, all fixed here:
- Add-OsMatrixMachine.ps1 assigned the path of the AutomatedLab disk
deployment lock before it checked that the lock exists, so a refusal because
another deployment held the lock made the finally block delete that foreign
lock. The path is kept until this script has created the lock.
- Repair-OsMatrixBoot.ps1 tested the switches of the machine with an array
-ne, which is false for a machine without an adapter, so the guard that is
meant to refuse a machine outside the lab let it through and the script
turned it off. The guard counts the switches now.
- Deploy-OsMatrixLab.ps1 took the installation and domain administrator
password of the lab from Get-Random, which isn't a cryptographic generator.
It uses RandomNumberGenerator without a remainder bias, as the controller
does.
- Run-MatrixLocalSuite.ps1 removed its scheduled tasks, which store the
password of the account that runs them, only after a successful poll. The
finally block of the machine removes the tasks of the run now.
- Probe-EffectiveAccess.ps1 cleaned up the domain controller before the machine
without a try block, so a failure there skipped the cleanup of the machine.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: AI Assistant <ai@example.com>
Probe-EffectiveAccess.ps1 runs Invoke-EffectiveAccessProbe.ps1 on one machine
of the operating-system matrix under up to four tokens and copies the output
back: the lab account in a scheduled task at the highest run level, the same
account with the token of a basic user (SAFER level Normal User), a local
standard user, and a standard user of the domain. The standard users are
created for the run with a random password that exists only in memory, get
the batch logon right through Performance Log Users, and are removed again
with their profiles and group memberships; the names carry a time stamp,
because Windows keeps the SID of a deleted account for its name for a while.
For the account of the token and for well-known SIDs and the accounts of the
domain, the probe asks the cmdlet for the default server name, localhost, an
empty name, the names of this computer, and other computers, and writes the
result, the warnings, and the native error with the failing method. It showed
that the remote interface of the authorization manager of a computer in a
domain refuses every user who isn't an administrator, which is the defect
that the previous commit fixes.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: AI Assistant <ai@example.com>
Raimund Andree