Modern Device Management with Microsoft 365 Business Premium–Part 1

The way that devices running Windows 10, iOS, Android and MacOS get managed with Microsoft 365 Business Premium can be daunting to those who aren’t familiar with it. The common way that it is explained is from the inside out, that is via policies in Intune first, rather than starting with the big picture and working in.

I therefore thought that I’d do my best to explain it from what I see is a more logical way to understand what is going on.

image

The starting point is the Microsoft 365 Business Premium tenant in which everything lives.

image

Inside a Microsoft 365 Business Premium tenant is an Azure AD tenant. See my article:

Deploy Office 365 and Azure together

for more information.

image

Inside the Azure AD tenant is Active Directory (AD) (i.e. Azure AD).

image

Inside Azure AD are user identities (i.e. login credentials).

image

Also inside Azure AD are devices.

image

The first type of device that can be used, are devices that are totally stand alone. They have no connection to the tenant or are joined in any way. Given a larger canvas, these would live outside the tenant, however for convenience and space, I’ll simply represent them where they are.

If you want to access Microsoft 365 Business Premium services on such devices, you typically do so just using a browser. There is no device (MDM) or application management (MAM) of these devices as well as no compliance to ensure they meet requirements like an up to date operating system.

image

The next set of devices are those that are simply ‘registered’ with Azure AD. You do this by following these steps:

Register your personal device on your organization’s network

for more information see:

Azure AD registered devices

Once a device is registered it will appear in Azure AD.

image

You typically find that in the Azure Portal under the Azure Active Directory service and then selecting Devices as shown above.

image

You will see that registered devices are displayed as Azure AD registered as shown above.

Azure AD registered devices typically have no application control (MAM), no device management (MDM) or compliance. The one advantage you do get over stand alone devices is that access to Microsoft 365 resources, like files, is easier and subject to less prompts to enter credentials.

Registered Azure AD devices are a typical scenario you see for BYOD in a pure Office 365 environment. That is, environments WITHOUT Intune.

image

The final type of devices are Azure AD Joined devices. The way that you join a device to Azure AD is covered here:

Join your work device to your organization’s network

and for more information about Azure AD joined devices see:

Azure AD joined devices

image

Azure AD joined devices will be shown as above with the join type as Azure AD joined. You will also note that these devices have MDM (device) management being Office 365 Mobile and a field for whether they are Compliant.

image

If you select an Azure AD joined device you largely get an inventory, as shown above, of that device, plus the ability to Enable, Disable and Delete the device via the top menu. Another benefit is the ability to capture BitLocker keys as well, which are shown at the bottom of the device if BitLocker is configured on the device.

Thus, the benefits of Azure AD joined devices is that they have some basic device management (via Office 365 mobile) as well as ability to be check for compliance. You can also, for example, do a device level wipe (i.e. factory reset) which you can’t do with the prior device connection methods. Azure AD Joined devices are also able to have easier access to Microsoft 365 services as with the previous two device connection methods.

Azure AD joined devices are a typical scenario you see for company issued devices in a pure Office 365 environment. That is, environments WITHOUT Intune where the company provides the device to employees.

Thus, Office 365 has a basic MDM and compliance capability which is detailed here:

Set Up Basic Mobility and Security

How you configure the Office 365 Mobile policies is found here:

Create device security policies in Basic Mobility and Security

You may need to use the direct URL:

https://protection.office.com/devicev2

to see these.

image

If you look at what these policies provide you see

image

for Access Requirements and

image

for Configurations.

Both of these options are quite limited and don’t provide any specific device OS/type targeting. They also roll compliance (Access requirements) and configuration together into a single policy, which lacks a certain amount of flexibility. In essence then, this is why the out of the box device management that comes with Office 365, known as Office 365 Mobile is ‘basic’. This is why something with more power and granularity is required if you are serious about device management.

You will note that, Office 365 Mobile management does not provide any real application management (MAM). This prevents doing things like push install to devices.

In summary, what has been covered so far is the out of the box device management capabilities you get with all Office 365 tenants. We can extend this much further using Microsoft 365 Business Premium and the power of Intune to manage devices. However, I’ll save that for an upcoming article as I want to break these concepts up into digestible chunks for people. So next we’ll take a look at how we can extend this basic device configuration using Intune.

Modern Device Management with Microsoft 365 Business Premium–Part 2

Moving to the Cloud–Part 3

This is part 3 of a multi part examination of moving to the Microsoft cloud. If you missed the first episode, you’ll find it here:

