MSP Microsoft Partner MFA request

I’m not a Managed Service Provider (MSP) but there are lot of them inside the CIAOPS Patron community so I understand the challenges they have. Their role is typically to provide managed of customers technology, including things like Microsoft 365 and Azure. To perform that role they will typically need global administrator access to the clients tenant. They may need this access across multiple tenants.

Best practices is always to ensure you secure global administrator access via Multi Factor Authentication (MFA). This means, when you log into an account you’ll be prompted to verify your identity using a second factor like a code from an app on a mobile device. As I have detailed previously:

Using multiple authenticator apps with a single Microsoft 365 user account

you can have multiple ‘tokens’ to verify an account. If you want all of these tokens to be unique the current Azure AD arrangements are:

“Your users can now have up to five devices across the Authenticator app, software OATH tokens, and hardware OATH tokens.”

per – https://techcommunity.microsoft.com/t5/Azure-Active-Directory-Identity/Hardware-OATH-tokens-in-Azure-MFA-in-the-cloud-are-now-available/ba-p/276466

That arrangement is generally fine if only one person is logging into an account but is a problems if you an MSP.

Why? Because you’ll typically have multiple technicians all needing to potentially manage a customers account. You want them to do this from a single global administrator account, however you want each technician to use a different token when they login. That way, if a technicians device gets lost or a technician leaves you merely revoke that one unique token. So, in the case where an MSP needs more than 5 tokens (say 1 for MSP and 4 for technicians) there is going to be an issue. For example what happens when you have 7 technicians say? Yes, there are ways around this but they are messy, cumbersome and inefficient as well as being more insecure I would suggest.

The ask here then is for the ability to increase the amount of tokens beyond 5 for a single account. I would suggest that perhaps the best way to accomplish this is only via a unique PowerShell command and not via the GUI. I also however suggest that a better idea would be to have a new unique global admin role in a tenant, say called “Partner Global Administrator”, that would allow more than 5 tokens. No other administrator could have this enabled, only this unique account. I would also suggest that this unique “Partner Global Administrator” also only be available in tenants that use CSP program from Microsoft. Thus, if the MSP is a CSP partner they will see this special role in the tenant. They then run a PowerShell script if needed and the number of tokens available on that account is increased up to say 20.

I also think that there is number of other benefits that a special “Partner Global Administrator” role could provide but for this request I want to stick to allowing the number security tokens be increased beyond 5.

I believe this request will help the many MSPs globally who manage a significant number of tenants for customers. Making it easier for MSPs to be secure and manage multiple customers more efficiently is a win for everyone.

Using the Microsoft Graph Explorer

According to:

https://docs.microsoft.com/en-us/graph/overview

the Microsoft Graph is:

The gateway to data and intelligence in Microsoft 365. Microsoft Graph provides a unified programmability model that you can use to take advantage of the tremendous amount of data in Office 365, Enterprise Mobility + Security, and Windows 10.

In essence, it can give you access to a range of data about your Microsoft cloud environment. You can explore this data quickly and easily via a web page.

image

If you navigate to the URL:

https://developer.microsoft.com/en-us/graph/graph-explorer

You will see the Microsoft Graph Explorer as shown above. You can then select the button on the left to Sign in with Microsoft using your Microsoft 365 credentials.

image

You will then be prompted to login to your tenant as normal, after which you will see a consent acceptance as shown above. This is basically granting the logged in user access to the areas of the Microsoft Graph for your tenant. Select Accept to continue.

image

You should again see the Graph Explorer as shown above but in the top left you should now see the account you used to sign in. Just below that you will notice a hyperlink modify permissions which you should select if you want to access different areas of the Graph information for your tenant.

In this case, if you want to access security alerts from the Graph you’ll need to select this.

image

Scroll down through the window that appears and check the following two options as shown above:

SecurityEvents.ReadAll

SecurityEvents.RewadWrite.All

Then select the Modify Permissions button at the bottom of the screen.

image

