@Roop_s610
Hi, Rupert.
Yes, there are multiple ways you can achieve this.
Taking a broad view of things, you can use two different forms of security principal:
- User account;
- Service principal.
User account
I only outline the user account approach because it's technically possible and therefore needs to be spoken to, however, you should never take this pathway as it's fraught with many potential causes for failure (such as MFA policies and campaigns, some of which can be Microsoft-initiated meaning you may not even be aware).
Another important reason is it's generally less secure for multiple reasons. One is that you typically need to exclude the account from mechanics such as conditional access policies. Another is that people can log on with it, introducing many other user-facing attack vectors.
Service principal
If you're not already familiar with service principals, then conceptually, think of them as accounts for applications and automation processes, not for users. Users actually can't log on with them
Using service principals rather than user accounts carries a number of benefits over user accounts but if we distil those down to just one, I'd choose continuity (yes, even over security - as compelling as security is).
If we stay focused on service principals for a moment, how the service principal authenticates can be broken down into two common forms:
- Client secret;
- Certificate-based.
Client secret
Since I'm going to include reference articles that contain greater information below, I won't go into too much depth. All I will say for now is that client secrets are becoming less relevant as certificate-based authentication becomes more popular.
Some would argue that using client secrets is easier than certificate-based authentication, however, that frequently does come at the expense of being less secure (particular where the secret features within the script itself - which is a massive no-no).
Certificate-based
This is the final element I'll discuss as this is the direction many frequently-used Microsoft PowerShell modules have been heading over the past two-ish years now, meaning this is something you will likely have to contend with eventually.
Again, there's a lot of documentation on how to use this pathway out there, so I won't dwell on it, but essentially, once you've created your service principal, you then attach a certificate to it in Azure. From there, you then store the certificate (with private key) somewhere where your script can read it and that's how your script then authenticates to Graph.
References
Here's some articles that discuss certificate-based authentication to Graph, which is what you want to leverage for your script, at which point you can then schedule that script to run using anything from a scheduled task on an on-premise server, a runbook or even in Logic Apps/Functions, etc. It's a very flexible model.
One final note in parting is that you do not need to use a publicly-issued certificate for certificate-based authentication. The certificate can be issued by an internal certificate authority (preferred) or even self-signed (not preferred as it's not as secure due to cipher limitations, etc.)
Cheers,
Lain