Moving to the Cloud  – Part 1

which covered off setting up a site to site VPN to Azure and

Moving to the Cloud – Part 2

which looked at creating traditional ‘dive mapped’ storage as PaaS.

It is now time to consider identity. We need to know where a user’s identity will live in this new environment because there are a few options. Traditionally, a user’s identity has lived on premises in a local domain controller (DC) inside an Active Directory (AD). With the advent of the cloud we now have Azure Active Directory (AAD) as an option as well. It is important here to remember that Azure Active Directory (AAD) is NOT identical to on premises Active Directory (AD) per:

image

What this means is that native Azure AD (AAD) can’t do some things that on premises Active Directory (AD) can do. Much of that is legacy services like Group Policy and machine joins, etc. You’ll see that Windows 10 machines can be joined to Azure AD (AAD) directly but legacy systems, like Windows 7, 8 and Windows Servers can’t be directly joined to AAD. That’s right. As we stand today, even the latest Windows Server cannot be directly joined to AAD like it can be joined to an AD on premises.

Thus, if you have legacy services and devices as well as Windows Servers you want to remain as part of your environment, you are going to need to select an identity model here that supports traditional domain joins. I will also point out that, as of today (changing in the future), if you want to implement Windows Virtual Desktop (WVD), you will also need a traditional AD to join those machines to. However, if you have no devices that require legacy services, for example if your environment is totally Windows 10 pro based with no servers (on prem or in Azure IaaS), then all you will need is Azure AD.

Thus, not every one can jump directly to AAD immediately. Most will have to transition through some form of hybrid arrangement that supports both AAD and AD in the interim. However, most transitions are ultimately aimed at eliminating on premises infrastructure to limit costs such as patching and updating things like physical servers. This will be what we are aiming for in this scenario.

In a migration from a traditional on premises environment with a domain controller (DC) and AD we now have a number of options when it comes to identity in the cloud.

1. You can maintain the on premises domain controller and AD, while using Azure AD Connect to synchronise (i.e. copy) the user’s identity to the AAD. It is important to note here that the identity in Azure is a COPY and the primary identity remains on premises in the local AD. This is still the case if you implement things like password write back that are part of Azure AD P1 and Microsoft 365 Business. Having the user’s primary identity still on premises means this is where you need to go to make changes and updates.

2. You can swing the domain controller from on premises to Azure IaaS. This basically means setting up a new VM in the Azure VNET that has been created already, joining it to the existing on premises domain across the VPN, then using DCPromo to make it a domain controller. To make it the ‘primary’ domain controller, you swing across the domain infrastructure roles via the following in PowerShell:

Move-ADDirectoryServerOperationMasterRole -Identity “Target-DC” -OperationMasterRole SchemaMaster,RIDMaster,InfrastructureMaster,DomainNamingMaster,PDCEmulator

and then DCPromo the original on premises domain controller out and then remove it altogether. This way you now have your Domain Controller and AD on the VM in Azure IaaS working with machines in the Azure VNET and on premises thanks to the site to site VPN established earlier (told you it would be handy!). In essence, this is like picking up the domain controller hardware and moving it to a new location. Nothing else changes. The workstations remain on the same domain, group policy is unaffected, etc, etc. The downside is that you still need to continue to patch and update the new domain controller VM in Azure but the maintenance and flexibility is superior now it is in Azure IaaS.

3. You replace the on premises domain with Azure AD Domain Services. Think of this like a cloud domain controller as a service. It is a Domain Controller as PaaS. This means that when you use Azure AD Domain Services Microsoft will spin up two load balanced domain controller VMs and connect this directly to AAD so the users there now appear in the PaaS domain controllers. Using Azure AD Domain Services removes the burden of you having to patch, update, scale, etc domain controllers for your environment. It also gives you a traditional AD environment you can now connect things like servers to. However, there are some trade offs. When you use Azure AD Domain Services you must start a new domain. This means you can’t swing an existing domain across onto it, like you can in step 2 above. This means detaching and reattaching all your legacy devices, like servers, from the original to new domain. You also get limited functionality with traditional AD services like Group Policy. You should see Azure AD Domain Services as a transitionary step, not an end point.

With all that in mind, you need to make a decision on what works best for your environment, now and in the future. Considering that most environments I see want to eliminate the on premises domain controller hardware as soon as possible and not replicate this going forward. That desire therefore means a migration to PaaS using Azure AD Domain Services.

