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…

Monitoring

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")
    }
    else
    { 
        #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!

-Michael

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

Microsoft releases new “Tenant Restriction” capability

A few days ago, Microsoft announced the General Availability of the “Tenant Restriction” capability. Although I have not been able to play with it so far, I wanted to take a few moments to reflect on the usefulness of the feature following a debate I had with a customer questioning me why they would be interested in something like this.

The Tenant Restriction capability, as the name already implies, allows an administrator to restrict access to a specific tenant. You might wonder how this is different from e.g. disallowing someone to authenticate by e.g. disabling their account? In the latter scenario, the user might not be able to use their account to login to e.g. Office 365, but that won’t prevent them from accessing other tenants (with other identities). From a data leakage point-of-view, the latter can be potentially dangerous. Maybe this is best explained with an example.

Let’s say a user called George works for Belgian Waffle House ltd. They have a tenant in Office 365 called “bwf.onmicrosoft.com”. George also works for a non-profit organization called the Belgian Chocolate Lovers and, they too, have a tenant in Office 365 called “bcl.onmicrosoft.com”. When no tenant restrictions have been configured, George can login to the bwf.onmicrosoft.com tenant (as he should!), but nothing would prevent him from logging in into bcl.onmicrosoft.com while at work. One might question why this is a problem, but let’s assume for a second that George first logged into the bwf.onmicrosoft.com tenant and downloaded some corporate documents. Perhaps these documents describe a new merger plan between the Belgian Waffle House and some Swiss Chocolate maker… As a Belgian chocolate lover, he might be interested in that! Either way, after downloading the document, he then logs into the bcl.onmicrosoft.com tenant and can upload the files there. The reason why he is able to login to both tenants is because the endpoint (e.g. login.microsoftonline.com) is a single endpoint for all tenants, world-wide. Blocking the endpoint (e.g. through a proxy server) would also prevent George to login into the bwf.onmicrosoft.com tenant.

Of course, there’s other ways to restrict access –but those pertain to accessing the tenant itself. For instance, an administrator can define a set of corporate IP addresses from which a user is allowed to authenticate into the corporate tenant. While this effectively prevents someone from accessing the tenant outside the corporate network, it doesn’t solve the problem described above.

The way this new Tenant Restriction capability works, is quite simple and the process isn’t really new. When a user authenticates to Azure AD (and thus a service which relies on Azure AD), the authentication platform will also look for a (HTTP) header called “Restrict-Access-To-Tenants“. The value of this header should contain all the tenants the user is allowed to access. If the tenant that the user is trying to authenticate to is listed, access is granted. If not, a warning message is displayed:

Image source: Microsoft.

A few things to reflect upon:

  • For this to work, there must be (some sort of) a proxy server between the user and the internet. Basically, anything that can add a header will do. If you want to ensure the limitation to access a tenant is maintained, e.g. also outside the corporate network, the user must always access the internet through a proxy server that injects the header. For this to work, other counter measures (such as ensuring the user cannot modify proxy settings etc.) must be present. Additionally, the proxy server must be accessible from outside the corporate network as well. One thing that would fit this requirement is a “proxy-as-a-service” such as e.g. ZScaler. But there’s others too.
  • The tenant restriction capability is not something you configure in Azure. Instead, it relies solely on your network infrastructure (proxy, ssl device, …) to inject the header. As such, the latter is quite important and you must consider the implications of doing so.
  • The feature only works with Modern Authentication. This is fine for the majority of Microsoft’s own application, but if you use other applications or even built-in ActiveSync apps, you must block access for those “legacy” apps if you want to maintain the restriction.
  • You can use the feature for free with Office 365, but have to buy a premium license if you want to restrict access to other applications relying on Azure AD for authentication.
  • The process described above only needs to be applied to the authentication process, hence thus only for the Azure AD endpoints. Users must not necessarily go through a proxy for access to e.g. SharePoint online or Exchange online.
  • Given the reliance on Modern Authentication, and because you cannot control how other tenants are setup, if those tenants still allow legacy authentication (e.g. basic auth), the restriction is bypassed (d’oh!). I hope/expect this to change in the future. However, if you also control the endpoint (and thus can control what applications can be used), it is still very effective.

As you can see, while the feature is pretty cool, it’s not 100% watertight. Perhaps that is a problem, perhaps not. It really depends on what your use case is for implementing it. However, if DLP is on your mind, every little thing can help and it can be an efficient way to stop the majority of the users of (accidentally) leaking sensitive data. Of course, it’s only a small cog in a much bigger machine as there’s many other features in Office 365 (and beyond) that can help you to prevent data leakage.

For more details, please read the announcement from Microsoft here.

 

Blog Office 365