Pragmatic approaches to MFA or alternatives?

[GeldHades27355]

Hey folks, apologies if this is (another) noob question.

We get that MFA isn't supported by M365DSC. Naturally, anything requiring human action to authenticate would be disruptive in any automation context.

That being said, we're really uncomfortable maintaining admin accounts with vast administrative privileges without MFA.

(yes, we could invest a few days or weeks for trial and error to figure our how to deal with it, but we're hoping for community help here).

1. From our understanding, the LCM needs to authenticate with the target M365 tenant each time its timer expires in order to check status. Is that correct? (this would even make one-time manual MFA impractical when initializing the service, as it would happen over and over again).

2. The User Guide says that we can use a Service Principal and a Certificate Thumbprint instead of credentials for ALL resources. This should bypass MFA restrictions for user credentials, correct? The reason we ask: The DevOps integration whitepaper still appears to use Global Admin credentials and stresses how important it is that this account must not have MFA. So we feel we're getting slightly conflicting recommendations. Which is true? (obviously, you need an admin account to create the app registration etc. but after the certificate is provided, use credentials shouldn't matter anymore, right?)

3. The User Guide mentions four examples of how to authenticate. Assuming our target tenants are green fields and we have global admin access on target tenants anyways, which authentication method would YOU, the community, recommend? We need something that'll work reliably across hundreds of tenants and months and years with minimal intervention. (we'll only check and remediate 1x per month)

If this is too much to ask/answer here - we're happy to pay for some advice, and share the outcome here.

Thanks!

[andikrueger]

M365DSC supports authentication with a service principal. This is the most versatile option in automation scenarios. Please make sure to secure your secrets and environments properly ( e.g. comparable to a domain controller).

1. LCM needs access to the certificate as soon as operations are triggered: verification of a configuration.

2. The whitepaper got published in November 22. By now, there were plenty updates in M365DSC. The support for SP improved a lot and there are only a few resources left that do not fully support SPs.

3. In such a multi tenant scenario with a multi tenant application would be the easiest option and needs to be verified if it will work across all services.

[adhodgson1]

In our case we use service principals secured by a certificate. We store the certificate in a Key Vault. The creation of the app and related infrastructure for the certificates is managed through Terraform. The other reason we use this approach is we can be granular with the perms we request (i.e, we don't use global admin but use the relevant API permissions).

[FabienTschanz]

@GeldHades27355 We are doing it pretty much the same way as @adhodgson1, but with Bicep instead of Terraform. For more granular authentication, we have different service principals for different workloads, so that one compromised service principal is not able to compromise the entire company (although it could still do a lot of damage).

[GeldHades27355]

Thanks for sharing.

In our case different service principals would easily escalate to hundreds of not thousands with a few hundred clients. And certificates... But yeah, makes sense.

So what do bicep and terraform add that wouldn't already work using vanilla M365DSC and Azure DevOps?

[FabienTschanz]

@GeldHades27355 Terraform and Bicep are tools to manage the state of your infrastructure, in my case that's the management of the service principals, certificates, Key Vault, Automation Account and more. Azure DevOps is the "pipeline" mechanism that executes the infrastructure management (in my company, we're using GitLab) and more.

The usage of infrastructure management tools like Terraform and / or Bicep is only necessary if you want a "configuration-as-code" approach, where you define in code how your environment is supposed to look like and the tools then apply that configuration. You're totally fine with running Azure DevOps with vanilla M365DSC. Don't sweat too much about it.