Office 365

Office 365

Office 365 Account Breaches – Detection, Investigation & Remediation with Cloud App Security

images (1)

Every day around the world, companies are compromised by phishing emails, brute force attacks, and email hacks. Admins now have to work harder than ever to protect and defend their Office 365 environments. In the unfortunate case of an attack, they must figure out how the breach was made, what the hacker did and what data was stolen. Browsing Office 365 audit logs after an attack can be a highly time-consuming and costly process for an organization, especially if you don’t know where to look or how to remediate the incident. As a precautionary measure, companies should have security playbooks in place, for example, I recommended having Account Breach & Search and Destroy Playbooks.

In my previous blog series ‘How to report on suspicious emails Part 1 and Part 2′, I talked about phishing attacks, preventative measures using the Report Message Add-in, and how to deploy this in your Office 365 tenant.

In this three-part series, I walk through how to detect, investigate and remediate account breaches with Cloud App Security and the Hawk PowerShell Module. This first blog of this series is looking closely at ‘Detecting Account Breaches in Cloud App Security’.

Part 1 – Detecting Account Breaches in Cloud App Security

Let’s start with covering what Cloud App Security is and what it can do to assist you in detecting account compromises. Microsoft Cloud App Security is a Cloud Access Security Broker (CASB). It allows you to have visibility into suspicious activity within your Office 365 platform, to investigate, and act against security issues that arise either manually or by automation. You can configure alerts and notifications to suspend an account, or, force the account in question to log back on to Office 365 depending on criteria built within the policies. Cloud App Security is available to tenants with an Office 365 Enterprise E5 license. If you don’t have an E5 license, you can purchase Cloud App Security as an add-on. Please note, you must also be a Global Administrator or Security Administrator or Security Reader to use Cloud App security.

If you already have E5 licenses or the Cl­­oud App Security add-on, then login to Cloud App Security portal and follow the below steps:

  1. Browse to and sign in with your work admin account.
  2. Click the Alerts Drop down and select Manage Advanced Alerts
Manage advanced alerts
  • Click on Go to Office 365 Cloud App Security
  • You will then be taken to the Policies Page within Cloud App Security
Cloud App Security

Cloud App Security Policies and how it works

Cloud App security uses Entity Behavioral Analytics (UEBA) and Machine Learning (ML) to allow tenants to start using these alerts as soon as Cloud App Security is enabled. Once enabled by license or subscription purchase there is an initial seven day learning period to gain an understanding of the users in your environment. Anomalies are detected by monitoring the user’s activities within Office 365. The overall Risk Score is calculated by looking at over 30 different risk indicators. Examples of these are Risky IPs, Admin Activity, Impossible Travel, Location, Login Failures etc. If something from the user happens outside of their normal baseline an alert can be triggered.

Microsoft provides a base set of Anomaly Policies and templates for starters. These base policies are created to detect ransomware, admin activity from untrusted IPs, impossible travel activity, malicious inbox rules, and more. In this article, I’ll be predominantly focusing on Activity and Anomaly Detection Policies.

Detecting Compromises with Cloud App Security Policies

Impossible Travel Activity Alert

  1. Within the Cloud App Security Policies default page, find and click on Impossible Travel to review the baseline settings

Each Policy can be configured to your entire organization or certain users or groups. I recommend that you leave the base policies in place and restrict certain apps or users if needed. To get the most out of these alerts wherever you are, you should configure the Send alert as Email and Send alert as text message. Also, if you want to be able to configure these policies faster next time, I would configure the Use your organization’s default settings.

With a global organization, the Impossible Travel Activity Alert is very effective in demonstrating the user traveling from one country to another. The general rule of thumb is to contact the user when these alerts have been triggered, so you can confirm whether they are in fact traveling.

Now, let’s look­ at an example of an Impossible Travel alert from a compromised account.

If you have the alert settings configured in the policy, you will receive an email and text message if configured like the below:

Microsoft Cloud App Security Alerts

Within the Cloud App Security Page select the Alerts Bell on the left pain.

Cloud App Security Alerts Bell

Below, you can see there are two alerts for this user, so the details of this Impossible Travel Alert need to be reviewed. The main areas here are in the Activity Log section, the user shows to be in the United States at 8:16 and then 2 hours later a login was detected in the Netherlands. This alert raises a concern because it is impossible to travel that far and log in again in that amount of time.