The first step in this process then is going to be to ensure that all your users are in Azure AD. The assumption here is that you have already set up your Microsoft 365 environment and the users are configured in Azure AD. If you retaining an on premises domain controller you’ll need to have set up Azure AD Connect to copy the user identities to Azure AD. Azure AD is where Azure AD Domain Services will draw it’s identities when it is installed, so the users need to be there first. Once the users appear in Azure AD, next step will be to set up Azure AD Domain Services. You can kind of think of a traditional on premises domain controller as somewhat being equivalent to Azure AD combined with Azure AD Domain Services.

Setting up Azure AD Domain Services is done via the Azure portal.

image

Login as a global administrator and locate Azure AD Domain Services and select that.

image

You’ll most likely find that no services are as yet configured. Select the Add option from the menu across the top as shown above.

image

You then need to complete the details. Here we face an interesting question, what should we call this new ‘traditional’ managed domain we are about to create with Azure AD Domain Services? Should it be the same as what is being used in Azure AD already?

image

image

How you configure this is totally up to you. There is guidance, as shown above, which can be found at:

Active Directory: Best Practices for Internal Domain and Network Names

In this case I have decided to go for a sub-domain, as recommended, and prefix the new Azure AD Domain Services with the letter ‘ds’ i.e. ds.domain.com.

image

With all the options completed, select Next – Networking to continue.

image

Unfortunately, you can’t configure Azure AD Domain Services on the same subnet that has service endpoints as you can see above. You’ll see this if you configured your Azure storage to use private endpoints as we have, which has been previously recommended.

If so, then you can select the Manage link below this box and simply add a new subnet to your Azure VNET and then use that to connect Azure AD Domain Services to.

image

Before you continue to Administration, ensure that you are adding Azure AD Domain Services to your existing Azure VNET as the default is to create a new VNET, which is NOT what you want here. You want to connect it to an existing VNET you have established previously.

When you have selected your existing Azure VNET and a suitable subnet, select the Next – Administration button to continue.

image

Here you’ll need to decide which users will be administrators for the domain.  So from the documentation:

What can an AAD DC Admin do?

Only Microsoft has domain admin and enterprise rights on the managed domain. AAD DC Admins can do the following:

  • Admins can use remote desktop to connect remotely to domain-joined machines

  • Admins can join computers to the domain

  • Admins are in the administration group on each domain-joined machine

Considerations for the AAD DC Administrators group

  • Pick group members for the AAD DC Administrators group that have these needs:

    • Users that need special administrative permissions and are joined to the domain

    • Users that need to join computers to the domain
  • Do not change the name of the AAD DC Administrators group. This will cause all AAD DC Admins to lose their privileges.

The default will be your global administrators and members of a special group called AAD DC Administrators, that will be created. So, you can simple add any Azure AD user to this group and they will have admin privileges in the  Azure AD Domain Services environment going forward.

You can of course configure these permissions any way you wish but generally the defaults are fine so select the Next – Synchronization button to continue.

image

The final question is whether you wish to have all or a subset of your Azure AD users synchronised into the Azure AD Domain Service environment. In most cases, you’ll want all users, so ensure that option is select and press the Review + create button to continue.

image
image

You should now see all your settings and importantly, note the box at the bottom about consenting to store NTLM and Kerberos authentication in Azure AD. This is because these older protocols have potential security concerns and having them stored in a place other than a  domain controller is something you need to be aware of. Generally, there won’t be any issues, but make sure you are aware of what that last box means for your security posture.

Press the Create button when complete.

image

You’ll then receive the above warning about what configurations options can’t be changed after the fact. Once you have reviewed this and you wish to proceed, select the OK button.

Your deployment into Azure will then commence. This process should generally take around 1 hour (60 minutes).

image

You should see the above message when complete and if you select Go to resource you’ll see:

image

You’ll note that it still says Deploying here, so you’ll need to wait a little longer until that process is complete.

image

In about another 15 minutes you should see that the domain is fully deployed as shown above. Here you will note that two domain controllers have automatically been allocated. In this case they are 10.0.1.5 and 10.0.1.6 on the subnet into which Azure AD Domain Services was deployed. You can select from a number menu options on the left but the service is pretty basic. Most times you’ll only need to look at the Activity log here from now on.

Can you actually manage the domain controllers like you can on premises? Yes, somewhat. To do that you’ll need to download and install the:

Remote Server Administration Tools for Windows 10

on a Windows 10 workstation that can access these domain controllers.

image

