Every outage has its learnings…

Early May 2019, Microsoft suffered from an outage which left many customers unable to connect to Office 365 or (some) Azure services. At the root of the issue lies a faulty DNS configuration which surfaced in an effort to move DNS services in-house at Microsoft.

Whilst I’m sure that Microsoft took all necessary precautions to avoid issues, I found one thing in the Post-Incident Report (PIR) very interesting: Apparently, Microsoft did not pick up on the outage until after it was reported by customers. Guessing at why that may be is because the have a heavy inside-focused approach to monitoring.
Indeed, from an “inside”-perspective, Office 365 was working just fine. However, externally not so much. As the PIR states: Microsoft will review their monitoring configuration as a result of this outage.

So, as you can see: every outage has its learnings! Should you want to learn morning, head over to the ENow blog where I’ve written a little more on the topic.


Microsoft updates the (Intune) Outlook App Configuration Policy experience

Microsoft just released the long-anticipated update to Intune’s App Configuration experience for the Outlook (mobile) app. First announced at Ignite, the update now makes it possible to configure (parts of) the Outlook mobile client through the GUI instead of having to specify the settings manually.

At this time, the update only allows basic profile configuration (as depicted in the image below). According to the announcement, future updates will allow you to configure additional functionalities like Focused Inbox or the ability to restrict contacts from syncing to the device, etc.

To access the feature, open Intune from the Azure Portal. From there, navigate to App Configuration Policies and create a new policy:

Note: Once you have created the policy, it should automatically apply IF you have deployed the Outlook app from the Company Portal. It will not work if your users have downloaded the app themselves directly from the platform’s respective app stores.

Although, at first, this might seem like a minor update. It’s one in a series of many which make Outlook Mobile easy to manage and deploy. Given my personal preference for the app, I can only applaud this and I look forward to future updates.

Blog Office 365

Update: Estimating the size of an Exchange (online) Archive

Hi all!

A couple of years back, I created a (very basic) script to help estimating the size of an Exchange Archive by looking at the age of a message and comparing it to time periode you envision to use in the the retention/archive policy. Originally, I believe I had posted the script on my personal OneDrive, but the file since seems to have gone missing.

After a few requests, I decided to upload the file to Github for a few reasons:

  1. You can download it again.
  2. People can contribute to improve the script. As I mentioned earlier, it was a very basic script and not super efficient. Unfortunately, I lack the time to spend much time on it, but that doesn’t mean others can’t and help the community by doing so.

