Fix container gMSA creation by authorizing CCG Virtual Accounts

[winkingturtle-vmw]

• Read the Contributing document.

Summary

This commit consolidates and cleans up the previous fixes for TNZ-97051 and TNZ-97067.

Reasoning:

1. TNZ-97051 addressed a Local Privilege Escalation (LPE) by restricting COM+ activation to specific accounts, but TNZ-97067 incorrectly assumed that ccg.exe invokes the plugin strictly as NT AUTHORITY\SYSTEM.
2. In reality, CCG impersonates the dynamically generated CCG Virtual Account for the container (e.g., CCG Virtual Account Domain\CCG Account X with SID S-1-5-95-X).
3. Since dynamically generated virtual accounts cannot be added to static COM+ roles at install time, we must rely on a built-in group they inherit. All Container Virtual Accounts inherently possess the NT AUTHORITY\SERVICE (S-1-5-6) token.
4. Microsoft's standard implementation for Azure Key Vault gMSA plugins explicitly authorizes both NT AUTHORITY\SYSTEM and NT AUTHORITY\SERVICE.

Security Management:

• We ensure ApplicationAccessChecksEnabled is set to $true on the COM+ app so DCOM enforces these restrictions.
• We restrict activation exclusively to the "SYSTEM" role, which is populated ONLY with NT AUTHORITY\SYSTEM and NT AUTHORITY\SERVICE.
• This fully remediates the LPE vulnerability because standard unprivileged users are explicitly denied DCOM access, while still allowing the dynamically generated CCG Virtual Accounts to fetch credentials and successfully spin up containers.
• The unnecessary attempts to assign the unresolvable NT SERVICE\ccg to a "CCG" role have been removed.

Backward Compatibility

Breaking Change? No