You can then use that to view your domain in the ‘traditional way’ as shown above.

Thus, with Azure AD Domain Services deployed, you have a ‘traditional’ domain but without infrastructure and with your Azure AD users in there as well.

The summary of the options around identity here are thus:

1. Primary = local AD, Secondary = none (which can be linked to Azure via a VPN)

2. Primary = Azure AD, Secondary = none (no on premises infrastructure like servers to worry about)

3. Primary = local AD, Secondary = Azure AD (thanks to Azure AD Connect, but need a VPN again to connect to Azure IaaS)

4. Primary = Azure AD, Secondary = Azure AD Domain Services (which can be linked backed to on premises via a VPN)

In this case, we’ll be going with Option 4. You can see however that a VPN is going to be required for options 1, 3 and 4. That’s why one of the first steps in this series was to set one up.

With all that now configured, let’s now look at the costs involved. The costs here will vary on what identity solution you select. If you stay with an on premises domain controller only, you will need to have site to site VPN to resources in Azure. The costing for this has been covered previously:

Moving to the Cloud  – Part 1

and equates to around AU$36 per month with less than 5GB of traffic inbound to Azure. Azure AD Connect software you use to synchronise user identities to Azure AD is free.

If you move the domain controller to a virtual machine in Azure, there will be the cost of that virtual machine (compute + disk storage). The cost will therefore vary greatly on what VM type you select. I’ll be covering more about VM options in this migration in an upcoming article, but for now let’s keep it simple and say we use a A2v2 Standard VM (4GB RAM, 20GB HDD) for a single role as just a domain controller. The cost for that is around AU$76 per month. If you also still have on premises infrastructure, like Windows Servers, that need access to the domain, then you’ll also need a site to site VPN to communicate with the domain controller VM in Azure IaaS. Thus, to move the domain controller to Azure IaaS and still allow access to on premises infrastructure the cost would be around AU$112 (Azure VM + VPN). Of course, if you can migrate all your on premises server infrastructure to Azure IaaS, you probably wouldn’t need the VPN but there would then be the costs of the additional infrastructure in Azure. Balanced against this cost in Azure IaaS is the saving in local hardware, power, etc.

Again, let’s keep it simple for now and say we want to maintain on premise infrastructure but have a dedicate domain controller in the Azure IaaS so the one on premises can be de-commissioned. That means the costs would be AU$112 per month for a domain controller in Azure IaaS and a VPN back to on premises.

Finally, the last identity option is if we wanted to use the Azure PaaS service, Azure AD Domain Services, which means no infrastructure at all but also means we need to start with a new ‘clean’ domain separate from the existing on premises one. The costs of this Azure PaaS service can be found at:

Azure Active Directory Domain Services pricing

which reveals:

image

For smaller directories (<25,000 objects) the cost is going to be AU$150 per month flat. Remember, here when equating costs, there are no VMs to backup or operating systems to patch because it is PaaS. This is a domain controller as a service and Microsoft will take care of all the infrastructure “stuff” for you as part of that service. Of course, if you need on premises infrastructure to access Azure AD Domain Services, you’ll again need a site to site VPN to get there. If all your infrastructure is cloud based, then no site to site VPN is required. However, in this scenario, we still want access to on premises infrastructure so the costs would be AU$186 per month (Azure AD Domain Services + VPN).

In summary then, the configuration options/costs will be:

Option 1. Retain on premises AD = AU$36

Option 2. Move domain controller to Azure IaaS = AU$112 (estimated typical cost)

Option 3. Migrate domain controller to Azure PaaS = AU$186 per month

Going forward we’ll be selecting Option 3, because we are aiming to minimise the amount of infrastructure to be maintained and we want to move to PaaS as soon as possible. That means the total cost of the migration so far is:

1. Site to Site VPN = AU$36

2. Storage = AU$107

3. Identity (PaaS) = AU$150

Total maximum infrastructure cost to date = AU$293 per month

This means we have:

1. Eliminated the old on premises domain controller (hardware, patching, backup, power, etc costs)

2. Can connect to on premises infrastructure to Azure AD (via Azure AD Domain Services and the VPN)

3. Have mapped tiered storage locations for things like archiving, profiles, etc that are PaaS

4. We can now build out a Windows Virtual Desktop environment

The next item that we’ll focus on is setting up a Windows Virtual Desktop environment as we now have all the components in place to achieve that.

What you need for Windows Virtual Desktop (WVD)

banking-checklist-commerce-416322

