Adding Acrobat Reader as an Allowed app

When you set up an Intune App Protection Policy for Windows 10 you are effectively enabling Windows Information Protection (WIP). This is designed to protect your business information being shared with non-business approved applications. This means there are a range of standard business ‘approved’ applications that are enabled by default. These are typically ‘enlightened’ apps that can differentiate between corporate and personal data. This allows them to abide by the policies set in the Intune App Protection policy you create. Applications that are not ‘enlightened’ are typically blocked from working with corporate data.

In a previous article:

Intune App Protection Policy blocking browser

I detailed how this could affect third party, non-Microsoft browsers, like Chrome, accessing the Internet. That article, also showed you how to easily overcome that issue with some minor configuration changes.

In this article I’ll look another way that ‘non-enlightened’ apps get blocked and how you can easily enable them.

image

So, let’s say that you have created an Intune Windows 10 App Protection policy like that shown above. When you do you configure a number of Protected apps as you can see. Typically, these a Microsoft products like Office, Internet Explorer, Edge and so on.

image

With that default protection policy successfully applied to a Windows 10 machine you can then see the data identified as personal or business on that machine now. The above shows you some files in OneDrive for Business, which is considered a business location. You can tell they are business files by the little brief case in the upper right of the file icon. Thus, all these files are considered to be business and are protected by WIP.

image

Let’s say that I now want to open the business PDF file with Adobe Acrobat Reader.

image

The result is, you are unable to do this because Acrobat Reader is not an ‘enlightened’ app. Thus, it is considered a personal app and is therefore denied access to business information.

image

To rectify this situation we need to return to the Protected apps section of the Intune App Protection policy and select the Add apps button as shown.

image

You then need to select the option Desktop apps from the pull down at the top of the screen. When you do so, you will probably see no apps listed below.

image

You should now enter the following information into the fields:

Name = Acrobat Reader DC
Publisher = *
Product Name = Acrobat Reader
File = acrord32.exe
Min version = *
Max version = *
Action = Allow

The most important item here is the filename for the program is entered correctly, (without any path) into the File field. In this case, the executable for Acrobat Reader is acrord32.exe.

Select Ok, once you are entered all the file details correctly here. Basically we are creating an exception for this app with WIP.

image

You should now see the program you just added in the list as shown above. Make sure you also Save your changes so they get applied to the policy.

Now with the policy updated, and the exemption for your app created, (in this case Acrobat Reader), you just need to wait a short time until the policy is applied to your machines.

image

With a few minutes, you should be able to repeat the process of opening that same business file and find that you can now view the file as shown above is the program that you couldn’t before.

You can now basically repeat the same process for any other custom applications you have that are ‘non-enlightened’ and you wish to have open business information saved in Microsoft 365 protected with WIP.

Intune App Protection Policy blocking browser

image

Within Intune I went and created a Windows 10 App Protection Policy.

image

I defined my Protected apps as you see above.

image

So the Required settings are as shown and utilise Windows Information protection (WIP). The idea is WIP is:

“Windows Information Protection (WIP), previously known as enterprise data protection (EDP), 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.”

according to Protect your enterprise data using Windows Information Protection (WIP).

After creating the policy I applied it to a test machine.

image

Most things worked as expected EXCEPT that I couldn’t use non-Microsoft browsers like Chrome! I kept getting a block message as shown above. if I removed the Application Protection policy then I could browse fine on non-Microsoft apps again. Clearly something to do with the policy was blocking Chrome browsing!

The root cause is the concept of enlightened apps in WIP.

“Windows Information Protection (WIP) classifies apps into two categories: enlightened and unenlightened. Enlighted apps can differentiate between corporate and personal data, correctly determining which to protect based on internal policies.”

from Unenlightended and enlightended app behavior while using Windows Information Protection (WIP).

As it turns out, third party browsers like Chrome are considered unenlightened apps. If you read a little bit further down that article you find the following table:

image

This explains why Chrome (unenlightened app) is being blocked because it is trying to connect via an IP address effectively. Ok, so now we know why, how do we fix the problem?

