Microsoft
MicrosoftA couple of issues I've noted from a quick play with the module (v1.0.0 as retrieved from the PowerShell Gallery):
1. The HelpInfoUri specified in the module manifest is broken: https://go.microsoft.com/fwlink/?linkid=2248308
2. The FunctionsToExport array in the module manifest uses wildcards for some entries (e.g. "*-MDIConfiguration"). This won't work, and so breaks using those commands that match the wildcard if the module hasn't been explicitly imported. The commands should all be listed explicitly in the array instead of using wildcards.
3. The Test-MDISensorApiConnection command doesn't work on Server Core as it uses Invoke-WebRequest under the hood, which defaults to using the Internet Explorer engine. This can be resolved by calling Invoke-WebRequest with the -UseBasicParsing parameter, which worked for me when I patched the module. I haven't verified if this usage is compatible work with all possible parameters and values which may be supplied to Invoke-WebRequest (i.e. maybe some do require the Internet Explorer engine).
4. Calling Set-MDIConfiguration with -Mode Domain and -WhatIf results in multiple failures due to the function attempting to access properties of GPOs that were not created from earlier in execution due to running in WhatIf mode.
5. Ideally the module wouldn't depend on the ActiveDirectory and GroupPolicy modules for the case where it's running on an AD CS server. The best-practice is that an AD CS server not be installed on a server with other roles due to their sensitivity, in which case they probably won't have those PowerShell modules present.
6. The GPO preference setting for the Auditing for CAs GPO makes an assumption about the CA name. It configures the AuditFilter setting name under the HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\%DomainName%-%ComputerName%-CA key, which from memory is consistent with the default name during CA configuration, but it can be changed (and often is). This is the case even when running the Set-MDIConfiguration command to create the GPO from an AD CS server, where the actual CA name can be trivially retrieved. The best approach is probably to enumerate the certificationAuthority objects under CN=Certification Authorities, CN=Public Key Services, CN=Services, CN=Configuration,DC=<domain>, and create a preference item for each CA which does not conform to the above default entry. In addition, each preference item should be configured to only apply if the key already exists.
7. The AuditFilter setting in the Auditing for CAs GPO is always set to the value 127. That's not wrong, but it does enable the Start and stop Active Directory Certificate Services audit event, which can have a significant performance impact on service startup (and shutdown?) on large AD CS databases. It's not required as far as I'm aware for the correct functioning of the AD CS sensor.
It'd be really great if the module could be published on GitHub (it doesn't appear to be currently?) so that fixes and improvements can be submitted. If it were, I'd submit pull requests for some of the above items!