Windows Virtual Desktop (WVD) is now generally available and I’ll be covering off how to set it up in upcoming articles. However, before you even login to your Azure tenant to start setting this up, here’s what you’ll need:

1. A Windows Virtual Desktop license for every user who want to use the service. These come with all Microsoft 365 and Windows E3 and E5 suites.

2. A paid Azure subscription. The majority of the cost of the WVD service will be your Virtual Machine hosts. The cost of these will vary on how many you want to use and how long they run for.

3. Azure Active Directory. The users who access the WVD service need to be in Azure AD. These users can be cloud only or synced from on premises using Azure AD Connect.

4. A Domain Controller (DC). At this point in time the WVD still requires a ‘traditional’ domain controller to allow the VMs to connect to for access. If you only have cloud users then the easiest option to achieve this is to add Azure AD Domain Services. If you already have an on premises Domain Controller (DC) you’ll need a Site to Site (S2S) VPN to link your on premises network to Azure. Note, that if you have an on premises DC that is using Azure AD Connect you can’t just add Azure AD Domain Services because Azure AD Connect doesn’t sync ‘traditional’ DC attributes. So, if you have an on premises DC, even if it is already using Azure AD Connect, you’ll still require a S2S VPN to Azure to allow the WVD service to connect VMs to that domain.

5. Azure AD tenant ID. Each Azure AD has a unique number which you can get from the web interface or via PowerShell. This is because it is possible to have multiple AD’s inside Azure and each can be configured and connected differently. The WVD service will need to know which specific Azure AD to connect to when provisioning.

6. Azure Subscription ID. The costs of the WVD service need to be applied against a unique subscription inside Azure. again, remember it is possible to have multiple independent subscriptions inside an Azure tenant. The WVD setup will need to know which subscription to bill for the service.

7. Azure tenant admin account. This will typically be a global administrator of your Azure environment. This will typically be the user who sets up, configures and manages WVD. They will also typically be an administrator of the domain that is connected to Azure AD.

8. Domain join account. This is an account that has the rights to join machines to the domain. The WVD service will create a number of VMs that need to be connected to the domain so that users on the domain can login to these machines in your WVD environment. You may wish to have a domain join user who is not a global administrator for security reasons but you should also be aware of the potential password requirement differences between your domain user and the Azure admin account. You may wish to use the same Azure admin account as your domain join account. If so, just beware of the password requirement policy for these.

image

As you can see above, the domain join account has to be at least 12 characters long, plus 3 of the following – 1 lower case character,  1 upper case character, 1 number, a special character. That requirement may be different from what your Azure AD or on premises AD requires. My recommendation would be to create a stand alone domain join account that meets the requirements and is only used for joining machines.

9. Azure Virtual Network (VNET). You’ll need a pre-existing VNET for the WVD machines to connect to. When you implement Azure AD Domain Services or a S2S VPN to connect an on premises DC, you’ll need a VNET. Make sure you understand the IP addressing and subnetting of your Azure VNET when you create it, as changing it later can be very painful.

10. Appropriate skill set. WVD requires a range of skills and understandings including:

– Identity management

– Azure AD

– PowerShell

– Azure IaaS including VNETs, VMs, Storage, etc

– Networking

– Azure backup, imaging, etc

Can you bumble you way through without these? Maybe, but life will be much easier if you do have these skills and really, if you are planning to work in the Microsoft Cloud environment, these should be considered mandatory.

There you have it, ten pre-requisite items to get sorted before you launch into creating a WVD for yourself. Get these sorted prior and your installation will be much smoother!

As I said, I’ll have upcoming articles on how to set this up, so stay tuned.

Using interactive PowerShell to access the Microsoft Graph

I recently published an article on how you can browse the Microsoft Graph directly from a web page here:

using the Microsoft Graph Explorer

The next step is to start working with the Microsoft Graph using PowerShell.

This article was recently published by Microsoft:

IT Pros can now easily connect to Microsoft Graph Security with the PowerShell Module!

and one of the confusing things I found where it talks about “Registering your application”, which you need to do successfully before you can run all the PowerShell commands.

Now if I find that confusing I’m sure others will also, as there is a bit of trick in setting it up correctly. So here is what you need to do, step by step, to actually get it all working.

SNAGHTML55ab07

Login to https://portal.azure.com using you Microsoft 365 credentials. Navigate to Azure Active Directory from the list of items on the left.

image

From the options available on the left select App registration (Preview).

image

From the pane on the right select New registration at the top of the page.

image

