Most users of Azure know that you can use AzureRM PowerShell with a service principal. The process of creating one is well documented and fairly straightforward.

The same is possible for AzureAD PowerShell, however the process is not quite as straightforward.

There are a couple of reasons for this.

The granularity of RBAC in the subscription model makes it easy to assign a service principal object a known set of permissions at a resource level.

At the Azure AD level – however – you need to work with directory roles. These give much broader access to the directory than the granular RBAC management at subscription level.

Make sure you review the relevant documentation and understand the rights you are granting to a service principal before doing so.

You should also bear in mind the following:

  • Any service principal can grant the rights it already has to another service principal, but it CANNOT grant any permissions it does not have without manual user intervention
  • You can create service principals with AzureRM and AzureAD PowerShell. The process looks different from the client (PowerShell) perspective but achieves the same thing

With all of that in mind, you should then review the relevant documentation around logging into the AzureAD module with a service principal.

As you can see – the recommended way of authenticating with Azure AD in this scenario is through certificate based authentication. This means that you can tightly control which machines (only those that actually have the certificate) can use the service principal.

If you try and use a password/key/credential instead, then PowerShell will tell you that the combination is not supported.

You can still use the REST API to generate a token with a client id/key pair anyway, but then you will be unable to use the AzureAD cmdlets.