Using the Microsoft Graph with multiple tenants

In a recent article:

Making PowerShell automation easier with the Microsoft Graph

I showed how to use the Microsoft Graph to embed an Azure AD application in a single tenant and then use that to make Graph queries against. What happens when you want to that across multiple tenants?

To achieve this you’ll need to basically do three things:

1. Embed a ‘static’ Azure AD application in all the tenants you wish to access.

2. Give those ‘static’ Azure AD applications, in all those tenants, the appropriate permissions to access the tenant values.

3. Run a Graph request against these Azure AD applications in each tenant and extract the results you want.

This article is going to look at Step 1 of this process.

So, the task at hand is to create a ‘static’ Azure AD application in all the tenants we want to access. I have detailed how to achieve this manually before here:

Using interactive PowerShell to access the Microsoft Graph

That may prove time consuming if you wish to do this across many tenants, so I have automated it via a freely available program here:

https://github.com/directorcia/Office365/blob/master/graph-adapp-add.exe

You can download the file into any directory on your machine. Best best is to use a Windows 10 machine that already has the AzureAD PowerShell module installed. This program will also generate a number of configuration files in the current directory for each domain you connect to.

Running the program will launch the PowerShell script as shown. You’ll then be prompted for the name of your Azure AD application. This is the display name that will appear inside your Azure AD. This name will be the same across all tenants you connect to. Here I’ve chosen to call my Azure AD application ciaops.

You’ll then be prompted for the email address of a tenant administrator with the rights to create an Azure AD application.

You’ll then be take through the normal sign in process for that tenant with that user as shown above. This will include any MFA if required.

The tenant will be check to see if an existing Azure AD application of the same name already exists and if it does you’ll see a warning like shown above. The program will then skip adding an Azure AD Application to this tenant and move on to the next tenant.

Assuming no Azure AD application of the same name exists in that tenant you’ll see that a new Azure AD application of that name is created. When a token is created in a tenant there are fours pieces of information that will need to be saved:

1. Application ID

2. Object ID

3. Application secret

4. Tenant ID

Each of these will be written to a secure configuration XML file I’ll explain in detail below. For now, just appreciate that these values need to be written securely to files so they can be used later. To achieve that, the program uses the get-credential PowerShell command to capture these securely to be written.

To complete this process all you need to do is use the Paste command (i.e. CTRL+V) when prompted at the password field as shown.

So here, simply hit CTRL+V and then ENTER. The actual value you are pasting is a few lines up in the display as you can see above if you need it.

You’ll need to complete that process four times for each variable as shown above.

You are then prompted for the next domain you wish to add an Azure AD application to. You repeat the same entry process for each new domain you wish to use.

When you have no more domains to configure, simply press Enter at the admin domain prompt. At that point, the program will disconnect from any Azure AD and use the captured credentials to check whether it can access all these tenants. To do this, it reads from the saved configuration files and makes a basic read request to the Microsoft Graph using the Azure AD application details for each tenant to verify success. It merely tests that it can get the Graph API for that tenant.

At this point you now have an Azure AD application of the same name, inside each tenant you configured, with no permissions to anything with the Graph.

If you now return to the directory where you ran the program from you’ll see a number of additional files as shown above.

The graph-adapp-set.txt is a log of the whole process so you can see what has happened.

You’ll also see four XML files per tenant. These contain the important variables for the tenant mentioned previously. They are in format of:

<domain>-tenid.xml – holds encrypted Tenant ID

<domain>-appsec.xml – holds the encrypted application secret of the Azure AD application for the tenant

<domain>.objid.xml – holds the encrypted Object ID of the Azure AD application for the tenant

<domain>.appid.xml – holds the encrypted Application ID of the Azure AD application for the tenant

Storing these details on a workstation is not the most secure option I agree, but it’s a starting point for what I’ll show you down track (read Azure Key Vault). However, because some people want the flexibility and simplicity of local files that’s where this starts.

If you examine one of these XML configuration files more closely, as shown above, you’ll see that the variable name (here AppSec) is stored in the Username field and the Password field has a long string of characters. You’ll notice that these characters actually don’t in anyway match the actual Appsec value that was captured earlier. That value was:

This means that the actual tenant variables save in the files are encrypted, so they can’t be easily recovered.

To get the unencrypted values back you’ll need to use the PowerShell import-clixml as shown above.

Well, you maybe thinking that it is easy enough to copy these configuration files to another PC and decrypt them there. Not so fast my sneaky friend, because the way these details are encrypted is that they are locked to just THAT machine and just THAT logged in user! As you can see from the above, if you try and decrypt these files with another user on that same PC or on another machine, you can’t.

All of this comes about because of the use of the export-climxl command to save the variables, which says:

The Export-Clixml cmdlet encrypts credential objects by using the Windows Data Protection API. The encryption ensures that only your user account on only that computer can decrypt the contents of the credential object. The exported CLIXML file can’t be used on a different computer or by a different user.

That’s why you needed to do that CTL+V paste command for each variable previously so that the variable could be saved as a credential object and take advantage of this encryption process.

This has now achieved STEP 1 in the process I spoke about initially to allow secure access to multiple tenant using the Microsoft Graph.

So what does the program actually do to each tenant behind the scenes? It is easy to see. Simply visit the Azure AD Directory location in the Azure portal for that tenant. If you then select the App registration from the menu on the left, and ensure you are viewing All Applications, you should see the application with the name you entered displayed on the right as shown above. Here, ciaops.

If you select the application name to get more details you’ll many of the variables saved to XML files as shown above.

If you then select API permissions on the left you will see that, as yet, no permissions have been given to this Azure AD Application (although they will be in an upcoming article).

However, we are not quite done yet as I have also created a program that will remove all of these Azure AD applications created quickly and easily. To do that download the program:

 https://github.com/directorcia/Office365/blob/master/graph-adapp-del.exe

You need to place it into the directory where all the tenant configuration file are located as shown. Double click the program to run.

To remove that Azure AD application you’ll need to log back into every tenant interactively as shown above. You’ll see the same of the tenant that it wants credentials for in the program flow.

Once you have provided access to the tenant, the Azure AD application will be deleted along with the configuration files. You’ll then be take to the next tenant and asked to repeat the process.

Once there are no more configuration files found the program will end.

Remember, this program will delete every matching tenant it finds configuration files for in the current directory. If you only want to delete a subset of the total tenants you have configured, move the other configuration files out of the current directory until this process is complete.

In summary then, the programs that I have created and made available for free will create a ‘static’ Azure AD application in all the tenants you select. The idea in upcoming articles will be to show you how this ‘static’ embedded Azure AD application can now be used to report and potentially change the configuration of multiple tenants quickly and easily. I also provided a program to also remove all these Azure AD applications from tenants.

Next step will be to give the Azure AD applications appropriate permissions and then get some information from the tenants WITHOUT the need of manually logging into each.