Give the new application a name. Here I have called it Graph. Next hit the Register button at the bottom.

image

You should now see the Overview of the app. On the right hand side save both the Application (client) ID and Directory (tenant) ID as you will need these later.

image

Here’s the bit that isn’t that clear in the existing documentation. Select the Authentication option from the menu and then on the right check the option

urn:ietf:wg:oauth:2.0:oob

From what I can work out, normally apps need to return to a location after using Azure AD authentication. However, because we will be using an interactive PowerShell session, the selected option will simply return there. Again, not really clear in the documentation I read.

You don’t need to make any other changes on the page but ensure you now select Save in the top left.

image

Next, select the Certificates and secrets option on the left. On the pane that appears on the right select + New client secret.

image

Give the secret a name and an expiry period and select Add.

image

You should then see you new secret and the actual value of that secret to the right as shown above. You will need to copy this secret value and keep it secure. treat it like a password.

You will see a banner across the top of the pane telling you that this is only time you get to see the value of the secret in the clear. After you navigate away, you’ll no longer be able to simply copy and paste the complete entry, so do it now and save the secret somewhere secure as you will need it down the track.

image

Now select API permissions on the left. You should see text Microsoft Graph is hyperlinked, so select this. This means your app already has some basic access to the Microsoft Graph, here just user read right. If the Microsoft Graph entry isn’t visible for some reason you can select the + Add a permission button at the top and then select Microsoft Graph from the following page. Hopefully however, the Microsoft Graph hyperlink will already be there.

image

There are two boxes at the top of the page. Ensure the left hand (Delegated permissions) one is selected first.

image

Scroll through the list of permissions in the bottom section until you find the heading SecurityEvents and expand it as shown.

image

Select both options as shown:

SecurityEvents.Read.All

SecurityEvents.ReadWrite.All

Once these options have been select, press the Update permissions at the bottom of the page.

image

You’ll be returned to the permission summary page as shown. You should now see the additional permissions you added displayed. You will however note a warning icon next to them as well as a banner across the top informing you that you need to consent to these. We’ll do that shortly, however we want to add some more permissions, so again select the hyperlinked text Microsoft Graph.

image

This time ensure the box on the right (Application permissions) is selected.

In essence, think of the box on the left (Delegated permissions) as permission for interactive sessions like typing commands into the PowerShell manually. that requires a user to login each time. The right box (Application permissions) however, is going to allow operations without the need for an interactive user login. Thus, we can run a PowerShell script and not be prompted for login. thus, while we are in here it is a good idea to set up both sets of permissions to give you the flexibility later.

 image

As before, scroll through the list of permissions below. Locate the SecurityEvents heading, expand this and select:

SecurityEvents.Read.All

SecurityEvents.ReadWrite.All

Once selected, press the Update permissions button at the bottom of the page to save the changes.

image

You are again returned to the summary page where you should see all the permissions added. You should see permissions of type Delegated and Application for the security events. A set for each.

image

If you scroll to the bottom of the page you should see a Grant consent section as shown. Select the Grant admin consent for tenant button below. This means all users will have the permissions you just created. If you don’t do this, then they will have to consent the first time they access the Microsoft Graph using this method.

image

You should see the above prompt asking you to confirm that you will be consenting for all users in the tenant. Select Yes to continue.

image

In a few moments, your permission screen should show all green as shown above.

image

As a final check in the portal, select the Owners option on the left and ensure the appropriate users are listed here. These people will basically have the permissions to edit the application settings, like what has just been configured.

Now you can run an elevated PowerShell window and type:

install-module microsoftgraphsecurity

Once that has installed successfully you can run:

get-graphsecurityalert

image

Because this is an interactive PowerShell session you’ll need to login to the tenant. A login prompt will appear as shown, however be careful here. You enter your user login AND the Application ID from the app just created in the Azure AD portal here. That is the really long string of digits in the Overview part of the application you just added in Azure AD NOT the user password!

image

You’ll then be prompted for the user password and MFA if configured

image

If all of that is good then you should get results as shown above. Now you can continue on with your interactive PowerShell session and all the great stuff in the microsoftgraphsecurity module. Yeah!

The main trick is selecting the urn:ietf:wg:oauth:2.0:oob option as the Redirect URI when configuring the app.

You may have noticed that we have used the Application ID here but not the Application secret. That is because this is an interactive session where the user is required to login in first. if we don’t want to be prompted for a login we need to use the Application secret. That process will be covered in an up coming article so stay tuned.