You’ll then be prompted to log back into the tenant again because the permissions you require have changed and are only updated after you login to a session.

When you do re-login, you’ll be greet with a consent window again as shown above for the additional security permissions you just selected. Select Accept to continue. This consent option only appears once if you select to accept.

image

If you go back in and look at your permissions you’ll see the ones you selected are now Consented as shown above.

image

If you change the URL line in the Explorer to read:

https://graph.microsoft.com/v1.0/security/alerts

and then select the Run Query button to the right, after a few moments you will see the Response Preview area below fill with information.

image

If you take a close look at this information you’ll see that it contains security alert information. The case above from Microsoft Cloud App Security (MCAS) and reports “Activity from an Infrequent country” as you can see.

Why is this important? Couldn’t you view this same information from the admin console? Probably, but using the Graph provides a since entry point to queries for all this kinds of information, from all different sources in you tenant. You don’t need to jump between different browser windows. You don’t need to load different PowerShell modules. It is all in one place that you can query through a web request. Now, doing this via a browser and the Graph Explorer is only designed to show you what is possible using the Graph. Not only can we browse information using the Graph Explorer as shown here, you can also use PowerShell. That will be the subject of upcoming articles, and that is where things start to get really interesting!

Need to Know podcast–Episode 204

I’m back from MVP Summit and we have a huge amount of news to cover off in this episode. You’ll hear about the latest in Office 365 ATP, Windows Virtual Desktop, the new Microsoft Edge Browser and so much more. So much in fact that we had to hold a lot of material off until our next episode. However, don’t fear, you’ll get the most important stuff right here, so tune in and let us know what you think.

Podcast recording done using Microsoft Teams

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-204-the-prodigal-host-returns/

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

@contactbrenton

@directorcia

CIAOPS Patron Program

New Edge Browser – https://blogs.windows.com/msedgedev/2019/04/08/microsoft-edge-preview-channel-details/

Shared Computer Access comes to M365 Business – https://blog.ciaops.com/2019/03/19/microsoft-365-business-adds-shared-computer-activation-sca-rights/

New Office 365 ATP licenses – https://docs.microsoft.com/en-us/office365/servicedescriptions/office-365-advanced-threat-protection-service-description

Office 365 ATP Automated response – https://techcommunity.microsoft.com/t5/Security-Privacy-and-Compliance/Bolster-efficiency-of-security-teams-with-new-Automated-Incident/ba-p/392773

Window Virtual Desktop now in public preview – https://azure.microsoft.com/en-au/blog/windows-virtual-desktop-now-in-public-preview-on-azure/?WT.mc_id=reddit-social-marouill

Getting Started with Windows Virtual Desktop – https://techcommunity.microsoft.com/t5/Windows-IT-Pro-Blog/Getting-started-with-Windows-Virtual-Desktop/ba-p/391054

25% of Phishing email bypass Office 365 default security – https://www.bleepingcomputer.com/news/security/25-percent-of-phishing-emails-bypass-office-365-default-security/

Your approach to Office 365 needs to change – https://www.loryanstrant.com/2019/04/03/your-approach-to-office-365-administration-needs-to-change/

Define an IP range in Cloud App Security

image

For me, Office 365 Cloud App Security is a must have add on for any Microsoft or Office 365 tenant as I have spoken about here:

A great security add on for Microsoft 365

As with all services, once you have enabled it you need to do some customisation to get the best from it. The first thing you should do is define your ‘corporate’ IP addresses. These typically refer to your on premises environment.

The first step in defining these is to access Office 365 Cloud App security, which you can do from the Microsoft 365 Security Center. Once at the home page, select the COG in the top right hand corner.

image

That should reveal a menu like you see above. From this menu select the option IP address ranges.

image

Then select the Category option in the middle of the page and the option for Corporate.

image

You will then see an IP address ranges that have been defined as ‘corporate’ already. To add more ranges simply select the + (plus) button in the upper right. Doing show will provide you a dialog box like shown above where you can now enter the appropriate details.