You can find the script here, now. (https://github.com/mvanhorenbeeck/EstimateExchangeArchiveSize)

Please note the script is provided as-is with no warranties. I suggest you test the code before trying it in production as I had to pull this source file from an old repository and it may or may not be the same version as I posted originally.

Good luck!


Blog PowerShell

Correlating events becomes easier as Microsoft adds ‘SessionID’ to the audit logs in EXO

Yesterday, Microsoft announced a new capability in Exchange Online which adds the ‘SessionID’-field to the existing audit logs in Exchange Online. Audit logs are a useful feature to go through and look at what actions have been performed on a mailbox at any given time. The events that are exposed through the Audit Logs are a great source way to correlate events and detect suspicious behavior – whether its for a legitimate user or through a potentially compromised account.

Many (security) solutions, including Microsoft’s own, use the information from the Audit Logs to correlate events and determine whether or not specific activity should be flagged as suspicious for further investigation. When such investigations happen, it’s sometimes hard to distinguish which actions of an account are safe and which ones aren’t. Consider the following example. I re-used the data from the announcement, to illustrate the point. The following data shows a series of (chronological) events, without the Session ID:

TimeStamp Action
3:42 MailboxLogin
4:35 MailboxLogin
4:45 MoveToDeleted
4:59 AddInboxRules
5:12 AddFolderPermissions
5:30 Set-Mailbox

Without more information, these actions look like something a real user would do too: authenticating to the mailbox (twice), and performing some actions like removing data and adding an Inbox rule. Unless there is a high amount of (infrequent) actions that immediately stand out from the ordinary, it is really hard for an administrator to determine whether the above data warrants further investigation or not.

Now, let’s look look at the same data with the SessionID:

TimeStamp Action Session ID
3:42 MailboxLogin bdcea574-5cfd-48b1-ab5b-d826f164da53
4:35 MailboxLogin 12bce6d0-bfeb-4a82-abe6-98ccf3196a11
4:45 MoveToDeleted bdcea574-5cfd-48b1-ab5b-d826f164da53
4:59 AddInboxRules 12bce6d0-bfeb-4a82-abe6-98ccf3196a11
5:12 AddFolderPermissions 12bce6d0-bfeb-4a82-abe6-98ccf3196a11
5:30 Set-Mailbox 12bce6d0-bfeb-4a82-abe6-98ccf3196a11

Again, the same events are visible, but we can now see that various actions have been performed in different sessions. This doesn’t necessarily point to malicious behavior. However, when different sessions are active at the same time, my attentions would be triggered more easily. Of course, the administrator will still have to verify with the user to identify the nature of the actions. But, by doing so, the admin might learn that the user did not create Inbox rules, nor did the user add any mailbox permissions.

At this point, having the SessionID has another benefit: it allows you to query the Audit Logs with the Session ID and list all actions that were performed within the same session, like shown in the table below:

00 AddInboxRules 12bce6d0-bfeb-4a82-abe6-98ccf3196a11
1:34 AddFolderPermissions 12bce6d0-bfeb-4a82-abe6-98ccf3196a11
1:42 AddFolderPermissions 12bce6d0-bfeb-4a82-abe6-98ccf3196a11
4:59 AddInboxRules 12bce6d0-bfeb-4a82-abe6-98ccf3196a11
12:34 AddFolderPermissions 12bce6d0-bfeb-4a82-abe6-98ccf3196a11
15:23 AddFolderPermissions 12bce6d0-bfeb-4a82-abe6-98ccf3196a11

Disabling/Blocking Basic Auth

This all seems good news, but what’s the caveat you might ask? As per announcement, sessions which were authenticated through Basic Auth will not have the SessionID information available because the information in only logged when modern authentication is used. Personally, I think this is great, as it is yet another reason to get rid of Basic (legacy) authentication. On the other hand, and the sad reality, is that many organizations are still using some form of legacy authentication today, not in the least through protocols like POP3 and IMAP.

Ideally, the SessionID (or similar) information would have been available for legacy auth as well. Especially because these non-modern authentication protocols do not support MFA and, hence, accounts using legacy auth are more susceptible to attacks/compromise.

Conditional Access to the rescue?

There are various ways to disable Basic Authentication in Microsoft’s online services. One way is to use Conditional Access, where you can define a set of policies that apply to different user (groups) in your organization. As such, you can be very granular as to whom you allow to use legacy auth and to what service.

Specifically for Exchange Online, you can use the recently-released Authentication Policies, where you can basically do the same, albeit just for Exchange Online.

Is auditing enabled?

To access the audit logs for a mailbox, auditing must be enabled first. Although Microsoft recently announced it would enabled mailbox audit logging for all users by default, older tenants might still have mailboxes that aren’t audited. To check whether auditing is enabling, connect to Exchange Online with PowerShell and run the following command(s). To get a list of all users and whether or not auditing is enabled, run the following command:

Get-Mailbox -ResultSize Unlimited | Select Name,AuditEnabled. 

To (re-)enable auditing, you would run the following command. More information on the process is available here.

Set-Mailbox <mailbox> -AuditEnabled $True"

Lastly, to verify if your tenant is configured to enable Mailbox Audit logging by default, run the following command:

Get-OrganizationConfig | Select AuditDisabled

Reading the audit logs

Before you get all hyped up about this feature, you must understand there are a few limitations too. First of all: to use the audit logs on a daily basis as means to improve your security monitoring and detection capabilities, you will need a mechanism (often in the form of an external tool or feature) that captures the audit events and performs an initial triage on them. This can be an external SIEM solution or – if you have the necessary licenses – Microsoft’s Cloud App Security.

Even though the audit logs can be access through PowerShell, doing so is merely effective for ad-hoc investigations in my opinion –not in the least because querying the audit logs for a large number of mailboxes can be slow. Additionally, audit logs are only kept for a (limited) amount of time. If you have E3 licenses, they are kept for 90 days. Audit logs for E5 licenses are kept for 365 days. Either way, you’ll have to take this into consideration if you have a requirement to be able to go back further in time than your current built-in retention period.

Increasing your tenant’s security

All in all, this is a small but important step towards increasing your organization’s security posture and making it increasingly more easy to detect (and thus react to) attacks. Security is an important topic and one of our core focus areas at The Collective. Feel free to reach out to us to understand how we can help you become more secure in Office 365.

Blog Identity & Security Office 365

Protecting your AD FS environment from password (spray) attacks (in an Office 365 context)

Recently, I attended the Thrive Conference in Ljubljana, Slovenia. During the IT Pro “Ask the Experts”-panel, an interesting question was raised: “How do I protect an on-premises AD FS environment from password spray attacks?”. Why is this such an interesting (and relevant) question, you may wonder? Well, over the past couple of months a lot of my customers have been targets of (organized) attacks, and I have been helping them overcome the effects of such attacks. Unfortunately, my customers are not the only ones! There is a disturbing trend, showing the number of attacks is steadily increasing, worldwide. These attacks aren’t only targeted towards large enterprises, it’s organizations of all sizes; seemingly random even.

The short answer to this question is: there isn’t ONE thing you can do solve the issue. Instead, there’s a bunch of things you could (and probably should) do. Spoiler: enabling MFA is one of them!

Before we dive into the technicalities, let’s first look at the dynamics of such attack(s). In a password spray attack, attackers use common passwords across various services (applications) to try and gain (unauthorized) access to password-protected services/content. The passwords they use are typically the so-called ‘usual suspects’ and include passwords such as “Summer2018!”, “Winter2018”, “Passw0rd” or the more ‘complex’ variant thereof “P@$$sw0rd”. I know you just chuckled, and you know why!

Unfortunately, attackers do not stop there. As more and more databases with user credentials are breached (more recently, Marriott ‘lost’ data from approx. 300 million accounts –including login data), attackers use the username/password combinations from those breaches in a similar way to try and gain unauthorized access to resources.

Because, nowadays, a lot of services are published onto the Internet, it’s almost a child’s game to target public services and be quite successful with these types of attacks. Even with a success ration of less than 1%, targeting several thousands of public applications yields enough success to make it worth their while. They are so successful because humans are creatures of habit and tend to use the same password for more than one service…

Once the attackers are in, they will use the breached account to (try) and exploit other vulnerabilities and increase privileges within the environment. Ultimately, their goal might be to steal data, encrypt contents and ask for ransom, etc.

So, now that we have that out of the way, let’s take a closer look at what you can do to harden your environment. Mind you that these recommendations are targeted primarily to Office 365, but the same principles (can) apply to other services behind AD FS as well! Note the recommendations below appear in no particular order. I did, however, add some thoughts here and there on what I believe is super useful and easy to implement. What you can (or cannot) do is up to you to determine, and in function of what applications you use, what your end user experience must look like and the buy-in from your management. The latter sometimes is the biggest challenge!

Use cloud authentication

Before diving into what you can do to enhance your AD FS infrastructure, you can also choose to replace AD FS with something else. For example, you could move to cloud-based authentication and use Azure AD accounts to authenticate to Office 365, federate with other applications, or use the Azure AD App Proxy to access on-premises applications.

Moving away from AD FS to cloud authentication moves the responsibility from dealing with these types of attacks from your own environment to Microsoft; they have the collective brain power, resources (like compute power) to intelligently detect and stop these types of attack. Although it solves the problem for you, it merely shifts the responsibility from having to deal with it yourself away.

When you move your authentication to the cloud, you can leverage additional components such as Azure AD Conditional Access. This, in turn, allows you to more intelligently perform authentication based on a set of (adaptive) rules. For example, Conditional Access can be used to not require MFA when you are using a known device from a known (trusted) location like your company network. When someone then tries to authenticate from outside the corporate network, or they aren’t using a registered device, they must perform MFA which then makes it a LOT harder for e.g. an attacker to gain access to an account –even when they have the right username/password combination…

Along the same lines, Microsoft offers Identity Protection in Azure AD. Instead of, or in addition to, defining a set of rules that will determine how authentication should be performed (Conditional Access), Identity Protection will leverage extensive AI-models to calculate a risk-score for an authentication attempt. Based on that score (low-medium-high), you can specific actions, such as denying access or requiring MFA (to prevent locking out valid users).

Telling people to replace AD FS with cloud authentication is easy. Doing so isn’t always possible, certainly not in the short term. So, let’s explore some other options.

Enable Multi-Factor Authentication

If there is one thing you should consider, it’s enabling MFA. Microsoft shared some startling numbers at their annual Ignite Conference: enabling MFA reduces the success rate of such attacks by an astonishing 99%. At the same time, they also revealed that too little organizations take advantage of MFA…

While it is an efficient way to stop password (spray) attacks from being successful, it doesn’t solve the problem caused by using passwords, or inherently the insecure way in which they are used and chosen by users. Nonetheless, MFA will render a valid username/password-combination virtually useless without the additional factor –something which is typically much harder to breach.

At the very least, you should use MFA for all your privileged accounts. These accounts can do most harm to your environment and should be well protected.

Off-topic: I know some will refer to the recent Azure MFA outage and point out that when MFA is not working, it really creates an operational problem. While this is completely true, there are few alternatives. Not turning on MFA could be far worse and will require you to keep a very close eye on the use of that account…!

Alternatively, consider keeping one or more break-glass accounts. These can be admin accounts that can be exempted from MFA using e.g. Conditional Access (e.g. require that the account can only be used from the internal network, on known devices). Having such an account will allow you to perform emergency-changes in your tenant, should such an MFA issues occur again in the future.

Turn on MFA as primary authentication

In addition to just using MFA, you can explore configuring MFA as the primary authentication method in AD FS 2016 and 2019. This doesn’t mean you can’t use passwords anymore: it can be used as the second factor after the initial MFA was successful. It means that attackers would first have to successfully perform MFA before they could attempt the username/password combination; very effective!

Use “advanced”, but built-in, AD FS capabilities

AD FS in Windows Server 2016/2019 have some features that are extremely useful. The first one is “(Extranet) Smart Lockout”. This capability will look at (un)successful authentication attempts and use the information gathered to proactively block authentication attempts from specific locations (IP addresses). The feature works in a very similar way than Azure AD’s smart lockout and is a good starting point to protect your environment.

Another feature is the “Banned IP”-list. This is a list of IPs that you can configure on your AD FS servers for which authentication attempts will be ignored. This is similar to the Smart Lockout capability, but you’ll have to configure it manually. If you leverage Azure AD Connect Health for AD FS, you can use the Risky IP report to block the IP addresses that consistently seem to be the source of unsuccessful authentication attempts and haven’t (yet) been caught by e.g. Smart Lockout.

Prevent bad passwords from being created

At the source of the problem (of password spray attacks) is the use of simple and predictable passwords. Educating users on what a good password is one thing, but do good passwords even exist? Even more so, users are notorious for not always playing by the rules…

So, better than just (blindly) trusting them, you can leverage Azure AD’s password protection in your on-premises environment. Without going into too much technical details, this feature will ensure that whenever a password change occurs in the on-premises environment, an agent will verify if the new password does not match a known bad (or banned) password and – if it does – prevent the password change, forcing the user to choose another password. Although this doesn’t solve the problem from known passwords to be used, it will – over time – ensure less simple and too obvious passwords exists in your environment. In turn, this decreases your attack surface a little bit.

Go for password-less, or just less passwords

Discussing the topic of whether getting rid of passwords is a good thing or not is worth an article by itself. Tldr; replacing passwords with something else is a good idea 😊

Today, you can already start by leveraging certificate-based authentication. This, too, is harder to compromise than passwords, but also notoriously difficult to implement (because of the management overhead for the deployment of client-side certificates etc). Because of the complexity, it’s not always a desired solution.

There are a few ways to go passwordless. One way I found to be super easy, is to use the Microsoft Authenticator app. Combining the requirement for MFA with password-less and Conditional Access is very powerful and super easy to deploy. Unfortunately, this will only work considering that 1) users must have a smart phone with the Microsoft Authenticator, and 2) they must access resources with their Azure AD account… Soon, you’ll also be able to use hardware (OAUTH) tokens instead of the authenticator app, adding (a bit) more flexibility in your options!