Offic e365 Cloud App Security Alerts

The Impossible Travel Alert is the first step in detecting account compromises as it continues to alert you on impossible travel. I would then recommend following up and confirming with users as to whether they are traveling; most people tend to respond quickly to security inquiries. If the user confirms they are not traveling, you can take immediate remediation action and have the user reset their password quickly before any further damage is done by the attacker.

Location Based Logon Activity Policy

Creating a location-based Activity Policy is another highly effective way of locating compromised accounts. In addition to Impossible Travel Activity, I recommended creating an Activity Policy in countries that you don’t have an office or facility locations. Recently, in my organization, we experienced multiple account compromisations coming from Nigeria. This was alarming because we don’t have any facility locations there, and after multiple compromises, we created a detailed policy just for this country. Upon receiving approval from Legal and Risk management it was agreed that any logons coming from Nigeria would result in an immediate account suspend action being enforced to prevent further access and harm on the account. When you use the suspend action for any policy you are preventing the user from signing in to Office 365. I will discuss the Suspend Action further in Part 3 of this series on remediation.

Below are the steps to create a new Activity Policy:

  1. Select the Control pane and Select Policies.
Office 365 Cloud App Security
  • Click on the Create Policy dropdown and Select Activity Policy.
Office 365 Cloud App Security window
  • In the Policy Template leave this as No Template
  • In the Name type in what you want to call the policy e.g. Nigeria Logon
  • In the Description enter some information about the policy e.g. Nigeria Logon – Potential compromise
  • In Policy Severity set this to High
  • In Category set this to Threat Detection
Edit activity policy
  • Then go to Create filters for the policy, set Act on to Single Activity
  • In the Activities Matching all the following click select a filter and type and select Location
  • In the Select Countries type and select the country you want, e.g. Nigeria
  • Configure the Alert settings to meet ­­­­your requirements
  • Under Governance Select the drop-down and check the Suspend user box (you can enable this after governance approvals from your legal and risk teams)
  • Finally, click the Create Button

What I like best about creating new Activity Policies, is in the Activity Matching section you can click on the Edit and Preview Results in the right corner. This will show all activity in the past that meet the criteria you are setting now and alert you for future matches. This ensures the Activity Policy will work without the need for testing.

activities matching the following

The example of Edit and Preview Results below shows alerts previously triggered for Nigeria location logins.

Suspicious Inbox Manipulation Rule

The third Anomaly Detection Policy I recommend is the Inbox Manipulation Rule policy. What this does is helps to identify if an attacker is already in the system just after logging in. It’s common for attackers to create inbox rules to either delete new emails being sent or to redirect them based on their criteria. Below, is an example of a real manipulation inbox rule alert that was triggered in a recent account compromise. You can see that the attacker has created a DeleteMessage rule named “NNEBBBBB”. Within the alert, it also shows in the activity log section the run command: task new-inboxrule.

Office 365 Cloud App Security alert

Seeing malicious inbox rules should flag as a potentially compromised account. To see what it is doing, you will need to investigate the rule that was created.

In part two of this article series, I will do a technical deep dive into the Investigation Process using Cloud App security and the Hawk PowerShell Module. I hope this article helps you to detect account compromises in your environment. Thank you and stay tuned!

read more
Office 365

Configuring Microsoft Cloud App Security to protect Exchange Online

download (2)

More than ever before, end users expect flexibility and functionality at work to enable them to work when they want, where they want, and without a limited user experience. However, this challenges traditional IT security controls, such as blocking access from non-corporate machines, or outside the corporate network. Microsoft Enterprise Mobility + Securityprovides new ways for organisations to meet their users’ increasingly demanding requirements, whilst not compromising on data security.

Microsoft Cloud App Security (MCAS) is included in Enterprise Mobility + Security E5 and builds upon the mobility and security functionality that comes as part of E3, predominantly Intune and Conditional Access.

What is MCAS?

MCAS is Microsoft’s Cloud Access Security Broker solution, which allows you to monitor the cloud applications and services being accessed and adopted by your users, whilst also providing increased protection for data across cloud applications. More simply, using the MCAS Proxy, you can apply deeper more granular control over the data stored in your cloud applications with the least possible impact on your end users.