image

Turns out the fix is in the last column as highlighted above. We need to use the /*AppCompat*/ string!

image

To do this navigate to Advanced settings from the menu on the left. Then select the entry you should have there called Cloud resources as shown above.

image

Here you should see your Microsoft 365 SharePoint and OneDrive sites as shown above.

image

Add the string

|/*AppCompat*/

to the end of the line. Ensure the little green tick appears on the right hand side. Select OK to close that blade and the Save to update the Advanced settings page.

image

If you now look closely on the Advanced settings page you will see the above information box alerting you to the need for the /*AppCompat*/ string if you want TLS by personal apps that connect directly to cloud resources via an IP. You can consider a third party browser unenlightened and therefore a personal app. Thus, it is telling us to do what we just did to allow third party browsers to connect to the Internet on machines where the policy is applied. Always read the configuration page eh?

Once you have saved the updated App Protection Policy and it has been applied to the devices, you should no longer be blocked when using third party browsers like Chrome and Firefox.

Scheduling compliance reports

image

If you go into the Microsoft 365 Security portal and locate the Reports option from the menu on the left and expand it, you should find the Dashboard option. This option, when selected, will show a range of reports like that shown above. You can get more details by simply selecting the body of the tile you wish to view. Here, I’ll select the Spam detections tile to get further information.

image

You’ll now see a more focused report but you’ll also notice that many graphs have the Create schedule in the top right hand corner as shown. Selecting this allows you to schedule a report to be delivered via email.

image

By selecting Create schedule you should see a tile appear from the right with the above options that you can configure.

image

If you scroll down to the bottom of the window you will see that there is a Customize schedule option as shown above.

image

Selecting this will give you much greater options as shown above.

image

Once you have saved your schedule, you will then receive a regular email like that show above with the report you configured. You’ll note that there is also a CSV file attached that you can use for further analysis.

image

You can adjust the schedules you have configured via the Manage schedules option as shown above.

As yet, I haven’t found an easy way to configure these using PowerShell. There is way using the Microsoft Graph but that requires some setup so I’m trying to find a way just to use a pure script. If I work that out, I’ll post an article on how to do it. Till then, you’ll just have to manually go in a select and configure the reports you wish to receive regularly.

Looks like Office 365 ATP is splitting in two

Seen some chatter here in Australia about there now being two Office 365 ATP SKUs (it appeared on a pricing sheet). Everything I could find suggested that this was not the case, however a US contact pointed out to me the following web site:

https://products.office.com/en-us/exchange/advance-threat-protection

That clearly shows 2 x Office 365 ATP SKUs.

image

There is not as yet an equivalent AU page.

The main things that Plan 2 adds according to that page are:

image

Even the services descriptions for Office 365 ATP here:

https://docs.microsoft.com/en-us/office365/servicedescriptions/office-365-advanced-threat-protection-service-description?fbclid=IwAR2FQUfHsjY3Ka03RSpcGGD9bLP8RFRI5VFc7aMUAcr936QPEYLY_-ZETLE

don’t talk about there being two plans. Thus, I (and others) are somewhat confused as to which version will be included in suites like Microsoft 365 Business. My guess is that most plans that have Office 365 ATP will get Plan 1, with Plan 2 going for higher end enterprise plans. However, that is all here say for now.

So, it looks like are going to get a new ‘advanced’ Office 365 ATP plan soon (Plan 2) but we are unsure in which suites it will be available. More as it becomes available.

Updated script to now check for Sweep

pexels-photo-1433350

The bad actors out there are clever and they’ll use any means at their disposal. Normally, when a user is successfully phished the first thing bad actors do is manipulate the email handling rules of the mailbox to hide their activity.

Unfortunately, there are quite a lot of different ways to forward email in Office 365 including via the mailbox and via Outlook client rules. It was brought to my attention that there is in fact another way that forwarding can be done, using the Sweep function. You can read more about this ability at:

Organize your inbox with Archive, Sweep and other tools in Outlook.com

