close

Office 365

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 https://outlook.office365.com/owa to https://outlook.office365.com.eu.cas.ms/owa (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

Office-Apps-Chrome-OS-Collage-WinBuzzer-696×522

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

New-to-Microsoft-365-in-December-2-696×489

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

Office365_Logo

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

word-about-1024×677

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

download

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

download

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

download

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
Office 365

A Look at Azure Advanced Threat Protection (Azure ATP)

download

In this article I’m going to take a look at Azure Advanced Threat Protection, or Azure ATP for short. Microsoft has several security products in the Advanced Threat Protection (ATP) family. In previous articles I’ve looked at Office 365 ATP and Windows Defender ATP.

Azure ATP is the cloud-based version of Advanced Threat Analytics (ATA). ATA is an on-premises product. Deploying ATA involves installing an ATA server in your environment. Azure ATP is cloud-based, and requires no additional on-premises servers. You can use Azure ATP today if you have Enterprise Mobility + Security E5 licenses, or by signing up for a trial.

The Role of Azure ATP

Azure ATP is designed for hybrid environments – customers who are using Office 365, but still have on-premises Active Directory infrastructure in place. Azure ATP detects and alerts you to suspicious activity in your on-premises Active Directory environment. As a post-breach alerting system, the assumption here is that an attacker has already gained access to your environment.

Microsoft describes a concept they call the cyber-attack kill chain, based on a military model that seems to trace back to Lockheed Martin. For Azure ATP, Microsoft focuses on three phases of the cyber kill chain.

The first is reconnaissance. This is the phase where an attacker gathers information about your environment. Azure ATP detects suspicious activity on the network and against your domain controllers. Examples of suspicious activity that may be attackers performing reconnaissance includes attempts to perform zone transfers from your DNS servers, or attempts to enumerate the membership of Active Directory groups.

The next phase is the lateral movement phase. This is where an attacker tries to spread out through your network, gaining access to other hosts or other sets of login credentials.

The third phase is the persistence phase, or what Microsoft calls “domain dominance”. This is where an attacker has gathered enough information to gain control of your environment. They can give themselves access to your network for future attacks, such as by creating admin accounts or installing remote access tools on a host.

According to Microsoft, each of those phases are similar and predictable. Clever attackers can compromise a workstation or a server, completely undetected by traditional antivirus products. But their reconnaissance, lateral movement, and persistence activity can be detected due to recognizable patterns.

How Azure ATP is Installed

Azure ATP uses data from sensors, known as Azure ATP Sensors, that are installed on your domain controllers. The ATP sensors monitor the domain controller network traffic for signs of malicious activity, as well as other security risks such as connections made with weak or insecure protocols. The ATP sensor automatically monitors the event logs of the domain controllers as well, and watches for suspicious activity against sensitive accounts (any accounts that are members of high privilege groups such as Domain Admins).

If you don’t want to deploy the Azure ATP Sensor directly on your domain controllers, you can instead deploy the Azure ATP Standalone Sensor on a separate server. The standalone sensor monitors traffic that you direct to it by using port mirroring on your network switches.

You can also use RADIUS account from your VPN server, syslog information from security servers, and Windows Event Forwarding from domain controllers, so that the Azure ATP Sensor or Standalone Sensor has full visibility of your network activity.

Getting Started with Azure ATP

Azure Advanced Threat Protection can be found in the Admin centerssection of the main Office 365 admin portal, or by visiting portal.atp.azure.com.

Azure ATP uses a concept of workspaces. A workspace is associated with a single on-premises Active Directory forest. Right now there is a limit of two workspaces per tenant. When you create a new workspace, it gets a name, and then you can choose whether to make it the primary workspace. The primary workspace is the one that you can integrate with Windows Defender ATP. If you have a single Azure ATP workspace then obviously you will just make that one the primary anyway. You also need to choose the geographic location for your Azure ATP data to be stored.

Azure ATP workspaces
Azure ATP workspaces

During setup of Azure ATP you must nominate a service account that can read from Active Directory. Just a regular user account is fine, no special admin rights are needed. If you’ve got your Active Directory organizational units locked down in a way that would prevent a regular user from reading them, you may need to do some delegation for this service account. It’s also recommended that the service account has read permissions to the Deleted Objects container of your Active Directory forest, so that it can detect bulk deletions.

