Getting started automating Microsoft 365 administration with the Graph

https://www.youtube.com/watch?v=e1ypZGfifSQ

The Microsoft Graph is a unique and powerful way to administrate Microsoft 365. This session will provide you with a introduction to what the Microsoft Graph is, how to access it and how to use to improve the way you maybe currently administrating your customers environments. The session will also be jammed packed with live demonstrations and best practices for automating any Microsoft 365 environment. Save time, save money and save effort by viewing this session.

Issues creating Endpoint Security Policies using the Microsoft Graph

I swear it was all working and now BOOM, it doesn’t! Using PowerShell I had been creating Endpoint Security policies but now those same policies were still being created but WITHOUT the configuration settings I had configured.

You can try this for yourself if you wish, without needing to code. Firstly visit the Microsoft Graph Explorer and authenticate.

Change the method to POST, set the API to beta and use the URL = https://graph.microsoft.com/beta/deviceManagement/templates/6cc38b89-6087-49c5-9fcf-a9b8c2eca81d/createInstance

Then in the Request body use the following:

https://gist.github.com/directorcia/6d8d2e5199c32b22b6fe782739447dc4

If you do you’ll find a new Endpoint Security Attack Surface Reduction – ASR rule has been created like so:

If you look at settings for this policy you’ll see:

all the settings are Not configured!

So, no errors during the POST but no settings! Strange.

If however you return to the Request body and change the word value to settingDelta as shown above and then run the same query.

Now, the Endpoint Security policy is created and the settings are configured.

So in summary, don’t use value any more it seems with the request body, use settingsDelta.

Removing Azure Enterprise app consented permissions

After installing the appropriate PowerShell modules you can connect to the Microsoft Graph with PowerShell using the command:

connect-graph

as shown above. First thing to remember is that this process can’t be completed in the Power ISE, you’ll need to do it elsewhere (here, using Windows terminal). The second thing to note is that you can specific the scope with which you to connect. Thus, in this case, the scope will be Files.ReadWrite.All and Sites.Readwrite.all. The scope is in effect the permissions the current user will be given when they connect to the Microsoft Graph. This allows you to only provide permissions for exactly what you need.

During the connection process you’ll be asked to consent to the permissions just requested, as shown above. If you simply select Accept here, you are just consenting for the current user. However, if you check the Consent in behalf of your organization option you’ll be providing these permissions to ALL users in your tenant! For now, only consent will be granted for the current user. However, be very, very careful consenting for the whole organization as I will illustrate.

You can now happily go off and perform whatever actions you need to using PowerShell for the Microsoft Graph.

With security in mind, I went to have a look at where these permissions just consented to actually appear. You’ll find them by opening the Azure Portal and navigating to Azure Active Directory as shown above. From here, select Enterprise applications from the menu on the left.

From the screen that appears ensure All applications is select from the menu on the left. Then on the right, locate and select Microsoft Graph PowerShell as shown.

From the screen that now appears, select Permissions from the menu on the left as shown. On the right you’ll then be able to select either Admin consent or User consent.

Because the permissions assigned were only for a single user, the User consent item will show these to us as shown above. This list of permissions matches those consented to when connecting to the Microsoft Graph.

The right hand most column in this display, Grant by, has a hyperlink to show the number of users with this assigned permission.

If you select any of these hyperlinks, you’ll see a list of users, on the right, that have been assigned this permission appear on the right as shown above.

Can you see the problem yet? No? Well…….how do you REMOVE or revoke a permission here?

From what I can determine, you can’t remove the permissions via the portal. If you select Review permissions menu option you’ll see a item displayed from the right as shown above. If you select the option This application has more permissions that I want and basically told to use PowerShell to revoke all permissions for this application as well as being provided with the code to do so.

The issue is that even after you disconnect from the Microsoft Graph, having completed any scripting, those consented permissions remain in place i.e. they are NOT rescinded. This means that if the user account with these permissions to the Graph is compromised then that attacker has access to the Microsoft Graph and potentially lots of sensitive areas in a tenant, especially if the permissions have been added to over time. Imagine how much WORSE it gets if permissions were consented tenant wide, rather than to an individual user?

Selecting that little check box in the above Permissions requested dialog, which I see MANY people do without thinking, can really give you a security headache by opening up your Microsoft Graph permissions for EVERY user in the tenant!

Thus, best security practice is going to be to remove these permissions when they are no longer required as well as limiting who has them initially. Personally, I’d remove them after each interaction so I don’t forget and leave a potential attack vector.

To make doing all that a little easier, I have gone out and created a script that you’ll find in my Github repo:

https://github.com/directorcia/Office365/blob/master/graph-adappperm-del.ps1

