Entra Connect servers

[chryzsh]

I'd like to discuss including Entra Connect servers as tier 0 assets. Again, its a question of known abuse paths and whether default configuration allows so.

This article claims:
"... if an organization uses Password Hash Synchronization, Entra connect has the privileges to perform a DCSync, which allows it to sync all attributes (including password hashes) from domain controllers. This means that the account that Entra uses in the on-prem AD is Domain Admin equivalent (which is why the system AD Connect is installed on should be treated as Tier 0). " - but this is from 2019 and a lot has changed since then.

Another highly regarded source recommends treating them as tier 0 assets. The same does Microsoft themselves

Here is a fairly recent PoC to GA (Tier 0) in Azure

There is another abuse path here for going to Tier 0 (Global Admin) in Azure with the sync account, assuming there is a vulnerable security principal to hijack.

What do you think?

[JonasBK]

Hey!

I think it makes sense to add Entra Connect servers as Tier 0 assets. Thanks for the suggestion :)

Feel free to submit a PR!

[chryzsh]

This one is a bit more involved than I expected, and I'm trying to find a good way to approach this for the project. Let me summarize what I've been able to piece together just now and we can discuss it.

Servers
The Entra Connect server(s) themselves are naturally Tier 0. Microsoft explicitly states that the Entra Connect server must be treated as a Tier 0 component, similar to Domain Controllers. This is documented in their official prerequisites and consistently recommended across their documentation.

Accounts
Entra Connect uses two primary service accounts that should be considered Tier 0:

• AD DS Connector Account

  • Used to read/write information to on-premises Active Directory
  • Often named MSOL_ or a custom service account
  • Has DCSync privileges (replicating directory changes) by default with Password Hash Sync
  • This effectively makes it Domain Admin / Tier 0 equivalent

• ADSync Service Account

  • Used to run the synchronization service
  • Accesses the SQL Server database
  • Often prefixed with AAD_ or can be a gMSA/sMSA
  • In a normal installation (Entra Connect on a member server) its a local account on that server only
  • In a Domain Controller installation (not recommended but possible) its created as a domain account in Active Directory

Groups
When Entra Connect is installed, four security groups are automatically created:

• ADSyncAdmins - Full administrative access to Entra Connect Sync Service Manager
• ADSyncOperators - Can execute sync operations and view statistics
• ADSyncBrowse - Permissions for user lineage information during password resets
• ADSyncPasswordSet - Permissions for password management operations

By default, these are local groups on the Entra Connect server (when installed on a member server). However, if Entra Connect is installed on a Domain Controller, these groups are created as domain groups instead.

Since these groups control services on the Entra Connect server, which is itself a Tier 0 asset, any accounts that are members of these groups have the ability to compromise a Tier 0 system. While the specific abuse paths from each individual group may vary and would require in-depth research I'd recommend treating membership in any of these groups as Tier 0, regardless of whether they're local or domain-level groups.

Let me know what you think of it all. Once we agree, we can find a way to document this. But I'm getting the feeling that something as detailed as this might not completely fit the table format. I'm eager to contribute in any way I can here.

Some references
Microsoft Docs - ADSync Security Groups
Microsoft Docs - Entra Connect Prerequisites

[chryzsh]

Hey. Wanted to follow up here. Do you think a PR for this one makes sense based on what I found?

[JonasBK]

Hey @chryzsh,

Sorry for the silence. To be fully transparent, we still intend to maintain and expand this table. We have fairly good coverage of built-in AD objects today, but we also want to add more systems - especially as BloodHound gains broader coverage through OpenGraph](https://bloodhound.specterops.io/opengraph/library).

That said, we are currently focused on several other projects, so expanding this table is still on our to-do list.

I do think your suggestion makes sense, though. Please feel free to submit a PR, and I will review it :)

[chryzsh]

Thanks! Its all good, and I am happy to hear you are still maintaining it, given that we reference this tables in reports to our clients now too. I've submitted a PR #15