Sweep rules only run once a day but do provide a potential way for bad actors to hide their activity, however as it turned out Sweep was in fact being exploited by bad actors inside a compromised mailbox.

I have therefore updated my publicly available PowerShell script at:

https://github.com/directorcia/Office365/blob/master/o365-exo-fwd-chk.ps1

That will now also check and report on any Sweep rules in finds in mailboxes as well as any other forwards configured in the tenant.

Let me know if you find any other methods that this doesn’t cover and I’ll look at incorporating those as well.

Need to Know podcast–Episode 201

We’ve recovered from our 200th episode and are getting back into the swing of our regular programming with some updates, information and opinions from the Microsoft Cloud. We cover some recent important updates, especially in the area of security, as well as some news around Microsoft 365 and Azure. We also dip our toes quickly into the area of certifications but we’ll need more time to do justice to the topic. So stay tuned for that episode coming real soon. For now, sit back and enjoy as we get back to what we like doing – keeping you up to date with everything that’s happening in the Microsoft Cloud.

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-201-back-to-normal/

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

Microsoft Cloud outage information

Duplicating a Microsoft Planner plan using PowerShell

GitHub and free access to private repositories

Office 365 will automatically block Flash and Silverlight

Azure AD makes sharing and collaboration seamless for any user account

Microsoft’s Cyber defense Operations Center shares best practices

Step 3 – Protect your identities. Top 10 actions to secure your environment

Get ready for the new Microsoft 365 Security Center and Microsoft 365 Compliance Center

Microsoft 365 NIST 800-53 action plan

Using multiple authenticator apps with a single Microsoft 365 user account

One of the best ways to ensure an account is secure is to enable Multi Factor Authentication (MFA) for it. This means, the user logs in as normal with their username and password but before the login process is complete they must enter another form of verification. That form is typically via an SMS, Phone call or an authenticator application on their mobile device.

The best practice with Microsoft 365 is to use the Microsoft Authenticator app, which is available on both iOS and Android. Here’s an overview video:

The way that you set up MFA for a Microsoft 365 account is to login to the Microsoft 365 portal as an administrator and navigate to the Admin center.

image

Then do a search for MFA as shown above. One of the returned results should be Azure multi-factor authentication settings as shown, which you should select.

You should be aware that here you are configuring Multi-Factor Authentication for Office 365 which is a subset of all the features available in Azure Multi-Factor Authentication. You can see the feature comparison here:

MFA version feature comparison

All versions of Office 365 and Microsoft 365 come with Multi-Factor Authentication for Office 365 the more advanced Microsoft 365 plans, such as E3 and E5 come with Azure Multi-Factor Authentication. The discussion here is focused on Multi-Factor Authentication for Office 365 and this applies to all plans. 

image

After selection of that option, a notification should now appear from the right of the windows. Select the Manage multi-factor authentication link that appears as shown above.

image

This should take you to a list of your users as shown above. This will show the MFA status of each user. The above shows you that Alex Wilber currently has an Enforced setting, while everyone else has Disabled.

image

Select the user you want to enable on the right and then select the Enable link on the right as shown.

image

You should now see the above message. Select enable the multi-factor auth button to continue.

image

After a moment or two, you should receive confirmation that MFA is now enabled for the account as shown above. Select the close button to continue.

SNAGHTML1980450f

As shown above, you will now see that the status of that user is now Enforced. This means that they have yet to complete their MFA enrolment. Once they have, their status will change to Enabled.

image

After the user enters their login and password into the Office 365 tenant the next time they login, they will see the above message telling them they basically need to enrol in MFA.

image

They should now see a screen like that shown above. In this case we are going to use a Mobile app as a means of authentication so we select that option from the top box. In the, How do you want to use the mobile app? box select Use verification code. This will request the user to end a unique code from the authenticator app to verify their identity during login. There is also the option to receive push notifications BUT if you are going to be using multiple authenticators then best practice is not to do this, and I’ll detail why further down when I talk about the scenarios where this multiple authenticator environment can be used. For now, select Use verification code and then the set up button underneath.

image

