Need to Know podcast–Episode 247

FAQ podcasts are shorter and more focused on a particular topic. In this episode I speak about what Office 365 Alerts is and provide some best practice suggestions.

This episode was recorded using Microsoft Teams and produced with Camtasia 2020

Take a listen and let us know what you think – feedback@needtoknow.cloud

You can listen directly to this episode at:

https://ciaops.podbean.com/e/episode-247-microsoft-cloud-app-security/

Subscribe via iTunes at:

https://itunes.apple.com/au/podcast/ciaops-need-to-know-podcasts/id406891445?mt=2

The podcast is also available on Stitcher at:

http://www.stitcher.com/podcast/ciaops/need-to-know-podcast?refid=stpr

Don’t forget to give the show a rating as well as send us any feedback or suggestions you may have for the show.

Resources

FAQ 13

CIAOPS Patron Community

Microsoft Cloud App Security options

@directorcia

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.

SNAGHTML1c9be6f2

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

SNAGHTML1ca0c8b3

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

image

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

image

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.

image

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.

image

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.

image

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:

image

image

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.

image

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

image

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

image

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.

image

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

image

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.

image

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

image

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

image

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

image

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

image

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.

image

If you scroll down to the Configuration settings:

image

You will see that the individual settings have been configured.

image

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.

Setting text language in Office Online

Some people don’t wish to use the default English (U.S.) as their preferred language for Office Online when they create new documents there. Interestingly, you can change the option but it doesn’t seem to work for all languages. Here’s how to change the setting, but it has limitations.

image

In my case, my production tenant is set up in Australia. The language I use everywhere is English (Australia). You would think that this applies to any new document created using Office Online. Not so, it seems. If I create a new Word document using the web interface as shown above, I get:

image

but if you look in the lower left you see:

image

If you click on the language text you get:

image

Here I can select English (Australia) as my language. Now my document reports:

image

All good right? Sure, until you create a new document using Office Online. You are then back to original language. In my case  English (U.S.) not English (Australia)! I don’t want to be changing the language manually for every new document I create with Office Online. How do I therefore make my preferred language ‘stick’ with Office Online?

As far I can tell, to make a different language ‘stick’ for a user when they use Office Online they will need to do the following:

1. Login to the Microsoft 365 portal (https://portal.office.com) with their own credentials.

2.  Select their Account Manager icon in the top right of the portal window like so:

image

3. From the menu that appears select My Office profile like so:

image

4. Select the Update profile button the Delve page like so:

image

5. On the Update your profile page, locate and select How can I change language and region settings? as shown:

image

6. This reveal a new line that includes a hyperlink on the word “here” as shown below, which you need to select. Note the additional instructions it also gives you – click the ellipse (…) and then choose Language and Region.

image

7. As the previous instructions detailed, on the Edit Details page select the ellipse (…) like so:

image

8. From the items that are displayed, select Language and Region as previously directed:

image

9. Select the option to Show Advanced Language Settings as shown:

image

10. Select the Pick a new language for both of the selection boxes displayed like so:

image

11. It is at this point that not all options are accepted it turns out. In my case if I select English (Australia), the Office Online documents continue to open with English (U.S.). As it turns out, the best I can do in my case is set the language to English (United Kingdom) and then select the Add button like so:

image

If you want another language, you’ll probably have to try a few to see whether they ‘stick’.

12.  My end result looks like:

image

You’ll also need to either remove the existing language (as I have done, so English (U.S.) no longer appears) or change the priority of the language added, via the up/down arrows on the right of the language, and place it at the top of list to make it the default.

13. Scroll to the bottom of the page and make sure you select Save all and close to update your preferences:

image

14. Lastly, you’ll need to wait about 15 minutes or so it seems for this to take effect.

If you now open a new Office Online document, you should now see the selected language as default like so:

image

Phew, that’s a lot of work isn’t it? It may not be English (Australia) but it is now much closer to that than what it used to be. Remember, that each individual who wants their language changed for Office Online will need to complete these steps.

Next challenge, how to script it with PowerShell for bulk deployment? Not sure I want to go down that rabbit hole. We’ll see. Let me know if you’d find value in a script to make these changes across your tenant.

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.

image

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.

image

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

image

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

image

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!

Attack surface reduction for Windows 10

You may not be aware, but Microsoft has a number of ways that you can implement Attack Surface Reduction (ASR) settings in your Windows 10 environment. You read about these here:

Reduce attack surfaces with attack surface reduction rules

In essence, these rules reduce the items that maybe exploited by attacks on Windows 10 desktops. In reality, they are a good ting to enable if you want to be more secure.

Microsoft has a number of ways you can implement these.

SNAGHTML5612e1b

The preferred option is to use Microsoft EndPoint Manager as shown above. To do this navigate to:

https://endpoint.microsoft.com/

Select Endpoint security on the left, then Attack surface reduction and create a new policy on the right.

image

You can then enable all the settings you wish such as:

Block executable content from email client and webmail

Once you save the policy, it can be deployed to the devices configured in Microsoft EndPoint Manager. This will typically mean those devices have a license for Intune and use that or Configuration manager to deploy such policies. However, it will also support others forms of basic MDM that you may have (like the basic Device management that comes with most Microsoft 365 plans)

image

You can also deploy these using the EndPoint protection configuration policies for Intune as shown above. You’ll find the ASR items under the Microsoft Defender Exploit Guard area in the policy.

Group policy setting showing a blank attack surface reduction rule ID and value of 1

You can also use Group policy as seen above.

And of course you can also do it via PowerShell. if you do elect to use PowerShell, which is great for a stand alone machine, there is a handy tool you can use here:

https://github.com/hemaurer/MDATP_PoSh_Scripts/tree/master/ASR%20GUI

which, when run, looks like:

image

All you then need to do is select your options and save them to update the policies on the local machine.

The options above, plus more are detailed here:

Enable attack surface reduction rules

and I encourage you to visit the page and implement the option that works for you and your environment. For me, using Microsoft EndPoint Manager is the quickest and easiest method to deploy it across my devices. However, you can use PowerShell to quickly and easily implement it for a single device. Using ASR will make your Windows 10 devices more secure, and we all want that, so what are you waiting for?

Need to Know podcast–Episode 246

Due to circumstances outside my control I have no interview for you in this episode. So it it is just me and the latest news from the Microsoft Cloud. Don’t forget that Microsoft Inspire is not far away either, so there’ll be plenty more news soon.

This episode was recorded using Microsoft Teams and produced with Camtasia 2020

Take a listen and let us know what you think – feedback@needtoknow.cloud

You can listen directly to this episode at:

https://ciaops.podbean.com/e/episode-246-just-the-news/

Subscribe via iTunes at:

https://itunes.apple.com/au/podcast/ciaops-need-to-know-podcasts/id406891445?mt=2

The podcast is also available on Stitcher at:

http://www.stitcher.com/podcast/ciaops/need-to-know-podcast?refid=stpr

Don’t forget to give the show a rating as well as send us any feedback or suggestions you may have for the show.

Resources

Microsoft unveils sweeping job training initiative to teach digital skills to 25M impacted by pandemic

An update on Web Content Filtering

Reimagining virtual collaboration for the future of work and learning

Together mode

The future of work—the good, the challenging & the unknown

On-demand training sessions for SharePoint, OneDrive, Teams, Yammer, and Stream

Migration to SharePoint, OneDrive, and Microsoft Teams in Microsoft 365, free and easy

The Standards at Work Behind the Microsoft Enterprise SSO plug-in for Apple devices

Determining legacy authentication usage

I’ve spoken previously about the need to eliminate basic authentication from your environment:

Disable basic auth to improve Office 365 security

The unfortunate reality is that some legacy applications could be using and can ONLY use legacy auth! So, you don’t want to necessarily disable it across your tenant without first understand who or what maybe using legacy auth.

image

One way you can see this is by navigating to your Azure Active Directory in the Azure portal for your tenant. You then need to select the Sign-ins options on the left under the Monitoring heading towards the bottom as shown above. You should then see a list of events display on the right. At the top of this pane select the Columns menu item.

image

From the pane that appears from the right ensure you have the option Client app selected, as shown above.

image

Next, select the Add filters button at the top of the list of events as shown above. From the list that appears select Client app and then the Apply button at the bottom.

image

A Client app option should now appear at the top of the list as shown. It will typically show None Selected.

image

Select the new Client app button and a list of items will be displayed as shown above. From this list, select all the items under the Legacy Authentication Clients heading.

image

When you now click away, the list of events should be filtered to only those events that match the use of Legacy Authentication. You can select any of these to get more information about the event including who or what generated this.

Armed with this knowledge you can now start working whether upgrades or additional configuration is required in your environment to minimise the attack surface area of Legacy Authentication in your environment.