Why is defining your ‘corporate’ IP addresses important? It helps prevent false positives, especially when you have multiple locations. This is handy when you start setting up rules in Office 365 Cloud App Security, you can easily use the ‘corporate’ definition to designate your known environment. It means also that when you add new locations you don;t have to go and change all your rules, just add top the ‘corporate’ IP range list.

Locking installed apps to Windows Store only

image

If you go into your settings in Windows 10 and select Apps you should see the above dialog.

image

You can see the options that are available to you as shown above. You’ll see that one of the options available is Allow apps from Store only. Although not a fool-proof security option but setting this would reduce the chances of malware executing on the desktop because the only method of installation is from the Microsoft curated Store. A random piece of malware, delivered via email say, could not execute since it doesn’t come from the Microsoft Store I would suggest.

image

Using Intune we can apply this setting across a range of Windows 10 desktops using a Windows 10 Device Restriction Policy as you see above. Simply locate the App Store option, then Apps from store only and set the value to Require as shown.

In a short period of time, once the policy has deployed, those devices will only be able to install software from the Microsoft Store, preventing installation from anywhere else and hopefully also preventing malware installations.

The good thing about this restriction is the user can still be a local administrator of their machine if you desire and installations will be restricted. The other good things is that it is policy based, which means it is easy to turn on and off as required or exclude users if need be.

As I said earlier, it is not a fool proof method of preventing malware being installed on a Windows 10 desktop, but would certainly make it much more difficult. In this day and age, we need all the help we can get to counter the threats. Hopefully, this will help.

Reporting mailbox logins

Before much of what is covered here is possible you need to ensure you have enabled all the logging in your Office 365 tenant. I’ve covered how to do that here:

Enabling Office 365 mailbox auditing

Enable mailbox auditing in Exchange Online

Enable activity auditing in Office 365

Once you have done that you will be able to track what’s going on in your tenant much better.

In the situation of a compromised mailbox, a bad actor has control of it using legitimate credentials. This eliminates looking for failed logins, because there won’t be any. It also makes the finding the bad actor tougher because their access is most likely mixed in with the legitimate user.

The place to start is to run an audit log search as I have detailed here:

Searching the Office 365 activity log for failed logins

image

However, as I mentioned, we can no longer search for failed logins, we need to use a different search criteria. I would suggest that you instead run a search using the attribute “User signed in to mailbox” as shown above. That will produce something like shown for all users. Problem with this is that times and dates are in UTC not local time and it is cumbersome to manipulate in a web page. You can of course manipulate by exporting the results to a spreadsheet for more control.

image

Unsurprisingly, I feel PowerShell offers a much better solution to check the logs and report as you can see above. The script to do this I have made freely available at my Github repo here:

https://github.com/directorcia/Office365/blob/master/o365-mblogin-audit.ps1

Basically, it will search the Audit log for Exchange Items that are Mailbox logins and send that output to a nice table via the Out-Grid command. As you can see, using Out-Grid you can now easily sort by time by clicking the column heading, and thanks to the script, the times are local not UTC!

By default, the script will check the last 48 hours but you can easily modify that to suit your needs by either entering the scope in hours or entering a start and end date in the variables at the top of the script.

With this output I can now look for suspect IPs that login into the mailbox and begin hunting from there. However, remember, all of this relies on you enable your auditing BEFORE you need it. So, if you haven’t enabled it, go do it now! You’ll find scripts to enable the logs also in my Office 365 repo here:

https://github.com/directorcia/office365

Monitor outbound spam as well

image

Hopefully everyone is well aware of the need to protect Office 365 email from inbound spam, however what are you doing about outbound spam?

Hopefully, no bad actor gains access to your environment BUT if they did and they started using you accounts to send spam email how would know?

image

For this reason, I suggest that it is a good idea to go into the Exchange Administration console, select Protection, then Outbound spam. Edit the default policy (that’s really your only option), then select outbound spam protection on the left hand side. Then I suggest you should enable the option to send an email when there is a suspicious outbound email to somewhere that is monitored.

