- AxLogonClient.Command always builds a Windows path to powershell.exe
- The grant-script test is skipped outside Windows (needs Windows PowerShell)
- The DNS test looks up an absolute name, so a search domain can't resolve it
v1.5.0 was tagged but never released because these failed in CI.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The grant script changes SCM and WMI security on customer servers. Before, a re-run
replaced every ACE of the account on a WMI namespace (also a customer's Deny), -Remove
took the account out of groups and ACEs it had before, only the SCM SDDL was backed up
(and never used), Remote Management Users also opened PowerShell Remoting, and
-EnableFirewall narrowed Windows' built-in rules for every other tool and was never undone.
- Checks everything before changing anything: elevation, the account resolves (broad
groups refused), Deny ACEs stop the script, -EnableFirewall needs -AgentAddress.
- Backs up the original SDDLs (SCM, WMI namespaces, WinRM), group memberships and
firewall rules before the first change; records what it added in a state file in an
administrators-only folder; -Remove removes only that.
- SDDL handled with RawSecurityDescriptor (GetSD/SetSD, sc sdshow/sdset): exactly one
ACE added in canonical order, verified before writing and after; aliases (NS) work.
- No Remote Management Users: -WinRM adds GENERIC_READ (no Execute) to WinRM's RootSDDL;
DCOM is the default.
- Firewall: its own "SQLInsight Agent: ..." rules only from the agent's address,
removed again with -Remove; Windows' rules untouched.
- -WhatIf, groups by SID, Danish messages, PowerShell 2.0 syntax.
- ServerGrantScript.For does not fill in an account that could end the PowerShell
string (typographic quotes, control characters); tests run the SDDL logic in
Windows PowerShell against real default SDDLs.
- docs/windows-servere.md: rights, safety net, firewall.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
