Exchange Online Automation with EXOv2 Module Part 2

In my first part of Exchange Online Automation with EXOv2 module, I covered how you can use Dave’s PowerShell module for cutting down the Azure AD application registration and configuration. Also, how and why you should store your secrets in Azure Key Vault.

In this post, I’m covering how you can access Azure Key Vault using REST API, which unlocks several scenarios.

Azure Key Vault REST API

With REST API we need an access token for authentication. This can be an access token with delegated permissions, which means with scopes, or with application permission and instead of scopes, the token will contain roles. I will show you later where you can see this.

Due to the fact that some DLLs are not available in PowerShell Core, we cannot use OAuth 2.0 code grant flow. But we can use client credentials grant flow.

In any case, we need to fulfill the following requirements to access Azure Key Vault via REST API:

• Register your application in Azure AD (Microsoft Docs)
• Add permissions for delegated scenario (Microsoft Docs)
• Configure Access Policies of your Azure Key Vault to allow access for the application (Microsoft Docs)

I registered an application and granted for delegated scenario permissions for Azure Key Vault

For client credentials grant flow, I created a secret

On your secret in the Azure Key Vault, set permissions for the previously created application:

Note: I’ve granted for all 3 areas Get and List, which are the minimal permissions you need.

With the following code you can request an access token:

Note: You can also use your tenant’s name instead of the ID. Replace the values client_id, client_secret and the tenant ID in the URI with your data.

The decoded token looks like this:

“aud” is the Audience for which the token was issued. As you can see there is no “scp” or “roles” as there is no Application permission for Azure Key Vault.

Here's what the token looks like using delegated permissions:

Now as we have a token, we can use the REST API and get our secret:

Remember what we did previously with the value?

Of course, you can also get the secret string:

Conclusion

I know this was a long article, which covers a complex scenario and the Exchange Online PowerShell v2 module doesn’t support either certificate object of client secret string as of now, but it will in the future (no ETA as of now!). This will open the doors for automation.

Using Azure key Vault also improves your security and transparency with features like Access Policies, Alerts, logging and more. You get full insight into who, where, and what accessed your sensitive information.

Besides this, the examples given for Azure Key Vault REST API above, might help you with coding stuff for other things.

If you are interested, I wrote several functions for my daily work (including the topic of this post). They are available on GitHub here.

Monitor Your Hybrid - Office 365 Environment with ENow

ENow’s Office 365 Monitoring solution is like your own personal outage detector that pertains solely to you environment. ENow’s solution monitors all crucial components including your hybrid servers, the network, and Office 365 from a single pane of glass. Knowing immediately when a problem happens, where the fault lies, and why the issue has occurred, ensures that any outages are detected and solved as quickly as possible.Monitor Your Hybrid - Office 365 Environment with ENow.