As many of us will have been reading about and hearing about in the news, online and in our feeds. Due to the situation in eastern Europe at the minute, many governments and their agencies are warning of an increase in both phishing and hacking at this time.
There are a number of measures you can employ to counter these, such as
Enable MFA
Keeping systems updated (Patching)
Using complex passwords (a password manager can help)
Staff Training (this is possibly your weakest point)
Enable phishing and email protection
If you have Microsoft (Azure), one way to help is to use Azure AD Conditional Access to block user logins by geographic location. This can add an extra layer of security to your Microsoft environment in the event one of your staff’s passwords becomes compromised.
Below we will outline a process using Microsoft Azure Active Directory and Active Directory Conditional Access that I have deployed to block access based on geographical location.
What is Conditional Access Location Blocking?
Conditional Access blocking based on location is a feature of conditional access policies where you can block a user from accessing your systems if they are attempting to log in from a country that they either do not have permission to be in or should not be in. It is also used to stop access and traffic from countries where you do not have users, or it is unusual for you to have users working from.
An example would be that you are positive that nobody in your organisation should be attempting to log in from Antarctica (yes, an actual location option) to access their emails, SharePoint, or even Teams. Once you have established that this is not one of your users, you can block these locations.
Another use that we have used is to block countries where we are getting large numbers of failed logins that we are sure are malicious attempts.
You should note that a VPN could bypass this rule if the locations are defined by IP Address. You can select GPS via the Microsoft Authenticator app (more info here)(LINK 1)
How To See Your Login Locations
It is a good idea to see first what locations your organisation has been accessed or attempted to be accessed from over a set period of time. This task is especially useful in conjunction with your HR/People Team in light of recent events. Login locations are used to determine access based on Conditional Access policies, which rely on signals from various sources about users to inform the system about the state and trustworthiness of the device or the device’s user before gaining access to the data.
We carry this out via Microsoft Sentinel on a weekly and monthly basis for a number of reasons, including Failed login attempts over a prolonged period. It can also help find configuration issues with servers, etc.
You can quickly check both successful and unsuccessful logins by using one of the built-in queries in Microsoft Sentinel (SignIn Locations). You can adapt this to pull out the users or user display names.
This can be found in Sentinel > Logs > Queries > Sign-in Locations
You can use the search bar, as I have to speed this up.
You will also need the Microsoft Country Codes, found here.
How Do They Know Where Users Are?
Below, we will highlight how to block users by location based on their IP address. Microsoft collects their IP address from the device they are logging in with. Microsoft then uses its database to resolve or match this IP address to a known location or country using IP ranges. This is not always an exact science with Microsoft, as they are known (in my experience anyway) not to be as accurate as they could be.
You can determine a user’s location by GPS. However, this requires the user to have the Microsoft Authenticator app installed on their mobile device. The app will then be used to connect to the system, initially to authenticate the user (done every 24 hours) and then silently each hour to determine the user’s GPS location.
You can find out more here
Create a Named Location with Trusted IP Address Ranges
Step 1 – Login to Azure > https://portal.azure.com/#home
Step 2 – Select Azure Active Directory Conditional Access Tab
Under Manage Section select Named locations > New Countries Location.
Creating named locations may require an Azure AD Premium P1, Azure AD Premium P2, or Microsoft 365 Business Premium license.
Step 3 – Name you new location Blocked Countries, select Countries/Regions and check any countries you wish to block.
Then Click Create
Create A Conditional Access Policy
Step 4 – Next go to Policies and select New policy.
Step 5 – Name the Policy Block Locations.
Step 6 – In Assignments select All users (you can also select specific users or groups if you wish – this may be useful for testing) that you want the policy to be applied to.
Step 7 – In Cloud apps or actions, select the specific applications for which you want the policy to apply. For example, you can require multi-factor authentication for email access within Office 365 Exchange Online while not requiring it for other types of access.
How to Exclude Users or Groups From Conditional Access
For users or certain groups who you do not want to be included in this rule, you can select the Exclude tab and enter those users or groups as needed. This can also include external users if you need to set up a policy that excludes certain user accounts from being affected. It may be a good idea to exclude yourself and another admin initially.
Step 7 – Select any cloud apps you want the policy to apply to and block access to the apps based on location. The example here uses all the Office 365 apps.
Step 8 – Select Conditions > Locations > Selected locations > Blocked Countries. (or whatever you named it earlier in the process.)
Then click Create
Step 9 – In Access controls select Block Access. Note: this rule can also be modified here to force multi-factor authentication rather than a block
Then click Enable Policy (or Report Only as below) and then Save
Once you have completed all of the steps and saved your new Conditional Access rule, your users (or anyone who gains access) will see a pop-up and be blocked from going any further.
I can decide if I like the fact that Microsoft has said in the pop up that their login was successful or not, however, this is what they will see
As always I would suggest testing this out on a small number of users in your organisation before pushing it out globally.
Please feel free to leave a comment or let us know if you know of a different way of doing this.