If you are up-to-date with your workstations (that is Windows 10, folks!) and you are using modern applications like Office 365 Pro Plus, you are in a good starting position to start adopting password-less authentication by implementing Hello for Business. Password-less is still very much something for the future, and passwords won’t disappear overnight. However, now is a great time to start planning and testing! If not, at the very least use it for a small subset of your (IT) users so you can get acquainted with it, both from a deployment and manageability perspective…


In Dutch, we have a saying: “meten is weten”. This roughly translates into “measuring is knowing”. Sounds horrible, doesn’t it? What it means though – in the context of this article – is that if you don’t measure/monitor your AD FS environment, you won’t know what’s happening or that you are under attack!

Azure AD Connect Health for AD FS is a good way to gain visibility into what’s happening in AD FS. However: what if you don’t have the licenses for it? Although there’s plenty of other (monitoring) solutions that can help you get the right information from AD FS, below I’ve included a (manual) way of using PowerShell to detect failed authentication attempts. It’s by no means a replacement for a decent monitoring solution –but it could be a starting point!

The script uses the AD FS event log information to lookup the IP information from the (failed) authentication attempts and compiles a list of countries that are generating these unsuccessful events. To retrieve the country to which an IP address belongs, the scripts uses the ipapi.com REST service. You will have to get your own API keys to perform the lookups! In the end, you can use the information from this report to proactively block specific IP addresses from the Internet. You can do this on your firewall or using the Banned IPs-feature in AD FS.

