Monthly Archives: July 2019

Like it or not – Guest Sharing now includes your Privacy Policy – or LACK of Policy

On June 18th Microsoft announced in the Office 365 Message Center (“MC182498”) that guest user invites will now include your organization’s privacy policy contact information to all external guest invites. This does not apply to you if you have disabled guest access.

Sounds great but what if you don’t have privacy policies? Your new guests will receive a Shame Prompt as shown below.

Follow these instructions to update your organization’s privacy policy. https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/active-directory-properties-area

Pro-Tip – You don’t need all three configured, you can get by with just the first two. Here is what it looks like when you only have the email address fields completed.

Note: If you have the data in Office 365, you can consider piggy-backing on the Microsoft Privacy Policy so you can defer to how Microsoft stores the data (run that by your Lawyer of course!).

https://privacy.microsoft.com/en-US/privacystatement

Otherwise, there is a free privacy template at the GDPR website here: https://gdpr.eu/wp-content/uploads/2019/01/Our-Company-Privacy-Policy.pdf

Top MFA Myths and Misconfigurations

As a consultant who specializes in deploying Microsoft security solutions, I have helped deploy multi-factor authentication to hundreds of companies over the years. I’ve heard lots of excuses why companies fail to deploy MFA, and I’ve seen even more misconfigured MFA deployments. I’ve heard alarming stats that fewer than 3% of Global Administrators are enabled for MFA. Let’s see if we can bust through the blockers that prevent people from deploying MFA correctly. Here are the top misconfigurations and/or myths that I have encountered.

  • “I can deploy a single Azure Conditional Access Policy to enforce MFA”

    That is a myth. You must deploy at least a 2nd policy to block legacy authentication, because CA policies do not block legacy authentication by default. You must have a 2nd policy that specifically has the client apps “other clients” selected. You would think a ‘block access’ means block all access and that you wouldn’t have to configure something beyond that, but you must create the additional condition.

  • I can block foreign attackers from signing in by creating a Conditional Access policy to block IP addresses outside of the United States.

    This is mostly a myth. While you may deter the laziest “drive-by attackers”, any determined attackers will relay through a VM residing inside the United States (for example, a compromised IaaS VM hosted in Amazon or Azure), or use a VPN proxy with an exit node inside the United States.

    Important note: IP-Fencing policies will not block IPv6 address unless you check the box “Include unknown areas.”

  • “I can’t block legacy auth because we don’t have an Azure AD Premium license”

    This is a myth because while the premium license certainly makes things easier, there are three ways you can still block legacy authentication.

  • “I don’t need to consider Office clients when deploying MFA.”

    That may be true if you have fully deployed Office 2016 or higher, however, if you have any older clients, then you have work to do.

    • Office 2013 clients do not support MFA unless you deploy two registry keys

    • Office 2010 and older clients require the use of MFA Application Passwords, which are pure evil because they never expire, so when you go to terminate the user by resetting their AD password, most helpdesks forget to delete the MFA app passwords because its buried in a separate administrative interface. Worse yet, MFA App Passwords are enabled by default unless you turn them off in the hidden MFA admin portal (here) (most people don’t realize that ‘service settings’ is a click-able link, so they never see the option to disable MFA app passwords!
  • “We couldn’t deploy MFA at my organization because it broke our administrative PowerShell.”

    Many of the Office 365 Administrators aren’t aware that they have to download MFA–compatible PowerShell modules.
    Try the new Azure Cloud Shell, which takes the hassle out of downloading MFA modules. Azure AD and Exchange Online are already pre-loaded. Sign in from any web browser! https://shell.azure.com

    Or, if you want to use the old method, download all the modules from Terry Munro’s blog here. Setup your workstation following his walkthrough (here), and then download the all-in-one script (here) which is what I prefer to use.

  • “we couldn’t deploy MFA because we use ActiveSync”

    While it is true that older ActiveSync clients do not support MFA, you can work-around this by deploying an MFA-compatible application such as Outlook for iOS or Android. If you don’t have the means of distributing software to your end-users, or if you think you can’t ask them to install the Outlook App themselves (by the way you are underestimating your users, they know how to use the App Store!). Anyway, if you don’t want the hassle of communicating to end-users, then you could create a policy in Exchange Online that quarantines devices by default unless they are authorized by IT. You can also run a PowerShell script to determine how many of your users are using older ActiveSync clients, like the script I published in the TechNet Gallery (here).

  • “we tried rolling out MFA, but our users still had to use “MFA App Passwords” so we stopped the rollout.”

    This can happen if your Office 365 tenant has not been enabled for Modern Auth. Microsoft stated that they were in the process of rolling this out to all new tenants created after August 2017, however, I still sometimes come across customer tenants where these settings are not enabled. In short, if you are still seeing modern clients require Modern Auth, it usually means that it is not enabled for Exchange Online and/or Skype Online. So you need to enable those with PowerShell as described here for Exchange and here for Skype Online.

    Did you know? The new admin center now allows you to enable Modern Auth without using PowerShell!

    https://docs.microsoft.com/en-us/office365/admin/security-and-compliance/set-up-multi-factor-authentication?view=o365-worldwide#enable-multi-factor-authentication-for-your-organization

  • CA Policies do not override MFA Always ON. You must disable MFA-Always ON before a CA Policy will take effect, otherwise MFA-Always ON will override the CA Policy.

    I had a customer start off with deploying Always ON MFA, then they wanted to stop having people prompted for MFA from domain joined machines. They couldn’t figure out why their conditional access policies were not working. It turned out, they never went back to disable Always ON MFA. They assumed it should have been smart enough to override the Always ON MFA. As soon as we disabled the Always ON MFA setting, then the conditional access policies kicked in correctly, so that MFA prompts did not appear when they originated from domain-joined machines.

  • “we are configured to use Mobile Authenticator so we are configured according to best practice!”

    That is only true if you also disabled SMS, which is enabled by default and available for an attacker to perform a downgrade attack. Technically, SMS is better than no MFA (it’s 99% effective against drive-by attacks), but if you want to be configured according to best practice, you will go the extra step of removing SMS from being an option presented to users. PCI & NIST 800-63: SMS should no longer be used in 2FA, because SMS is only 76% effective against nation-state groups.

    Note: As stated above, this setting can be hard to find because the “service settings” option does not appear like a click-able link. Here is the direct link if you need help navigating to that setting. https://account.activedirectory.windowsazure.com/UserManagement/MfaSettings.aspx?culture=en-US&BrandContextID=O365

  • “we use Duo, RSA, OKTA or xyz MFA provider so we are protected against credential phishing.”

    This is a huge misnomer. You can be using what you think is the best user-MFA solution in the market, however, unless you have added machine-level authentication to your conditional access policy, you are vulnerable to man-in-the-middle proxy solutions such as EvilGinx2. The only correct way to defend against man-in-the-middle is to add machine authentication as an additional factor (or Intune enrollment for mobile devices). Machine authentication can be domain-join checking, certificate authentication, or FIDO2/U2F. To learn more about this vulnerability, read my other blog post (here).

  • “Conditional Access Policies are not secure because when a user roams outside the corporate network, they are not immediately prompted for MFA.”

    This loophole was fixed ~2 years ago (for Exchange Online) with the New-clientaccessrule. To learn more about it, watch Jeff Kizner’s 2017 Ignite presentation (here) starting at 7:35 through 15:55. In a nutshell, conditional access provides an authentication token if you meet the requirements at the time the token is issued. If the user roams outside the network, the token is not immediately invalidated. Exchange Online has the ability to re-check the IP address location with every packet, to avoid roaming to unauthorized network locations. It would be great if the other services like SharePoint had this but as far as I am aware they do not.

  • MFA is just too much of a user impact for us to deploy.

    I can sympathize with this sentiment: your IT department is stretched thin and you just can’t gamble with impacting productivity. Just remember this: nobody is going to thank you for reducing user impact when there is a ransomware outbreak that causes a complete work stoppage for days or weeks, or results in having to pay a massive $230 million dollar GDPR fine. Here are four things you can do to reduce the burden of the MFA rollout.

    • Avoid MFA prompts when the PC is domain joined devices (read my blog about this here)
    • Avoid MFA prompts when the mobile device or Mac OSX is managed by Intune
    • Avoid MFA prompts when the user is indie the corporate network
    • Avoid passwords and use the MFA Authenticator app for authentication ( with one important caveat here <- don’t enable passwordless auth if you use the ‘require compliant device checkbox’ )
    • Avoid MFA prompts when connecting from a device that has previously authenticated with MFA at least once (aka Trusted Device)

      If you do any of the above (or all of them), users would only be prompted for MFA when outside the network on a personal device that they haven’t used in the last 60 days! That should reduce the helpdesk calls!

Other Tips:

  • You can now change the frequency of how often users get prompted for MFA! For example, internal users can see the MFA prompt never (see #12 above) or every 1 week, whereas external users can see the MFA prompt every 12 hours.
  • Enable the new Combined Registration experience so that when users register for MFA, they also register for self-service password reset at the same time. Bonus: by enabling the new combined registration experience, you are one step closer to using FIDO2 tokens (the new combined registration is a pre-requisite). Read more here.
  • You can extend your MFA to also protect on-premises workloads like VPN. Read more (here)

I hope this helps! If you need help securing your Office 365 Environment, contact us at Hello@PatriotConsultingTech.com

How to disable diagnostic data from being sent to Microsoft in Windows 10 and Office

I have never put much thought into disabling diagnostic data from being sent to Microsoft, because I’ve always given them the benefit of the doubt that they benefit from using this data to identify faulty drivers and things that cause reliability issues in Windows. However, according to Microsoft, this data may contain “personal data” as defined by Article 4 of the European GDPR (more on that below) and therefore our friends in Europe have asked for guidance on how to disable this diagnostic data from being sent to Microsoft.

If you want to see what type of information is being sent to Microsoft, Windows 10 now includes the ability to view the diagnostic data by downloading a tool called the Diagnostic Data Viewer.

Step 1. Enable the Viewing of Diagnostic Data in Windows 10 (full documentation is here)

Step 2. Download the Diagnostic Data Viewer tool from the Microsoft App Store

Step 3. Launch the tool to review the diagnostic data that was sent to Microsoft.

According to this Microsoft Support article (here)

“Diagnostic data may contain “personal data” as defined by Article 4 of the European GDPR, but it does not contain your name, your email address, or any content from your files. All diagnostic data Microsoft collects during the use of Office applications and services is pseudonymized, as defined in ISO/IEC 19944:2017, section 8.3.3.

According to this Microsoft article (here) this is what the basic data is:

We use Basic diagnostic data to keep Windows devices up to date. Microsoft uses:

  • Basic error information to help determine whether problems your device is experiencing can be addressed by the update process.
  • Information about your device, its settings and capabilities, including applications and drivers installed on your device, to ascertain whether your device is ready for and compatible with the next operating system or app release and ready for update.
  • Logging information from the update process itself to understand how well your device’s updates are proceeding through the stages of downloading, pre-installation, post-installation, post-reboot, and setup.
  • Data about the performance of updates on all Windows devices to assess the success of an update’s deployment and to learn device characteristics (e.g., hardware, peripherals, settings, and applications) that are associated with the success or failure of an update.
  • Data about which devices have had upgrade failures and why to determine whether to offer the same upgrade again

 

However, if you want to block the transmission of this diagnostic data, on a per machine basis you can go into Windows 10 and change the default ‘enhanced’ to ‘basic’


 

To disable this on all machines, deploy the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DataCollection

Create a new a 32-bit DWORD value named AllowTelemetry and set it to 0

Windows 10 build 1511 and newer disable these two services:

Connected User Experiences and Telemetry
dmwappushsvc

Then restart the computer.

 

Now as it relates to Office, you need to go into the settings of the Diagnostic Viewer and enable the Office data viewer toggle as shown here:


For Office 365 ProPlus, Microsoft documents the diagnostic information sent to Microsoft (here)

You can manually turn this off on a per user basis as shown below, or you can disable it for all users using the config.office.com website also as shown below.

Office 365 ProPlus Manual Configuration

File Account > and under Account Privacy select Manage Settings.


 

Office 365 ProPlus Configuration for all machines (use config.office.com as shown below)

 


 

 

And for Windows 7, the July 9th 2019 security patch added telemetry. Disable or delete these scheduled tasks after the security patch installation but before rebooting the computer.

\Microsoft\Windows\Application Experience\ProgramDataUpdater
\Microsoft\Windows\Application Experience\Microsoft Compatibility Appraiser
\Microsoft\Windows\Application Experience\AitAgent

Reference: https://www.howtogeek.com/428265/windows-7s-july-2019-security-patch-includes-telemetry/