Azure ATP service account configuration
Service account configuration for Azure ATP

To deploy the sensors, download the install package from the Azure ATP portal. You can use a software deployment tool to roll it out to your domain controllers, or just install it manually if you only have a few DCs in your environment. The access key displayed in the portal is used for initial registration of the sensors. They will then use certificates for ongoing authentication.

Azure ATP sensor deployment
Downloading Azure ATP sensor deployment package

After deploying the sensors there are some further configurations that you can perform. The Windows Defender ATP integration is useful, because it allows you to correlate device threat levels (e.g. suspicious code running on a workstation) with suspicious network traffic (e.g. an attacker performing reconnaissance). Entity tags allow you to specify honeytoken accounts, which are dummy accounts that should never show any login or network activity. If Azure ATP sees activity on those accounts, it is a strong signal of a likely attack in progress. Similarly, you can specify sensitive accounts and groups, such as the CEO’s account or any other high risk individual. These are different to the sensitive accounts such as members of Domain Admins, which are already given special attention by Azure ATP.

Azure ATP entity tags configuration
Configuring entity tags in Azure ATP

No monitoring system is perfect, so you can also configure exclusions for any false positives that appear in your network. One of the first false positives you should see is triggered by Azure AD Connect, which performs activity that ATP considers “malicious replication of directory services”. It is recommended to add the Azure AD Connect server to the exclusions list for that type of activity. Similarly, if you have a security monitoring system that performs scans of your environment then you should exclude that system’s IP address to prevent false positives.

Azure Advanced Threat Protection also has email reports and notifications. The reports are useful for regular reviews, and I recommend you configure them to go to somebody who will actually look at them and take action on any issues. You can also manually run the reports as needed.

Azure ATP scheduled reports
Scheduling email reports in Azure ATP

The notifications are for real-time alerting, and I recommend you send those directly to your ticketing system so that support tickets can be raised at the appropriate priority and alerts can be sent out via email, txt message, pager, etc to the individuals who need to respond.

Azure ATP notifications
Configuring email alerts in Azure ATP

Investigating Azure ATP Alerts

Azure Advanced Threat Protection will display a timeline of events prioritized according to the level of risk that they represent. In the screenshot below you can see an example of the false positive triggered by Azure AD Connect sync activity, as well as two reconnaissance alerts.

Azure ATP alert timeline
Azure ATP alert timeline

Looking closer at the DNS reconnaissance alert, we can see the details of the machine involved, which sensor detected the suspicious activity, and also a link to more information about what this type of activity might represent.

Azure ATP alert details
Azure ATP alert details

We can then drill down to the machine itself, which is W10PC4 in this example, and see a complete timeline of authentication and network activity that the ATP sensors have recorded as originating from this computer. In the screenshot below we can see an attempt to login with a non-exist “localadmin” account, and two reconnaissance events. There are also two attempts to enumerate users and groups in the domain (these would normally be alerts, but ATP was still in learning mode at this point), and then an admin account used to connect to a domain controller over RDP.

Azure ATP machine timeline
Azure ATP machine timeline

As you look at the above screenshot keep in mind that none of that activity would be detected by typical antivirus software. Without Azure ATP in this environment, an attacker would be free to perform reconnaissance, attempt credential elevation, and basically spend as much time as they need to gain control of the environment. But with Azure ATP in place, the very first stages of the attack are immediately detected and alerted.

The activity shown above was created by me during Azure ATP testing, following Microsoft’s ATA Suspicious Activity Playbook, which walks you through a complete attack scenario. When you deploy Azure ATP to a production environment, it’s quite possible that you’ll see other alerts for things like passwords in clear text, weak protocols, and other security risks. All of this intelligence that you gather from Azure ATP will help you to strengthen the security of your environment, and provide you with better monitoring in the future.

Summary

Azure Advanced Threat Protection provides monitoring and alerting for suspicious activity in your on-premises Active Directory environment. As a cloud-hosted service with a minimal on-premises in the form of sensors, deploying Azure ATP is fast and simple. In a small to mid-size environment, you can be up and running in just a few hours, with the bulk of the work being the sensor deployment to your DCs. If you’re already licensed for Azure ATP, I recommend you deploy it in your environment. If you’re not already licensed, sign up for an EM+S E5 trial and give Azure ATP a test run.

read more
1 2 3
Page 1 of 3