If you run the script, it will first check whether the Azure AD PowerShell module is loaded. If it is, it will then ask you to login to your tenant. Then it will display a list of all the Azure AD applications in your tenant and allow you to select the ones you want to change (yes, you can select multiple Azure AD apps if you want) as shown above.

In this case, Microsoft Graph PowerShell application is selected.

You’ll then be prompted to select whether you wish to select Admin consent and/or User Consent permissions. You can select both here if you wish by using the CTRL and/or SHIFT key when making selections (i.e. just like when you use Windows Explorer).

If you selected User consent, you’ll then be prompted to select the users you want. Again, multiple selections are available if offered.

You’ll now be prompted to confirm you wish to delete these permissions for these users.

Those permissions will be removed and the script will continue to work through the rest of your selections.

In this case, because there were no Admin consented permissions for this application we receive a notification line as shown in above output.

If you now return and have a look at the permissions for that app in the portal, you should see they have all been removed as shown above.

Leaving users with standing permissions to something as powerful as the Microsoft Graph is not best security practice. It is therefore important to regularly review these and remove what is not required. If you need those permissions again in eth future, after they have been removed, you can always re-consent to them when you next connect to the Microsoft Graph.

Automating the deployment of an Attack Surface Reduction policy across multiple tenants

A while ago I wrote an article on:

Using the Microsoft Graph with multiple tenants

which showed you how to embed a ‘static’ Azure AD application in all the tenants you wish. I then showed how to give those ‘static’ Azure AD applications, in all those tenants, the appropriate permissions to access various tenant configuration settings in this article:

Reporting on multiple tenants with the Microsoft Graph

This meant that you could now run Microsoft Graph requests across all those tenants, securely and without needing a login to each tenant.

Recently, I also wrote about the:

Attack Surface Reduction rules for Windows 10

and how to set these in an automated way via PowerShell. I’m now going to bring these two concepts together and show you how to deploy an Attack Surface Reduction (ASR) policy into Microsoft Endpoint Manager across multiple tenants WITHOUT the need to login to each to do it!

Before you can do all this you’ll need to embed an Azure AD App into all the desired tenants. The information to do this I have previously covered here:

Using the Microsoft Graph with multiple tenants

Once you have an Azure AD application inside your tenants you can continue to use this for continued configuration processes like this. Thus, you only need to add an Azure AD application to the desired tenants once. You can then simply re-use it as needed.

With the Azure AD application in place, the next step is to provide the appropriate permissions for that Azure AD application to do to what it needs. In the case of working with ASR the Azure AD application will need the following Graph API permissions:

Read and write Microsoft Intune Device Configuration and Policies

and

Read Microsoft Intune Device Configuration and Policies

You can add these manually which I have covered off previously here:

Using interactive PowerShell to access the Microsoft Graph

However, I have also made available an automated tool to do this.

In this case, my pre-existing Azure AD application is called ciaops-S6 as shown above.

In this first tenant, you see that there are current no API permissions associated with my Azure AD application.

In the second tenant, there are already existing permissions as you can see above, but they currently don’t include the ones I want detailed above, so they will also need to be added here.

What I want to achieve for both tenants, is to add these two Graph API permissions:

Read and write Microsoft Intune Device Configuration and Policies
Read Microsoft Intune Device Configuration and Policies

to my existing Azure AD application, while also leaving any existing permission in place.

You’ll need to visit my Office 365 GitHub repository and down the program:

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

You’ll need to put the graph-adapp.per.exe in the same directory as the XML configuration files for the tenant, as shown above. Then you’ll need to run:

graph-adapp-per.exe 89a0934cc6064c1a95caffdaec4e5429

The 89a0934cc6064c1a95caffdaec4e5429 parameter tells my program which permissions you wish to add to the existing Azure AD application.

The program will check whether the Azure AD PowerShell has been loaded. If not, it will terminate.

In this case enter A when prompted to ADD permission to those that exist.

You’ll then be prompted to login as an administrator to the first tenant. This is required once for each tenant because you are ADDING permissions to an existing Azure AD application. Once these permissions have been added, you won’t need to repeat for any access to the same properties. For example, say you later on want to configure the Microsoft EndPoint Manager Firewall policy, you won’t need to complete this permissions step because what you are doing here adds the same permissions you need to do the Firewall policy.

The required permissions are added and you will be then prompted to ‘consent’ to these. Unfortunately, I can only find a way to do this via a browser. Selecting Y here will open a browser in-private mode and allow you to complete consent. The required ‘consent’ URL is also copied to the clipboard, so if you already have the tenant open is a browser somewhere, just paste the clipboard there to complete ‘consent’ like so:

You should now see the permissions request as shown above that you need to Accept. What you see will vary slightly. You will always see:

Read and write Microsoft Intune Device Configuration and Policies

Read Microsoft Intune Device Configuration and Policies

as these are new permissions. However, if you have existing rights, as this first tenant did, you will also see those.

Simply select Accept to continue.

If you now return to the program, you’ll be prompted to confirm that ‘consent’ has been completed. Enter Y to continue.

That will complete the first tenant and then commence the same process on all subsequent tenants as shown above.

The only difference you’ll probably see is the list of permissions you need to accept. This is because, in this case, the option to ADD permissions was selected. The above shows you the prompt from the second tenant in this example which started off with no permissions for the existing Azure AD application.

Once the program is complete, it will pause as ask you to hit ENTER as shown.

If you now look at the API permissions for the Azure AD application that was added you should see that they now have:

Read and write Microsoft Intune Device Configuration and Policies

Read Microsoft Intune Device Configuration and Policies

As shown above.

And if you check an Azure AD application that already had permissions, like the second example here shown above, you will see that the appropriate permissions have been added to any that previously existed.

Remember, you only need to go through this process when you want to ADD permissions to your Azure AD application. As mentioned, now that these permissions have been added to the Azure AD application you can work with just about any EndPoint Manager configuration for the tenant.

Now that the permissions are in place, the next step in the process is to run the program to add the ASR policy to EndPoint Manager for the tenant. To do that you’ll need to download the following program from my Office 365 GitHub repository:

https://github.com/directorcia/Office365/blob/master/graph-asr-set.exe

and copy into the same directory you have been using as shown above. That is the one with all the tenant configuration files.

Run the program:

graph-asr-set.ps1

The program will run and work through the required tenants without any prompts.

You will see the policy settings for each tenant, as shown above, as a confirmation.

If you return to Microsoft EndPoint manager for the tenants and refresh that ASR policy listing as shown above, you should a new ASR policy as shown.

If you scroll down to the Configuration settings:

You will see that the individual settings have been configured.

The only you’ll need to do manually, is to actually assign this policy to your environment as shown above. I have chosen not to do this automatically for all users and or devices in the tenant, because there may need to some tweaking of the individual settings as applying to a test group first to ensure there are no issues. Maybe in a future iteration I’ll look at providing that option.

If you run the graph-asr-set.ps1 program again, it will create an additional policy of the same name with the same settings. Another to-do item will be a program to adjust an existing script.

If for some reason you wish to remove ALL the permissions from your Azure AD application in ALL your tenants, use the command:

graph-adapp-per.ps1 693cb755244848a2a556025710cec086

Youi can also, of course, do this manually via the portal as well as selectively by the same method if you wish. However, I see no major not to leave the permissions in place, having gone to all that trouble, so you can make additional configuration changes later on (without the need to login to the tenants as I will again point out!)

So there you have it! An automated way to set ASR policies in Microsoft EndPoint Manager, across multiple tenants, without individually logging in, using the Microsoft Graph.

Case sensitivity is important with the Microsoft Graph

I recently wrote an article about implementing Attack Service Reduction (ASR) which you can read here:

Attack Surface Reduction for Windows 10

The next step was now to automate ASR policies with Microsoft EndPoint Manager via PowerShell. Luckily I found a great blog article by Ben Leader which you’ll find here:

Creating EndPoint Security policies with PowerShell

Ben’s article focused on BitLocker, while mine focused an ASR. It took a little time to reverse engineer things with ASR and I had my script working without error.

However, the problem was that the changes that the script made didn’t show up in the web interface as shown above? There were no errors reported. Strange? Maybe, it was a timing thing? Nope. what could it be?

Puzzled, I contacted Ben again and it turns out that the syntax with the Microsoft Graph is case sensitive!. A simple solution once you know but super frustrating until your do.

So the original code I have set the “value” to Enable as shown above. That is with a capital ‘E’, which is invalid.

As it turns out (thanks to Ben), I learned it should be a lower case ‘e’ as shown above.

As shown above, this works as expected in the web interface. Phew.

The moral or the story is that you need to be careful when it comes to setting values with the Graph. That hopefully, hopefully should accelerate my development of automating ASR across environments!

Summary report on multiple tenants with the Microsoft Graph

In recent articles I’ve covered off how to add an Azure AD application to multiple tenants, then set the permissions and finally run a report all quickly and easily using automation. You’ll find all that here:

Reporting on multiple tenants with the Microsoft Graph

With those same Azure AD applications and permissions in place I have now developed a program that will provide you a summary report of emails, Teams, OneDrive for Business and SharePoint usage across multiple tenants, all WITHOUT the need to login to any of them!

You’ll find this program available at my GitHub repo here:

https://github.com/directorcia/Office365/blob/master/graph-summary-get.exe

For it to execute you’ll have needed to completed the process I detailed earlier of creating an Azure AD application in every tenant and adding suitable permissions. When that is complete you can simply run the above program. The program will need to be downloaded into the same directory that the tenant configuration files are located and run from there.

When it runs, it will get the configuration files in the current directory and access each tenant in order. It will collect information via the Microsoft Graph and then report on emails (above),

Teams (above),

OneDrive for Business (above),

and SharePoint (above). It will do this for each user in each tenant, again without the need to login to the tenant.

Thus, you could use this report to run on a regular schedule and provide details on each of the tenants. because no login is required to the tenants you can do this whole process unattended!

There is lots more that can be done in this manner via the Microsoft Graph, so look out for more stuff I’ll be making available in the future.

Microsoft Graph tenant management summary

I’ve covered a lot in recent articles around using the Microsoft Graph to manage a tenant. You can find those previous articles here:

Reporting on multiple tenants with the Microsoft Graph

Making PowerShell automation easier with the Microsoft Graph

To bring this all together I have created a summary video which you’ll find here:

https://www.youtube.com/watch?v=P3xhE2ESgE8

In it, you see how to use the code that I created to install Azure AD applications in tenants, provide permissions to these Azure AD applications and then finally run a report routine to extract the desired information.

Hopefully, this summary provides a nice easy way to see this concept in action end to end.

Reporting on multiple tenants with the Microsoft Graph

The aim of this project has been to show you how to manage multiple Microsoft 365 tenants quickly, easily and securely using the Microsoft Graph. this article builds on a previous article so go and take a look at:

Using the Microsoft Graph with multiple tenants

The complete steps in this whole process are:

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 desired results.

This article will show you how to complete Steps 2 and 3. Step 1 was covered in the previous article.

Step 2 requires granting appropriate permissions to the Azure AD application already in place inside each tenant. The manual process of how to achieve this is covered in my article:

Using interactive PowerShell to access the Microsoft Graph

However, why do it manually if you can automate it I say? With that in mind, I have created a self executing PowerShell script to add the appropriate permissions to multiple tenants and allow the reading of OneDrive for Business usage information for all users. You’ll find the program to do this in my GitHub repo here:

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

You’ll need to download the file into the location where all the XML configuration files are that were created in Step 1. These will be needed again as the program cycles through all those tenants adding the appropriate permissions.

When you run the program, it will read the XML configuration files it finds in the directory and then ask you to login to each tenant again. You need to do this as you are granting/consenting to permissions and that requires administrator access.

You’ll need to complete the process of opening a browser session to each tenant and Accept the permissions as shown above. You’ll note that, in this case, they are read only permissions.

For more details on this process if you haven’t seen it, take a look at the article I wrote about doing the same thing for a single tenant:

Making PowerShell automation easier with the Microsoft Graph

Remember, that you don’t necessarily have to open the default browser all the time as the consent URL is always copied to the clipboard, so you could just past it into existing active sessions for that tenant if you wished.

The program will work through all the domains available.

If you want to see what’s happened visit the Azure portal for each tenant. Navigate to Azure Active Directory, then App Registrations, All Applications. Select the name of the Azure AD application you are using, then API permissions as shown above. You should see that the only permission it has is Read All usage reports. You should not that consent has also been granted.

That now completes Step 2 of the process.

We now have an Azure AD application in all the desired tenants and that Azure AD application has the appropriate permissions to do things. We can now start extracting information by continuing to Step 3.

In this example, we’ll run a program that will retrieve usage information about OneDrive for Business for each user in each tenant, without prompting for a login!

You’ll need to download the program I’ve written to do this (graph-odfb-get.exe), which you’ll find here:

https://github.com/directorcia/Office365/blob/master/graph-odfb-get.exe

Again, you need to place it the same directory where all the tenant configuration files are, as shown above, so it can access all the tenants configured in previous steps.

When you run the program, you’ll see the program loop through all the domains and all the users in those domains, without asking for a login.

At the end of each domain you’ll see a summary of OneDrive for Business for that domain as shown above.

At the end of the process you’ll see an aggregate summary for all your domains, as shown above.

This may seem like a lot of work but remember, you only need to do Steps 1 and 2 ONCE! Once the Azure AD application is configured for each tenant and the Graph has the appropriate permissions you can run Step 3 as MANY TIMES as you wish, securely, WITHOUT be prompted for a login to each tenant! How easy is that to automate?

This example has used just one aspect of the Graph being OneDrive for Business. You can use the Graph to do just about anything in Microsoft 365 you need to, including actually changing and update parameters!. In fact that is what I’m off to do right now.