Authentication Options for Automated Azure PowerShell Scripts, Part 3: Additional Considerations

Part 1 of this blog series discusses why you should use app registrations and certificates for your automated PowerShell scripts. Part 2 details how to configure them. In this final blog, we discuss some other important considerations when taking this approach to automation.

Service Principal Sign-ins

Most Microsoft Azure administrators are familiar with going to the sign-in tab under Entra ID when troubleshooting issues with users signing in or when just monitoring activity. The older sign-ins report shows only user sign-ins—but signing in as an app registration uses the associated service principal, which doesn’t show up in the user sign-in report. However, this data is available in a newer version of the sign-in report that’s currently in preview.

If your sign-in report looks like the one in Figure 1, then you need to switch to the preview by clicking the “Try out our new sign-ins preview” link.

The preview has a separate tab for service principal sign-ins, as Figure 2 shows.

Selecting “Service principal sign-ins” will allow you to view signs-ins of that type in your tenant.

The information available is limited when compared to user account sign-ins, but you can see when a service principal is authenticating and from which IP address. This can be useful in investigating unauthorized or unexpected usage, or in just taking a census on which service principals are in use.

The sign-in data isn’t currently available via Microsoft Graph but is available in Azure Monitor.

Microsoft.Graph Module

Microsoft is constantly adding more methods to the Graph API to support automation of Azure operations. The Microsoft.Graph PowerShell module is a simple wrapper around those methods—but given the rate at which methods are added to the Graph API, you may want to use a method that doesn’t yet have a corresponding Microsoft.Graph cmdlet.

In such situations, you can still take advantage of the authentication services bundled in Microsoft.Graph and use the Invoke-MgGraphRequest cmdlet to access the underlying Graph API method. This is very similar to using Invoke-RestMethod to directly access the API, but Microsoft.Graph handles building the authentication token and all the data paging semantics, so it’s a lot simpler to implement. This is illustrated in the following code and in Figure 3.

Connect-MgGraph -ClientId 90474a7c-28db-40fe-913a-c943725df0d5 -TenantId foobarqux.onmicrosoft.com -CertificateThumbprint F88526EAE98C39A44477AB1105839111FE8B8BD5
Invoke-MgGraphRequest -Method Get -Uri "https://graph.microsoft.com/beta/reports/credentialUserRegistrationDetails"
Code language: PowerShell (powershell)

Using the Invoke-MgGraphRequest cmdlet requires some additional work versus using a wrapper cmdlet. In the example above, the data is returned in the returned object’s value property, which needs to be decomposed—but this is the same work that would be needed if using Invoke-RestMethod.

If a PowerShell cmdlet does exist for a given method, it can be challenging to determine what the cmdlet is called. There are so many Microsoft.Graph cmdlets that simply eyeballing the cmdlet list isn’t an effective way to find the one you want. Microsoft does have a helpful guide on how to determine the likely name of the cmdlet based on the semantics of the API call. The Microsoft.Graph module controls which version of the API you’re accessing using the Select-MgProfile cmdlet. If you’re accessing a beta method and the cmdlet isn’t showing up, you may need to switch the active profile as shown in the following code and in Figure 4.

Select-MgProfile -name beta -Verbose
Select-MgProfile -name v1.0 -Verbose
Code language: PowerShell (powershell)

With newer APIs (especially those in private preview), you may encounter situations with no support for authenticating as an application. This will typically show up on the Permissions section of the documentation, as shown in Figure 5.

You won’t be able to authenticate as an app registration in this case until such support is added.

References

The following are some useful links to Microsoft documentation related to using app registrations for authentication in PowerShell:

• Az
• EntraID
• ExchangeOnlineManagement
• Microsoft.Graph

Many of these links include PowerShell approaches for creating app registrations and certificates. You can use those approaches or the steps outlined in Part 2 of this blog series depending on your preference. You should read through this documentation to understand how to allocate permissions for each PowerShell module.

In Summary

Scripting is a powerful tool for Azure administrators; however, using the traditional user ID and password combination for authentication can inadvertently create solutions that either leak privileged credentials or place an undue burden on the script developer to implement methods to manage secrets. Using app registrations and certificates for authentication can simplify credential management by offloading it to the Windows certificate storage system.

Although this approach may be less familiar to many administrators, the use of app registrations and certificates is actually relatively simple—and it has value versus managing credentials by hand.

Need help with automating your PowerShell scripts or managing authentication? Contact the experts at Ravenswood Technology.