Initial build of AD DS tests.

[soulemike]

Description

Provides new functionality to enable Active Directory tests.

• ActiveDirectory is a new service available for Maester to connect to
• Caching of AD queries is provided through new function
• 10 initial new tests specific to Computer objects provided

Contribution Checklist

Before submitting this PR, please confirm you have completed the following:

• 📖 Read the guidelines for contributing to this repository.
• 🧪 Ensure the build and unit tests pass by running /powershell/tests/pester.ps1 on your local system.

 

Join us at the Maester repository discussions 💬 or Entra Discord 🧑‍💻 for more help and conversations!

[SamErde]

The 'ActiveDirectory' module is not needed in this array. An inline explanatory comment would be helpful: it is checking modules that rely on the MSAL to determine which one should be connected to first, which ensures that the newest (and backwards compatible) version of Microsoft.Identity.Client.dll is loaded to avoid version conflicts between the MS modules.

[soulemike]

Since the switch case is dependent on the array returned, does that work as intended?

[SamErde]

This is an exciting addition, @soulemike! I have reviewed the overall structure and will have to come back to review the individual tests soon.

One question that I wondered while reviewing is what the anticipated usage will look like as we potentially add more tests outside of the core M365 suite.

Would we recommend or expect users to run All and test on-premises, hybrid, and cloud systems all in one shot? I'm sure some will want that option! However, it may be unexpected for others. Have you brainstormed the pros and cons of any other potential approaches for test inclusion during execution?

For example, including potential future test suites:

Group tags by platform environment using core module

• AllCloud - all cloud services
• AllM365 - all Microsoft 365 services
• AllLocal - all self-hosted systems such as AD (I don't like 'local' because this could include servers hosted in Microsoft Azure IaaS or Amazon EC2.)
• All - but we just eliminated this tag 😂

Using this approach, Invoke-Maester with no tags might default to AllM365 (excluding LongRunning and Preview).

Group test suites using test provider modules

• Maester.ActiveDirectory - a module that provides AD tests
• Maester.Citrix - a module that provides Citrix tests
• Maester.PaloAlto - a module that provides Palo Alto tests
• Maester.GitHub - a module that provides GitHub organization tests
• Maester.Azure - a module that provides Azure tests

Use one core module and select tests by Platform

Test to execute could be referenced by their platform name in addition to the existing options. Examples:

• Invoke-Maester -Platform M365,ActiveDirectory -IncludeLongRunning -Tags Hybrid
• Invoke-Maester -Platform M365 -IncludeLongRunning -IncludePreview
• Invoke-Maester -Platform M365 -Tags MDO
• Invoke-Maester

Curious about your thoughts!

[soulemike]

Would we recommend or expect users to run All and test on-premises, hybrid, and cloud systems all in one shot? I'm sure some will want that option! However, it may be unexpected for others. Have you brainstormed the pros and cons of any other potential approaches for test inclusion during execution?

Using this approach, Invoke-Maester with no tags might default to AllM365 (excluding LongRunning and Preview).

I think leaving the default option as Graph is still the best. I do think adding a nuance to All is beneficial though, initially adding an AllCloud option was my thought. The intent would be that this could be handled in a single run though.

I had originally thought an integration with WireGuard would be really cool. It seems like most in the Discord would just prefer to run a self-hosted runner or a utility server though.

[tdcthosc]

This is an awesome addition and I'd love to chip in; at least with our approach. We should certainly support cloud based automations, as I expect many have done exactly that given that Maesters original target was M365.

I have also been keen on getting started with a module for Palo Alto, as I have many years of experience with Palo Alto NGFW, but I have been reluctant due to the connectivity question and how to approach this. Firewalls are (often) not exposed on management interfaces, so I also think local runners would be ideal in this scenario. The next question is how to relay that to the cloud automation. Happy to work with you guys on this 👍

There is also Palo Alto Panorama (often cloud hosted) and Palo Alto Cortex XDR (cloud hosted) with API integration, so we could attempt to draft a standard for cloud service (API with keys) and local services (self-hosted runners).

[SamErde]

It would be great to see a common architecture document or a framework for these scenarios so others can consistently build tests for infrastructure that requires other forms of access and authentication. I have minimal experience with local runners, but it does seem like a good approach.