The monitoring capability, Cloud Discovery, allows you to monitor and identify your own corporate cloud environment as well as evaluate the adoption of non-sanctioned cloud apps your users are utilising, and allow or deny access to these apps. You can use APIs for supported third-party services to monitor and provide governance of those apps outside of the Azure AD/Office 365 stack. Using Conditional Access App Control (also known as MCAS Proxy) you can monitor and control use of cloud apps in real-time.

In this article, I will investigate what MCAS actually is, and what benefits it offers above the more simplistic controls within EMS E3, and then I will explain how you can implement Azure AD Conditional Access to protect users with MCAS, and how you then go on to protect your data – in this case within Microsoft Exchange Online – using MCAS Session Policies.

Conditional Access App Control

The functionality within MCAS which enables the restriction of behaviourin web applications is Conditional Access App Control. This can be implemented with any apps configured with SAML or Open ID Connect with single sign-on in Azure AD. This functionality has recently been extended to Office 365 apps (Exchange Online, Yammer, OneDrive for Business, SharePoint Online and Microsoft Teams) in Preview.

What is the difference between MCAS and OWA Mailbox Policies?

One of the key questions I had from an Exchange Online perspective when first investigating MCAS was why I would use this EMS E5 (the more expensive option) capability over the native protections within Exchange Online, perhaps alongside Conditional Access which comes as part of EMS E3.

The simple answer is the improved granularity of the control.

Using OWA Mailbox Policies, you either allow access to all attachments completely in OWA (open and download), view-only (just open in Office Web Apps) or block access to all attachments completely.

Using MCAS Session Policies, you can target more specific usage, such as device type (PC, mobile, tablet or other), specific geographic locations, or even specific ISPs. More importantly, you can also target specific file properties, so rather than restricting your users’ access to all files received as attachments, you can instead treat differing files alternatively, either targeting classification labels, file extensions, file names or file size. Then, you can reach another level of granularity again by using Content Inspection, applying controls on specific sensitive data types, for example, protect files that contain an email address to ensure you’re not sharing Personally Identifiable Information (PII), or write custom expressions to monitor what emails are being exchanged regarding a confidential project.

Those who are eagle-eyed reading this may have noticed I’ve hinted the final key benefit of MCAS. This being rather than just blocking access to the files sent in an email, you can apply protection to files accessed using OWA automatically based on the criteria specified above, using Azure Information protection Classification Labels (currently only labels that apply protection and are within the Global policy are supported) and block download of any files that can’t be protected – i.e. .txt files.

How do I enforce MCAS protection?

You can now configure conditional access policies in Azure AD to applyMCAS protection. When configuring your CA Policy, under the Session Access controls, select use Conditional Access App Control.

There is also a link here to the Cloud App Security portal.

Enforce MCAS protection using the Cloud App Security Portal.

How do I configure MCAS protection?

To demonstrate the capabilities, I am going to create three MCAS Session Policies to enforce different behaviours:

  • First, I am going to apply a protection label to any documents which makes reference to Project X-Ray accessed from a non-domain joined machine, to ensure if they are downloaded, they will remain restricted to only members of the specified group via AIP Protection.
  • Second, I am going to create a policy that blocks files download from a non-domain-joined or compliant machine.

For my first policy I will start by creating a new Session Policy from the Policies screen.

Create a new session policy.

Then, I Create policy > Session Policy.

Create session policy.

In the Create Policy window, I will configure my policy. First I will configure general details such as Policy nameDescription and Session control type. For these policies, I will be selecting Control file download (with DLP) from the drop-down list.

Control file download.

Under the Activity source section, I configured the filter to match the requirement of applying the policy when the machine is not domain joined.

Activity Source.

I then configure the Content inspection section, which is where I will identify the data to be protected. This is where you could use Sensitive Information types, but I am simply using a text string custom expression.

Configure content inspection.

In some cases, you may want to protect anything that is encrypted and therefore can’t be scanned, but in this case, I am not applying this.

Next, you specify the action to be taken on the file. In this example, I want to block access to the file.

Block access file.

