Information about SharePoint, Microsoft 365, Azure, Mobility and Productivity from the Computer Information Agency
The slides from this month’s webinar are available at:
If you are not a CIAOPS patron you want to view or download a full copy of the video from the session you can do so here:
http://www.ciaopsacademy.com.au/p/need-to-know-webinars
Watch out for next month’s webinar.
Join me for the free monthly CIAOPS Need to Know webinar. Along with all the Microsoft Cloud news we’ll be taking a look at OneDrive for Business.
Shortly after registering you should receive an automated email from Microsoft Teams confirming your registration, including all the event details as well as a calendar invite.
You can register for the regular monthly webinar here:
(If you are having issues with the above link copy and paste – https://bit.ly/n2k2310
The details are:
CIAOPS Need to Know Webinar – October 2023
Tuesday 31st of October 2023
11.00am – 12.00am Sydney Time
All sessions are recorded and posted to the CIAOPS Academy.
The CIAOPS Need to Know Webinars are free to attend but if you want to receive the recording of the session you need to sign up as a CIAOPS patron which you can do here:
or purchase them individually at:
Also feel free at any stage to email me directly via director@ciaops.com with your webinar topic suggestions.
I’d also appreciate you sharing information about this webinar with anyone you feel may benefit from the session and I look forward to seeing you there.
In a previous article I covered off how to use Defender for Cloud Apps to monitor a break glass account. Typically, the alerts generated there will feed into Sentinel, however it is possible to configure Sentinel to perform a similar role.
The starting point is to use a KQL query like this:
SigninLogs
| where UserPrincipalName == “breakglass@domain.com”
| where OperationName == “Sign-in activity”
| project TimeGenerated, UserPrincipalName, ClientAppUsed, LocationDetails
If you run that query manually you’ll see a result like shown above. You will however also notice a New alert rule option in the top right of the window.
Selecting this will reveal two choices as shown above. Select Create Microsoft Sentinel alert to continue.
Make the appropriate settings in the General page, like shown above, and continue.
Here there are number of settings you can select but you will probably want to adjust how often the query is run as shown above. The important point to remember is that, as Azure is a consumption based billing model, there is a (very, very small charge) every time the query is run. Thus, the more often it runs the more it will cost.
When you have completed this section, move onto the Incident settings.
Here it is important to ensure that the option to Create incidents is Enabled as shown above.
Make any additional adjustments and move to Automated response.
Here you can enable any automation action you wish by selecting from those already created, as shown above. You can always add additional automation later if desired.
Finally, review and create the alert.
Verify that the alert you just created now appears in the list of Analytic rules for your environment as shown above.
If you now test this by logging as your breakglass account you should an incident generated as shown above. Once again, it is important to remember that this incident doesn’t appear immediately. It will appear in a time period based on how often you set the alert to check.
Another important thing to remember is that by default, the incident will not send an email notification of the alert. You can configure that a variety of different ways if you wish, which I won’t cover here.
The differences with using Sentinel for custom alerts is that the billing is consumption based, but you have a lot more flexibility in how you configure the actual alerts as well as any automated response if desired. I would also say that Sentinel has more power around actually analysing signals as well which is handy to protect your breakglass account.
It is a very good thing to have a breakglass account in your environment. I have spoken about this in depth in an episode of my podcast:
Need to Know podcast – Episode 310
The challenge can be ensuring you know if and when this account is used because it typically has less protection associated with it than normal accounts in the environment.
One way to achieve this is to use Defender for Cloud Apps, which can be found by navigating to:
https://security.microsoft.com
to generate alerts when the account logs into the environment.
On the left hand menu of the Microsoft Security Center for your tenant expand the Policies option under the Cloud apps heading, and select the Policy management item.
Now select the +Create policy menu item on the right as shown above.
From the drop down that appears, select Activity policy as shown above.
Give the new policy a Name and Description. Select the Policy severity and the Category.
Select the option to Act on: Single activity.
In the Activities matching all of the following select:
Activity Type equals Log on
then add another filter and select:
User Name equals breakglassaccount@domain.com as Any role
as shown above. This in essence will trigger and alert whenever the breakglass account logs into the environment.
Configure the Alerts and Governance actions to suit your requirements. At a minimum you probably want the alert to be emailed to an external address. You can also build a Power Automate Flow from this also if you wish.
Save the new policy.
Locate the policy just created in the list (you can sort using the Modified column if necessary). Select the ellipse (three dots) to the right of the policy entry and from the menu that appears, select View all matches as shown above.
Ensure you test the policy by logging into your breakglass account.
This will now show all the matches in your environment as shown above. It is also recommended that you Save as so you can easily return these results if needed in the Activity log.
If you have also set up Sentinel, the alert should also flow into here as shown above. More automation and alert options are available here if needed.
The most important thing to remember that any alert generated by the login of your breakglass will NOT be immediate! It should however appear with a a few minutes of the action taking place and then a little while after in Sentinel as it flows through the logging process.
There is more that can be done to with this process, but this should get you started protecting your breakglass account.
Microsoft has announced that Copilot will be available on November the 1st 2023. Unfortunately, Microsoft is only targeting the initial release at enterprises as revealed in a document titled:
Microsoft 365 Copilot General Availability FAQ for partners. In essence it says:
Availability will be worldwide, in the public clouds, and customers will be able to transact via the EA/EAS/MCA-E channels.
the document also addresses the question:
Why are we not making the SKU available in Direct and CSP channels?
Microsoft 365 Copilot is an amazing new technology, but we are all learning together. To ensure
a smooth integration process, we’ve decided to start by introducing it to our Enterprise and
SMC-Corporate customers via EA/EAS/MCA-E.
there will also be minimum purchase requirements, also highlighted in the document:
Is there a minimum number of seats customers should buy?
Yes, customers must buy at least 300 seats of Microsoft 365 Copilot.
It is disappointing to see many claim, even some well respected identities in the SMB space, that Microsoft is not delivering Copilot to SMB. The reality is that the SMB space has always had to wait for technologies to trickle down and Copilot will be no different.
As I understand it, Copilot and AI in general, places a lot more load on the back end servers and much of this cannot be cached like normal searching can. Also, Microsoft doesn’t have a true indication of the load users will place on cloud infrastructure when it starts to be used in production. They therefore want to bring this load on in a controlled manner to avoid failure, which would not be good or profitable for a new service like Copilot.
Thus, there are many technical and business reasons for limiting the roll out of Copilot to the customers. There is significant demand in all areas for the technology but it needs to both prove itself and pay its way before it is widely adopted. That means that those in SMB are going to wait a little longer before it becomes available as a direct purchase. It does not mean that Microsoft won’t be delivering to all audiences, it just means people will need to be patient.
I would point you back to the features that have been added to Microsoft Business premium over time. At release of this product it didn’t include technologies like Entra ID P1 or Defender for Business. However, they did come to the product. Perhaps they didn’t arrive as soon as people would have liked but they did arrive and we are reaping the benefits today.
There is no doubt that the demand for Copilot is significant. There is no doubt that will will benefit the SMB market. However, it is incorrect to say Copilot will not be available for the SMB market. It will just require a little patience for it to become available, which to be honest is probably a good thing to let others work the kinks out.
In recent article:
Block applications on Windows devices using Intune
I outlined how to prevent an application from running on a Windows device. It would be nice to know how many people are running this application prior to it being blocked (and even before). You can achieve this using Sentinel.
Many don’t appreciate
The extra value that Microsoft Defender provides
apart from security. In a nutshell, Defender for Endpoint sends signals from devices into the Microsoft cloud that something like Sentinel can take advantage of. This is something that can be taken advantage of to see application usage.
DeviceNetworkEvents
| where InitiatingProcessFileName contains “msedge.exe”
| project TimeGenerated, RemoteUrl, RemoteIP, DeviceName, InitiatingProcessAccountName
| summarize count() by bin(TimeGenerated,1day),DeviceName
| render columnchart
an example of this is the above KQL query, which when run provides an output like:
The result is basically a bar graph, over whatever time you specify, of how many times an application has been used. This is a great indicative way to get a feel for how often a device is running a particular application (here msedge.exe). The different bar colours show each particular device and each bar height represents the total usage of that application for one day.
The great thing is that you can further customize and enhance this query to suit your needs to product the output your require. You can then take that query and embed it into a Sentinel workbook so that it is available as part of a dashboard.
There is just so much that you can do and all it takes is becoming familiar with the tools Microsoft provides in your environment.
This series of posts is an approach to implementing Intune inside a business. So far, I have covered off:
1. Create compliance policies and update devices to be compliant
2. Implement LAPS to control the local device admin account that cannot be deleted
3. Remove all other accounts from local administrator group on devices
4. Setting the default search engine in Edge with Intune
5. Managing browser extensions in Edge with Intune
6. Setting an Edge Security Baseline with Intune
7. Setting an individual Attack Surface Reduction (ASR) rule in Intune
8. Setting Edge as the default browser using Intune
Now that we have Microsoft Edge all set up and have done as much as we can to encourage people to shift away from using other browsers, it’s now time block any other browsing options. We can again use Intune to achieve this and, typically, it can be done using a number of different methods. Here, we’ll use what I consider the easiest method.
Once again, create a Configuration profile for Windows 10 and later using the Settings catalog as shown above.
Give the policy a suitable name and continue.
In the search field type ‘specified windows application’ and select Search. The only category that appears should be Administrative Templates\System, which you should select. Then in the lower pane select Don’t run specified Windows applications (User) as shown above.
Enable the Don’t run specified Windows applications (User) and then enter the name of the applications you do not wish to run. Here, we’ll block chrome.exe and brave.exe as shown above.
These settings are covered in the RestrictApps documentation in which you will note:
1. The setting applies to users not devices:
and
2. This policy setting only prevents users from running programs that are started by the File Explorer process. It doesn’t prevent users from running programs such as Task Manager, which are started by the system process or by other processes. Also, if users have access to the command prompt (Cmd.exe), this policy setting doesn’t prevent them from starting programs in the command window even though they would be prevented from doing so using File Explorer.
3. Blocking occurs by filename only. If users can rename the file then it will execute.
As mentioned previously, this is but the simplest method to block existing applications from running. Other options are available if you wish a more comprehensive blocking approach.
Finish configuring the policy remembering to assign it to a user NOT device group.
Once the policy has been deployed to your fleet and these machines have been rebooted, when a user tried to run an application that you have specified as block in the policy they will receive message like that shown above.
The good thing about this policy is that you can easily extend it to include any other applications you don’t users to run on their Windows devices.
This series of posts is an approach to implementing Intune inside a business. So far, I have covered off:
1. Create compliance policies and update devices to be compliant
2. Implement LAPS to control the local device admin account that cannot be deleted
3. Remove all other accounts from local administrator group on devices
4. Setting the default search engine in Edge with Intune
5. Managing browser extensions in Edge with Intune
6. Setting an Edge Security Baseline with Intune
7. Setting an individual Attack Surface Reduction (ASR) rule in Intune
Now that Microsoft Edge has been secured in the environment, the next task will be to set Microsoft Edge as the default browser. There are number of ways of achieving this, but I’ll use the more modern Intune Settings catalog approach.
The first step in the process is to take a machine that already has Microsoft Edge configured as the default browser app and run the command:
dism /online /export-defaultappassociations:edgedefault.xml
This will produce an XML with all the application defaults for that device.
If you just want to configure Microsoft Edge as the default browser you’ll need to edit the XML file until it looks something like this:
<?xml version=”1.0″ encoding=”UTF-8″?>
<DefaultAssociations>
<Association Identifier=”.htm” ProgId=”MSEdgeHTM” ApplicationName=”Microsoft Edge” />
<Association Identifier=”.html” ProgId=”MSEdgeHTM” ApplicationName=”Microsoft Edge” />
<Association Identifier=”.mht” ProgId=”MSEdgeMHT” ApplicationName=”Microsoft Edge” />
<Association Identifier=”.mhtml” ProgId=”MSEdgeMHT” ApplicationName=”Microsoft Edge” />
<Association Identifier=”.pdf” ProgId=”MSEdgePDF” ApplicationName=”Microsoft Edge” />
<Association Identifier=”.svg” ProgId=”MSEdgeHTM” ApplicationName=”Microsoft Edge” />
<Association Identifier=”.xht” ProgId=”MSEdgeHTM” ApplicationName=”Microsoft Edge” />
<Association Identifier=”.xhtml” ProgId=”MSEdgeHTM” ApplicationName=”Microsoft Edge” />
<Association Identifier=”ftp” ProgId=”MSEdgeHTM” ApplicationName=”Microsoft Edge” />
<Association Identifier=”http” ProgId=”MSEdgeHTM” ApplicationName=”Microsoft Edge” />
<Association Identifier=”https” ProgId=”MSEdgeHTM” ApplicationName=”Microsoft Edge” />
<Association Identifier=”microsoft-edge” ProgId=”MSEdgeHTM” ApplicationName=”Microsoft Edge” />
<Association Identifier=”microsoft-edge-holographic” ProgId=”MSEdgeHTM” ApplicationName=”Microsoft Edge” />
<Association Identifier=”ms-xbl-3d8b930f” ProgId=”MSEdgeHTM” ApplicationName=”Microsoft Edge” />
<Association Identifier=”read” ProgId=”MSEdgeHTM” ApplicationName=”Microsoft Edge” />
</DefaultAssociations>
Next, you’ll need to convert that XML file to a base64 file for us an Intune policy. You can do that using the following site:
The output from this conversion should look like this:
PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4NCjxEZWZhdWx0QXNzb2NpYXRpb25zPg0KCTxBc3NvY2lhdGlvbiBJZGVudGlmaWVyPSIuaHRtIiBQcm9nSWQ9Ik1TRWRnZUhUTSIgQXBwbGljYXRpb25OYW1lPSJNaWNyb3NvZnQgRWRnZSIgLz4NCgk8QXNzb2NpYXRpb24gSWRlbnRpZmllcj0iLmh0bWwiIFByb2dJZD0iTVNFZGdlSFRNIiBBcHBsaWNhdGlvbk5hbWU9Ik1pY3Jvc29mdCBFZGdlIiAvPg0KCTxBc3NvY2lhdGlvbiBJZGVudGlmaWVyPSIubWh0IiBQcm9nSWQ9Ik1TRWRnZU1IVCIgQXBwbGljYXRpb25OYW1lPSJNaWNyb3NvZnQgRWRnZSIgLz4NCgk8QXNzb2NpYXRpb24gSWRlbnRpZmllcj0iLm1odG1sIiBQcm9nSWQ9Ik1TRWRnZU1IVCIgQXBwbGljYXRpb25OYW1lPSJNaWNyb3NvZnQgRWRnZSIgLz4NCgk8QXNzb2NpYXRpb24gSWRlbnRpZmllcj0iLnBkZiIgUHJvZ0lkPSJNU0VkZ2VQREYiIEFwcGxpY2F0aW9uTmFtZT0iTWljcm9zb2Z0IEVkZ2UiIC8+DQoJPEFzc29jaWF0aW9uIElkZW50aWZpZXI9Ii5zdmciIFByb2dJZD0iTVNFZGdlSFRNIiBBcHBsaWNhdGlvbk5hbWU9Ik1pY3Jvc29mdCBFZGdlIiAvPg0KCTxBc3NvY2lhdGlvbiBJZGVudGlmaWVyPSIueGh0IiBQcm9nSWQ9Ik1TRWRnZUhUTSIgQXBwbGljYXRpb25OYW1lPSJNaWNyb3NvZnQgRWRnZSIgLz4NCgk8QXNzb2NpYXRpb24gSWRlbnRpZmllcj0iLnhodG1sIiBQcm9nSWQ9Ik1TRWRnZUhUTSIgQXBwbGljYXRpb25OYW1lPSJNaWNyb3NvZnQgRWRnZSIgLz4NCgk8QXNzb2NpYXRpb24gSWRlbnRpZmllcj0iZnRwIiBQcm9nSWQ9Ik1TRWRnZUhUTSIgQXBwbGljYXRpb25OYW1lPSJNaWNyb3NvZnQgRWRnZSIgLz4NCgk8QXNzb2NpYXRpb24gSWRlbnRpZmllcj0iaHR0cCIgUHJvZ0lkPSJNU0VkZ2VIVE0iIEFwcGxpY2F0aW9uTmFtZT0iTWljcm9zb2Z0IEVkZ2UiIC8+DQoJPEFzc29jaWF0aW9uIElkZW50aWZpZXI9Imh0dHBzIiBQcm9nSWQ9Ik1TRWRnZUhUTSIgQXBwbGljYXRpb25OYW1lPSJNaWNyb3NvZnQgRWRnZSIgLz4NCgk8QXNzb2NpYXRpb24gSWRlbnRpZmllcj0ibWljcm9zb2Z0LWVkZ2UiIFByb2dJZD0iTVNFZGdlSFRNIiBBcHBsaWNhdGlvbk5hbWU9Ik1pY3Jvc29mdCBFZGdlIiAvPg0KCTxBc3NvY2lhdGlvbiBJZGVudGlmaWVyPSJtaWNyb3NvZnQtZWRnZS1ob2xvZ3JhcGhpYyIgUHJvZ0lkPSJNU0VkZ2VIVE0iIEFwcGxpY2F0aW9uTmFtZT0iTWljcm9zb2Z0IEVkZ2UiIC8+DQoJPEFzc29jaWF0aW9uIElkZW50aWZpZXI9Im1zLXhibC0zZDhiOTMwZiIgUHJvZ0lkPSJNU0VkZ2VIVE0iIEFwcGxpY2F0aW9uTmFtZT0iTWljcm9zb2Z0IEVkZ2UiIC8+DQoJPEFzc29jaWF0aW9uIElkZW50aWZpZXI9InJlYWQiIFByb2dJZD0iTVNFZGdlSFRNIiBBcHBsaWNhdGlvbk5hbWU9Ik1pY3Jvc29mdCBFZGdlIiAvPg0KPC9EZWZhdWx0QXNzb2NpYXRpb25zPg==
In the Intune console, create a new Device Configuration profile using the Settings Catalog:
Give the new policy a meaningful name and continue.
In the Settings picker search for applications and then select Application defaults and then Default Associations Configuration in the results as shown above.
Into the option Default Associations Configuration paste a copy of the base64 file you created from the original XML.
Complete the policy by assigning it to a group of devices NOT users. This is because the Policy CSP – ApplicationDefaults is only scoped to devices per:
This may mean you need to create a different Edge configuration policy from the one created in previous steps, if that policy was assigned to users.
When the policy has been deployed from Intune, and the device rebooted, Microsoft Edge will be the default browser for the device.
Of course, the user can still change the default back but they will need to do that after every reboot. In the future, you’d create a policy to prevent that, but for now, if the user is that desperate for their old browser they can swap. However, the next policy I’ll cover will show you how to stop other browsers (or any other application) from running on Windows devices.
CIAOPS 