That obviously, won’t stop outbound spam but it should at least give you a heads up that it is happening.

Windows Information Protection (WIP) in action

Windows Information Protection:

“helps to protect against this potential data leakage without otherwise interfering with the employee experience. WIP also helps to protect enterprise apps and data against accidental data leak on enterprise-owned devices and personal devices that employees bring to work without requiring changes to your environment or other apps”

It is a technology that is limited to Windows 10 desktops and is typically deployed via Intune using App Protection Policies.

image

To get there you’ll need to navigate to the Microsoft Intune service in the Azure portal and then select Client apps from the menu on the left.

image

You’ll then need to select App protection policies.

image

You’ll need to create a policy if one does not already exist.

For Windows 10 there are two policy options, with and without enrolment. The difference is that “with” enrolment the machine is effective using MDM (device management) and is typically directly connected to Azure AD. “Without” enrolment is typically just MAM (only application management) and is typically not directly joined to Azure AD. I’ll focus on a “with enrolment” option here but “without” is pretty much identical in the options provided.

image

Once the policy is in place don’t forget that you’ll also have to assign it to a group of users for it to take action. However, before you actually assign it to live set of users in your environment, you may want to take a moment to understand the ramifications of what the policy will do.

If you examine the Required settings of the policy, as seen above, you will see that you can set an option for the Windows Information Protection mode. If you are just testing things and don’t want to impact or change your environment then I recommend the Silent option. If however, you want to have the policy protections enabled but want a choice when it is applied, select Allow Overrides (recommended). If you want to be totally strict about applying the policy to your Windows 10 devices, select Block.

The domain for your tenant should appear in the Corporate identity field below. If you have any addition domains you use, ensure they are entered in this field.

image

If you then examine Advanced options, as shown above, you should see that an existing entry for Cloud resources already exists. When you drill into this, it should contain your Office 365 environment. I spoke about this location more in a previous post:

Intune App Protection blocking browser

and noted that you may need to make some adjustments to it to allow non Microsoft browsers on Windows 10 machines.

The interesting part is now if you also have on premises infrastructure you wish protected. So, imagine the Windows 10 devices are accessing data from Office 365 and from a local file server. By default, this local infrastructure will be considered ‘personal’ and won’t allow saving of corporate data there. In essence, Windows Information Protection (WIP) prevents corporate data being saved to personal locations. By default, your Microsoft 365 environment will be configured as a corporate data location but local fileservers will not be. Thus, if you wish to have your local infrastructure also classified as corporate data, then you need to specify your local DNS domain and IP range as I have done above as a Network Boundary. However, be warned, this has other implications that you need to consider which I’ll speak about later.

image

There are additional options if you scroll down further. When data that is protected by WIP is stored on a device covered by this policy, it will be protected by WIP encryption at rest. An option here in the policy allows you to revoke these encryption keys if the device is ‘unenrolled’ from Azure AD. That means, the moment the device is removed from Azure AD, any corporate data will be unable to be read since the encryption keys will be revoked for the device. You can generate and upload a recovery agent as you see above if required, however modern Windows 10 releases will actually recover the key from Azure AD if that same machine is re-joined again to Azure AD.

I have also select the option to Show the enterprise data protection icon which will appear on documents WIP considers corporate data. This is always a good way to distinguish corporate data, so my best practices is to have it there as a reminder.

You’ll also see that you can use Azure RMS (rights management) with WIP if you want. I’ll leave this disable for simplicity now, but if you want that extra protection that Azure RMS gives, then it is available if you have a license for RMS.

image

If those options are now saved to the policy and the policy is actually assigned to a set of users, once the policy has been fully assigned to a device you will see something like the above.

Here you will notice that all the OneDrive for Business files have been classified as corporate data as noted by the briefcase graphic in the file type icon. You will also note a new column as well – File ownership, which contains the domain you configured.

image

If I look at the data on a local file server I see the additional File ownership column again, with all data being owned by my domain.