Once these settings are all configured you can click Create to create the policy. Note, that you see the warning message confirming that this is only applied to browser-based apps.

Activity source.

For my second policy, I will configure the same settings, with different values.

Under the Activity source section, I have configured the filter to match our requirement of applying the policy to machines that are not domain-joined or compliant.

Configure filter in activity source.

In this case, I will not configure content inspection and will simply set the action to block download with a custom block message.

Action to be applied when user matches policy.

Click Create, and this is all the policies configured.

What is the user experience?

The first thing the user will notice is a warning that their access to OWA is being monitored by MCAS.

The next thing is that the URL for OWA will be changed from to (in my case as my tenant is based in the EU).

Email example

Now, let’s look at what happens when we trigger our Session Policies, first looking at the Project X-Ray policy. When I open an attachment which contains Project X-Ray information from OWA, I can view this in the browser and I’m still able to download it. When launching the document after download, the first thing you will notice is this during Word’s start-up process:

Amended Word startup process.

The fact that your machine is configuring “Information Rights Management” is the first sign that the policy has been applied, and the document has been protected. When we open the document, you can see the policy has applied correctly:

Policy correctly applied.

The SECRET – PROJECT X-RAY protection template has been applied, and when we look at the permissions you can see the restrictions this puts in place.

Secret Project X-Ray template applied.

So in this scenario, you could have a set group of people who you have set specific permissions. This means they can download their documents and work on them so long as they are signed in to their Office 365 account (by applying this restriction in the AIP label), giving these users more flexibility than before had they not been using their corporate machines.

Finally, the behaviour when the second policy is applied, this in turn blocks the downloading of files.

Again, you can open the attachment within OWA/Office Web Apps, and the option to download the file still displays within the email. This may be one of the reasons organisations prefer the user experience of OWA Mailbox Policies because if you block the download of attachments from OWA the option is removed from the interface. For users, this is less confusing, but obviously it has to be outweighed against the flexibility benefits.

When you attempt to download the file, you are shown a Download blocked notification including the custom wording we configured in our policy above.

Download blocked notification.

You will also notice a txt file being downloaded which contains further information on the file. This is because where the MCAS Proxy sits in the navigation process, something must be downloaded at the time the proxy intervenes in the download. Consequently, this txt placeholder is downloaded and contains some original file information and the custom block message again.

The file was blocked code.

This article is just a brief introduction to some of the capabilities of MCAS Proxy with Exchange Online and how they are implemented. Over the last 12-18 months, we have seen there has been a bigger uptake of Office 365 E5.

As a result of this, there have been greater monitoring and protection capabilities with Cloud App Security, so I won’t be surprised to see more organisations implementing these technologies in their environments.

read more
Office 365

Office 365 and Azure Among Microsoft Services with Account Problems


Microsoft recent poor record of service upkeep is continuing. Just last week, the company’s Office 365 subscribers in Europe could not get into their mailbox for a whole day. Fast forward to this week and Microsoft is trying to solve a similar problem.

Once again Office 365 is part of the prison. The new issue is wider spread in terms of location and affected services. ZDNet reportsthe issue is not just in Europe this time and is being described by users all over the world.

Alongside Office 365, the latest problem is also being observed in Dynamics 365 and Azure platforms. It seems the problem is the same as last week. Users are reporting being unable to log in to their accounts.

On its status pages for Azure and Office, Microsoft confirmed the issue and said it started at 21:00 UTC last night. It is worth noting that the problem has been resolved and both status pages now show no problems.

“Engineers have identified an issue with Level 3 as an internal network provider,” the OS maker said. “Steps have been taken to fail over to an alternative DNS provider.”

Cross-Service Problems

Microsoft says its Azure Active Directory (AAD), the identity and access cloud management tool. Used as an account authentication tool for cloud services, it seems AAD is causing problems for Microsoft account holders on the cloud.

Microsoft returned this morning at 06:15am to confirm it has fixed the problem:

“We’ve fixed the delay some customers may have experienced accessing cloud resources,”a Microsoft spokesperson said in a statement sent to ZDNet.

read more
Office 365

Microsoft 365 Gains New Features During December