First, we’ll get the relevant events from the event logs:

#Define time frame for which to retreive events. Can be omitted.
$StartDate = "26/10/2018 19:00:00" | Get-Date
$EndDate = "27/10/2018 14:59:59" | Get-Date

#get events
$eventsFailed = Get-WinEvent -FilterHashtable @{logname='Security'; ID=1203; StartTime=$StartDate; EndTime=$EndDate} -ComputerName adfs1.domain.com
$eventsSuccess = Get-WinEvent -FilterHashtable @{logname='Security'; ID=1202; StartTime=$StartDate; EndTime=$EndDate} -ComputerName adfs1.domain.com

Next, we’re taking the events and extracting the required information from them. I am not a PowerShell-guru, so I am sure there are better ways to do this. However, below is what I could come up with in the short period I had to troubleshoot whilst an attack was going on. The customer I created this for then added a bunch of additional information (like coordinate and time stamps) afterwards.#reset variables

#reset variables
$result = @()

#Loop through results and compile the list

foreach($event in $eventsFailed){
    #workaround to get information.
    [xml]$eventXML = [xml]$Event.ToXml()
    $eventXML.Event.EventData.Data[1] | Out-File xml2.xml
    [xml]$xmlData = Get-Content .\xml2.xml
    $data = New-Object PSObject
    $ipAddress = $xmlData.AuditBase.ContextComponents.Component[3].IPAddress.Split(",")[0]

    #the clause below differentiates between internal and external IPs
    if ($ipAddress -eq "<internal IP addresses>")
        $data | Add-Member -MemberType NoteProperty -Name UserID -Value ($xmlData.AuditBase.ContextComponents.Component[0] | Select UserID).UserID
        $data | Add-Member -MemberType NoteProperty -Name IPAddress -Value $ipAddress
        $data | Add-Member -MemberType NoteProperty -Name Continent -Value "Europe"
        $data | Add-Member -MemberType NoteProperty -Name Country -Value "Belgium"
        $data | Add-Member -MemberType NoteProperty -Name City -Value "City"
        $data | Add-Member -MemberType NoteProperty -Name Region -Value "Region/Province"
        $data | Add-Member -MemberType NoteProperty -Name Lat -Value "50.9160" #latitue
        $data | Add-Member -MemberType NoteProperty -Name Long -Value "4.0402" #longitude
        $data | Add-Member -MemberType NoteProperty -Name Status -Value "Failure"
        $data | Add-Member -MemberType NoteProperty -Name TimeCreated -Value $event.TimeCreated
        $data | Add-Member -MemberType NoteProperty -Name Source -Value "Internal"
        $data | Add-Member -MemberType NoteProperty -Name Date -Value $event.TimeCreated.ToShortDateString()
        $data | Add-Member -MemberType NoteProperty -Name DateNearestHour -Value (($event.TimeCreated).AddMinutes(-(($event.TimeCreated).Minute % 60))).ToString("yyyy-MM-dd HH:mm")
        $data | Add-Member -MemberType NoteProperty -Name TimeNearestHour -Value (($event.TimeCreated).AddMinutes(-(($event.TimeCreated).Minute % 60))).ToString("HH:mm")
        #perform REST lookup to get IP information
        $ipLookup = Invoke-RestMethod -Method Get -Uri "http://api.ipapi.com/$($ipAddress)?access_key=<accessKey>"

        $data | Add-Member -MemberType NoteProperty -Name UserID -Value ($xmlData.AuditBase.ContextComponents.Component[0] | Select UserID).UserID
        $data | Add-Member -MemberType NoteProperty -Name IPAddress -Value $ipAddress
        $data | Add-Member -MemberType NoteProperty -Name Continent -Value $ipLookup.continent_name
        $data | Add-Member -MemberType NoteProperty -Name Country -Value $ipLookup.country_name
        $data | Add-Member -MemberType NoteProperty -Name City -Value $ipLookup.city
        $data | Add-Member -MemberType NoteProperty -Name Region -Value $ipLookup.region_name
        $data | Add-Member -MemberType NoteProperty -Name Lat -Value $ipLookup.latitude
        $data | Add-Member -MemberType NoteProperty -Name Long -Value $ipLookup.longitude
        $data | Add-Member -MemberType NoteProperty -Name Status -Value "Failure"
        $data | Add-Member -MemberType NoteProperty -Name TimeCreated -Value $event.TimeCreated
        $data | Add-Member -MemberType NoteProperty -Name Source -Value "External"
        $data | Add-Member -MemberType NoteProperty -Name Date -Value $event.TimeCreated.ToShortDateString()
        $data | Add-Member -MemberType NoteProperty -Name DateNearestHour -Value (($event.TimeCreated).AddMinutes(-(($event.TimeCreated).Minute % 60))).ToString("yyyy-MM-dd HH:mm")
        $data | Add-Member -MemberType NoteProperty -Name TimeNearestHour -Value (($event.TimeCreated).AddMinutes(-(($event.TimeCreated).Minute % 60))).ToString("HH:mm")


    $result += $data

#get the results. This can be changed to output to CSV, XML or anything else, really.
Write-Output $result

Note: you’ll have to turn on AD FS Audit Logs for these events to start popping up in your Security Logs!

Help! I’m under attack…!

If your monitoring shows an unusual high number of failed authentication attempts, you might be under attack. But what to do next? First, keep calm and breathe! Now is not a good time to panic. Without you, the attackers have free reign! Pulling the plug might work but it is a bit drastic. So, let’s hold off on doing that for now.

Once you’ve overcome the initial shock, try to identify what the attack vector/angle of attack is. Perhaps the suspicious activity is coming from just a few IP addresses? Good. Block those. If things take a turn for the worse, you might have to (temporarily) block external access to resources. This doesn’t necessarily mean you have to lock out your users: if they have other means to access the (internal) network such as through a VPN-connection, they would still be able to authenticate directly to the internal AD FS servers.

The challenge with the VPN-approach is that it doesn’t work for basic authentication (e.g. ActiveSync with Exchange Online). This is because with basic authentication, the authentication request(s) are initiated by Exchange Online and blocking those IP addresses will cripple access for everyone who uses basic authentication.

As such, it’s important that you try to move away from Basic Authentication as a rule of thumb anyway. In a modern world, and with modern applications, there should be no need to basic authentication. For example, Outlook and Outlook Mobile can perfectly live without it. POP3 and IMAP on the other hand, not so much…

Basic Authentication is the root of all evil. A simple username/password combination is no longer from this era. It might have been a fitting solution in the early days of computing, but that’s long past. Even complex and long passwords provide little to no value if used incorrectly, which is how most of the users use them. It’s not just because of what passwords one use, passwords themselves are because of how they are used also subject to man-in-the-middle attacks, etc… But that’s besides the point of this article. What is the point, is that you should disable basic auth when you get the chance, and there’s plenty of ways you can do it in Office 365/Azure AD:

  • Use Conditional Access to block legacy Auth
  • Use Authentication Policies in Exchange Online to block basic auth
  • Block specific protocols (such as e.g. POP3/IMAP) for specific user accounts.
  • Use AD FS Claim Rules to (selectively) block basic auth from specific locations (or users, or groups, etc.)

If you can’t block basic auth completely, limiting what accounts can use it, is already a good first step! Remember, there is no single security strategy that you can implement in a single go. As with many things, it’s something that takes time to setup correctly and get users accustomed to. It’s like a good wine: it can get better with the age. But if you wait too long, it can become bad as well!

Wrapping up

There are many countermeasures, each addressing parts of the challenge. The more of the above features and capabilities you implement or configure, the more secure your environment becomes. However, it doesn’t mean that doing all of this will make you 100% secure, as there is no such thing…

Instead, make sure that you take a holistic approach. After all, your defense is only as good as the weakest link in the chain. Having a multi-layered approach is key. Secondly, make sure to monitor your authentication traffic. If not, you’ll be flying blind and it might take you a while to figure out something bad is happening.

Over the next couple of weeks, I’ll be diving more deeply into some of the topics mentioned in this article. Until then, all there is left for me is to wish you a great end of the year!


ADFS Blog How-To's Identity & Security Office 365

Office 365 Outlook on the web (OWA): controlling “opt-in” for early versions and new experiences

Recently, Microsoft announced they are releasing the ability for users to “opt-in” for new OWA, or Outlook on the Web, experiences themselves by switching a toggle that will be made available to them in the interface.

Toggle blog.png
Image courtesy of Microsoft.

While I personally applaud the ability to try new features early, leaving it up to the users to decide whether or not to try out new features might not always be the best solution –especially if they leverage a (centralized) IT support organization which may not (yet) be able to support new capabilities (or even be aware of them). Although it wouldn’t be a huge problem per se, it might generate some unwarranted calls to the support staff…

Luckily, Microsoft learned from earlier mistakes and is providing the ability to control the presence of this toggle through the OWA Mailbox Policy assigned to the user.

My suggestion would be to update the default OWA Mailbox Policy to disable the toggle by default and create a new policy and assign it to a (small) group of test users (e.g. the ones enabled for Targeted Release) which could take advantage of the option. That way you limit the exposure in your environment and keep it available to users best suited to evaluate new experiences which will be coming to everyone else when it’s released more widely, later.

To update the OWA Mailbox Policy, connect to Exchange Online Powershell and run the following command:

Set-OwaMailboxPolicy “<OWA Mailbox Policy Name>” -OutlookBetaToggleEnabled $false

Unfortunately, there is no “OutlookBetaToggleEnabled”-parameter for the New-OwaMailboxPolicy cmdlet. Therefore, you’ll have to create a new policy, and update it afterwards should you require a separate policy for some users that would be allowed to take advantage of this feature.

Blog Office 365

Re-awarded as Microsoft MVP for 2018-2019!

Perhaps I’m a bit late to the game, but I’m happy and honored to share with you that on July 1st, I’ve been re-awarded the Microsoft MVP award in the category “Office Servers and Services”. This is my 6th consecutive time that I receive this award which is given to individuals in recognition of their contributions to the community.

Obviously, this would not have been possible without your continued support; thank you for that! Maintaining contributions to the community has not been easy in the past 1,5 years. In between writing for the 4th edition of the Office 365 for IT Pros book, I started my own business which means a lot more things to deal with! On the upside, I’ve been able to work with some brilliant people and am working on some really interesting project. A combination that is bound to create lots to talk and write about!

I look forward to another exciting year working with, and discussing, technologies like Microsoft Office 365, Azure Active Directory, Enterprise Mobility + Security and Teams. It will be especially interesting to see how the latter will continue to evolve. In the past year Microsoft Teams underwent some major improvements and continues to do so on an almost daily basis.

Last – but not least – I look forward to the different conferences that ramp up again coming September. I will be speaking at Ignite again this year and hope to join you at some other great conferences too like the Evolve Conference (formerly known as UK UC Day) and the Office 365 & SharePoint Connect in Haarlem. See you there?!