Thus, all data from Office 365 and my local infrastructure is now considered corporate, not personal, data. This means that it can only be accessed using the apps I have authorised to access corporate data in the policy.

image

So how does this all work in practice? As an example, I created a new data file on the local Windows 10 device subject to the App Protection policy. This file is currently considered a personal file because it doesn’t have the briefcase graphic in the file icon.

image

I can change the file from personal to corporate by right mouse clicking, selecting File ownership and then picking the option that I want. Here’s I’d choose Work (ciaops.com) to swap that file to being considered corporate data.

image

Once I make the option to categorise it as corporate data, you’ll see the logo changes immediately to indicate the file is now managed. The file has also now been encrypted by WIP on the local device for protection. The user doesn’t see this as the WIP encryption/decryption is handled seamlessly behind the scenes on the device.

image

Now that this data is a corporate file, only apps that I have defined as corporate apps can open that file. You’ll see above that Notepad will work on both types of files, corporate and personal, but what happens if you try and open this corporate file with a non corporate app like Wordpad, which, as you can see, says it will only open personal files?

image

What happens, is that the corporate file cannot be opened by the non corporate app as shown above and I get an denied message.

image

You’ll see that I get a similar result if I try and copy data from a corporate app and attempt to paste to a personal app. Because I set the option earlier in my policy to Allow Overrides, I see the options shown above indicating that I can proceed pasting corporate data into a non corporate app but the actions may be tracked.

image

The way that I can tell whether the data in the file is being protected and considered corporate is with a small briefcase icon in the upper right as shown above.

image

If I select this icon I get further information that the app is being managed by my domain as shown.

This means in summary, that you can use WIP applied via Intune App Protection policies to ensure that defined corporate data does not end up in non corporate locations. WIP corporate data while stored on a Windows 10 device is protected at rest by encryption.

Also, remember that not all Windows 10 devices will be enrolled into your Azure AD. Some may just be associated (typically BYOD). By implementing a Windows 10 App Protection policy Without Enrolment you can protect the corporate data that is on these device as well. A good scenario here is to imagine a user’s personal Windows 10 Home machine that they use to access corporate data after hours to work on while not on their corporate joined devices. This means you can protect data even on Windows 10 Home editions machines (via a  non enrolled App Protection policy).

There are some issues to be aware of here, especially when you start mixing WIP with on premises locations. The best way to explain this is via an example I’d suggest. I set up WIP to include my local server and when the policy applied, all the data on that server was considered corporate. The apps that I used are mainly those that were set up in the Intune policy such as Word, Excel, etc as well as some custom apps like Adobe Acrobat Reader which I have detailed how to do here:

Adding Acrobat Reader as an Allowed app

Where things came unstuck a tad was when I wanted to use a not so common app like Keypass. The Keypass app lived on my Windows 10 machine but that data lived in the on premises server. Thus, the Keypass app could only open ‘personal’ data but all the data on the local file server, including the Keypass data file, was now ‘considered’ corporate data thanks to the Network Boundary settings in the policy. In short, I couldn’t open the data when I needed to. Moving the data file to other locations didn’t help either as it was still considered corporate data and the Keypass app could only open personal data. Annoying to say the least.

In the above scenario, with a small number of custom apps required to open data, you could add these custom apps to allowed list of apps in the policy so they are permitted to work with corporate data. If that becomes to hard then you probably need to evaluate whether you want your on premises infrastructure classified as ‘corporate’ data. However, failing to do that means you can’t copy from locations defined as corporate, such as Office 365, to these.

image

As you can see from the above, when I attempt to copy from my OneDrive for Business (corporate location) to a location that is considered non-corporate (local server) I get the above. Because I specified the ability to override I do get a bypass option but you’ll see when I do that, the data I copy will have it’s corporate protection removed and reverted to a personal data.

The key message is therefore that implementing WIP is something you need to think about carefully and plan prior to implementing. If you get it wrong then it will be a huge source of frustration for users, However, implemented correctly it is yet another way to protect your corporate data on both managed and unmanaged Windows 10 devices.