There are some big changes potentially coming to Microsoft 365 with a reported free version set to arrive next year. While we wait to see if that happens, Microsoft is continuing to update the bundle. The company has today announced its December update for Microsoft 365.

In a normal month, Microsoft will detail monthly updates at the end of the month. However, with the holidays in December, the company has pulled the trigger early.

Microsoft 365 is getting some handy updates across several Office applications. On Word, Excel, and PowerPoint, Microsoft has rolled out its Dark Mode for macOS Mojave users.

PowerPoint seems to be the focus of the new update, following recent changes made to the app for non-Microsoft 365 users. Among those changes are live real-time captions, which have also recently arrived on Skype. This feature supports 12 spoken languages and places text onto the screen from over 60.

Also on PowerPoint, Microsoft has added the ability to reuse slides from other presentations and from across an organization.

Once again, Microsoft is leveraging AI and Graph to work as part for a feature in Word. The app will now provide acronym definitions whenever you see an acronym you don’t know. To access the feature, enter the Review tab in Word to find the definition.

read more
Office 365

Exporting Office 365 Group membership to a CSV file


As part of day to day administration, or as part of a migration project, exporting information from your Office 365 tenant is a common requirement. As Office 365 Groups is one of the core foundations for services like Microsoft Teams, you may need to retrieve information not only about the group, but also about group members and owners and share that with others.

For example – if you need to perform a tenant to tenant Office 365 migration then being able to provide reports on current group membership, so that you can plan migrations and update the target groups will require exports of membership information. Or, you might want to simply provide a weekly report on Office 365 Group membership as part of your efforts to track usage and adoption.

A great way to do this is by using PowerShell. You can use the Exchange Online PowerShell module to easily collect Office 365 Group information, and then after getting the list of groups in your tenant, interrogate each group to retrieve membership and owner lists. In some cases you might use that output in another script, but in this example we’ll create a custom CSV file that’s not only easy to read and edit in Microsoft Excel, but can also be re-imported after editing for further scripting.

Before we dive into the PowerShell scripting, we’ll take a quick look at what to expect once the output is open in Excel. You’ll see in the example below we’ve exported some key information, like the group’s SMTP address, it’s identity, display name and then two columns – one for the members and another for containing owners:

One thing you’ll also notice is that for the list of members, we’ve used a multi-line row in the CSV file. By default, when you export an array to a row using PowerShell, you’ll usually see System.Object[] rather than the actual list itself.

To avoid this issue, we select a useful unique identifier for each member, and concatenate all those members into a single item, separated by a new line. This is good for user visibility in Excel, and also easy to convert back into an array if we re-import the file.

Example PowerShell script

