Conditional Access Initial Setup
Posted by bd79user@reddit | sysadmin | View on Reddit | 20 comments
I am just starting the process of building a set of CA policies. I have enabled the standard two (block legacy and enforce phishing-resistant for admins). I am playing with restricting login to home country (aware of the various caveats and loopholes that exist and that this is only part of the overall setup).
I have set the home country as a named location. I have set up a policy that includes all locations, excludes the named location (country), and blocks.
The issue is that users cannot log in - review of the sign in logs shows that the CA policy is matching the location despite the fact the login location is correctly seen by Entra as being in the home country (i.e. to mind, it is failing to respect the exclude setting in the rule).
Am I missing something simple?
I am aware that this set up is relatively high risk of generating login failures and tickets. As an alternative, I was considering setting up a rule to block the top 10 or 20 high risk locations worldwide (does anybody take this approach, and what list do you use). Again aware the many loopholes here but still makes sense to deploy some sort of location policy as part of the setup I think.
Very grateful for any advice!
FunctionPitiful@reddit
Not sure if you already went ahead with the creation of your CA, but check out my tool to create a suite of CA in report only, and the KQL Query to actually verify what would happen before activating them:
Teuftis/ConditionalAccessBaseline-Hardened
Old_Cheesecake_2229@reddit
well, Location based conditional access is useful but fragile geo-IP isn’t reliable enough to be a primary control. We still use CA for identity hygiene, but added browser level controls ths layerx security to mitigate session hijacking and risky behavior post-auth, especially for unmanaged devices. That reduced our reliance on aggressive geo-blocking.
ItJustBorks@reddit
Geoblock is borderline useless as it's trivial for an attacker to circumvent. Most all attacks originate from datacenter, VPN and proxy service providers.
If you want to restrict logins based on IP addresses, block logins outside of your company endpoints. If that's not feasible, you can block and harden logins with risk policies.
Compliance requirement is what you should be doing.
bd79user@reddit (OP)
Yes - it seems an extremely limited intervention, but still generall suggested in guides. Is it the case that many setups just don't bother with this element?
ItJustBorks@reddit
It's a noob trap. It might seem like a decent policy on the surface level for people who haven't dealt with security breaches that much. The attacker will just change their IP address seconds later.
KING_of_Trainers69@reddit
Conversely I've had this policy block a genuine breach. Yes they 100% could have just VPNed to another country to get around the restriction but they didn't and it kept them locked out for long enough to reset password/etc.
tmontney@reddit
If done in isolation. Do it in conjunction with other measures, it's a no-brainer.
If they have access to a VPN or some compromised machine in-country. You won't know either way how many attacks geo-filtering truly stopped or hampered. But if you have a solid platform that gets geo-detection right and you have a small country allow list, why not?
Security by obscurity is security but are highly dependent on what that obscurity is and the situation. Security must be done in layers, and obscurity is quite valid as a layer.
GhostNode@reddit
I Don’t disagree at all from a practical security perspective, but it’s a nice milkbone to get thrown your way when an exec travels to Thailand and can’t log in, and you can be like “that’s right, sir, we’re Secure!”
wikiwaldron@reddit
This makes sense for a targeted attack but most MiTMs are low effort phishing attempts parsed through some sort of VPS with Evilginx (or equivalent) setup and they don't actually jump to a localised IP until they've already scraped the session token. Geoblocking is easy to circumvent but the act of geoblocking sites outside the country of origin will limit the initial attack vector for an initial low effort automated attack. If someone is targeting your company specifically then all bets are off but it's more likely someone will be casting the net wide and geoblocking will prevent it in that instance.
ItJustBorks@reddit
The common automated attacks aren't that crude.
wikiwaldron@reddit
I'm not in security so there may be other methods I'm unaware of but I dealt with one a year ago and the entra id logs showed that it was in fact that crude.
tmontney@reddit
Meaning you checked a particular sign-in failure in the Azure portal, sections "Authentication details" and "Conditional Access"? Those combined should tell you what blocked it. Can you post your CA policy?
In addition, you probably would've wanted to set the CA policy in report-only. Insights and reporting will help you determine if there are any failures. Of course, you have to set it up and funnel logs there. It's not free but unless you have a ton of users, the cost should be pennies a month. I have instructions if you want them.
And other comments here would have you believe geo-filtering is security by obscurity (and that obscurity is bad). I don't believe either, so long as you have other layers and geo-filtering isn't causing you a ton of disruption (whether a very diverse workforce or a bad platform incorrectly detecting locations).
Bright_Arm8782@reddit
Whatever you do, run it in audit mode for a week or two before going live.
kubrador@reddit
conditional access location matching is notoriously buggy with excludes, microsoft basically admitted it years ago and never really fixed it. try inverting the logic insteadcreate a policy that includes only your home country and applies your allow condition, rather than trying to exclude everything else.
as for blocking high-risk countries, everyone does it but honestly it's security theater unless you're actually getting compromised from those regions. you'll spend more time on false positives than actual attacks.
bd79user@reddit (OP)
This is my read of the situation and it's really helpful to have it endorsed independently by another person - thank you!
fanofreddit-@reddit
These are good starts
https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-policy-common?tabs=secure-foundation
https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access
bd79user@reddit (OP)
Thank you - yes going through, along with a few other guides recommended in other posts here. I guess I was wondering if there is a well known reason (or known bug/limitation) why the policy I set up above is firing (or rather mis-firing as far as I can tell) the way it is.
ccatlett1984@reddit
Before you start playing with CA policies. Create a Break-Glass admin account, and exclude it from all CA policies.
bd79user@reddit (OP)
Thank you! Yes already done.
Call_Me_Papa_Bill@reddit
Beat me to it! 🙂