You’ll now see a QR code like shown above that you can use with your Microsoft Authenticator app. However, using this does come with limitations.

Firstly, this method doesn’t support third party authenticator like Google Authenticator or Lastpass Authenticator.

file

If you try to use those you’ll get an error like you see above and be unable to configure the third party authenticator.

file2 (002)

Secondly, if you try and use the same QR code on another device running a second Microsoft Authenticator app then you’ll see the above error, basically telling you that the QR code has been used before (which it has).

image

The trick to overcoming both of these limitations is to select the link Configure app without notifications to the right of the QR code as shown above.

image

When you do so, you’ll get a new QR, that looks very similar but has different wording a link.

You can now use this QR to set up multiple Microsoft Authenticator apps on different devices as well as third party authenticators. You may also want to take a screen shot of this QR code for future reference if you wish to set up or reconfigure authenticator devices in the future.

Some considerations here. All devices you now use with this QR code will configure the same identical sequence of rolling numbers for authentication. Thus, when you configure multiple devices this way you’ll see that the pin numbers will be identical on all devices and will change more or less at the same time. What you have effectively achieved here is a duplication of the MFA token for that user. Is that a good thing? Best practice is to only have ONE and only ONE authenticator per account but there are scenarios I will illustrate later where having a duplicate is acceptable. However, please remember, the more tokens you have for an account, the less secure it is.

image

Once you have used the QR with all the devices you wish to use, select Next and then Next. You’ll then be prompted to enter a verification code from any of the devices (as they all show the same code now anyway) to verify the account set up. Enter the code and continue.

image

You’ll then need to enter a phone number as a fall back option. Select the Next button when this is complete.

image

You’ll then see a single app password you can use if needed, but best practice is that you shouldn’t be using these so select the Done button.

image

Now when the user logs in to Microsoft 365, they’ll enter their login and password as before but then also be prompted for a code from an authenticator. If you have duplicated the authenticator as shown above, the code on the devices will be the same and thus all you need to access that account is any of the devices just configured.

image

So where might a duplicated authenticator make sense? Perhaps as an administrator of a tenant I move between different locations and devices. Or perhaps I want to have the same code for everyone using authenticators for access. Perhaps different people need to read me the code from an authenticator on their device. There are scenarios where duplicated authenticators may make sense, so it is an option if needed.

Duplicating authenticators is probably ok if there is only one user accessing the account, but what happens when multiple need to access the one account using MFA? They should use a unique authenticator as best practice I would suggest.

To set up multiple unique authenticators (rather than just duplicates), complete the above process but just for a SINGLE authenticator app. Again, it is recommended not to enable push notifications and just use a pin code entry. Once the single MFA has been configured for the account, login to that account using MFA. Select the user icon in the top right of the screen. That should display a menu like shown above. From this menu, select My account.

image

In the window that appears, locate the Security & privacy section and select the Manage security & privacy button.

image

Now select Additional security verification at the bottom as shown above.

image

This will display two additional options as shown. Select Update your phone numbers used for account security.

image

This should display the above options, where you can configure the MFA settings for the account. At the bottom of this screen you will see that there is already one Authenticator app, which is the initial one configured for the account. To add a second independent authenticator tied to this account select the Set up Authenticator app button as shown.

image

This should display the now familiar MFA configuration window as shown above. The default option will be for push notifications. This means that any time the account logs in a push notification will be send to ALL the authenticator apps configured to this account whether they have been set up as duplicates or separate authenticators. As mentioned previously, this option also only allows a single Microsoft Authenticator configuration and no third party options.

image

Thus, best practice is again to select the Configure apps without notifications link on the right to make more authenticator options available.

image

This will again give you a slightly different screen with a QR code to configure the authenticator device. Remember, here you are not duplicating the existing authenticator that was created initially, you are creating a separate independent authenticator app that is tied to the same user account.

image

When you have completed the configuration process for this authenticator you’ll again need to verify it as shown above.

image

When you return to the Additional security verification screen you will now see two authenticator apps at the bottom of the screen as shown above.

image

