Connect/Okta and Identity Sync Hardening

The MGM story is still developing, but it’s a helpful reminder about the importance of hardening your identity sync processes and infrastructure. Microsoft publishes hardening guidance for Connect, but just know…it’s simple, but it’s not necessarily easy. What do I mean by that? Here are 5 areas that are commonly overlooked (PS, many of the principles are also applicable to Okta):

Note: These are all variations on a common theme, which is about how well you understand and isolate your “Tier 0” assets in traditional Active Directory (how “Tier 0” relates to the more modern Enterprise Access Model is explained here). This is what I mean by “simple, but not easy”—the concepts are simple, but implementing isolation in traditional AD after 23 years of operational bloat, third party integrations, unhelpful and insecure administrative practices, etc. makes it easier said than done. But while the challenges can be ugly, skipping over them is basically the same as not doing anything at all, from an attacker’s perspective.

What are some of these challenging areas, which often get skipped/incompletely addressed?

1. Isolating SQL: If you can own the SQL server used with Connect, you are effectively a Domain Admin. It must be isolated in the same way as Connect (including the hypervisor layer), which means you have two choices: 1.) The team that manage your Tier 0 assets manage the SQL instance too, or 2.) Your usual DBA team manage the SQL instance, but using the secure Tier 0 management practices established by the Security team (for example, requiring the use of a PAW and a Tier 0 management account). It must not be managed like “any other SQL server”, because it isn’t just any other SQL server.
2. Isolating Connect from upstream control: You don’t need to compromise the Connect server directly, if you can control any of the upstream apps which have control over it (this is a Tier 0 principle in general, not just for Connect…it applies to the DCs, federation, and SQL as well). Think about systems management tools, and other security tools which can execute code on the system. Does isolating Tier 0 systems like Connect increase administrative overhead? You bet. Is it still necessary? Absolutely.
3. Dedicated admin workstations: Arguably the most important part of your Tier 0 management process is the required use of dedicated admin workstations (we call them PAWs in Microsoft, Privileged Access Workstations). They are physically separate, hardened devices which do not have the most commonly exploited attack vectors, such as email and internet access (except by allow-list only), and use the most restrictive OS controls (Cred Guard, WDAC, no local admin access, separate cloud-only mgmt infrastructure, etc.). You should not be able to manage any Tier 0 infrastructure unless you are using one of these devices.
4. Sync and location of highly privileged accounts: Connect performs some checks to ensure highly privileged group members are not sync’d to Entra ID. But as we all know, what is considered “privileged” is contextual; often accounts and groups have been made highly privileged, based on the way an org uses them, even if they have no connection with well-known privileged groups like Domain Admins. Your most privileged human accounts (and PAWs) should not live in your traditional AD at all, they should only live in Entra ID. This removes the most common pivot-point used by attackers in hybrid attack scenarios. What can’t be moved to Entra ID is isolated using your on-prem Tier 0 isolation controls.
5. Network isolation: Connect only needs to speak to the DCs (and only a subset of them at that, depending on how you have configured your AD Sites and replication topology) and SQL (if you are using it). This means you can quite effectively isolate it at the network layer. This won’t help you if the management layer isn’t also isolated, but it is an effective control in addition to management layer isolation.
6. A bonus 6th: This is easier said than done, I get it…but the best way to avoid these issues is to move to Entra ID as your Identity Provider. Not because it fills Microsoft’s pockets (although that’s true, let’s be honest), but because it’s simply the best decision, from a risk perspective. I can say this with full sincerity, as someone who worked for years in security long before I ever joined Microsoft: it is inherently more secure, the preventative and detective controls are more effective, and most importantly: you and I both know that you cannot, no matter how hard you try, effectively isolate Tier 0 assets in traditional AD without starting over (and that isn’t realistic). But you absolutely can shift the lion’s share of your identity risk away from traditional AD, even as you burn down the legacy app landscape over time. You can start that today; you don’t have to have an answer for every legacy app scenario before you begin.