In the example PowerShell script below this is all performed through a few simple steps:

  • We first retrieve all Office 365 Groups in the tenant using Get-UnifiedGroup, setting the ResultSize parameter to Unlimited.
  • We then use a for each loop on the resulting $Groups object to iterate through each group.
  • Within the loop, we then retrieve the list of members and the list of owners for the current group. For each of those, a sub-loop extracts just the members or owners SMTP address and adds it to two temporary arrays, one for $MembersSMTP addresses and one for $OwnersSMTP addresses.
  • Next, we create a new custom object and assign it to the $GroupsRow variable. This object represents the current line in the resultant CSV file. We address the SMTP address, Identity and Display Name, and then for both the Members SMTP addresses and the Owners SMTP addresses lines, we concatenate the values in each temporary array – using a newline character (`n).
  • Finally, we export the results to a CSV file.

Download the Export-O365Groups.PS1 script from GitHub here.

Using the script itself is straightforward – after connecting to Exchange Online, execute the script (named Export-O365Groups.ps1 in the example below) and use the -CSVFilename to specify the output file to create:

Re-importing the CSV file for use in PowerShell

You might choose to re-import the data for further use in scripts. For example, if you are performing a tenant to tenant migration, then you might edit the membership lists and map the source and target group and member names across (in fact, the idea for this script came from a larger script written to manage that exact process).

In those cases you’ll want to re-import the CSV file data and convert the new-line separated membership lists back into PowerShell arrays. This is very straightforward, as shown below:

When you then view the $Groups object you’ll then see the lists of members and owners are back in the form used in the script prior to conversion to CSV-compatible lines:

read more
Office 365

Configuring Skype Room Systems for Microsoft Teams

download (1)

The answer really starts with the question ‘Are you trying to allow a roomsystem to have video with Microsoft Teams?’  and if there is any variation of ‘yes’ in your answer, then right now there is only one supported option and that’s to use a Skype Room System.  At the time of writing this article, there are no systems other than the Skype Room System that allows for native and supported usage of Microsoft Teams in this way. Skype Room Systems come in several flavours and a really good place to start is the Microsoft Teams devices shop here. This will help you understand what options there are and what has been successfully passed as a supported endpoint. The shop is not limited to Skype Room Systems but also includes items such as conference phones, desk phones, speaker phones and headsets. In this blog post, we are going to help walk through the provisioning of a Skype Room System, which is the same process that we would follow if we wanted to enable a speaker phone that is a Teams-enabled endpoint.

Currently the available meeting room systems are available from:

  • Crestron
  • HP
  • Lenovo
  • Logitech

I would expect to see Yealink also enter this area very soon. Each brand has their own certified and tested solution and it is possible to mix and match aspects of the Skype Room System such as allowing a Logitech Camera work with a Crestron SR or having a HP Elite Slice SRS work with a Polycom USB PTZ camera and a Polycom Trio conference phone.  HP and Lenovo have the added ability to work as an audio device for a smaller or ‘huddle’ meeting room, which will save on the desk real estate being taken up by the addition of the Skype Room System.

Configuration Outline:

The following outline describes the required steps to provision a Skype Room System account in Office 365.

Workflow for provisioning a Skype Room System account

Require a new Skype Room System account:

One of the first steps, could be creating all the required accounts needed, you may already have some or all of the accounts you need. For example, there may be an existing star phone device such as a Polycom Trio 8800 or Yealink CP860 that is configured as a voice only endpoint.  If this device has been provisioned properly there may be a requirement to utilise this existing account.  This guide will ultimately assume that no existing equipment or accounts are in place and will walk through this process as if we need to create everything from fresh, as if it’s a greenfield meeting room and Skype for Business Room System account. Then, we’ll take a look at how to provision the account to work with Microsoft Teams. Let’s get started.

Configuring Exchange Online:

One of the initial steps that needs to occur is the creation of the Meeting Room email account.  This can be completed using the following commands using the Microsoft Exchange Online PowerShell Module.

Create new resource mailbox:

Once you are authenticated you will need to create the Skype Room System mailbox:

What do these variables mean?

$rm is the name of the account that is being created for the meeting room

$newpass is the password that is going to be assigned to the account

The next process is to give the mailbox a name – this can be any useful name that users will identify the device or the room as.  This is the same name that we will use when we want to select the room within Outlook as an available resource.

You may be warned that the replication hasn’t yet occurred, this is standard and seems to happen every other creation. The importance here is to be patient and allow for the replication to occur, it can take a few minutes for the account to be created and configured within Azure AD and Exchange Online.

Set the mailbox properties:

I also like to create a MailTip when I’m creating the mailbox, this will ensure that when booking the room, people will get a response back from their booking and utilise Skype for Business Room System when it’s relevant to do so.

Connect to Office 365 PowerShell Session:

From within the same Microsoft Exchange Online PowerShell Module you can enter:

You will be prompted to authenticate as you have before when we created the Mailbox.

Set account password to never expire:

Assign correct licenses through the Admin Centre

For the Account to work properly as a video endpoint, a Skype for Business plan 2 or plan 3 must be assigned to the account.  Assigning a full E3 plan is overkill for what is required for the account.  In addition, assigning a Common Area Phone license is not supported for Skype for Business Room Systems.  Each individual license must be applied.  If the Skype for Business Room System requires the ability to make inbound and outbound calls from a Public Switched Telephone Network (PSTN), two additional licenses will need to be applied, these are Microsoft Phone System and a Calling Plan.  For most cases a domestic calling plan will be sufficient, however, it is important to note that this should be reviewed on a regular basis to assign the correct calling plan to the meeting rooms that make calls regularly. More information about these plans can be found here.

Once the correct Skype for Business licenses have been applied, the device will start to work and function as a Teams Meeting device as well.  This process will work at the time of writing, but it may need to be reviewed at a future time, when Skype for Business Online becomes more engrained into Microsoft Teams. At this point, the licensing steps may need to include Microsoft Teams, however at the moment the advice within Microsoft best practice is to assign the Skype for Business Online (Plan 2) Licenses as outlined above.

read more
Office 365

Office 2019 vs. Office 365: What’s Really Happening


Microsoft’s release of Office 2019 this week has triggered a bit of confusion in the user community. Your questions are understandable, as this release marks an important change in the way that Microsoft makes and sells its office productivity solutions.

And if this release is confusing to you, take heart: It’s confusing to just about everyone, myself included. So I spoke with Microsoft corporate vice president Jared Spataro at the software giant’s Ignite 2018 conference. And he neatly cleared up the confusion.

Office 2019 is the latest version of Microsoft’s standalone Office productivity suite. It’s what the firm now calls the “perpetual” version of Office, or what old-timers like myself might still call “on-premises.” And that’s for good reason: As Spataro told me, Office 2019 doesn’t offer any of the cloud-connected features that Office 365 subscribers would see using the exact same apps. Thus, it is, in fact, a subset of Microsoft Office compared to the versions of the suite—or, the applications—that Office 365 subscribers see.

This is an important distinction: For the first time ever, a major new release of Microsoft Office provides less functionality than what current users—in this case, Office 365 subscribers—already have access to.

This isn’t the way Microsoft markets the product, of course. And it’s fair to say that Office 2019—e.g. the perpetual version of Microsoft Office—provides more functionality than its predecessor, Office 2016.

For Office 365, Microsoft quietly dropped the year-based version numbers from the Office desktop applications. You can see this when you start up Word or one of the other applications: The about box that pops up while it loads will read “Office 365” rather than the version number (like “2016” or “2019”).

read more
Office 365

Integrating Windows Defender ATP Device Threat Levels with Intune Compliance Policies


In my recent post about Windows Defender ATP I discussed how we should assume that a breach can and will occur. Even secure Windows 10 computers can be compromised by a determined attacker using advanced tools, although in may cases it is basic attacks such as social engineering that lead to breaches.

When Windows Defender ATP detects suspicious activity on one of your endpoints, it applies a “machine risk” rating, such as “Medium” in the example below.

When Windows Defender ATP detects a threat, it has the capability to automatically respond and attempt to remediate the threat. But in some cases, automatic remediation will take some time, or it will be unsuccessful and require manual investigation that takes longer. During that investigation, it makes sense to blocking access to corporate apps and data from the compromised endpoint.

You can achieve that by enabling Windows Defender ATP integration with Intune. The Intune connection is enabled in the Windows Security Center.

Within the Intune blade of the Azure Portal, you can then enable the connection of supported Windows devices to Windows Defender ATP, allowing their device threat level to be evaluated as part of the Intune compliance policies.

The device threat level is an option when configuring compliance policies in Intune. You can decide which threat level is still considered compliant for your organization. For example, some organizations might be happy to allow access from devices with a Low threat level, but not from Medium or above. Other organizations will require all devices to be at a Secured level, and block any other threat level.

After you’ve made the device threat level a factor in device compliance, any conditional access policies that require device compliance will block the user from access Office 365 services from a device that has been compromised according to Windows Defender ATP. After the compromised device has been remediated, either automatically or manually, and the threat level decreases again, conditional access will begin allowing the device to access Office 365 services again.

read more
Office 365

Configuring Terms of Use for User Logins to Office 365 and Azure Active Directory


In the good old days there were organizations who were fond of throwing a message up in front of users each time they logged in to their Windows computer on the domain. The messages were typical warnings about improper use of corporate PCs, the internet, and so on.

The old approach had a few problems. First, users would largely ignore the message, and just became trained to hit the Enter key quickly to skip past it every day, because the message appears every time they log in. Also, there was no enforcement mechanism, other than saying that continuing to use the computer implied agreement with the terms of use. Nor is the agreement or disagreement with the terms of use audited in any way. Today, that’s just not good enough for organizations that truly care about ensuring that users are aware of the terms of use of their corporate computers, apps, and services.

Furthermore, in the modern cloud era users are able to login to all sorts of SaaS applications using their corporate credentials. Although some SaaS apps have their own method of displaying terms of use, a central point of management is best. Fortunately, Azure Active Directory provides that central point with Azure AD Terms of Use, which is a feature of conditional access.

Configuring terms of use in Azure AD requires you to be licensed for Azure AD Premium P1/P2, which are available as standalone licenses or bundled in the EM+S E3/E5 licenses.

You’ll find the terms of use in the conditional access section of the Azure AD portal.

You can have multiple terms of use, which are assigned to users by conditional access policies (which I’ll show you in a moment). Creating terms of use is simple, with just a few fields to fill out. The terms of use themselves are supplied in a PDF document that you must create yourself (or have your legal department create).

The option to require users to expand the terms of use means that they must display the full document before they are allowed to accept or decline it. If they don’t expand it, then they’ll receive a message similar to this.

The conditional access option for the terms of use determines whether a new conditional access policy is created for these terms. If you choose “Access to cloud apps”, an entire policy is created for all users (even admins) and all apps, with no exceptions.

Important! If you allow the terms of use to create a new conditional access policy automatically, the policy applies to all users. That includes the account that AAD Connect uses to authenticate during sync operations. This will cause AAD Connect directory synchronization to break. The solution is to add an exclusion to the conditional access policy for your Sync_* user account.

The other option is to “Create the conditional access policy later”.

If you choose that option, the terms become available as an access control in conditional access policies. Note that any terms of use will become available as an access control now matter which of the conditional access policies you chose.

It’s also possible to use the same terms of use for multiple policies, or to have multiple policies with their own unique terms of use. You can even “stack” terms of use policies such that a user will need to accept a general terms of use when they first log in to any application, and then have additional app-specific terms of use if there are additional policies that they must comply with for those apps.

For your end users the experience is mostly a good one. Logging in to any app through the browser, a desktop app, or a mobile app will present the terms of use to be accepted or declined.

What I did find was that multiple apps could simultaneously present the terms of use. Logging in to a desktop, I opened a web browser to access Outlook, and as I was reviewing the terms of use both the Teams and OneDrive apps on the desktop also popped up a login dialog with the terms of use displayed.

That could be an edge case though. Either way, once you’ve accepted the terms of use you are no longer presented with them at login. This is an improvement from the old days of the login messages that would show up every single time you logged in.

For admins or compliance staff the list of terms of use in the Azure AD portal will show the number of accept and decline results. There’s also an audit log showing a timeline of events, both administrative and end user.

All up this is a decent feature, certainly an improvement over the old way of doing things. The additional license cost stings a little, but by now it seems we just need to get used to anything even remotely resembling a compliance feature being available through premium license tiers.

read more
Office 365

Azure Active Directory Terms of Use or Conditional Access Policies Can Break Directory Synchronization


I mentioned this issue in my recent post on using Azure AD terms of use, but it’s worth another post here to share some more details.

The issue is that the terms of use policy creates a conditional access rule in Azure AD that applies to all users. That includes the service account that is used by Azure AD Connect for directory synchronization. The service account can’t accept the terms of use, so it fails to authenticate. This breaks directory synchronization.

If you’re watching your directory sync health, or if you have processes that depend on frequent directory sync, you’ll notice the broken sync fairly quickly.

Otherwise, you should receive an email alert after 24 hours to notify you that synchronization is unhealthy.

One of the troubleshooting steps I used was to run Get-ADSyncScheduler in PowerShell on the AAD Connect server itself. In the days leading up to this problem I had opened the AAD Connect configuration to check some things. This pauses the sync schedule, so my thinking was that the schedule had not been re-enabled for some reason. But instead of seeing the expected output, the following error occurred.

It was the part of the error message that says “Showing a modal dialog box or form…” that turned my thoughts towards other recent changes in the environment, namely the configuration of Azure AD terms of use. The conditional access policy that was created for my Azure AD terms of use applies to all users in the organization by default, with no exceptions. So the Azure AD Connect service account is unable to login, because it can’t view and accept the terms of use.

Adding the sync account as an exception to the conditional access policy in Azure AD immediately solved the problem.

The Get-AdSyncScheduler cmdlet now returns the expected results, and the next sync run was successful as well.



read more
1 2 3
Page 1 of 3