This might appear confusing, but in my example I configured two different authenticator apps independently on the same device (one Microsoft, one Google). If you configure authenticator apps on two different physical devices it should look more like the above where you can tell the difference between the devices. In my experience, if there is ever confusion or duplicates, the more recent configurations appear at the top of the list if you ever wish to delete one.

image

You may want to ensure that you DON’T select the option to Notify me through app, because doing so will send a push notification to all configured and supported apps for verification. If you have different people, all with their own authenticator app configured, on separate devices, you don’t want them all getting a notification when ANY one of them attempts to login to the account. Not only is it annoying, but any of the other devices can approve the login request, even though they didn’t initiate it. You can use the notification option for authentication if you wish BUT, use it with care and an understand of the risks it brings.

Screenshot_20190115-084113_Authenticator file1 (002)

The above shows you that I have configured authentication on two separate devices (Android on left, iPhone on right). Note how the time is the same on each device, along with the account it protects. You’ll also notice that one device is using the Google Authenticator while the other is using the Microsoft Authenticator, just to show you that you can mix and match authenticators as you please. These are two independent authenticators tied to the one account as I have just shown you how to configure. Thus, if I now try and login to the configurated account, I use the one user name, plus the one password and either of the two numbers on the authenticators I have configured on these devices.

Now, where does this multiple authenticators to a single Microsoft 365 account make sense? The most common scenario is for IT resellers who need to support multiple customer tenants with multiple technicians securely using MFA. A typical scenario would be to configure a single management account in each customer’s tenant that is a global administrator for the tenant. That account would have an initial MFA authenticator enabled during set up. Then, for each technician who needs access, each of their personal devices would also be enabled for MFA on that same single customer admin account using the process I detailed above. Thus, the admin login details would be shared amongst the technicians along with the password BUT each would use their own authenticator app to gain access to the customers management account. Thus, each technician use the same username and password to access the account but a unique MFA pin code that is generated on their own personal device and is unique to them.

In the event that a technician leaves, the IT reseller could merely remove that technician’s authenticator app from the customer’s admin account and probably change the password and re-share that updated password amongst the remaining technicians. In an environment with lots of tenants and technicians, manually doing this would be time consuming. I’d be confident that this process could be scripted using PowerShell but can’t say for sure until I look at that in more detail. Stay tuned. But at least you can have multiple technicians accessing multiple shared accounts with their own unique MFA authenticator app.

So there you have it. Yes, it is possible to have multiple authentication apps providing MFA to a single Microsoft 365 account. Yes, it is possible to achieve this with both Microsoft and third party authenticator apps. Yes, it is possible to have duplicate and independent authenticator configurations for one account. And finally, YES, it makes an account LESS SECURE by having multiple authenticator apps configured against a single account, so use with CARE and THINK before you implement.

Need to Know podcast–Episode 199

I speak with Program Manager Windows Defender ATP, Iaan Wiltshire, from Microsoft all about this security offering and how it fits into the market. We discuss what Defender ATP is and what it includes, so if you are keen to hear how Microsoft is integrating threat management from the desktop through to the cloud, listen along.

Brenton and I, of course, give you all the latest Microsoft Cloud news in this first episode for 2019. There is still lots happening so listen in to stay up to date.

Also, don’t forget our invite to join us during the live recording of episode 200 on the 21st of January 2019. Just sign up at http://bit.ly/n2k200

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-199-iaan-wiltshire/

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

Iaan.Wiltshire@microsoft.com

@contactbrenton

@directorcia

MSP risks for clients

Questions to ask your MSP

Report into MSP hacking

Discounted cyber security for your client

December updates video

Ignite 2019 – Sydney agenda

Contextualizing Attacker Activity within Session in Exchange Online

MyAnalytics, the fitness tracker for work is now more broadly available

Watch Microsoft Stream on the go

SharePoint Roadmap Pitstop: December 2018

Introducing new advanced security and compliance offerings for Microsoft 365

Evaluating Windows Defender ATP

Windows defender Test Ground

Microsoft Security Blog

Defender ATP Overview